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 :) It just happens that the US smartphone market has radically different market share proportions than the worldwide one :)

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.