There is a TED talk about it,
https://www.ted.com/talks/fei_...

Quite interesting.

Can you explain that a bit further? I use Mendeley daily and am fairly happy with it, minus a feature here or there. For that matter, I don't understand what this article is on about. Yes, they were purchased by Elsevier. No, it hasn't affected their service. In fact, a few things, like the tablet client, are much better than they used to be.

And yet, to publish in a, not necessarily equally ranked, open access journal can cost up to ten times as much in publishing fees.

You are missing the point. The traffic for Comcast will always be less bidirectional than for a transit provider, because they are a last-mile provider. In other words, the majority of traffic entering Comcast's network is for delivery to its customers, not transit to another network. This has always been true and has not changed because of Netflix.

Nonsense. If this were about a few thousand dollars worth of hardware upgrades, it could have been settled a long time ago in a number of different ways,
    1) Comcast and Cogent renegotiate their peering arrangement. This doesn't happen because the peering arrangement actually works fine. Cogent can definitely pass the costs of a new peering arrangement back up to Netflix. This hasn't happened.
    2) Level 3 offers to buy Comcast routers for their congested points. This has happened. Comcast refused.
    3) Netflix offers to host a CDN within Comcast's network, paying all the costs of maintaining and running that CDN. This has happened. Comcast refused.
    4) Comcast asks its customers to pay more for the extra bandwidth they are using. This hasn't happened.

Instead, Comcast went with,
    5) Let the service degrade to such a point that Netflix has no other option but to pay their extortion fee.

Don't be fooled. Comcast knows exactly what they are doing. They don't want Netflix competing with their cable and video-on-demand services, that they sell to the same customers that also buy their ISP service. They want a cut of Netflix's profits, the same way a traditional cable delivery arrangement is made with other content providers.

This article breaks it down pretty well,
http://qz.com/256586/the-insid...

Pay attention to the figure at the end. After Netflix started paying, quality returned to 720p within one week. There are no hardware issues here. Comcast flips a switch and it is done.

You are missing the point again. Comcast is a cable company. It makes money selling cable channels and service to its customers. Those same customers also buy ISP service. Comcast has seen demand for cable decrease as online video has become more popular: Hulu, Netflix, Amazon, Apple, etc. This is a problem for Comcast because it makes a lot more money, and has a much stronger negotiating position, with its cable services than its ISP service. It doesn't want to lose the control it has over content providers on its cable service to "the Internet".

Verizon, not being a traditional cable company, does want to sell their own video-on-demand service. So it makes complete sense that they would be in the same boat as Comcast. As soon as there is precedence for differential agreements on content, every ISP will want a piece of the action. Don't think Comcast will be the only one trying to get a piece of Netflix.

Sure, as soon as there is another one in my area (not seeing that happen any time soon). Would also have to move from my apartment, because they helpfully buy Suddenlink for us and charge us extra rent for that.

Yes, it is, you just don't see it. This is about Internet services competing with cable services. Comcast can't block Netflix (it is too big and Netflix is too obvious a target), but it can put pressure on Netflix to pay up.

Ok, but nobody is talking about that in this thread. They are just saying "government=bad because its government".

Well, I wasn't replying to you, but since you bring it up:
    1) True, not talking about this.
    2) Maybe true in a few areas, but mostly not true.
    3) True, but this isn't the real problem.
    4) Yes, but it must treat all services as a class (ie: "streaming video", not "Hulu is ok, but Netflix has to pay"). Nobody is saying Comcast can't use QoS on their network.
    5) True, but monopoly status is an issue that is hard to get rid of and beyond the scope of the FCC anyway. What the FCC can do is classify ISPs as common-carriers. It helps because it forces ISPs to be "dumb pipes", so that conflicts-of-profit don't affect their service decisions.

I don't doubt that there are better, more complete, solutions to be had. Possibly breaking up Comcast into separate cable and ISP divisions. But this isn't forthcoming. It wasn't anywhere on the radar of our Congress or the justice department to deal with monopolies or net neutrality. In fact, the only reason the Time Warner merger must pass public review and will hopefully be blocked is because of the FCC. Until we can get other people to pay attention to these issues, I'm in support of the FCC's band-aid. I think it is a decent stop-gap measure.

