Ah, who gives a rat's ass then? As a user I don't want my search keywords going to third-party sites to begin with, and I don't click on paid links in search results. (It wasn't clear from the original article that this referred to *ad links on the Google page* and not *links to sites with google ads*.)

Far more worrying is that the redirect always goes through HTTP, giving a chance for MitM attacks to sniff or alter your target traffic -- for instance redirecting you from what you thought was a nice safe HTTPS link to a phishing site.

Excellent question -- I was very surprised to see absolutely no analysis of this in TFA!

Doing a very quick test googling my own blog from https://google.com/ the referer I end up seeing is like this:

"http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fbrionv.com%2F&ei=fjynTpC4KoSqiQLFvezYDQ&usg=AFQjCNHi_Ia5lQINhrMRGTJyRLFc4ZOajw"

I don't have any Google ads on my site, so I guess this would be in the "Ordinary Site (http: = non-SSL)" category, which TFA claims gets no referer -- but I do get a referer, and it's an intermediary redirect that's on http, leading the browser to happily send that as referer info.

Following the same link from https://encrypted.google.com/ shows no referer, indicating that it either went through no intermediate redirect, or an https one (you can see by testing that there is one, also on https://encrypted.google.com/) that didn't pass on referer info from the browser.

SSL pages on my own site don't seem to be in index, but the intermediate redirects I see on other things like mailing list archives that are in there look the same -- http: redirects from https://google.com/ and https: redirects from https://encrypted.google.com/

I think it's just sending everything through an http redirect so everyone sees referer data, unless you search from encrypted.google.com.

Every desktop Linux distro I know of releases source along with beta packages throughout the entire development process. I still think it's a shame that Android instead develops in secret, sharing development sources only with exclusive partners.

Or did getting that hardware to market and into peoples' hands help to provide pressure on Google's Android developers to actually come through with a tablet-oriented version?

And could that tablet-oriented version have been made even better if the vendors and other developers who had been pushing for netbook and tablet-friendlier Android earlier on could have participated in the actual development of Honeycomb instead of duplicating partial effort by half-assing a few tweaks on top of Gingerbread?

That's pretty much how the Android platforms works -- if you want the branding and the Google apps, you have to license it and work within additional restrictions beyond just the open-source base. That hasn't stopped LG, Samsung, and Motorola -- official paying licensees all -- from making UI customizations that a lot of people complain about, so I suspect they need to adjust their partner agreements rather than restrict the offbrand open-source redistributors.

*ding ding ding*

And of course we can expect the result of this decision to not actually be "small manufacturers don't try to stick broken Honeycomb on their off-brand handsets", but rather "small manufacturers who already don't license the Google-branded bits anyway keep putting Froyo or Gingerbread on their off-brand tablets, keeping them at least as bad as the previous generation of on-brand tablets".

A rushed update can still be released without destroying the overall brand image. Google's own Chrome browser (under its 'Chromium' alternate brand) as well as Mozilla's Firefox, and the Linux kernel itself, are all developed much more openly, with warts and all exposed during the whole development and clean-up process. Chromium and Firefox even provide regular installable binary snapshots, so you can test in-development versions without compiling, and always have the source for both unreleased and ALL released versions. This gives them several important advantages:

• Debugging: App developers encountering problems with the system actually have the opportunity to dive in and see what's going on in the core libraries. This can save hours of mystery questions if it turns out you misunderstood a function's requirements for instance, or if there's actually an internal error -- which you know have a chance to report or even fix directly. If we have to wait for source until months/years AFTER the binary releases, we might as well be developing on iOS.
• Testing: you get more pre-release testing, with both app developers and system integrators able to give feedback and provide patches.
• Better bug reports: while not every bug reports is going to be magical, the fact is that there ARE power users and devs who can make use of the source to aid in debugging, either to narrow down a problem or to actually provide a patch. (Even if an initial patch isn't the right solution, it can help in identifying the right solution, and as importantly it can serve as a workaround for particular folks.)
• Unexpected innovation: Sure, not every non-traditional customization is going to be good. But some of them will, and those are things that can't happen until the source is out there.

This can actually help you clean up your messy code base... Google's Android group is giving those advantages up here, and that's a shame.

I tend to simply to keep servers' local timezone set to UTC, especially if you have admins distributed over multiple time zones themselves; this avoids any confusion about what times listed in logs mean.

The US also has 50 times the population of Israel; that might go towards filling up the positions. :)

Users won't need to recompile or reconfigure anything -- they'll get the updated system installed for them by the distro packagers in upcoming versions. You only need to do anything if you want to enable this *right now by yourself*, and there are indeed a few different ways to do it.

The differences between the change to the kernel and the shell script are basically two: one, they apparently have slightly different algorithms for choosing how to group the processes. That's not due to it being in-kernel vs out-of-kernel though -- that's just because they are slightly different. Both can be implemented in both ways, and both work with the same actual implementation mechanism -- simply one works from userspace through the interfaces and one's built-in to the kernel.

Auto-tuning behavior that's built in will probably be the most reliable, easiest, and best-performing way to do this, rather than requiring every Linux distribution to ensure that they're running the same extra scripts and keeping the userspace stuff in sync. Do it once and leave it built-in to the kernel.