Sorry, I should have said PulseAudio, not ALSA.

I've tried using LTS on some machines, but it hasn't worked out well. The trouble with it is that Ubuntu's quality is crap, and that applies to LTS releases just as much as non-LTS. For instance, they started gratuitously breaking sound with Jaunty, and as of Precise it's still broken on some machines I use. When important stuff is randomly broken in an LTS release, you end up upgrading to a non-LTS to see if they've fixed the bug.

The root problem is that Ubuntu is more interested in random, useless crap like Unity and ALSA than they are in just fixing bugs and making something that works. Rolling releases won't make that any better or worse. You'll get the bug fixes sooner, but you'll also get new bugs sooner.

Here's what worked for me on debian. See https://kb.askmonty.org/en/how-can-i-upgrade-from-mysql-to-mariadb/

mysql --version # I'm running 5.0, am supposed to upgrade to mysql 5.2 or later to run mariadb 5.2
mysql_upgrade -p # upgrades me to 5.1, no 5.2 available; will just try installing mariadb 5.2 and see if it works
mysqldump -u root -p --all-databases > whole_database.sql # shouldn't be needed, but just in case
mysqladmin -u root -p shutdown
apt-get remove mysql-server

Now install MariaDB.

https://kb.askmonty.org/en/installing-mariadb-deb-files/

apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
cat /etc/issue # tells me I'm running debian 6.0, which is squeeze, http://en.wikipedia.org/wiki/Debian#Release_history
# use this web ui to generate text to put in sources.list
# https://downloads.mariadb.org/mariadb/repositories/
cat >/etc/apt/sources.list.d/MariaDB.list
# ...cut and paste into this newly created file
apt-get update
apt-get install mariadb-server
mysql -u root -p # still called mysql for compatibility, but it comes up and identifies itself as mariadb
show databases; # all still there, no need to restore from backup

The mysql binary, etc., are all still named the same thing for compatibility, so, e.g., there's no need to change the cron jobs that back up my database.

The Wikipedia article is much better than the Byte article. (Do people still read Byte? I don't remember seeing it since the 80's.)

One thing that seems a little different from Y2K is that this bug seems to be prevalent in a lot of embedded systems. To me that seems harder to test than a desktop system. On a desktop system, you can just set the time to Dec. 31, 2037, let it roll over, and test as much stuff as possible to see if it broke. You can't do that with a car or an airliner.

The crappy little superficial one-page MIT Technology Review article has a link to another, similarly crappy article on the same site, but if you click through one more layer you actually get to this much more substantial piece in the New Yorker.

Total nonsense. This is like saying that people get electrocuted by their toasters, and people get electrocuted repairing downed power lines, so toasters are just as dangerous as downed power lines. Toasters are safe by design. So is the java applet sandbox.

Plenty of people are still using java applets. I use them. They're commonly used in medicine, banking, and law offices.

Or are you claiming that the version of the browser plugin "made by Oracle" is the only one broken? If so, could you explain what you're basing that claim on? As far as I know, groups like IcedTea use Oracle's code extensively, and all of these bugs are likely to be present in all implementations of the Java 7 applet sandbox.

I don't own a cell phone. Various online services such as google keep badgering my to associate my account with a cell phone number. I can't, don't want to, and don't need to. Their desire to do this is a desire for their own convenience, not mine. If some other user writes his google password on a post-it and then loses the post-it, google wants a method by which it's easy for google to retain the guy as a customer by giving the guy back his password. They want to do this with zero labor cost to them. They don't want to do it by email because if the guy's forgotten his gmail password he can't access his gmail. All of this has to do with what google wants, not with what I want.

TFA says, "Passwords are a cheap and easy way to authenticate web surfers, but they're not secure enough for today's internet, and they never will be," with a link to this article by someone named Mat Honan. Honan says:

Um, no. I don't use the same password for all these different things. Anyone who does is a fool. And no, I don't post naked pictures of myself online, with or without password protection.

No. This guy obviously has no clue. Web sites typically store a hash of your password, not the password itself. And if you don't reuse the same password for multiple important accounts, there are no major ramifications from having your password for, say, facebook released into the wild, because it's not the same as your password for your bank account, etc. If someone uses a single password for every single account they have, then they're asking for trouble. That's their problem, not mine, and it's not a generic problem with passwords, it's a specific problem with the insecure way those people use passwords.

What the hell does he mean by "linked?" This makes no sense.

If AOL does this, then AOL is a bunch of idiots. This has nothing to do with the security of passwords in general.

