The food in Google cafeterias covers a broad range of healthy and not really healthy choices, with a clear labelling system. People can choose to eat as well (or as badly) as they like, because yaknow, that's how you please the broadest range of people while also encouraging them to think a little about what they are eating.
The source is linked to from the Chrome for Android developer FAQ; see http://code.google.com/chrome/mobile/docs/faq.html
The actual tarball is at http://chromium-browser-source.commondatastorage.googleapis.com/chrome_android.v0.16.4130.199.tgz and contains ordinary, buildable source code, not binaries.
And FYI im not sure you're informed enough to comment since there are no 3G owners "happily fast switching apps" since fast app switching is part of multitasking which, as is well publicised, you dont get in ios4 on the 3G.
You do if you jailbreak it; the jailbreak process has the option to enable the 3GS-only functionality like multitasking and wallpapers.
I restored my 3G to a fresh install of 4.0.1 and skipped restoring from backup (I put specific files back by hand over afc2 afterward), jailbroke and enabled multitasking, and everything works fine for me, so mileage really does vary substantially between users - even with multitasking and the other features the 3G is supposed to not have enough memory for, it works fine for me (and I have a bunch of mobilesubstrate addons installed which eat up even more of the limited ram)
iPhone 2G and 3G users can both install the 3.2.2 update that fixes the same vulnerability, so your comment is wrong on all counts.
No, they can't. The 3.2 series is only for the iPad, and doesn't exist for any iPhone/iPod. The 3.2.2 update does fix the vulnerability, but only iPad users can install it.
Of course, anyone buying an Apple iPhone/iPod Touch/iPad just because you can jailbreak it and do what you want is pretty stupid - there are millions of other devices out there that are perfectly open.
Nobody has ever bought an iPhone just because you can jailbreak it. The people who buy them with the intention of jailbreaking them have compared the options and decided they would rather have the iPhone and then go through the process of removing some of the restrictions, than any of the other choices which may or may not have those restrictions to begin with.
I decided I preferred it to any of the other devices available at the time, and after confirming that the restrictions which I cared about were removable via jailbreaking, and that the specific iPhone I was buying was jailbreak-able, I bought it. It's a perfectly sensible decision, as long as you don't have an irrational belief that jailbreaking is wrong
I've never figured out what is really supposed to happen when you shut off a worm-hole in mid-transit. In one episode of SG-1, some heavy material re-materializes inside of the nearby planet's sun (causing/solving the red sky and eminent doom). In another episode, Teal'c is trapped inside of the buffer, and his atoms are not just randomly lost at some point in space between the two gates. Also, there is at least one episode I can recall where a Jaffa retreating through a gate has his staff weapon cut in half when the gate shuts off. Also in the 2nd episode of the entire series of SG-1, Kawalsky had his head cut in half by them shutting down the gate while his head was partially in the wormhole. So the whole thing about transporting entire objects as one packet seems to be not true all of the time.
Can't believe I'm being this nerdy but everything you mention there is consistent in the show's canon
As you push things into the event horizon, they are dematerialised and stored in a buffer in the stargate - so if you stick the staff weapon (or your head) halfway in it's not "there" any more. Once the stargate decides the whole object is inside, it sends the data in the buffer to the other stargate via Sci Fi Awesomeness. It's sorta established that this is *not* instant. When the data gets there, the receiving stargate receives it into the buffer, and once the whole object is in the buffer, rematerialises it out of the event horizon.
So what happens when you shut the gate off depends what stage in this process you are at: if you shut off while a object is partly into the stargate then the bit in the stargate vanishes, no part of it was sent yet (the other half I guess is left in the buffer, but the buffer gets cleared when the gate connection *opens* at least). If you shut off while the 'signal' is in transit between the gates then you get the materialising in space scenario, which rematerialises it without its actual structure (just dumps the fundamental particles back out into 'reality'). Teal'c gets trapped in the buffer because the gate is malfunctioning and is refusing to rematerialise the objects it receives; they have to get him out before anyone else dials into the gate because this will clear the buffer and destroy his stored pattern.
So yah, it basically does transmit each object as a single "packet", but there is a buffering phase inside the stargate at each end to allow this, and the gates don't bother to push partially buffered objects back out if the connection is cut (guess the ancients weren't too big on safety).
The point is that you can exploit the machine remotely using some software bug, and then install such an update on the user's keyboard. The exploit running on the OS will reassure the exploit running on the keyboard that everything is OK periodically. If the user discovers their computer has been compromised and reinstalls the OS from clean media, the keyboard will no longer be told that the machine is still owned, and can reinstall the exploit by, say, typing in a suitable command once the keyboard is idle for some time and thus the user hopefully isn't looking at the screen.
Voila, a rootkit that persists even through clean OS reinstalls from trusted media!
Apple are one of the exceptions, which I should've stated in my post, sorry; I was replying to the previous poster's claim that *all* phones work this way, which is most certainly not true (and a vanishingly small proportion if you count low-end cellphones as well).
Apple, HTC and many of the Blackberry devices are dual chip, but these are a very small proportion of the global smartphone market which is dominated by Nokia and by the large Japanese manufacturers (who all use single chip designs for most or all of their devices).
The analogue components of the baseband (the actual radio) are a separate issue from the processor that runs the baseband communication stack; single chip phones still have a separate radio chipset, but it only handles the signal processing domain, not the protocols used to communicate with the cell tower. Radios are off the shelf components: some include a baseband processor, some do not, but both varieties are available from chip vendors and ones without a processor are significantly cheaper.
I've looked inside plenty of cellphones, by the way; I'm a realtime OS kernel developer for a major cellphone manufacturer, and have to deal with issues from the people developing the baseband stack quite often
For an example, pick any Nokia phone released since about, hm, 2002? Only Nokia's very earliest smartphones used a separate baseband processor. Motorola, Fujitsu, Sharp, Samsung, and probably many others also use single chip systems for the majority of their modern products.
HTC, Apple and BlackBerry are the exceptions; they are the small fry in the global cellphone market
Nokia and the large Japanese manufacturers all produce almost exclusively single-chip devices throughout their entire range of products, budget, midrange and high end smartphone. Current system-on-chips from TI, Samsung, Sharp, etc are explicitly designed to be able to support a baseband stack as well as the application OS on a single processor. This is also one of the major applications of ARM's TrustZone secure mode on the ARM1176 and above (isolating the RTOS/baseband from the application OS).
The manufacturers that produce single-chip phones generally use their own proprietary OS as the RTOS, so the licensing cost is zero: for example, Nokia S60 smartphones currently run Symbian as a task under NOS, their own OS which also powers S40/S30 phones (including the UI on those non-Symbian devices).
Most smartphone OSes have a public key infrastructure anyway, and modern ARM cores have support for a separate secure mode of execution which can be used to run the RTOS.
Most cellphones do *not* use a separate baseband processor, because this is expensive. Almost all non-smartphones only have one processor which runs a realtime proprietary OS responsible for both the UI and the modem stack: Nokia S40 is the prime example of this.
Some smartphones have a separate baseband processor, true, but only because the OS the application processor runs is not realtime and thus not capable of supporting a modem stack; and even then many of them just run the application OS as a subtask of another realtime OS on the same processor.
Having a separate baseband processor is a modern 'innovation' and is generally only used by smaller or less experienced smartphone manufacturers who cannot afford to spend the development effort coming up with a proper single-chip solution; the big players would not be willing to use a second processor, as this drives up the bill of materials cost and keeps them from pricing the device competitively for the midrange market.
Never call a man a fool. Borrow from him.
