Wrong. The fix is to, basically, reinstall the OS. Jailbroken or not. Jailbreak != OpenSSH preinstalled. People claiming this hole is somehow the result of jailbreaks are either clueless or anti-jailbreak. Jailbreaking is the enabler, but the real problem are clueless users who install (or are instructed to install) OpenSSH and do not change the default passwords.
The default install doesn't come with OpenSSH anyway. If you deliberately install OpenSSH (to access your stuff using WiFi, which is why most people do) and fail to change your password (which should be blatantly obvious, since it's what you'll be using to access the phone over WiFi), well, shame on you. If you can't deduce that anyone can access your phone remotely just as well as you can, you shouldn't be doing these things.
Really, a good part of the blame is probably on tutorials and guides out there that tell you to install OpenSSH and don't mention changing your password (or don't mention it in bold/red enough text). Smart people change their password, and dumb people don't go messing with a weirdly-named package that isn't listed under the "user-friendly GUI stuff" categories. It takes a poorly-written tutorial to bridge the gap.
FWIW, the default passwords are already there on Apple's OS. Jailbreaking by itself doesn't make the phone any less secure because it only lets you install unsigned apps. It's installing OpenSSH that suddenly turns the default passwords into a huge security hole. If OpenSSH were hypothetically available on the App store, the issue would still be present.
Do the Chinese even use Google much? I thought the most popular search engine there was Baidu. In fact, I seem to recall that China redirected Google to Baidu at least once.
By all means, do blame the spanish (government) for the ridiculous low speed.
Seriously, we have a pretty bad monopoly issue over here. The former state-owned telco controls most of the last mile wiring and equipment everywhere, and resells to other ISPs at ridiculous prices. Other ISPs have been making inroads into large cities, but if you live anywhere with 50k population, chances are you're SOL.
The required password security for SSH is often overstated. The absolute number one never-ever-do-this thing is dictionary words (or user names or easily guessable information) with little to no mangling: that's a recipe for disaster. Besides that, any reasonable password length (8 characters or more) is fine. It doesn't even have to be random, it can be pronounceable gibberish or even something coherent to you, as long as it's very particular to you and obscured in a non-obvious way (e.g. don't just do 'standard' leetspeak on a dictionary word). Plain numbers are significantly weaker, but even an 8-digit number is unlikely to be guessed in a network SSH attack, though I wouldn't recommend relying on it.
Realistically speaking, 6 characters of pure random, 8 characters of pronounceable random, or 10-15 characters of something coherent but mangled are basically secure for SSH. SSH attacks are over the network, which means you can't get even close to the number of tries per second of local password hash cracking attempts. The number of passwords that are going to be tried are in the thousands or millions over the long term, not the billions of possible combinations.
I use public keys to access some remote systems and they certainly are a lot better security-wise, but I keep my home boxes and my main server accessible via passwords, since I don't usually carry my private keys around when I need to log in from another box.
CDs and DVDs are a lot weirder than that. Bytes aren't stored verbatim: they're swizzled around and mixed up to improve error performance (that way a scratch kills many distant bytes that can be corrected, instead of a bunch of nearby ones that can't) and they are also converted to a self-clocking encoding (EFM) before writing to disc.
However, an explanation of this isn't that hard to write and fit into a small-ish book (you don't need all the details and specs, just a guide of just how the data made it onto the disc). Given a generous use of diagrams, it would help tremendously even if the language is dead by then.
You can obviously find just about anything mentioned anywhere on Google with the right keywords and site restrictions. Now figure out what rank that hit is on a Google search for, say "go programming language". My point is that the authors of Go at Google definitely wouldn't have found this programming language by doing some simple searches. It's very obscure. The only reason it's up there on Google now is due to this very controversy.
The Wikipedia page was created yesterday. Let me know if you find any hit on Google for Go! that isn't less than a day old. It's an obscure academic programming language.
Wait, you su back? You do realize that that leaves your root session in the background and complete accessible, right? The proper way to "unsu" is to just exit the shell (exit, ^D, etc).
Sorry, you're completely wrong. 1080p 60Hz 24bpp uncompressed video (this is the stuff going through your DVI cable) requires 356 MB/s of bandwidth (I just fixed the Wikipedia article). That is a completely unrealistic metric. 1080p 30Hz 4:2:0 video (half the X and Y chroma resolution, which for all intents and purposes is indistinguishable to the eye) is 88 MB/s, which is a reasonable baseline for an uncompressed HD signal of the kind you might actually watch.
Compressed, using decent codecs (h.264), anywhere from 10-30mbps (that's 1.25MB/s-3.75MB/s) is perfectly reasonable for great 1080p HD quality (depending on how complicated the video is). In fact, HD-DVD's maximum bitrate is 30mbps, and Blu-Ray's is 40mbps, about 6% of the uncompressed signal. Video signals have a huge amount of redundancy, and video codecs these days (especially x264) are very good.
7mbps "divx" (MPEG-4 ASP) is not adequate for 1080p material, but the real bitrates aren't nearly as far off as you say if you switch to a modern codec (h.264).
In the case of Theora, inferior and open can't necessarily be improved. Last I checked, the Theora bitstream format was frozen, which means the encoder will only be able to improve to some extent. I'm pretty sure h.264 is quite a bit more advanced than Theora, as a format.
By that I meant "developed for Google, useful to other people".
We can divide Andrew's potential kernel work into 4 categories:
Private changes for Google, not useful for other people.
Public changes for Google, deemed useful to other people but originally developed to suit Google's needs.
Public changes of general usefulness. Google might find them useful, but doesn't drive their development.
Maintaining -mm and signing off and merging other people's stuff
Points 1 and 2 can be considered a result of Andrew's employment at google. Points 3 and 4 would happen even if he weren't employed at Google. From my understanding, the vast majority of Andrew's work is point 4 (that's why he's listed under non-author signoffs as 6%, along with Google). Both Andrew's and Google's commit-author contributions are below 0.9%.
So what we can derive from the data in the article, assuming it's accurate, is:
Google's employees as a whole authored less than 0.9% of the changes that went into 2.6.31
Andrew authored less than 0.8% of the 2.6.31 changes
Andrew signed off on 6% of the 2.6.31 changes
Besides Andrew, 3 other changes were signed off by Google employees (that's like.03%)
So no, Google doesn't contribute much to the kernel. Having Andrew on board gives them some presence and credibility in kernel-land, but they don't actually author much public kernel code. Hiring someone to keep doing what they were already doing doesn't make you a kernel contributor.
Andrew has been doing a large amount of kernel work for some time now, before his employment with Google. Note that the 6% figure is under non-author signoffs - people that patches went through, instead of people who actually authored them. Heck, even I submitted a patch that went through Andrew once (and I've submitted like 5 patches to the kernel). Andrew does a lot of gatekeeping for the kernel, but he doesn't write that much code, and he certainly doesn't appear to be committing code written by Google's kernel team under his name as a committer.
Google isn't even on the list of actual code-writing employers, which means they're under 0.9%. I watched a Google Tech Talk about the kernel once (I forget the exact name) where it was mentioned that Google was (minus Andrew) somewhere in the 40th place or so of companies who contribute changes to Linux.
Andrew Morton, Google employee and maintainer of the -mm tree, contributed the vast majority of the changes filed under "Google" (and most of those changes aren't Google-specific - Andrew has been doing this since before he was employed there). If you subtract Andrew, Google is responsible for a tiny part of kernel development last I heard, unfortunately.
It's also a myth that hum is always caused by the grounding: sometimes, hum is caused by poor or lack of grounding. Often, hum that can be "fixed" by breaking the ground indicates an underlying problem (and possibly a danger for you or the equipment). For example, my Acer laptop has a hum issue when the AC adapter is connected and I route the audio to another grounded device. In this case, the cause is actually the poor grounding on the laptop's DC power cord: it should have 3 wires (earth, +, -) but instead they used a single shield for both earth and negative. The problem is this shield is poor, it has resistance, and a rather large current goes through this DC cable. Then, the laptop ground develops a varying voltage offset above AC earth. This voltage is shunted through any audio cable into any earthed appliance back into mains earth. In layman's terms, the laptop's DC current takes a detour through the audio cable, through the audio device into mains earth, and back out to the laptop's DC adapter, instead of (mostly) sticking to the DC cable. I've seen this very issue on at least one other Acer laptop model, so it might be endemic to their power adapters.
The proper fix would be to break the negative-ground connection at the AC adapter and run two wires (joined together at the laptop side of things), but I didn't want to tear the thing apart, so instead I just added a big fat extra ground: a thick mains-style wire running from the VGA port shell (a convenient ground on the laptop) to an AC outlet's ground (preferably one right next to the AC adapter's outlet) fixed the issue.
Remember people, wires aren't perfect, and that circuit analysis stuff that you learn in college is bullshit. Just because you draw a line between two points on a schematic doesn't mean they are at equal potential, at least until room-temperature superconductors become common (and then it's still DC only - even in mythical superconductor-land, inductance will still bite you if your current isn't constant).
Read this and note the third step. Read the description of the SL disc on the Apple Store too. It says "upgrade from Leopard". The $29 SL disc is being sold as an upgrade from Leopard only. They might not be able to enforce it legally if it's not clear enough on the box, but that's what they're officially trying to do (unofficially, I suspect they don't care, since they aren't even making a straight SL-no-iWord-no-iLife disc available).
The only question here is whether you can legally sell a full version of a product for a reduced price to customers of a previous version. I suspect the answer is yes, but it might have not been tested in court yet.
If you have a Mac, it means you own some version of OS X. That means that, effectively, any versions of OS X that you buy is an upgrade-only version (if Apple decides so), since you can't possibly install it on a non-Mac (as long as they specify this in the EULA). Hacking it would be fine, but you'd be breaking their copyright by installing it on a non-mac, since at that point you aren't using an existing license of OS X. I imagine you'd be fine if you owned a previous license. For example, you could install a (hacked) OS X on a PC as long as you have an OS X-capable Mac lying around that either has some other OS or is broken (such that its license to OS X isn't in use). Apple won't like it, but it should be a workaround for their scheme, and I'm pretty sure it should be fine, legally.
Hmm, I have a cheapo Mac Mini. If I ever get tired of it I bet I can legally wipe it, use it as a Linux box/whatever, and put OS X on some beefier machine.
Just because they sell a product that will let you install it on blank hardware doesn't mean they can't consider it an upgrade for the version that came with your hardware (which you legally bought a license for when you bought the hardware).
Since every Mac comes with Mac OS (even pre-X macs), I don't see why Apple couldn't spin the EULA such that each and every version of OS X that they sell is considered an upgrade for the version that came with your Mac. Whether there are technical protection measures to enforce that is irrelevant: you're not required to add copy protection in order to enforce copyright. They should be legally fine there. The only problem here is that they do not offer any non-upgrade versions at all, and I could see a judge taking issue at that. Maybe the "solution" (from their standpoint) would be to sell true real non-upgrade versions of OS X at some exorbitant price. They could even cripple them to only run on Macs still, though people would always be able to legally hack support in. Psystar would be in trouble if they were legally required to buy a $800 copy of OS X for each Mac-PC that they sell.
BTW, you're wrong. The $9 upgrade is for recent Macs that came with Leopard. The $29 upgrade is for any Mac with Leopard. If you have an older version of OS X, your legal upgrade option is to get the Mac Box Set for $169, which comes with iWork and iLife whether you need them or not. Using the $29 version on a box with Tiger would be against their license.
Desktops and laptops have plenty of ARM chips in them. Lots of drives use ARM chips for the drive controller, for example. Just about everything that needs more than an 8-bit micro has a very good chance of having an ARM chip these days (not 99%, but still a pretty high number). It's almost scary. And now, with Cortex-M0, ARM is heading straight for the 8-bit and 16-bit market (though it isn't here yet: so far, low end devices like computer input devices, simple appliances like microwave ovens, etc. don't use ARMs).
Slashdot Mirror
Wrong. The fix is to, basically, reinstall the OS. Jailbroken or not. Jailbreak != OpenSSH preinstalled. People claiming this hole is somehow the result of jailbreaks are either clueless or anti-jailbreak. Jailbreaking is the enabler, but the real problem are clueless users who install (or are instructed to install) OpenSSH and do not change the default passwords.
The default install doesn't come with OpenSSH anyway. If you deliberately install OpenSSH (to access your stuff using WiFi, which is why most people do) and fail to change your password (which should be blatantly obvious, since it's what you'll be using to access the phone over WiFi), well, shame on you. If you can't deduce that anyone can access your phone remotely just as well as you can, you shouldn't be doing these things.
Really, a good part of the blame is probably on tutorials and guides out there that tell you to install OpenSSH and don't mention changing your password (or don't mention it in bold/red enough text). Smart people change their password, and dumb people don't go messing with a weirdly-named package that isn't listed under the "user-friendly GUI stuff" categories. It takes a poorly-written tutorial to bridge the gap.
FWIW, the default passwords are already there on Apple's OS. Jailbreaking by itself doesn't make the phone any less secure because it only lets you install unsigned apps. It's installing OpenSSH that suddenly turns the default passwords into a huge security hole. If OpenSSH were hypothetically available on the App store, the issue would still be present.
Do the Chinese even use Google much? I thought the most popular search engine there was Baidu. In fact, I seem to recall that China redirected Google to Baidu at least once.
By all means, do blame the spanish (government) for the ridiculous low speed.
Seriously, we have a pretty bad monopoly issue over here. The former state-owned telco controls most of the last mile wiring and equipment everywhere, and resells to other ISPs at ridiculous prices. Other ISPs have been making inroads into large cities, but if you live anywhere with 50k population, chances are you're SOL.
Most motherboards these days do implement SATA hotplugging. In fact, it's pretty important for eSATA.
The required password security for SSH is often overstated. The absolute number one never-ever-do-this thing is dictionary words (or user names or easily guessable information) with little to no mangling: that's a recipe for disaster. Besides that, any reasonable password length (8 characters or more) is fine. It doesn't even have to be random, it can be pronounceable gibberish or even something coherent to you, as long as it's very particular to you and obscured in a non-obvious way (e.g. don't just do 'standard' leetspeak on a dictionary word). Plain numbers are significantly weaker, but even an 8-digit number is unlikely to be guessed in a network SSH attack, though I wouldn't recommend relying on it.
Realistically speaking, 6 characters of pure random, 8 characters of pronounceable random, or 10-15 characters of something coherent but mangled are basically secure for SSH. SSH attacks are over the network, which means you can't get even close to the number of tries per second of local password hash cracking attempts. The number of passwords that are going to be tried are in the thousands or millions over the long term, not the billions of possible combinations.
I use public keys to access some remote systems and they certainly are a lot better security-wise, but I keep my home boxes and my main server accessible via passwords, since I don't usually carry my private keys around when I need to log in from another box.
CDs and DVDs are a lot weirder than that. Bytes aren't stored verbatim: they're swizzled around and mixed up to improve error performance (that way a scratch kills many distant bytes that can be corrected, instead of a bunch of nearby ones that can't) and they are also converted to a self-clocking encoding (EFM) before writing to disc.
However, an explanation of this isn't that hard to write and fit into a small-ish book (you don't need all the details and specs, just a guide of just how the data made it onto the disc). Given a generous use of diagrams, it would help tremendously even if the language is dead by then.
You can obviously find just about anything mentioned anywhere on Google with the right keywords and site restrictions. Now figure out what rank that hit is on a Google search for, say "go programming language". My point is that the authors of Go at Google definitely wouldn't have found this programming language by doing some simple searches. It's very obscure. The only reason it's up there on Google now is due to this very controversy.
The Wikipedia page was created yesterday. Let me know if you find any hit on Google for Go! that isn't less than a day old. It's an obscure academic programming language.
Wait, you su back? You do realize that that leaves your root session in the background and complete accessible, right? The proper way to "unsu" is to just exit the shell (exit, ^D, etc).
Meh, I rarely use sudo. I guess I'm just not too used to it. So su me.
We can thank our dear president for both the unemployment rate and the nuclear hate. Gotta love politics.
Sorry, you're completely wrong. 1080p 60Hz 24bpp uncompressed video (this is the stuff going through your DVI cable) requires 356 MB/s of bandwidth (I just fixed the Wikipedia article). That is a completely unrealistic metric. 1080p 30Hz 4:2:0 video (half the X and Y chroma resolution, which for all intents and purposes is indistinguishable to the eye) is 88 MB/s, which is a reasonable baseline for an uncompressed HD signal of the kind you might actually watch.
Compressed, using decent codecs (h.264), anywhere from 10-30mbps (that's 1.25MB/s-3.75MB/s) is perfectly reasonable for great 1080p HD quality (depending on how complicated the video is). In fact, HD-DVD's maximum bitrate is 30mbps, and Blu-Ray's is 40mbps, about 6% of the uncompressed signal. Video signals have a huge amount of redundancy, and video codecs these days (especially x264) are very good.
7mbps "divx" (MPEG-4 ASP) is not adequate for 1080p material, but the real bitrates aren't nearly as far off as you say if you switch to a modern codec (h.264).
In the case of Theora, inferior and open can't necessarily be improved. Last I checked, the Theora bitstream format was frozen, which means the encoder will only be able to improve to some extent. I'm pretty sure h.264 is quite a bit more advanced than Theora, as a format.
Maps is AJAX, Street View is Flash. They also use flash for some graphs in Analytics, at least (last I checked).
By that I meant "developed for Google, useful to other people".
We can divide Andrew's potential kernel work into 4 categories:
Points 1 and 2 can be considered a result of Andrew's employment at google. Points 3 and 4 would happen even if he weren't employed at Google. From my understanding, the vast majority of Andrew's work is point 4 (that's why he's listed under non-author signoffs as 6%, along with Google). Both Andrew's and Google's commit-author contributions are below 0.9%.
So what we can derive from the data in the article, assuming it's accurate, is:
So no, Google doesn't contribute much to the kernel. Having Andrew on board gives them some presence and credibility in kernel-land, but they don't actually author much public kernel code. Hiring someone to keep doing what they were already doing doesn't make you a kernel contributor.
Andrew has been doing a large amount of kernel work for some time now, before his employment with Google. Note that the 6% figure is under non-author signoffs - people that patches went through, instead of people who actually authored them. Heck, even I submitted a patch that went through Andrew once (and I've submitted like 5 patches to the kernel). Andrew does a lot of gatekeeping for the kernel, but he doesn't write that much code, and he certainly doesn't appear to be committing code written by Google's kernel team under his name as a committer.
Google isn't even on the list of actual code-writing employers, which means they're under 0.9%. I watched a Google Tech Talk about the kernel once (I forget the exact name) where it was mentioned that Google was (minus Andrew) somewhere in the 40th place or so of companies who contribute changes to Linux.
Andrew Morton, Google employee and maintainer of the -mm tree, contributed the vast majority of the changes filed under "Google" (and most of those changes aren't Google-specific - Andrew has been doing this since before he was employed there). If you subtract Andrew, Google is responsible for a tiny part of kernel development last I heard, unfortunately.
It's also a myth that hum is always caused by the grounding: sometimes, hum is caused by poor or lack of grounding. Often, hum that can be "fixed" by breaking the ground indicates an underlying problem (and possibly a danger for you or the equipment). For example, my Acer laptop has a hum issue when the AC adapter is connected and I route the audio to another grounded device. In this case, the cause is actually the poor grounding on the laptop's DC power cord: it should have 3 wires (earth, +, -) but instead they used a single shield for both earth and negative. The problem is this shield is poor, it has resistance, and a rather large current goes through this DC cable. Then, the laptop ground develops a varying voltage offset above AC earth. This voltage is shunted through any audio cable into any earthed appliance back into mains earth. In layman's terms, the laptop's DC current takes a detour through the audio cable, through the audio device into mains earth, and back out to the laptop's DC adapter, instead of (mostly) sticking to the DC cable. I've seen this very issue on at least one other Acer laptop model, so it might be endemic to their power adapters.
The proper fix would be to break the negative-ground connection at the AC adapter and run two wires (joined together at the laptop side of things), but I didn't want to tear the thing apart, so instead I just added a big fat extra ground: a thick mains-style wire running from the VGA port shell (a convenient ground on the laptop) to an AC outlet's ground (preferably one right next to the AC adapter's outlet) fixed the issue.
Remember people, wires aren't perfect, and that circuit analysis stuff that you learn in college is bullshit. Just because you draw a line between two points on a schematic doesn't mean they are at equal potential, at least until room-temperature superconductors become common (and then it's still DC only - even in mythical superconductor-land, inductance will still bite you if your current isn't constant).
It's also worth noting that Table P can be derived from the other tables if given in full (with all the entries revealed).
Right - I meant to imply "exclusively" in there (sell the reduced version only to customers of previous versions).
Read this and note the third step. Read the description of the SL disc on the Apple Store too. It says "upgrade from Leopard". The $29 SL disc is being sold as an upgrade from Leopard only. They might not be able to enforce it legally if it's not clear enough on the box, but that's what they're officially trying to do (unofficially, I suspect they don't care, since they aren't even making a straight SL-no-iWord-no-iLife disc available).
The only question here is whether you can legally sell a full version of a product for a reduced price to customers of a previous version. I suspect the answer is yes, but it might have not been tested in court yet.
If you have a Mac, it means you own some version of OS X. That means that, effectively, any versions of OS X that you buy is an upgrade-only version (if Apple decides so), since you can't possibly install it on a non-Mac (as long as they specify this in the EULA). Hacking it would be fine, but you'd be breaking their copyright by installing it on a non-mac, since at that point you aren't using an existing license of OS X. I imagine you'd be fine if you owned a previous license. For example, you could install a (hacked) OS X on a PC as long as you have an OS X-capable Mac lying around that either has some other OS or is broken (such that its license to OS X isn't in use). Apple won't like it, but it should be a workaround for their scheme, and I'm pretty sure it should be fine, legally.
Hmm, I have a cheapo Mac Mini. If I ever get tired of it I bet I can legally wipe it, use it as a Linux box/whatever, and put OS X on some beefier machine.
Just because they sell a product that will let you install it on blank hardware doesn't mean they can't consider it an upgrade for the version that came with your hardware (which you legally bought a license for when you bought the hardware).
Since every Mac comes with Mac OS (even pre-X macs), I don't see why Apple couldn't spin the EULA such that each and every version of OS X that they sell is considered an upgrade for the version that came with your Mac. Whether there are technical protection measures to enforce that is irrelevant: you're not required to add copy protection in order to enforce copyright. They should be legally fine there. The only problem here is that they do not offer any non-upgrade versions at all, and I could see a judge taking issue at that. Maybe the "solution" (from their standpoint) would be to sell true real non-upgrade versions of OS X at some exorbitant price. They could even cripple them to only run on Macs still, though people would always be able to legally hack support in. Psystar would be in trouble if they were legally required to buy a $800 copy of OS X for each Mac-PC that they sell.
BTW, you're wrong. The $9 upgrade is for recent Macs that came with Leopard. The $29 upgrade is for any Mac with Leopard. If you have an older version of OS X, your legal upgrade option is to get the Mac Box Set for $169, which comes with iWork and iLife whether you need them or not. Using the $29 version on a box with Tiger would be against their license.
Desktops and laptops have plenty of ARM chips in them. Lots of drives use ARM chips for the drive controller, for example. Just about everything that needs more than an 8-bit micro has a very good chance of having an ARM chip these days (not 99%, but still a pretty high number). It's almost scary. And now, with Cortex-M0, ARM is heading straight for the 8-bit and 16-bit market (though it isn't here yet: so far, low end devices like computer input devices, simple appliances like microwave ovens, etc. don't use ARMs).