Even though it may appear that they are specifically targeting Linux with a broken file, it's far more likely that it's an innocent mistake: they could very easily have taken the DSDT data from another board they produce, copied it, and then made the modifications required to make Vista and XP work. The Linux support included in the old board would then still be included, even though no effort had been made to ensure it functions properly.
It's a shame that they left it in there, but I really don't think there's a conspiracy with Microsoft regarding this.
This sort of behaviour is nothing new. qmail accepts all mail immediately and then if it bounces, generates its own bounce message and sends it back to the envelope sender. Relays, by necessity, do the same thing too. OK, so it would be nice if Google could reject the messages right away, but accusing them of being evil because of this is a huge stretch.
Instead of disabling passwords completely to stop the brute force SSH attacks, I disable password authentication but leave public key and keyboard-interactive enabled. Keyboard-interactive is just a fancy way to request a password by default, but won't work with the brute force attacks I've seen so far. It's not going to work forever, but seems to be effective for now.
My understanding is that they have a signature for the SSL handshake and use that. They could actually do quite well with that strategy if they make the first 50-100kb go fast and then drop the priority after that -- it makes most HTTPS transfers have no noticeable change in speed, but would dramatically slow down anything trying to do bulk data transfer.
If they are using Sandvine equipment to do the resets, it's worth nothing that Sandvine can do more than just kill P2P traffic -- they can do things like allow seeding only to other customers of the same ISP (and redirect connections to other seeds back inside to that one). It's not quite as polite to the rest of the Internet, but it means that the ISP's other customers can download that file through P2P without consuming as much bandwidth (upload or download) on the general transit connections. What happens is highly dependent on what the ISP chooses for its policy.
Of course, the article says nothing about what technology is being used, so there are several other ways they could be doing this too.
After one particularly eye-opening electric bill, I started putting everything on timers, save one computer and my fridge. If I'm asleep or not at home, the power gets cut....at the prevailing rates around here, 1W constantly burning all month is about $5.
This leads to a question: do the timers (over a 24 hour period) use less power than the power saved during the portion of the day that the devices are turned off?
Excellent. This means that factoring in the usual "Valve can't make release dates" fudge factor, it should be out sometime in December, just in time for playing over the Christmas break!
This is a tactic spammers use with mail servers. It's rude, annoying and breaks the rules/protocol.
RFC 2920 is the SMTP extension for pipelining. Pipelining is a perfectly valid strategy to reduce the time it takes to send mail by reducing the number of round-trips.
What's rude is violating the RFC that says that certain round-trips are required and the spammers tend to violate those rules (such as asking if a message body can be sent before actually sending it, and waiting for the server's introduction message before the client introduces itself). Pipelining itself is actually quite good.
I won't comment on HTTP pipelining because someone else did already.
Perhaps they've discovered some new codes for larger block sizes that are closer to being perfect codes than the current ones they use. If the codeword size is 6x what it was before, then maybe the % of possible read vectors that get the "too many errors; don't know how to correct this" case will be smaller. Also, I'm not sure where you're going with your CD example: the coding they used in CDs is really obsolete by today's standards anyway.
You make an excellent point. Really, Google can't be caught doing bad things with the data they collect -- otherwise they're doomed (if people don't trust them, they get no traffic, no advertisers and no sites willing to post their ads... any one of which would impact them greatly). The simplest way to ensure that they don't have that problem is if they don't do bad things with the data in the first place. They know this. Why are we freaking out when they haven't done anything yet, nor is there any indication they would even want to?
I'm used to ircu, where the juped nicks are in U lines and not even opers can/nick to them, so you'd have to edit a server's config file and rehash to free up the nick. Ah well, I guess such things vary.
I was going to suggest something along those lines, but if you think about it... if the services database were compromised, even if there's hashing, then everyone's passwords might get out anyway. I don't think anything actually implied that they're stored plaintext.
OK, I suck for not RTFA first. But still, relying on jupes is fairly weak for that very reason -- if one server has it taken off, you lose all the protection.
As an admin on another IRC network, I'm actually quite surprised that the ircd would let someone take the nick nickserv... or at least, if it's permitted to happen, that there isn't some alternate authentication mechanism that guarantees it only goes to a legitimate recipient (i.e./nickserv or/msg nickserv@services.ircnetwork.net or whatever). Fortunately, my password on there is intentionally weak.
On the other hand, I understand what it's like to have compromised servers on the IRC network. I wish them the best in their efforts to get things working smoothly again. Tracking down the culprits can be exceedingly hard and time intensive, and reloading rooted servers is never fun.
The ISPs oversell bandwidth because otherwise it'd be too expensive for anyone to be willing to use the Internet. Ratios are typically 10:1 or for connections >5mbps, perhaps 20:1. Almost nobody would pay hundreds of dollars per month for their internet connection.
Ever wonder why business DSL costs so much more? That's because they only oversell those connections about 2:1.
"Writing a cross-platform worm is difficult because it limits you to functions that are available on both operating systems," Ullrich said. "You have to also code the virus in assembly to make it work without relying on any OS-specific function," he said.
Why?
Doesn't it seem plausible that it could just have one copy of itself for each executable type, and then whichever one actually executes knows how to insert the other(s) if needed? Then it's not really a single virus, but more of a set of symbiotic viruses. It still gets the same result though.
The question I have is: How do you even know that traffic is encrypted if you snoop it in transit?
It's just data. It looks like randomness. Compressed data (which I imagine makes up the bulk of torrent traffic) looks like randomness too. It's not like there's an actual flag in the packet saying "I'm encrypted. Try to crack me!"
So really, this makes it harder for the automatic shaping tools to snoop on the control traffic and shape the torrent flows while leaving the rest of the traffic alone. What will the ISPs do? Probably just start running all traffic through a shaper that they can't otherwise identify.
As for catching the terrorists... they wouldn't even want to use "normal" encryption. Even if the actual message can't be read, if their location is given away, that's not really ideal. So they'd probably be using stenography anyway and might even already hide their communications within otherwise innocent-looking unencrypted bittorrent streams.
So we have:
Torrent traffic becomes harder to identify. ISPs can get around this by just shaping stuff they can't identify.
Terrorists could hide before. Terrorists can hide now. Nothing changes.
By taking on the filtering themselves, Google is making the statement to Chinese citizens that they support their government's censorship, whereas if they stood their ground and kept the search results uncensored, at least some Chinese citizens using out-of-country proxies would be able to use the search engine to its fullest extent.
Ah, but there's something clever that Google will be doing there -- they said that if anything is censored out, then the search results will contain a note saying that "some results were removed to comply with local laws". I imagine that use of out-of-country proxies is a somewhat dangerous affair... this way anyone can search for things and then only try getting around the filters if they're informed that something they want was removed from the results.
Err, if it's a polynomial of degree 5, and there are 5 numbers listed that are supposed to be roots, then of course there are no nonreal roots -- the sum of the number of real roots and the number of nonreal roots equals the degree of the polynomial.
So REAL nerds recognized that you don't need to manually check it!
Every month or two (really, whenever something prompts me to think about it, which is infrequent) I go through and delete all of the cookies except the ones I know do something I want (i.e. keep me logged into slashdot) or I personally know the people who run the site & am completely sure that they're not being used for anything I disagree with.
I tried selectively allowing cookies (making liberal use of the "always accept from this site" and "always deny from this site" buttons), but it was a pain, and cookies don't really hurt me. My browsing habits won't be hard to track anyway because I've got a distinctive user-agent (firefox on linux) and my IP changes infrequently.
You probably ran out of random bits and they are slow to accumulate. Try /dev/zero or if you want pseudorandom data, /dev/urandom.
Even though it may appear that they are specifically targeting Linux with a broken file, it's far more likely that it's an innocent mistake: they could very easily have taken the DSDT data from another board they produce, copied it, and then made the modifications required to make Vista and XP work. The Linux support included in the old board would then still be included, even though no effort had been made to ensure it functions properly.
It's a shame that they left it in there, but I really don't think there's a conspiracy with Microsoft regarding this.
This sort of behaviour is nothing new. qmail accepts all mail immediately and then if it bounces, generates its own bounce message and sends it back to the envelope sender. Relays, by necessity, do the same thing too. OK, so it would be nice if Google could reject the messages right away, but accusing them of being evil because of this is a huge stretch.
Instead of disabling passwords completely to stop the brute force SSH attacks, I disable password authentication but leave public key and keyboard-interactive enabled. Keyboard-interactive is just a fancy way to request a password by default, but won't work with the brute force attacks I've seen so far. It's not going to work forever, but seems to be effective for now.
My understanding is that they have a signature for the SSL handshake and use that. They could actually do quite well with that strategy if they make the first 50-100kb go fast and then drop the priority after that -- it makes most HTTPS transfers have no noticeable change in speed, but would dramatically slow down anything trying to do bulk data transfer.
If they are using Sandvine equipment to do the resets, it's worth nothing that Sandvine can do more than just kill P2P traffic -- they can do things like allow seeding only to other customers of the same ISP (and redirect connections to other seeds back inside to that one). It's not quite as polite to the rest of the Internet, but it means that the ISP's other customers can download that file through P2P without consuming as much bandwidth (upload or download) on the general transit connections. What happens is highly dependent on what the ISP chooses for its policy.
Of course, the article says nothing about what technology is being used, so there are several other ways they could be doing this too.
This leads to a question: do the timers (over a 24 hour period) use less power than the power saved during the portion of the day that the devices are turned off?
Excellent. This means that factoring in the usual "Valve can't make release dates" fudge factor, it should be out sometime in December, just in time for playing over the Christmas break!
This is a tactic spammers use with mail servers. It's rude, annoying and breaks the rules/protocol.
RFC 2920 is the SMTP extension for pipelining. Pipelining is a perfectly valid strategy to reduce the time it takes to send mail by reducing the number of round-trips.
What's rude is violating the RFC that says that certain round-trips are required and the spammers tend to violate those rules (such as asking if a message body can be sent before actually sending it, and waiting for the server's introduction message before the client introduces itself). Pipelining itself is actually quite good.
I won't comment on HTTP pipelining because someone else did already.
Perhaps they've discovered some new codes for larger block sizes that are closer to being perfect codes than the current ones they use. If the codeword size is 6x what it was before, then maybe the % of possible read vectors that get the "too many errors; don't know how to correct this" case will be smaller. Also, I'm not sure where you're going with your CD example: the coding they used in CDs is really obsolete by today's standards anyway.
You make an excellent point. Really, Google can't be caught doing bad things with the data they collect -- otherwise they're doomed (if people don't trust them, they get no traffic, no advertisers and no sites willing to post their ads... any one of which would impact them greatly). The simplest way to ensure that they don't have that problem is if they don't do bad things with the data in the first place. They know this. Why are we freaking out when they haven't done anything yet, nor is there any indication they would even want to?
I'm used to ircu, where the juped nicks are in U lines and not even opers can /nick to them, so you'd have to edit a server's config file and rehash to free up the nick. Ah well, I guess such things vary.
I was going to suggest something along those lines, but if you think about it... if the services database were compromised, even if there's hashing, then everyone's passwords might get out anyway. I don't think anything actually implied that they're stored plaintext.
I hope not, at least.
OK, I suck for not RTFA first. But still, relying on jupes is fairly weak for that very reason -- if one server has it taken off, you lose all the protection.
As an admin on another IRC network, I'm actually quite surprised that the ircd would let someone take the nick nickserv... or at least, if it's permitted to happen, that there isn't some alternate authentication mechanism that guarantees it only goes to a legitimate recipient (i.e. /nickserv or /msg nickserv@services.ircnetwork.net or whatever). Fortunately, my password on there is intentionally weak.
On the other hand, I understand what it's like to have compromised servers on the IRC network. I wish them the best in their efforts to get things working smoothly again. Tracking down the culprits can be exceedingly hard and time intensive, and reloading rooted servers is never fun.
The ISPs oversell bandwidth because otherwise it'd be too expensive for anyone to be willing to use the Internet. Ratios are typically 10:1 or for connections >5mbps, perhaps 20:1. Almost nobody would pay hundreds of dollars per month for their internet connection.
Ever wonder why business DSL costs so much more? That's because they only oversell those connections about 2:1.
"Writing a cross-platform worm is difficult because it limits you to functions that are available on both operating systems," Ullrich said. "You have to also code the virus in assembly to make it work without relying on any OS-specific function," he said.
Why?
Doesn't it seem plausible that it could just have one copy of itself for each executable type, and then whichever one actually executes knows how to insert the other(s) if needed? Then it's not really a single virus, but more of a set of symbiotic viruses. It still gets the same result though.
Valve pushes back a release date.
In other news, water is still wet.
Of course, when they *do* finish, their games tend to be pretty great. So I don't mind.
It's just data. It looks like randomness. Compressed data (which I imagine makes up the bulk of torrent traffic) looks like randomness too. It's not like there's an actual flag in the packet saying "I'm encrypted. Try to crack me!"
So really, this makes it harder for the automatic shaping tools to snoop on the control traffic and shape the torrent flows while leaving the rest of the traffic alone. What will the ISPs do? Probably just start running all traffic through a shaper that they can't otherwise identify.
As for catching the terrorists... they wouldn't even want to use "normal" encryption. Even if the actual message can't be read, if their location is given away, that's not really ideal. So they'd probably be using stenography anyway and might even already hide their communications within otherwise innocent-looking unencrypted bittorrent streams.
So we have:
Nothing new here.
By taking on the filtering themselves, Google is making the statement to Chinese citizens that they support their government's censorship, whereas if they stood their ground and kept the search results uncensored, at least some Chinese citizens using out-of-country proxies would be able to use the search engine to its fullest extent.
Ah, but there's something clever that Google will be doing there -- they said that if anything is censored out, then the search results will contain a note saying that "some results were removed to comply with local laws". I imagine that use of out-of-country proxies is a somewhat dangerous affair... this way anyone can search for things and then only try getting around the filters if they're informed that something they want was removed from the results.
I don't have any comment on the post you were replying to, but people do (indirectly) put their age, sex and possibly race on their resumes:
It's called sash. Most of the important commands have a duplicated version built-in if you prepend a hyphen.
There's also busybox, but that's more of a replacement for the standard utilities.
Err, if it's a polynomial of degree 5, and there are 5 numbers listed that are supposed to be roots, then of course there are no nonreal roots -- the sum of the number of real roots and the number of nonreal roots equals the degree of the polynomial.
So REAL nerds recognized that you don't need to manually check it!
ExchangeIt is another option.
Disclaimer: I used to work there (but not on that product), and I still think that company is really cool.
Every month or two (really, whenever something prompts me to think about it, which is infrequent) I go through and delete all of the cookies except the ones I know do something I want (i.e. keep me logged into slashdot) or I personally know the people who run the site & am completely sure that they're not being used for anything I disagree with.
I tried selectively allowing cookies (making liberal use of the "always accept from this site" and "always deny from this site" buttons), but it was a pain, and cookies don't really hurt me. My browsing habits won't be hard to track anyway because I've got a distinctive user-agent (firefox on linux) and my IP changes infrequently.