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.
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:) 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.
Clarification of what ARMv7 means
on
Ubuntu Ports To ARM
·
· Score: 5, Informative
Lots of people are getting mixed up, and/or saying "big deal Debian already supports it". ARM has a slightly confusing numbering scheme: ARM7, ARM9, ARM11, Cortex-A8 are processor models, whereas ARMv4, ARMv5, ARMv6, ARMv7 are their respective architecture versions.
Pretty much all current ARM devices are ARM9 or ARM11 based (smartphones, Nokia's internet tablets, etc). This means they are too old to run this:)
The Pandora, and other upcoming devices, are based on the Cortex-A8, an ARMv7 architecture processor and the most recent ARM currently generally available: this is what Ubuntu are targeting here.
Debian's ARM port is for any ARMv4t or higher currently, which includes ARM11, ARM9 and even ARM7TDMI. This is rather suboptimal for chips like the Cortex-A8 which have many, many more instructions available, so Ubuntu are indeed doing something different here.
Bittorrent *is* used by people who wish to transfer material in breach of copyright because it is fast, practical and can be fairly anonymous but that is not its sole purpose and it is just as easy to use other methods to distribute that material as it would be to use alternate methods to distribute Linux.
BitTorrent is absolutely not anonymous at all. Anyone in the world can connect to the tracker and get a list of IP addresses which are currently in the swarm, and then connect to these IP addresses and ask for blocks of data to verify they are in fact serving up the material. It's used for copyright infringement solely because it's fast and easy:)
Just my 2 cents, but why compile something for heat? A lot of the electricity used doesn't go towards the heat (modern CPUs are designed to produce as little heat as possible).
Er, yes it does. Where else would it go? The energy taken to actually do computation is tiny (since only information erasure requires energy input - see laws of thermodynamics) - my understanding is that it's something like 99.9% dissipated as heat.
For an example, see Apple's figures here: http://docs.info.apple.com/article.html?artnum=86694 The first CPU listed consumes 170W when fully loaded, and outputs 580 BTU/h of heat. Wikipedia says 1W is about 3.41 BTU/h, so that's spot on.
AFAIK - no. Man In The Middle would be possible (if difficult) at the moment of pairing.
That would be what I implied, yes, when I said "If you were not privy to the pairing between the two devices".
You could also try to hack the keyboard controller itself
Bluetooth HID controllers are very simple, and pretty standardised, so this is possible but very unlikely.
or use vulnerablities of the PC with bluetooth plugged in and active (the dongle must be working to allow the keyboard to connect) depending on what besides keyboard the PC allows.
This kind of thing is always possible, but it's nothing to do with compromising the privacy of the keyboard's connection.
I'm also not sure you can't try coupling with the PC acting as its keyboard while the real keyboard is off (then you don't snoop but you have actual access.)
The PC's bluetooth stack would have to be very broken indeed to allow this - HID devices would not normally be allowed to initiate pairing.
These are all guesses on my side though. I don't know if any actual work was done in this direction.
OK, that's a different class of attack than described in the paper entirely, but that's *still* not the ability to intercept an existing paired connection. The attack you describe is to be able to connect to a device, regardless of it being discoverable or it wanting to talk to you - which is bad, but will not work on a keyboard/mouse that is already paired with a host, as they don't support multiple associations and will just ignore anyone but their pairing partner until the user hits the button on the bottom again. When two devices that are already paired (e.g. your PC and your keyboard/mouse) connect, they establish a session key using data that was already sent over the air and stored at pairing-time. If you were not privy to the pairing between the two devices, you cannot crack this to read the data unless a fundamental weakness in the encryption algorithm in use is discovered.
So, for Bluetooth profiles which require pairing (audio, input devices, networking - but not OBEX or similar) this attack will only work if the device is unpaired or supports multiple pairings, and only if you know the pairing key (which for a lot of input/audio devices is 0000, sadly). As far as I know it won't work on my Bluetooth mouse unless you are listening at the time I hit the 'make connection' button, as there's not much of a conceivable avenue for attack there - unless you have a citation?
Bluebag Project can crack any bluetooth device in some 6 hours. The current form of it has a potential to increase the speed 8 times (currently it uses 8 dongles to scan possible 64 channels in paralell. If you use 64 bluetooth dongles to scan one channel each, you gain a lot of speed).
The article you reference has absolutely nothing to do with cracking Bluetooth as far as I can see, though it does mention several security flaws in implementations in the introduction. It's talking about going around trying to propagate malware over Bluetooth file transfer by automatically scanning for devices and sending them files. This doesn't require a pairing association and doesn't require breaking anything - the devices they found were all discoverable and configured to respond to any random device that tries to talk to them - and on any sane device the user would have to accept the malware explicitly;)
I'm not aware of any success in actually cracking communication between two already-paired Bluetooth devices, though there are some theoretical weaknesses that would allow you to eavesdrop if you were present and listening *during* the initial pairing process. Your Bluetooth keyboard/mouse only need to be paired once unless you move them to a different machine, so as long as you weren't being eavesdropped during setup, you should, for now, be secure.
And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.
There's no such thing as "locked down in hardware" for telephony stacks - the stack is firmware as well and thus subject to being reflashed and modified. OpenMoko and similar devices have a separate baseband processor which runs its own firmware, which you talk to over a serial interface - the application processor runs free software, the baseband processor doesn't.
But.. handset manufacturers in general are moving towards a single-processor model - a separate baseband processor costs money. Either they run an RTOS which has the entire application stack as a task (so, your OS is effectively being context switched in and out, whether it's Linux or whatever) and the telephony stack as a separate task - which is also going to be nonfree - or they run Symbian, which has a hard realtime microkernel and can support a telephony stack running on that alongside Symbian tasks - which is nonfree.:)
So, while openmoko and similar might choose to make hardware designs that allow it to be 'truly open' - assuming you choose to call it that - other handset manufacturers probably won't, your free software will be stuck running on a closed RTOS to support the telephony stack.
remapping failed blocks from a small pool of reserved good ones Is that before or after you save data to that block?!
During. Flash blocks fail while you are writing to them (or more specifically, when you are reading back the data to verify the write), so you have the data you wanted to write right there to save to another block. Flash blocks, under normal circumstances, don't go bad when they are just storing data or having it read out.
Now for the serious part of the discussion: How does flash determine when a block failed? I know regular hard disks use this feature too, but how does it determine a block failed also? If a block fails, how would it be able to recover the data contained there? How does wear leveling fit into securely erasing flash storage? Even if you overwrite a block, how can you be sure it was really overwritten?
Flash block remapping normally works by detecting write failures as above, so you don't need to recover any data. HDDs do it by using ECC, usually by marking sectors as bad after errors are detected and corrected (so unless it's so bad it's gone past the ECC correction threshold you keep your data).
Wear levelling makes it impossible to securely erase flash storage without taking flash-chip specific measures.
(Total units sold) less (contracts with AT&T) != (number sold with intent to unlock).
Missing from this oversimplified calculation are iPhones sold but not yet registered with AT&T. This would include (and is potentially a figure large enough to throw off their estimate) iPhones sold to non-registered resellers.
True, but also missing from this are iPhones sold, registered with AT&T, and then unlocked anyway, perhaps because they were registered before the method for unlocking was known, or because they were resold to someone else intending to unlock it.
Take MySQL for example, they seem to believe that any program that _connects_ to the database is now under the GPL and requires a special commercial license ($$$$$$$$) if you want an exemption.
No, MySQL believe that any program which uses their GPLed client library, libmysqlclient, to connect to the database is now under the GPL. This is obviously true, because one of the explicit purposes of the GPL is to require you to GPL your code if you distribute it linked against a GPLed library.
If you can manage to connect to the database without using their client library, then you can write all the non-GPLed software you want with no obligation whatsoever to buy a commercial licence. You'll find your software breaks whenever MySQL changes their protocol (as you won't automatically get the benefit of a newer client library), but that's your choice.
But I am curious as well now, I know it's main player is mplayer, but regarding the gui and everything else, I thought it was all written with a modified version of linux? I guess not, but a better explanation there would be interesting.
No, XBMC runs on top of MS's standard Xbox kernel (well, standard except for being patched to support binaries not signed by Microsoft, and often a few other features such as hard disks larger than 137GB), using MS's standard Xbox libraries for IO, the same as an Xbox game does. No Linux is involved at all.
Sounds likely. I mostly do BREW and WinCE (and the Windows and Linux builds that I didn't even bother mentioning). Just keeping up to date with what's hot and what's dropped is a task that I'd rather skip.
I'm a Symbian kernel developer, so I'm pretty familiar with what's compatible with what there whether I want to be or not:)
I think that list is a little unfair, Symbian series 60 version 1 software works fine on Symbian Series 60 version 3 it doesn't take much to convert this over to UIQ (admitting i've only run this in simulation)
Nope, S60 3.x is binary and source incompatible with older S60 versions. UIQ is a totally different UI layer and requires that all UI-related parts of your code be more or less totally rewritten. UIQ 3.x is also binary and source incompatible with older UIQ versions - it's likely not included on the grandparent poster's list as UIQ 3 is not a very popular platform yet:)
Both S60 version 3 and UIQ version 3 are based on a new underlying version of Symbian (9.1 and later) which uses a new kernel and is absolutely not binary compatible.
I'll have you know I have many good friends that let me hit them -- quite hard -- in some circumstances.
Ever heard of BDSM?
I'm pretty sure that if Bill had the ball gag and and leather restraints on, most jurisdictions would not prosecute.
Actually, in many jurisdictions this is in fact still counted as assault/similar and is still criminal. In the UK an ongoing campaign named for a previous case has existed for some years (http://www.spannertrust.org/).
Slashdot Mirror
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.
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) :)
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.
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 :)
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.
Lots of people are getting mixed up, and/or saying "big deal Debian already supports it". ARM has a slightly confusing numbering scheme: ARM7, ARM9, ARM11, Cortex-A8 are processor models, whereas ARMv4, ARMv5, ARMv6, ARMv7 are their respective architecture versions.
Pretty much all current ARM devices are ARM9 or ARM11 based (smartphones, Nokia's internet tablets, etc). This means they are too old to run this :)
The Pandora, and other upcoming devices, are based on the Cortex-A8, an ARMv7 architecture processor and the most recent ARM currently generally available: this is what Ubuntu are targeting here.
Debian's ARM port is for any ARMv4t or higher currently, which includes ARM11, ARM9 and even ARM7TDMI. This is rather suboptimal for chips like the Cortex-A8 which have many, many more instructions available, so Ubuntu are indeed doing something different here.
BitTorrent is absolutely not anonymous at all. Anyone in the world can connect to the tracker and get a list of IP addresses which are currently in the swarm, and then connect to these IP addresses and ask for blocks of data to verify they are in fact serving up the material. It's used for copyright infringement solely because it's fast and easy
Er, yes it does. Where else would it go? The energy taken to actually do computation is tiny (since only information erasure requires energy input - see laws of thermodynamics) - my understanding is that it's something like 99.9% dissipated as heat.
For an example, see Apple's figures here: http://docs.info.apple.com/article.html?artnum=86694
The first CPU listed consumes 170W when fully loaded, and outputs 580 BTU/h of heat. Wikipedia says 1W is about 3.41 BTU/h, so that's spot on.
That would be what I implied, yes, when I said "If you were not privy to the pairing between the two devices".
Bluetooth HID controllers are very simple, and pretty standardised, so this is possible but very unlikely.
This kind of thing is always possible, but it's nothing to do with compromising the privacy of the keyboard's connection.
The PC's bluetooth stack would have to be very broken indeed to allow this - HID devices would not normally be allowed to initiate pairing.
Stop guessing, then?
OK, that's a different class of attack than described in the paper entirely, but that's *still* not the ability to intercept an existing paired connection. The attack you describe is to be able to connect to a device, regardless of it being discoverable or it wanting to talk to you - which is bad, but will not work on a keyboard/mouse that is already paired with a host, as they don't support multiple associations and will just ignore anyone but their pairing partner until the user hits the button on the bottom again. When two devices that are already paired (e.g. your PC and your keyboard/mouse) connect, they establish a session key using data that was already sent over the air and stored at pairing-time. If you were not privy to the pairing between the two devices, you cannot crack this to read the data unless a fundamental weakness in the encryption algorithm in use is discovered.
So, for Bluetooth profiles which require pairing (audio, input devices, networking - but not OBEX or similar) this attack will only work if the device is unpaired or supports multiple pairings, and only if you know the pairing key (which for a lot of input/audio devices is 0000, sadly). As far as I know it won't work on my Bluetooth mouse unless you are listening at the time I hit the 'make connection' button, as there's not much of a conceivable avenue for attack there - unless you have a citation?
The article you reference has absolutely nothing to do with cracking Bluetooth as far as I can see, though it does mention several security flaws in implementations in the introduction. It's talking about going around trying to propagate malware over Bluetooth file transfer by automatically scanning for devices and sending them files. This doesn't require a pairing association and doesn't require breaking anything - the devices they found were all discoverable and configured to respond to any random device that tries to talk to them - and on any sane device the user would have to accept the malware explicitly
I'm not aware of any success in actually cracking communication between two already-paired Bluetooth devices, though there are some theoretical weaknesses that would allow you to eavesdrop if you were present and listening *during* the initial pairing process. Your Bluetooth keyboard/mouse only need to be paired once unless you move them to a different machine, so as long as you weren't being eavesdropped during setup, you should, for now, be secure.
There's no such thing as "locked down in hardware" for telephony stacks - the stack is firmware as well and thus subject to being reflashed and modified. OpenMoko and similar devices have a separate baseband processor which runs its own firmware, which you talk to over a serial interface - the application processor runs free software, the baseband processor doesn't.
But.. handset manufacturers in general are moving towards a single-processor model - a separate baseband processor costs money. Either they run an RTOS which has the entire application stack as a task (so, your OS is effectively being context switched in and out, whether it's Linux or whatever) and the telephony stack as a separate task - which is also going to be nonfree - or they run Symbian, which has a hard realtime microkernel and can support a telephony stack running on that alongside Symbian tasks - which is nonfree.
So, while openmoko and similar might choose to make hardware designs that allow it to be 'truly open' - assuming you choose to call it that - other handset manufacturers probably won't, your free software will be stuck running on a closed RTOS to support the telephony stack.
During. Flash blocks fail while you are writing to them (or more specifically, when you are reading back the data to verify the write), so you have the data you wanted to write right there to save to another block. Flash blocks, under normal circumstances, don't go bad when they are just storing data or having it read out.
Flash block remapping normally works by detecting write failures as above, so you don't need to recover any data. HDDs do it by using ECC, usually by marking sectors as bad after errors are detected and corrected (so unless it's so bad it's gone past the ECC correction threshold you keep your data).
Wear levelling makes it impossible to securely erase flash storage without taking flash-chip specific measures.
True, but also missing from this are iPhones sold, registered with AT&T, and then unlocked anyway, perhaps because they were registered before the method for unlocking was known, or because they were resold to someone else intending to unlock it.
So who knows.
No, MySQL believe that any program which uses their GPLed client library, libmysqlclient, to connect to the database is now under the GPL. This is obviously true, because one of the explicit purposes of the GPL is to require you to GPL your code if you distribute it linked against a GPLed library.
If you can manage to connect to the database without using their client library, then you can write all the non-GPLed software you want with no obligation whatsoever to buy a commercial licence. You'll find your software breaks whenever MySQL changes their protocol (as you won't automatically get the benefit of a newer client library), but that's your choice.
No, XBMC runs on top of MS's standard Xbox kernel (well, standard except for being patched to support binaries not signed by Microsoft, and often a few other features such as hard disks larger than 137GB), using MS's standard Xbox libraries for IO, the same as an Xbox game does. No Linux is involved at all.
I'm a Symbian kernel developer, so I'm pretty familiar with what's compatible with what there whether I want to be or not
Nope, S60 3.x is binary and source incompatible with older S60 versions. UIQ is a totally different UI layer and requires that all UI-related parts of your code be more or less totally rewritten. UIQ 3.x is also binary and source incompatible with older UIQ versions - it's likely not included on the grandparent poster's list as UIQ 3 is not a very popular platform yet
Both S60 version 3 and UIQ version 3 are based on a new underlying version of Symbian (9.1 and later) which uses a new kernel and is absolutely not binary compatible.
Actually, in many jurisdictions this is in fact still counted as assault/similar and is still criminal. In the UK an ongoing campaign named for a previous case has existed for some years (http://www.spannertrust.org/).