Uh, no. Netflix, in case you didn't know, is a company, and (non-ISP) companies, much like individuals, purchase internet access from ISPs. Netflix purchased internet access from many upstream providers including Cogent, Level 3, and some CDNs (as well as investing in their own CDN, btw). Peering arrangements are not between companies like Netflix and Comcast. Peering arrangements are between ISPs. That's the first point.

The second point is that Comcast is not a transit provider. It is a last-mile provider. It will, by definition, have an asymmetrical flow of traffic. This is very much a part of the peering arrangements between Cogent et al. and Comcast. It is not a new change brought on by Netflix.

This is not about peering arrangements. This is about cable companies. Comcast, in addition to being an ISP, sells cable service. It gets revenue from any content delivered to its subscribers. This market is threatened by Netflix, and so Comcast wants to impose cable-like business arrangements on Netflix, which it sees as a content-provider. If you can't see how this is in opposition to the underlying principles of the internet, you are a fool. As soon as Comcast did it, Verizon had a go too. It wasn't going to take long for all of the last-mile networks to try to turn themselves into cable companies.

In other news, if you are anywhere near Texas, you would know about the contract dispute between Suddenlink (cable company) and Viacom ( the parent company of Comedy Central and some other channels). Suddenlink was (is) not delivering Comedy Central to its customers. But Suddenlink the ISP knows that its customers can stream Comedy Central from the web, so it is intentionally blocking access to streaming from www.cc.com. In other words, Suddenlink is degrading its ISP service as leverage for negotiations with its cable service. You may say this is an antitrust case, and I may agree. But net neutrality probably solves the problem more efficiently.

Net neutrality may not be perfect in every way. But to say that there are no problems out there that need to be addressed is just ignorant and head-in-the-sand.

I suppose by "nobody" you mean "everybody except nvidia"? Because the nvidia binary blobs are pretty much the only drivers that occasionally have problems with kernel updates due to the way they really mess around deep into the kernel (ie: they implement their own drm code and X api). With Nouveau finally starting to mature, this is thankfully becoming less and less of a problem. But pretty much every other driver (proprietary or otherwise) seems to work just fine with the linux driver model.

So, are you saying that over the life time of your system (what is that, say 6-7 yrs?), you never update the drivers? What do you think a service pack is? Nevermind. Anyway, it doesn't matter because you are wrong. SP2 broke a lot of XP drivers (and software for that matter), including the nvidia driver. Yes, you can now download an updated nvidia driver that works, but at the time of the SP2 release the old nvidia driver did not work on SP2.

You can, actually. You have to book your flights through a service ( ex. Orbitz, Kayak) instead of the airline itself, but there are ways to do exactly what the GP wants to do. I've done it.

Volume shadow copy is a feature of Samba, not FreeNAS specifically. So, yes, you can use it with NAS4Free.

Meh, I played around with FreeNAS for a while. I originally thought it was neat, but I kept having problems with it and eventually realized that it was easier to just set everything up myself. The GUI didn't offer that much in the way of ease of use. A short list of my observations.

1) FreeNAS makes it dead easy to set up ZFS...but ZFS is actually pretty easy to setup on its own. Easier than RAID/LVM by far. So no huge gain there, in my opinion.

2) FreeNAS makes it so you don't really have to learn the ins and outs of FreeBSD, but zfsonlinux is fairly mature and works well, so not a big deal for me.

3) This may be my linux bias showing, but FreeNAS is limited by the capabilities of FreeBSD. Hardware support is the biggest one (controllers, nics, etc). For example, plenty of Dell hardware won't work optimally. Also, what the fuck did they do the PAM? Lots of functionality missing (kerberos password changing, mkhomedir, etc). The version of SCP seems to come from a stone age that doesn't know about directory recursion. Just lots of little things that really annoyed me. No NFSv4 support. Seriously, this is like 10 yrs old now, and you still can't authenticate NFS users over Kerberos if you are using FreeNAS. Maybe it is fixed in this version, but not in 9.2.

