"So really the article is bogus as they are two different things"
Nope, your understanding is bogus.
It's not important whether the test is technically math or arithmetic: what's important is whether *those being studied* consider it to be math. Follow it through. The test demonstrates quite strongly that both women and men acting as 'hiring managers' tend to believe men will be better than women at this arithmetical task, even though it is known that in fact the two perform equally. (This is why the test designers chose the simple arithmetical task: because we know that *in truth*, women and men do it equally well).
The key question is this: do you really think they'd be biased when they assess the ability of men and women to perform a simple arithmetical task, but *not* be biased when assessing their ability to perform a complex mathematical one? Unless you truly think the answer to that question is 'yes', which seems unlikely, then no, you haven't invalidated the test. If anything, I'd have expected that perhaps people wouldn't be biased against women when it came to something this simple (i.e. that if anything, the test had a chance of coming up 'negative' even though the bias does exist). The fact that people displayed such a strong bias *even when the task in question is very simple arithmetic which we know the sexes actually perform equally well*, if anything, makes the study more compelling.
"I could be that PERHAPS there IS a difference in some math skill between males and females?"
The test under discussion was specifically designed to use a 'mathematical' task that it is already established women and men perform equally well at. As the article states.
RTFA: this specific factor is mentioned, and was compensated for by giving different 'hiring managers' different levels of information about the applicant. Some got just a picture of the applicant. Some got a self-assessment by the applicant of how they thought they'd do on the test (and the authors note that, indeed, men tended to give over-optimistic self-assessments, and women over-pessimistic ones). Some got the applicants' actual results.
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.;)
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.
"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.
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.
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).
Re:Still with FC18 and probably swtich distro
on
Fedora 20 Released
·
· Score: 1
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'.
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.
Slashdot Mirror
From summary (and presumably TFA):
"one of the most terrible sins on Wikipedia is to edit articles for pay, or otherwise violate the 'neutral point of view' policy"
but...that's not what NPOV is about. NPOV isn't a conflict-of-interest policy. It doesn't say anything about editing articles for pay.
The video that forms part of a series from these lunatics?
http://www.mgtow.com/
Yeah, i'll pass.
"So really the article is bogus as they are two different things"
Nope, your understanding is bogus.
It's not important whether the test is technically math or arithmetic: what's important is whether *those being studied* consider it to be math. Follow it through. The test demonstrates quite strongly that both women and men acting as 'hiring managers' tend to believe men will be better than women at this arithmetical task, even though it is known that in fact the two perform equally. (This is why the test designers chose the simple arithmetical task: because we know that *in truth*, women and men do it equally well).
The key question is this: do you really think they'd be biased when they assess the ability of men and women to perform a simple arithmetical task, but *not* be biased when assessing their ability to perform a complex mathematical one? Unless you truly think the answer to that question is 'yes', which seems unlikely, then no, you haven't invalidated the test. If anything, I'd have expected that perhaps people wouldn't be biased against women when it came to something this simple (i.e. that if anything, the test had a chance of coming up 'negative' even though the bias does exist). The fact that people displayed such a strong bias *even when the task in question is very simple arithmetic which we know the sexes actually perform equally well*, if anything, makes the study more compelling.
*was about to complain about stereotyping, then realized he was listening to Rufus Wainwright covering Judy Garland*
"I could be that PERHAPS there IS a difference in some math skill between males and females?"
The test under discussion was specifically designed to use a 'mathematical' task that it is already established women and men perform equally well at. As the article states.
RTFA: this specific factor is mentioned, and was compensated for by giving different 'hiring managers' different levels of information about the applicant. Some got just a picture of the applicant. Some got a self-assessment by the applicant of how they thought they'd do on the test (and the authors note that, indeed, men tended to give over-optimistic self-assessments, and women over-pessimistic ones). Some got the applicants' actual results.
The bias persisted in every case, it appears.
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.
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.