Search for "#!/bin/bash".

I think that's what you want the article to be doing. I read this:

The good news for those concerned about privacy is that it appears for now Canonical is just interested in tracking the users of OEM installations -- those PCs that ship with Ubuntu by default such as from ZaReason, System76, and Dell.

To mean that, for now, they're only installing it on OEM computers. Also, it is a GPL'd bash script with nothing hidden. The comments at the top of the script say, "This is used for surveying how many original OEM installs are still existing on real machines." Somebody previously posted the source, search for "#!/bin/bash".

No. It's a bash script posted in a comment above. Search for "#!/bin/sh"

I think it's important to note that the Wired article didn't conclude their was a brigade, probably many individuals with individual agendas. Also, they didn't mention a side to which these buriers leaned.

Also, the Lyndon LaRouche "Plants" weren't plants at all, they wanted to be Tea Party members. Read the articles.

Wow! For me, Firefox never crashes. Even on Windows.

How many of those 1,000 employees need help from the priest and social worker because they aren't paid enough to buy food, clothing, and/or shelter?

Sorry for your troubles, I can't figure out why your sound/wireless/graphics worked so perfectly on the LiveCD (unavailable on Mac or Windows), but then didn't when you installed. Did you point out in your bug report how the LiveCD worked so well? That might have helped the bug folks track it down.

And I'm really sorry it happened to you again on the next release. Wow, intermittent freezes that didn't occur on the LiveCD either. I heard there was freezing caused by upgrading Ext3 partitions to Ext4, that you wouldn't have seen on the LiveCD. However, since Ext3 was the default and stable filesystem for LTS+2 (Jaunty), I doubt you would have done something that risky.

Again, I'm sorry for your troubles. I truly wish your experiences were as good as mine. For me, the LiveCD experience exactly predicted the final installation experience, except that the LiveCD was a bit slower.

Maybe OS X, but definitely not Windows. Hell, I can't even scroll or click with my touchpad on Windows 7 out of the box. Linux detected my touchpad and set it up for me. Nice.

Except there's a little notification in the top bar saying something about drivers. Wonder what that does. Oh, it installs the Nvidia driver for me. I don't have to go to the site and download it. Cool. Restart and what do you know, System->Preferences->Display, Boom, 2 monitors.

Sounds like somebody thought they knew what they were doing, but didn't. They decided to do it the backwards Windows way, and it didn't work. Shocking.

I think you posted to the wrong story. This story is about the next Ubuntu release in late October, Karmic Koala.

It doesn't.

This is an excellent description of the issue. However, if the application writers, in this instance KDE, had synched after messing with extremely important files then the issue wouldn't occur.

The real issue is this, should the filesystem itself have to figure out whether it's dealing with important files or not. Or, should the application tell the filesystem the files are important by forcing the updates to be written. Since the former is impossible, the filesystem would have to treat ALL files as important and thus never be able to do the cool things the Ext4 can do that decrease wear on SSDs, save battery power, save disk space and speed things up.

1. POSIX is an API. It tries not to force the filesystem into being anything at all. So, for instance, you can write a filesystem that waits to do writes more efficiently to cut down on the wear of SSDs.
2. Ext3 has a max 5 second delay. That means this bug exists in Ext3 as well.
3. If you have important data that if not written to the hard drive will cause catastrophic failure, then you use the part of the API that forces that write.
4. Atomicity does not guarantee the filesystem be synchronized with cache. It means that during the update no other process can alter the affected file and that after the update the change will be seen by all other processes.

We don't need a filesystem that sledgehammers each and every byte of data to the hard drive just in case there is a crash. What we DO need is a filesystem that can flexibly handle important data when told it is important, and less important data very efficiently.

What you are asking is that the filesystem be some kind of sentient all knowing being that can tell when data is important or not and then can write important data immediately and non-important data efficiently. I think that it is a little better to have the application be the one that knows when it's dealing with important data or not.

From the article:

That title's not quite right. The bug points to a workaround that has existed since the bug was initially reported. Maybe this title: "With new update, Ubuntu make Laptop-Killing BIOS bug workaround automatic".