4) Some aspects of the UI were nice (ex: being able to easily to see appropriate ZFS flags) and other not so nice (ex: the snapshot interface). Yes, FreeNAS supports the ability to replicate ZFS, but this requires a cumbersome setup that even involves saving your ssh private key into the UI (maybe they have changed this since then). It's easier to just set this up in a cron job on your own, in my opinion.

5) FreeNAS makes some things very easy, but if you need to do anything differently, it's a pain to work around the UI. The settings are saved in a special database that writes config files on the fly, so you have to know what to edit to make a change. I spent a lot of time making FreeNAS talk to our domain controller and enumerate groups correctly, because the UI had a generic way that didn't work with our schema and there was no way to just change the necessary settings.

Bottom line: if you want to get a quick NAS running to use as a media server, FreeNAS works pretty well. But if you have special hardware or integration needs, you can probably achieve everything you need much easier by just configuring everything by hand.

1. Doing away with journald requires a replacement, because it is functionality needed by systemd. No suitable replacement exists. Therefore, it can't be replaced. Why is this so hard to understand? It has nothing to do with being modular or not. Just because syslogd is a logging daemon and journald is a logging daemon doesn't mean the two are interchangeable. If that was a requirement for modularity, we would never be able to develop new interfaces. The syslog API was developed in the 1980s. At some point, the systemd developers decided they couldn't do everything they needed through the syslog API alone, so they developed a new API and journald to go with it. So yes, it is modular, but no you can't replace it because no suitable alternative exists. If you need further elaboration, consider the Unix userspace before multiple syslogd daemons were available. There was the syslog API, but only one syslogd daemon. Since you can't run a functional system without logging, this effectively required you to use syslogd. Does that mean syslog/syslogd was not a modular system until rsyslog and syslog-ng came out? No, of course not.

2. I see you make no effort to elaborate your argument beyond saying "no, you are wrong." The reason for lack of alternatives is that nobody has developed them. I stand by that statement. However, there is starting to be some movement on that front, with efforts by the BSD folks, for example, to port the logind functionality over to BSD so that software that depends on it can use it. Likewise, if you wanted to write a logging daemon that provides the functionality that systemd needs without, for example, using a binary file format, you could do that and I am sure you would have no problem replacing journald with it.

The original point of this thread was that the 69+ individual binaries that systemd builds was an example of being monolithic, with claims by various people that you are forced to use all of them and none of them can be replaced. That is false, and that is the origin of my statement above. Journald cannot be disabled with a compile-time switch, unlike the others. Strictly speaking, this does not mean it is monolithic. Journald communicates with the rest of systemd via well-defined, albeit some in a state of flux, APIs (that is the definition of modular, in case you were wondering). The reason why the developers have not made journald optional is because no currently available syslog variant can replace the functionality of journald, so why bother? Since systemd needs something like journald to function, and journald is currently the only available option, make it a hard dependency. Maintaining backwards compatibility with syslog is not a requirement for modularity.

Glad to hear it.

Why does it matter? Journald cannot be separated from systemd because it draws on many features to gather the information it needs, such as to verify timestamp and authenticity, for example. Systemd is dependent on journald because it needs a logging facility that provides information (indexed and organized by process) in a way that no other logging facility currently does. So yes, this is monolithic because they can't be separated. One might ask if they could in principle be separated. Maybe. It depends at least somewhat on the rational for doing so.

With respect to syslogd, journald communicates all logging information to any external logging daemon via a socket and a well-defined interface. It also gathers logging information from userspace processes via the syslog API. So by definition, journald is modular in this sense (it communicates with other processes via well-defined interfaces). The fact that journald must relay logging information to syslogd is a consequence of listening directly to /dev/log, which prohibits syslogd from doing so. Is this bad? It depends on your perspective.

You don't lose that ability. Why do you think that? The bug report that you linked to is about a different issue.