Your password can't be guessed or cracked by brute force if you pick a good password. It can't be "lifted from a password dump" if whoever you have the account with stores it in hashed form. If it's being stolen through a keylogger on your computer, then you have a bigger problem than the insecurity of your gmail account. Social engineering methods are the hardest to protect against, but the damage is mitigated if you don't reuse the same password for multiple high-stakes accounts, and in any case, switching from authentication via a password to authentication via a physical object such as a phone doesn't do anything about social engineering attacks. Someone can call google, say they're me, and say I lost my phone.

What I like is that it cuts down on the effort required to manage different projects. The 14 projects that I now have on github all used to have different makefiles used for building tarballs and posting them publicly. Each used to have a web page saying stuff like "the current version is 3.1.5," which had to be edited when I put out a new version. Now all of that stuff is automatic. I just do a git tag and a git push, and bam, it's there. I had material on the individual web pages which is now in each project's README.md file on github. When I want to change it, I just edit README.md, and then next time I do a push, it'll be there on github.

It's a shame that github's web interface isn't 100% open source, but many parts of it are (e.g., https://github.com/github/linguist ), and there is no major vendor lock-in, either. They're just hosting my git repo. If I fall out of love with them, I still have my repo and can just host it somewhere else.

In this context, the meaning of violating causality is this. Let events A and B be such that motion at greater than c is necessary to get from one to the other. Then there exist frames in which A occurs before B, and also frames in which B occurs before A.

Oops, I actually gave the wrong reference. The correct one is this:

Vieira, An Introduction to the Theory of Tachyons, 2011, http://arxiv.org/abs/1112.4187

If you want to have an observer, you have to have a frame of reference for that observer. Having such a frame of reference means that you have to be able to define some way of converting from that frame into other frames, such as frames that are not FTL relative to the stars. Various people, going back at least as far as 1986, have worked out a way of extending the usual Lorentz transformations so that they connect frames that have relative velocities greater than c. Suppose you have two frames A and B that are moving relative to one another at a speed greater than c. Alice is an observer in frame A, Bob in B. What ends up happening is that Alice says she's made of bradyons (particles that go slower than c), and she sees Bob as being made out of tachyons. But Bob sees himself as being made of bradyons and Alice of tachyons. Also, what Alice perceives to be a time axis Bob says is a spatial one, and what Alice says is space Bob says is time. This final part is the one that makes it not work in 3+1 dimensions. There is no mathematically consistent way to carry the whole thing through if the number of time and space dimensions isn't equal.

And every time we use GPS, we're using a tool that would not work at all without general relativity.

And even so, theorists were very enthusiastic about trying to modify SR accomodate the superluminal neutrino results from 2011. Unfortunately those results turned out to be due to a loose cable.

The slashdot summary is totally inaccurate. It makes it sound as though the paper calculates what would be seen by an observer going faster than c relative to the stars, but actually the paper calculates what would be seen by an observer going at v=0.9999995c.

There is also basically nothing new in this paper. The effects they describe (relativistic aberration and Doppler shifts) have been well understood for a long time. ANU has made a nice educational video showing these effects.

The question of how things would look if you could go faster than c relative to the stars is a whole different issue. Special relativity doesn't forbid relative motion faster than c, but it puts a bunch of constraints on it: (1) it can't be achieved by a continuous process of acceleration from velocities less than c; (2) if it exists, it violates causality; and (3) although special relativity is consistent with the existence of faster-than-light particles (tachyons), it is not consistent with the existence of faster-than-light observers in a universe with 3 spatial dimensions and 1 time dimension, a.k.a. 3+1 dimensions. Result #3 (no tachyonic observers in 3+1 dimensions) has been known for a long time, but it seems to keep getting rediscovered.

http://noscript.net/faq#qa1_3

http://forums.mozillazine.org/viewtopic.php?p=1586359&highlight=flashblock+noscript#1586359

http://flashblock.mozdev.org/faq.html#fbNojavascript

But anyway I think the real problem with noscript is the untrustworthy behavior of its author.

There are unfortunately lots of problems with noscript.

Noscript is incompatible with flashblock.

Noscript's codebase has a reputation for being a mess.

I stopped using noscript in 2009, because of a variety of issues related to their attempts to maximize ad impressions on their site. It does extremely frequent updates, sending you to its home page every time. It is possible to defeat this, about:config, if you set noscript.firstRunRedirection to false. In May 2009, they got in some kind of a war with adblock: http://news.slashdot.org/article.pl?sid=09/05/01/236248&art_pos=1 They were modifying the behavior of adblock, and some of the code of noscript was obfuscated. In general, the behavior of the noscript developers seems irresponsible, sneaky, and deceptive. I don't want to fix a security problem on my machine by installing software written by people who behave ... kind of in the same scummy way as the people I was trying to protect myself from in the first place.