I understand the idea, yes. But:

1. Most of the time, it doesn't work. Let's face it, at least 95% of the people looking to buy a laptop don't understand this issue. A good amount of people doesn't care about spying either, because they think they have anything to hide, or because the US government is doing it so it must be good, or because the US government doing it makes it impossible to avoid anyway, or for a myriad other reasons. I think Lenovo would have to be in a very weak state for this to do them under.

2. If it worked, it wouldn't be a good thing anyway. The laptop business is a very expensive to enter and competitive one. If people ran a company out of business every time it displeased them enough, despite trying to rectify their mistake, nobody would want to enter the market. Who would want to risk their money in such a way? So the market would eventually stabilize with 2 or 3 remaining companies which are too big to bankrupt, or who people won't boycott because there's too much inertia and not enough alternatives.

If the market settled for instance on Dell and Apple, boycotting one would require rebuilding your entire infrastructure and way of doing things. This won't happen, so if such a situation is reached they can basically do whatever they want.

If we want a consumer friendly environment we need plenty of competition, and this means that bankrupting a company should be the absolute last resort.

That's a counterproductive way of doing things.

Whenever making that kind of statement towards any sort of business you're telling them that there's no point to try to correct whatever upset you, as all resources spent to that end are going to be in vain anyway.

The spyware gives them some money. If all people who hate it put Lenovo in their blacklist forever, then the most sensible business decision is keeping the spyware. The customers that hate it won't come back, and the ones that remain don't care, so nothing is gained by removing it after losing that part of the customer base.

Right, so here is seems how things are:

1. Google seems to have little regard for long term backwards compatibility, at least on the timeframes Debian wants it. Kernel 3.17 came out in October 2014. Fedora has a new enough kernel, but also doesn't have Chromium officially apparently because Google likes to clone various libraries and do API changes, rather than trying to work with the original developers, distributions, etc. So it seems Google mostly does its own thing and lets other people to deal with it.

2. So Google is now releasing browsers that require kernel 3.17 to work properly. Users want to run it on their systems.

3. But Jessie is frozen and so changes only happen for good reasons. The question is then whether to backport the TSYNC feature. On one hand, it's a new feature and it doesn't go in frozen releases, on the other hand it stops new versions of Chrome from running, which is a security concern. Ubuntu seems to have went with the later logic.

4. Ben's reaction is "1. I don't like Chrome, so no", and "2. Distro is in freeze, there needs to be a formal proposal explaining exactly what patch to merge, and a sympathetic maintainer, which I am not".

So really what's going on is a conflict between organizations. Google wants to move faster than Debian does, and Debian (or at least Ben) doesn't want to give Google special concessions.

Digging around a bit this is what I gathered:

TSYNC is some flag added to seccomp to aid in something relating to thread synchronization: http://patchwork.linux-mips.or...

And seccomp is a security mechanism of the Linux kernel used to implement the sandbox in Google Chrome, which it uses for instance to run the Flash plugin in such a way that it doesn't compromise the system if one of its many security weaknesses: http://lwn.net/Articles/347547...

None of this seems to have any relation to spyware, in fact it would seem to have the exact contrary purpose: protecting the system from potentially malicious code and security exploits.

Unless I'm missing something obvious, it sounds like Ben Hutchins (the Debian mailing list guy who made the comment on spyware) just dislikes Chrome for whatever reason unrelated to TSYNC and decided that it would be a fine way to ensure new versions of Chrome don't run.

What do you mean by tech fetichism? Tech places a huge priority on energy efficiency. Computing is going increasingly mobile, lighting is shifting to LED... all of which is high tech by the way. Do you think old incandescents are better?

You don't understand statistics

More than a head per side? It's been attempted, and turned out it's not really worth it. It's a lot of extra complication for not that much benefit. Heads are expensive and generate heat, so it works out to close 2X the price anyway, plus an increased change of failure. Easier and safer to just add another drive.

These days there are SSDs too.

Got a link on that?

I tried googling and all I found is various keyloggers for sale.

It's pseudocode, just because something is allocated in a function doesn't mean it has to be freed right there. Though I suppose the example could be better.

...and of course I messed up, that should be:

if (!buf2) goto abort2;
if (!buf3) goto abort3;

The ability to edit comments would be nice.

Error handling with multiple instances of allocation.

Eg, something like:

char *buf1 = malloc(...);
if (!buf1) goto abort1;

char *buf2 = malloc(...);
if (!buf1) goto abort2;

char *buf3 = malloc(...);
if (!buf1) goto abort3;

return;

abort3:
free(buf2);
abort2:
free(buf1);
abort1:
return;

Also, bailing out of multiple nested loops.

No, it has plenty point to it, it makes everything much crisper looking.

Look at the screen of any person with a 4K Mac, they're not using a microscopic font. Their font sizes are the same size as on the older hardware, but they get more pixels per character.

A dosimeter won't tell you you picked up a hot particle in your shoe that is killing your foot. Vising the area with proper tools to find and identify the hot particles is essential to working and living there.

I have visited the exclusion zone on a tour. To enter and to exit you have to pass through a full body scanner, with a sensor per body part. It will tell you if something on you is radioactive and what exactly. According to the guide one of the visitors had to leave her pants behind due to having sat in the wrong place (they warn you not to do that)

You're barking up the wrong tree. I don't think you remember how things were before PulseAudio.

You had /dev/dsp or later /dev/snd. Since the kernel doesn't do sound mixing, they were one user only, unless the soundcard provided mixing. Which a lot of them didn't. So esd, artsd and similar appeared. Running KDE and want sound in the one Gnome app you use? Have fun making esd run against artsd. Want to run an old game or app that only knows about /dev/dsp? Sorry, artsd has it busy. You make it auto-close the device when unused? Unreliable as hell. USB audio? what is that? Certainly no plugging and unplugging support there. For a while dmix was all the rage. Thing is, dmix is implemented in the ALSA libraries, which means it does nothing for you unless your app uses ALSA libraries, so it doesn't help your any with your /dev/dsp using app.

PA was created to solve all this mess. PA basically handles everything and provides interfaces for everything, so finally pretty much all apps can talk whatever protocol they like, and work. And audio can be reconfigured as you plug and unplug devices.

Was it unreliable for a while? Yes. But there is still nothing better. The kernel doesn't mix audio. You need a daemon by design, and you need something PA-like to provide a modern level of functionality. The only way to do without PA is have the kernel implement all that, and as far as I know, the kernel devs don't want it.

I used a rack and pinion driven by a motor with a gearbox, with the hardware installed in the window blinds box. Unlike the linear actuator, there's no position sensing, so it uses limit switches.

I also installed temperature sensors and a RTC chip for scheduling, plus a control box with buttons and a LCD. The brains is an Arduino.

My next step is figuring out the AC's IR protocol, and adding an IR led to make it control the AC. After that, maybe replace the window blinds with motorized ones, and add a light sensor to automatically close them when the sun is shining right into the window.