Certainly not true about Microsoft Research. As mentioned in the article, Microsoft Research is practically a university. Everything they research ends up peer-reviewed at academic conferences and in academic journals. It's virtually in the public domain.
Just in case anyone thought (like me) that the vulnerabilities they're talking about might let an attacker install arbitrary software just through the package manager, this doesn't seem to be the case.
The attack might go like so:
the attacker finds some really old version of some software that they know to be buggy. E.g., they find OpenSSH version negative 5 or something, which had a terrible buffer overflow bug in it. This software has already been signed (years ago) by the package authorities
the attacker then sets up a mirror with only the broken version of OpenSSH on it
when a hapless Linux user goes to update OpenSSH, your mirror replies saying "the newest version is negative 5. See! I even have a 5 year-old certificate for it"
your client says "...oh...okay"
you install the old, buggy version of OpenSSH
the attacker has your IP address and knows that you downloaded (and presumably installed) the old version of OpenSSH
the attacker haxx0rz you
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
Maybe I'm missing something, but that sounds like an extremely tight implementation. It sounds to me like "draw the line distinctly and allow everything up to that line". You said it yourself: "almost naked girl" with no actual sex scenes. It looks like they're allowing everything up to, but not over, the line.
I would support alternative voting methods, even preferential ones, but I would warn against advocating for IRV. IRV is the only well-known electoral method which I would consider to be worse than the current one.
Namely, IRV fails the monotonocity criterion. In IRV, it possible that voting someone higher will cause them to lose and voting someone lower will cause them to win. The current system (plurality) does not have this flaw; neither does approval (which is very simple to implement and understand); and neither do many other preferential systems such as Borda or a Condorcet method.
A lot of people jump on IRV I think because it allows people to rank their candidates without really looking in depth at the mathematical behind it to see how those rankings are used to determine the winner. Sadly, with IRV, the winner is sometimes, well, meaningless (or flat-out contrary to the voters' intentions). If you like preferential ballots, I would push for other preferential counting schemes such as Borda or a Condorcet method.
Personally I think approval voting is more practical. It is not as strategy-free as a Condorcet method, for example, but it is strictly better than the system we have now. It also has the (very important) benefit of being very simple to implement and very simple to understand.
I find depressingly little time to code. I love coding, but coding ends up being just a tiny, tiny part of research (trying out proofs of concept). The vast majority of my time is working through the math or reading or writing papers.
Mind you if you're not very good at coding, maybe you also wouldn't be very good at coming up with the theory behind the coding.
People who tune their radios while driving don't grasp how dangerous it is.
Seriously, your post comes off as a bit condescending. "Other people who do something seemingly safe are too stupid to realize that it's dangerous. But when I do something seemingly safe, it's because I'm smart enough to know that it actually is safe!"
That's fantastic that you only do it when you're on a barren straightaway and only press one button. Phone talkers who only phone while on straightaways and only press one button to do it (speed dial) can make exactly the same argument. Guess what? It's still dangerous. Changing the radio station while driving is dangerous. Period.
According to Wikipedia, there are 1.407 billion people online in 2008. So they're predicting a 30% increase over 4 years? Considering in the 1990s we would have had a 1500% increase over 4 years (again, using Wikipedia as a source: 100% increase per year), that seems remarkably underwhelming.
Man, I'd hate to live with you if you think that's whining.
AM's roommate: uh oh, looks like it's going to rain soon.
AM: STOP FUCKING WHINING! I CAN'T TAKE IT!
Isn't that three paid releases in 8 years? So how is this different...Panther, Tiger, Leopard.
Panther, Tiger and Leopard were three paid releases in 4 years. 4 is not the same as 8. Apple has had 6 paid releases in 6 years (Cheetah 2001, Puma 2001, Jaguar 2002, Panther 2003, Tiger 2005, Leopard 2007).
6 paid releases in 6 years is more expensive than 3 paid releases in 8 years.
It's not illegal to speak and ask for Swahili service in Quebec either. One or two people doing that wouldn't even be a big deal. However, hundreds of people doing that (e.g., Slashdotters) would make them all pretty big jackasses.
Once upon a time, you could buy an Apple product and expect it to work. Then the common wisdom became "as long as you don't get revision A, it should be okay". Now I'm to the point where I'm not even expecting the fucking fourth revision to work properly.
Do blind users count as real users? They often don't use "real browsers" and their screen readers often depend on mark-up being valid, not just "looking nice".
A typical source is something like this. This is not looking at typical use: it's looking at writing to the drive constantly. In the worst case scenario, the drive would last 51 years. That article is out of date too. Flash drives could potentially last hundreds of years in the worst case these days.
This is not to say that modern flash drives last hundreds of years, just that the number of rewrites is not the limiting factor. It doesn't matter how little free space there is on the drive, what access patterns you use, etc. Take a modern flash drive with no free blocks and write and rewrite to it non stop. It should last at least a few decades before the number of rewrites starts to become an issue.
If I tell you that I read slashdot, assuming that I am tech minded is not 100% accurate but it is much, much more accurate than making that assumption if I tell you that I drink water.
It is also much, much less accurate than the assumption that you drink water, based on the fact that you read Slashdot.
There is a correlation between reading Slashdot and drinking water. "But!" you exclaim "that correlation only works in one direction! It's worthless!" Not any less worthless than the correlation between consuming violent pornography and committing violent crimes, which similarly works only in one direction.
What it comes down to is that there's no rational reason to believe that violent pornography has any effect on committing violent crimes. Yes, it's common sense, but in my experience, common sense and truth are often diametrically opposed. This law is based on common sense, wishful thinking, moralizing and, to put it bluntly, making shit up. It is not based on truth or evidence.
Do imprisoned suspects have the right to send encrypted letters (of the ink-and-paper variety) to an attorney? If so, encrypted emails should be fair game. After all, your objection doesn't seem to be with the encryption per se, but rather that the email is actually being routed to a lawyer. It wouldn't be difficult for the warden to ensure that the email is going where it's supposed to go, regardless of whether it's encrypted.
I've always kind of wanted a CAPTCHA scheme like this. Provide the user/bot with an email, and ask the user/bot to flag the email as "legitimate email" or "spam". All data collected is fed to some machine learning algorithm to better SpamAssassin, etc.
In effect, you're getting spammers to help you defeat spam.
The downside is you'd need volunteers to give up their email:P
Further, the code given does nothing (that I can see) to handle divide-by-zero errors at compile time, which I would think would be the most common error needed to be caught at compile time.
Slashdot Mirror
Certainly not true about Microsoft Research. As mentioned in the article, Microsoft Research is practically a university. Everything they research ends up peer-reviewed at academic conferences and in academic journals. It's virtually in the public domain.
Just in case anyone thought (like me) that the vulnerabilities they're talking about might let an attacker install arbitrary software just through the package manager, this doesn't seem to be the case.
The attack might go like so:
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
Maybe I'm missing something, but that sounds like an extremely tight implementation. It sounds to me like "draw the line distinctly and allow everything up to that line". You said it yourself: " almost naked girl" with no actual sex scenes. It looks like they're allowing everything up to, but not over, the line.
I would support alternative voting methods, even preferential ones, but I would warn against advocating for IRV. IRV is the only well-known electoral method which I would consider to be worse than the current one.
Namely, IRV fails the monotonocity criterion. In IRV, it possible that voting someone higher will cause them to lose and voting someone lower will cause them to win. The current system (plurality) does not have this flaw; neither does approval (which is very simple to implement and understand); and neither do many other preferential systems such as Borda or a Condorcet method.
A lot of people jump on IRV I think because it allows people to rank their candidates without really looking in depth at the mathematical behind it to see how those rankings are used to determine the winner. Sadly, with IRV, the winner is sometimes, well, meaningless (or flat-out contrary to the voters' intentions). If you like preferential ballots, I would push for other preferential counting schemes such as Borda or a Condorcet method.
Personally I think approval voting is more practical. It is not as strategy-free as a Condorcet method, for example, but it is strictly better than the system we have now. It also has the (very important) benefit of being very simple to implement and very simple to understand.
The OP specifically mentioned research. My experience with research is that you rarely work with someone in the same country as you.
It's not a bad deal when you're giving a dollar to yourself and getting back an addition 40 cents, though.
You really only get one ballot? In Canada, you get as many ballots as you like. In your scenario, it would work like this:
It seems like a simple system? I haven't found any problems with it.
I find depressingly little time to code. I love coding, but coding ends up being just a tiny, tiny part of research (trying out proofs of concept). The vast majority of my time is working through the math or reading or writing papers.
Mind you if you're not very good at coding, maybe you also wouldn't be very good at coming up with the theory behind the coding.
People who tune their radios while driving don't grasp how dangerous it is.
Seriously, your post comes off as a bit condescending. "Other people who do something seemingly safe are too stupid to realize that it's dangerous. But when I do something seemingly safe, it's because I'm smart enough to know that it actually is safe!"
That's fantastic that you only do it when you're on a barren straightaway and only press one button. Phone talkers who only phone while on straightaways and only press one button to do it (speed dial) can make exactly the same argument. Guess what? It's still dangerous. Changing the radio station while driving is dangerous. Period.
According to Wikipedia, there are 1.407 billion people online in 2008. So they're predicting a 30% increase over 4 years? Considering in the 1990s we would have had a 1500% increase over 4 years (again, using Wikipedia as a source: 100% increase per year), that seems remarkably underwhelming.
More specifically, it didn't store software in memory.
Man, I'd hate to live with you if you think that's whining. AM's roommate: uh oh, looks like it's going to rain soon. AM: STOP FUCKING WHINING! I CAN'T TAKE IT!
The implicit assumption seems to be that good players don't prefer to be on the red team.
Panther, Tiger and Leopard were three paid releases in 4 years. 4 is not the same as 8. Apple has had 6 paid releases in 6 years (Cheetah 2001, Puma 2001, Jaguar 2002, Panther 2003, Tiger 2005, Leopard 2007).
6 paid releases in 6 years is more expensive than 3 paid releases in 8 years.
It's not illegal to speak and ask for Swahili service in Quebec either. One or two people doing that wouldn't even be a big deal. However, hundreds of people doing that (e.g., Slashdotters) would make them all pretty big jackasses.
Will they fix Spaces? Make X11 usable?
Once upon a time, you could buy an Apple product and expect it to work. Then the common wisdom became "as long as you don't get revision A, it should be okay". Now I'm to the point where I'm not even expecting the fucking fourth revision to work properly.
Do blind users count as real users? They often don't use "real browsers" and their screen readers often depend on mark-up being valid, not just "looking nice".
He's not the only person to consider. Who do you think he was writing emails to? Himself? Alive people have some expectations of privacy.
A typical source is something like this. This is not looking at typical use: it's looking at writing to the drive constantly. In the worst case scenario, the drive would last 51 years. That article is out of date too. Flash drives could potentially last hundreds of years in the worst case these days.
This is not to say that modern flash drives last hundreds of years, just that the number of rewrites is not the limiting factor. It doesn't matter how little free space there is on the drive, what access patterns you use, etc. Take a modern flash drive with no free blocks and write and rewrite to it non stop. It should last at least a few decades before the number of rewrites starts to become an issue.
You still seem to be not getting it.
It is also much, much less accurate than the assumption that you drink water, based on the fact that you read Slashdot.
There is a correlation between reading Slashdot and drinking water. "But!" you exclaim "that correlation only works in one direction! It's worthless!" Not any less worthless than the correlation between consuming violent pornography and committing violent crimes, which similarly works only in one direction.
What it comes down to is that there's no rational reason to believe that violent pornography has any effect on committing violent crimes. Yes, it's common sense, but in my experience, common sense and truth are often diametrically opposed. This law is based on common sense, wishful thinking, moralizing and, to put it bluntly, making shit up. It is not based on truth or evidence.
Do imprisoned suspects have the right to send encrypted letters (of the ink-and-paper variety) to an attorney? If so, encrypted emails should be fair game. After all, your objection doesn't seem to be with the encryption per se, but rather that the email is actually being routed to a lawyer. It wouldn't be difficult for the warden to ensure that the email is going where it's supposed to go, regardless of whether it's encrypted.
Still, wouldn't "fast" and "slow" work just as well as "broadband" and "narrowband"?
If you want to slip an exploit into the kernel, couldn't you accomplish it through a kernel module? I don't patching the kernel buys you too much.
I've always kind of wanted a CAPTCHA scheme like this. Provide the user/bot with an email, and ask the user/bot to flag the email as "legitimate email" or "spam". All data collected is fed to some machine learning algorithm to better SpamAssassin, etc.
In effect, you're getting spammers to help you defeat spam.
The downside is you'd need volunteers to give up their email :P
Further, the code given does nothing (that I can see) to handle divide-by-zero errors at compile time, which I would think would be the most common error needed to be caught at compile time.