From TFA you cite:

"However, installing Java and loading and running the Java applet can be annoying. So in 2006, Hushmail began offering a service more akin to traditional web mail. Users connect to the service via a SSL (https://) connection and Hushmail runs the Encryption Engine on their side. Users then tell the server-side engine what the right passphrase is and all the messages in the account can then be read as they would in any other web-based email account.

The rub of that option is that Hushmail has — even if only for a brief moment — a copy of your passphrase. As they disclose in the technical comparison of the two options, this means that an attacker with access to Hushmail’s servers can get at the passphrase and thus all of the messages."

Hushmail was aware of the weakness of the server-side option and explicitly told its customers about it. These customers, foolishly given what they were doing, accepted that.

Lastpass doesn't have the same problem; you don't need anything messy to do the client-side encryption and decryption. There is no server-side 'option' for Lastpass, nor would anyone have a reason to use it if there was one, really.

They can't, because they don't have them. They have a bunch of encrypted blobs.

Note: this is basically the same story as http://linux.slashdot.org/stor... . The source is datelined February 10, 2014 , but starts "On Jan. 7, Karanbir Singh, project lead on CentOS, announced to his community that he and a handful of other core CentOS developers would now be employed full-time by Red Hat." (emphasis mine). The hiring isn't a new thing, it was announced at the time of the whole CentOS announcement (and actually happened, er, considerably earlier, AIUI).

Are you sure your problem is the server and not the client? You keep saying the server 'doesn't show' your video files, but are you sure the problem isn't that your client box is not capable of playing them? Many of those boxes have fairly limited format compatibility.

I've been through various HTPC setups over the years, and the one I'm happy with is a PC - I use a Zotac Zbox, but you can buy a lot of similar HTPC-type boxes that will be fine for the job - running OpenELEC, a special-purpose Linux distro which is basically a very light framework for running XBMC. I don't use a 'media server' at all, I just have a NAS which shares the files via CIFS (always seems to work better for this purpose than NFS, for some reason). I've tried various streaming boxes, including a Popcorn Hour when that was the flavour of the month and supposed to play any format imaginable and work with subtitles and so on, and they all had some kind of problem which made them a PITA. It may be old-skool and 'unelegant', but a PC running XBMC is still the most versatile 'media player' box I've found.

The Kodak/Instagram comparison jumped out at me, because I wrote a letter to The Guardian when it printed it half a year ago.

It's a silly comparison. Instagram only directly employed 13 people because it did very little work itself. Any small startup can only be small because it can outsource huge piles of its work by using content storage services, content distribution services, buying in (or using open source for) large chunks of its software, etc etc.

It'd be more reasonable to pull out some kind of number of all the people employed at Amazon and Rackspace and Red Hat and all the other companies that provide services to the 'rock star startups' and add that to the number of people they employ directly.

"Within a day or two they sent back a custom patched kernel that fixed the issue, and later rolled that fix out generally in the next update release (though, admittedly, that second part took quite some time)"

There are, as you can probably imagine, a hell of a lot of hoops a patch has to jump through before it lands in a stable RHEL kernel update =)

"The question is, how will RH help Centos? That isn't very clear from this announcement. "

It does mention that we (RH) have hired the core CentOS devs - that is, we're giving them a paycheck to work on CentOS full time, we're not hiring them to do other stuff instead. And it mentions that RH has offered CentOS some resources to improve their build infrastructure, though CentOS is still deciding whether to take that offer up or not.

"While I love the ideas behind systemd, and it undeniably works very well (it wouldn't have been adopted otherwise), it does have it's disadvantages. One of the most important ones is it is Linux-exclusive, which means that any distribution and any software that wants to be available for other platforms, simply cannot use it. That is the case, for example, for Debian."

That doesn't appear to be correct. Debian is currently actively considering a switch to systemd, which I don't think it'd be wasting time on if it couldn't use it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

"Are where you will find syslogd and init scripts. Get away from your wibbly-wobbly daemony-waemony way of doing things"

You do know the 'd' in syslogd is short for 'daemon', right?

"Anyone know when RHEL7 is out?"

Whenever it's coming out, it has systemd and journald. Have you actually tried using them and read up on why we think they're better?

19 had MATE and Sugar spins too. We didn't change the spins loadout for F20 at all (well, I think we dropped some that no-one tsted any more).

We've been working on making non-stable Fedoras more manageable for day-to-day usage lately, with pretty good results. I'm on Rawhide (F21) already and it works fine, nothing is exploding. It's fairly feasible to run Rawhide day-to-day for an experienced user, these days - nirik (Kevin Fenzi) runs rawhide full-time, updated daily, on one of his workstations, and blogs about it at http://www.scrye.com/wordpress/nirik/category/rawhide/ (as a part of the 'make rawhide suck less' efforts, a kind of long-term public record of how it's going).

These days I usually bump to N+1 the day N comes out, run it till it's released, bump again.

I don't know if anyone's tested it recently. It may work with fedup. 'use software RAID' is a misleadingly vague statement of the problem, though; IIRC it was only ever broken if you *have /boot on RAID*, which is rather different from just 'using RAID'.

I don't think the 'nice' support in anaconda actually got done (or if it did, I missed the memo) so yeah, it probably is still that hard. Sorry.

We (Fedora) didn't write anything comparing the way we provide desktops to how Ubuntu does it. That's something the person who submitted the story wrote. It's not a comparison we'd find particularly interesting, I don't think.

"Might as well ask why we're not talking about Mandriva anymore... (or is that openMandriva now? or Mageia? I get so confused..)"

All of the above. Plus Rosa.