I use Caps Lock as my compose key, and fix two problems at once (not having a compose key, and hitting Caps Lock by mistake; hitting Compose by mistake is pretty minor, really).
Right Alt is pretty useful if you aren't American; it tends to be used to type a bunch of accented or non-ASCII characters in Europe, for instance (notably, the euro currency symbol, which is standardised as right alt+4 on all the major OSes at this point).
More to the point, it's trivial to break a chroot on Linux if you have root access; it's not designed to be secure against someone with root permissions. (You create a second chroot inside the original chroot, and move your shell inside it but keep the working directory between the two chroots. Then you can just do cd.. until you reach the original root, and chroot again to reset the root to its original value.) I think this is intentional; there are plenty of other ways to break a chroot as root, but they tend to be more destructive, so having an easy way out is nice. (This is also the reason that chroots can only be created as root; otherwise, they'd be no security even against unprivileged users.)
Not at all. You only apply the "patch" when debugging symbols are off and optimisation is on, which would cover nearly any production build. Even if you left in debugging symbols, you would still have a hard time discovering it with a debugger since optimisation is supposed do change the output.
You would also make it trigger under very special circumstances and as others have pointed out, the error you introduce could be a subtle change of behaviour of the random number generator.
If you did that, the backdoor would disappear over the course of time whenever someone released a production compiler that was compiled with a debugging-symbol version of the same compiler. (This is a lot more likely than it seems; the people who actually develop compilers, and thus compile them, are likely to have debugging symbols on for their compilers as a matter of course, because they frequently make changes that break them.)
/dev/random blocks if it feels that there wasn't enough entropy gathered from the environment to produce a truly random number./dev/urandom will never block; rather, if there isn't enough entropy gathered from the environment, it will give you a cryptographically secure pseudorandom number instead. So the difference basically depends on what level of true randomness you need; in general,/dev/urandom is just fine for all applications except cryptography, and if you're doing cryptography, you shouldn't be using either directly but rather relying on a crypto library anyway (and the library probably uses/dev/random, possibly among other things).
The AC used to be correct, but gcc have been trying to clean up more recently. (Most likely, at least partly because competition from clang meant that trying to lock out third-party closed-source plugins wasn't a particularly useful thing to do anyway.)
I remember to set a quick LC_ALL=C when I'm doing anything that might have to parse the output of a shell command (typically just on that command, rather than exported). Including the space you need to separate it from the command, it's what, nine characters? (And as a bonus, it forces things like the decimal point convention to known values too.)
(By the way, "C" is a better setting than any specific language, including English; its entire purpose is to be as portable as possible across computers. I've actually also come across programs that give more 'friendly' output on, say, "en_US.UTF-8" than they do on "C"; it's the difference between knowing that your output will be read by a human, or by a computer.)
I think Duckduckgo is actually using Yandex behind the scenes now, rather than Bing (sometimes they give an attribution to that effect). Possibly even both.
INTERCAL uses the same character for opening and closing parenthesis (' or ", the programmer can choose, and occasionally has to mix them to resolve ambiguity). This is not particularly easy to read, although it is normally unambiguous; look at my signature for an example.
The private key is normally protected by a password, without which it won't/can't work. The password doesn't need to be sent anywhere in order to work correctly.
SSH keys are actually one of the easiest ways to get two-factor authentication ("something you have" = the encrypted private key, "something you know" = the password to decrypt it.
A bunch of Pokémon fansites were hacked recently (here's one reasonably detailed report from one of the sites). Although as far as I know no plaintext passwords were stored on any of the servers, there were a bunch of password hash databases taken; and because Pokémon is a Nintendo property, Nintendo's website would be an obvious place to try any username/password pairs that were weak enough to be reversed from the databases (and some plaintext passwords would be available as a result of compromised login forms).
Many of the hacked sites (that I know about, at least) were reasonably small, with user counts measured in thousands; as such, 24 thousand total seems to be a reasonable estimate for the number of accounts that might have been affected.
Well, I can't drive, so there'd be a passenger in the car who could make the call. (As such, I'm very used to car-sharing, because I don't know of any other sort of driving; if I'm in a car, there's always a passenger able to make the call.)
I'm thinking of situations like "needing to pick someone up in an emergency (with limited time) and trying to contact them to verify where they are". If you pull over in order to make the call, then you're going to have to break the speed limit in order to get there on time, which is dangerous in a different way. If a passenger's making the call, there's no danger involved, and so things are safer all around.
The problem with trying to do that via technical means is that I've seen several situations where a passenger needs to use a cellphone while a car is driving. It can't be very technically easy to distinguish between a driver using a phone, and a passenger using a phone.
There's a similar law in the UK, and companies generally comply with the letter. (Although I've seen some interesting ways of working around the spirit; one form I saw asked for permission to use the information in a variety of ways, which were opt-ins and opt-outs more or less at random, so you had to read it carefully to determine which boxes to tick.)
Unlike the Windows 8 version, the Canonical version appears to be to use the same codebase for the tablet and desktop programs, but to have a different interface for each. (It's entirely possible to put multiple interfaces in one codebase or even one binary; NetHack has been doing it for years.)
What's probably more interesting was their fix for the problem. Instead of trying to do any sort of rollback (although they did find people with impossibly high currency amounts and reduce them to saner values), they put a large amount of very expensive trophy items for sale which didn't do anything useful, in the hope that people would put their newfound wealth to an amusing trivial cause.
It doesn't. You can do it with two clicks in two different ways, but as far as I know, there's no way to pin the applications lens, which is what would be required to do it in one. (They have fixed the dock, now, though.)
The way it's done in the UK is that the shop (whether it's a small corner shop, or a large chain) charges you the tax anyway and gives you a receipt with a tax breakdown (as they're required to do on request, by the law). Then you take the receipt to a tax reclaiming kiosk with proof that you're not a UK national and are only there for a short time (holiday or the like), and they give you a refund for the tax. (They tend to be at airports, for obvious reasons; they wouldn't really be required anywhere else.) This way, the shops don't have to worry about establishing whether someone's meant to pay tax or not; all that complex handling can be centralized.
Basically the problem is that OpenGL has a lot of old cruft in that people have been trying to get rid of for a while, that made sense at the time but nowadays only exists for backwards compatibility. OpenGL ES is gaining in prominence because it looks like it might actually be a chance to make a clean break with OpenGL's past.
Unless they've done something stupid like copying the documentation word for word, or stealing source code, it isn't likely that there will be copyright-related problems. (And giving it a different name means that trademark-related problems are also unlikely.) People are mostly scared about patents, instead.
Slashdot Mirror
I use Caps Lock as my compose key, and fix two problems at once (not having a compose key, and hitting Caps Lock by mistake; hitting Compose by mistake is pretty minor, really).
Right Alt is pretty useful if you aren't American; it tends to be used to type a bunch of accented or non-ASCII characters in Europe, for instance (notably, the euro currency symbol, which is standardised as right alt+4 on all the major OSes at this point).
More to the point, it's trivial to break a chroot on Linux if you have root access; it's not designed to be secure against someone with root permissions. (You create a second chroot inside the original chroot, and move your shell inside it but keep the working directory between the two chroots. Then you can just do cd .. until you reach the original root, and chroot again to reset the root to its original value.) I think this is intentional; there are plenty of other ways to break a chroot as root, but they tend to be more destructive, so having an easy way out is nice. (This is also the reason that chroots can only be created as root; otherwise, they'd be no security even against unprivileged users.)
Not at all. You only apply the "patch" when debugging symbols are off and optimisation is on, which would cover nearly any production build. Even if you left in debugging symbols, you would still have a hard time discovering it with a debugger since optimisation is supposed do change the output.
You would also make it trigger under very special circumstances and as others have pointed out, the error you introduce could be a subtle change of behaviour of the random number generator.
If you did that, the backdoor would disappear over the course of time whenever someone released a production compiler that was compiled with a debugging-symbol version of the same compiler. (This is a lot more likely than it seems; the people who actually develop compilers, and thus compile them, are likely to have debugging symbols on for their compilers as a matter of course, because they frequently make changes that break them.)
/dev/random blocks if it feels that there wasn't enough entropy gathered from the environment to produce a truly random number. /dev/urandom will never block; rather, if there isn't enough entropy gathered from the environment, it will give you a cryptographically secure pseudorandom number instead. So the difference basically depends on what level of true randomness you need; in general, /dev/urandom is just fine for all applications except cryptography, and if you're doing cryptography, you shouldn't be using either directly but rather relying on a crypto library anyway (and the library probably uses /dev/random, possibly among other things).
The AC used to be correct, but gcc have been trying to clean up more recently. (Most likely, at least partly because competition from clang meant that trying to lock out third-party closed-source plugins wasn't a particularly useful thing to do anyway.)
I remember to set a quick LC_ALL=C when I'm doing anything that might have to parse the output of a shell command (typically just on that command, rather than exported). Including the space you need to separate it from the command, it's what, nine characters? (And as a bonus, it forces things like the decimal point convention to known values too.)
(By the way, "C" is a better setting than any specific language, including English; its entire purpose is to be as portable as possible across computers. I've actually also come across programs that give more 'friendly' output on, say, "en_US.UTF-8" than they do on "C"; it's the difference between knowing that your output will be read by a human, or by a computer.)
I think Duckduckgo is actually using Yandex behind the scenes now, rather than Bing (sometimes they give an attribution to that effect). Possibly even both.
INTERCAL uses the same character for opening and closing parenthesis (' or ", the programmer can choose, and occasionally has to mix them to resolve ambiguity). This is not particularly easy to read, although it is normally unambiguous; look at my signature for an example.
Most likely, both. (It would even likely cause an increase in BSD use, although BSD would still have insignificant market share even then.)
The private key is normally protected by a password, without which it won't/can't work. The password doesn't need to be sent anywhere in order to work correctly.
SSH keys are actually one of the easiest ways to get two-factor authentication ("something you have" = the encrypted private key, "something you know" = the password to decrypt it.
A bunch of Pokémon fansites were hacked recently (here's one reasonably detailed report from one of the sites). Although as far as I know no plaintext passwords were stored on any of the servers, there were a bunch of password hash databases taken; and because Pokémon is a Nintendo property, Nintendo's website would be an obvious place to try any username/password pairs that were weak enough to be reversed from the databases (and some plaintext passwords would be available as a result of compromised login forms).
Many of the hacked sites (that I know about, at least) were reasonably small, with user counts measured in thousands; as such, 24 thousand total seems to be a reasonable estimate for the number of accounts that might have been affected.
Well, I can't drive, so there'd be a passenger in the car who could make the call. (As such, I'm very used to car-sharing, because I don't know of any other sort of driving; if I'm in a car, there's always a passenger able to make the call.)
I'm thinking of situations like "needing to pick someone up in an emergency (with limited time) and trying to contact them to verify where they are". If you pull over in order to make the call, then you're going to have to break the speed limit in order to get there on time, which is dangerous in a different way. If a passenger's making the call, there's no danger involved, and so things are safer all around.
The problem with trying to do that via technical means is that I've seen several situations where a passenger needs to use a cellphone while a car is driving. It can't be very technically easy to distinguish between a driver using a phone, and a passenger using a phone.
It's basically done per household, and indirectly for all the people in the household in some special cases (e.g. portable TVs used inside cars).
There's a similar law in the UK, and companies generally comply with the letter. (Although I've seen some interesting ways of working around the spirit; one form I saw asked for permission to use the information in a variety of ways, which were opt-ins and opt-outs more or less at random, so you had to read it carefully to determine which boxes to tick.)
Unlike the Windows 8 version, the Canonical version appears to be to use the same codebase for the tablet and desktop programs, but to have a different interface for each. (It's entirely possible to put multiple interfaces in one codebase or even one binary; NetHack has been doing it for years.)
What's probably more interesting was their fix for the problem. Instead of trying to do any sort of rollback (although they did find people with impossibly high currency amounts and reduce them to saner values), they put a large amount of very expensive trophy items for sale which didn't do anything useful, in the hope that people would put their newfound wealth to an amusing trivial cause.
It doesn't. You can do it with two clicks in two different ways, but as far as I know, there's no way to pin the applications lens, which is what would be required to do it in one. (They have fixed the dock, now, though.)
The way it's done in the UK is that the shop (whether it's a small corner shop, or a large chain) charges you the tax anyway and gives you a receipt with a tax breakdown (as they're required to do on request, by the law). Then you take the receipt to a tax reclaiming kiosk with proof that you're not a UK national and are only there for a short time (holiday or the like), and they give you a refund for the tax. (They tend to be at airports, for obvious reasons; they wouldn't really be required anywhere else.) This way, the shops don't have to worry about establishing whether someone's meant to pay tax or not; all that complex handling can be centralized.
Is it possible that the address was spoofed? (Perhaps because they were reflecting attacks off your computer.)
Basically the problem is that OpenGL has a lot of old cruft in that people have been trying to get rid of for a while, that made sense at the time but nowadays only exists for backwards compatibility. OpenGL ES is gaining in prominence because it looks like it might actually be a chance to make a clean break with OpenGL's past.
Unless they've done something stupid like copying the documentation word for word, or stealing source code, it isn't likely that there will be copyright-related problems. (And giving it a different name means that trademark-related problems are also unlikely.) People are mostly scared about patents, instead.
The same bug can brick Samsung laptops on Windows too. It's just that it was noticed on Linux first.