What this study goes quite a long way to showing is that people tend to think women are worse than men *even at very basic arithmetical tasks which we already know both sexes are in fact equally good at*. The implication being that if the bias extends that far, it seems much more likely it's not actually based on 'inconvenient truths' about real performance.
The reason for this is given right in the article: it's a task already known to be performed equally well by both men and women, so the test runners don't have to try and compensate for a difference in actual performance, which would make things way more complex.
If you follow the logic of the test, the significant issue is not whether it's really math, but whether it's *perceived* as math by those acting as hiring managers in the test. I think it's reasonable to conclude that it is. Or do you think the conclusion of the test is valid strictly for simple arithmetic - people have a strong unfounded bias that women are worse than men at arithmetic - but not valid for more complex math? Do you really think it's likely people are biased against women when it comes to arithmetic but not to complex math?
Also, note this salient part from the ticket comment:
"Export rules are very hard and very complicated (and they change from time to time)."
Red Hat has a very solid legal department. When serious legal issues crop up in relation to Fedora, Fedora goes and asks RH legal (which talks to SFLC, FSF, and other major bodies' legal teams when appropriate, of course). The advice we get back, we stick to.
In other words: we take legal advice from professional lawyers, not from Slashdot comments, folks.
This isn't really a policy.
The specific case arose, FESCo asked Fedora Legal for it, Fedora Legal asked for expert opinion from Red Hat's lawyers, and the guidance that came back was posted to the FESCo ticket and meeting log. That's it. It's a case where a general project committee asked for expert legal guidance.
You can read basically the entire thing happening at https://fedorahosted.org/fesco... .
Food Scientists: OK, you guys, we admit it, we really don't have a freaking clue. Sorry. Just go eat whatever seems sensible.
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.
"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).
"Little else matters than to write good code." -- Karl Lehenbauer
