I LOVE your similitude! I'm using it everywhere, from now on.

"Cheerios? Man, that is the "Thomas Kincade" of breakfast cereals."

Alabama and Oklahoma have orgasm.

Pointing out that someone is a troll is flamebait now?

Troll.

Another reason to use an encrypted root.

Of course there are ways to get round that, too, but the size of the hard drive firrnware is limited.

You're confusing cause with effect. Programmer wages aren't high in the Silicon Valley because of having a lot of programmers. There are a lot of programmers because the wages are so high that CS majors come here in droves after college.

The reason the wages are so high here is because of basic supply and demand at work. Silicon Valley has only about a 3.6% unemployment rate among programmers, and a lot of the unemployed either want to be unemployed or are unemployed because their specific skills aren't in high demand. Programmers may be common in the Silicon Valley, but the demand in the Silicon Valley far exceeds the number of qualified programmers who are available and looking for jobs. Thus, the entire market is a zero-sum game, and the high wages are a result of the need to buy people away from other companies.

As a result, any sudden increase in the number of programmers drives down salaries for new hires, and fairly dramatically at that. For proof, you need only look at what happened to programmer salaries outside the Bay Area during the dot-com crash, when droves of people suddenly were looking for more affordable places to live. In some areas, salaries for programmers dropped almost in half because of that exodus.

Is it realistic to believe that there will ever be enough programmers to satisfy the Silicon Valley's voracious appetite? Hard to say. But that's a separate question.

Isn't the very point of this player's system, that the player serves the interests of the disc's publisher over the interests of the users, where the users' needs should always yield whenever there is a conflict? That's not a mere technicality; it's the very essence. From the spec's pov, this is desirable operation. Nothing has been subverted.

I can see some appeal to that, but surely any sane leaker will post using a restaurant's free wifi or similar - meaning their doxing gets associated with any other innocent user who happens to have posted updates from that restaurant, with no apparent link to their own isolated accounts?

Personally, I'd probably use the free wifi at the railway station on my daily commute - indeed, I do use it most days, for innocent purposes - or if I wanted to do something that might be traced, ride an hour or so on one of the lines and use another station on the network, using a randomised MAC address on a laptop. Anyone who was identified as associated with me then is completely uninvolved. Yes, maybe you'd catch a few low-level trolls, but you'd be falsely smearing a whole lot of innocent third parties - making the identification worthless anyway.

Yup, sounds exactly like the way we're "dealing" with global warming.

Yes, it is pretty silly for them to expect the government to educate people. It is not like an educated population is some kind of public good.

Well, it is a benefit to the public as a whole to a large degree, but there is a dark side, too. The main reason that companies want to increase enrollment in CS is to get a larger pool of people to draw from so that they won't have to pay employees as much.

We need to address the real underlying problem you are describing right there - code written by different people that does not conform to any standards is hard to manage over its lifecycle - and this goes double for limited frameworks that may get some things right, at the expense of not allowing you to get all things right.

This is one thing that open source has gotten right on occasion - think of the Linux kernel for example, and how many people contribute to that and keep it going.

So really the answer I think is twofold - on the one hand people need better tools that make it easier to integrate their efforts, on the other hand entities engaged in this activity need to develop standards that ensure when people develop things - they document and build interfaces that are consistent, if not globally, at least between members of the groups expected to work on the code. If you do both of these things - and by extension some other things that those recommendations imply (e.g. code reviews, agile development methods etc).

Now, if you are only building software for yourself, then this isn't so important. However, if you expect other people to extend and manage your code over the long term, then I would still opt for leaning towards either creating and documenting standards, or selecting and learning existing well known standards - and sticking to that in your own code. Keep it consistent between all the things you build that you want to share, and you just might get people to help - if that's what you are looking for.

To having Communists read your stuff.

Seriously, I was buying Lenovo before now. I did not get burned on Superfish. But I'm done with Lenovo. If this is what they try get away with without effort at hiding, then what they are they spending effort on hiding? I don't need the PRC in my network also, I have the NSA for that.

I would not consider being overly risk averse as being rational behavior.

There are many rational reasons to take risks:

1. Gives you, and by extension your company the opportunity to learn and grow. If you never take risks you stagnate and learn nothing.

2. Real invention occurs through taking risks. If you never take risks you don't innovate.

3. Taking responsibility, and therefore risk is what men and women do. Being overly risk averse is immature slug-like, weasel word behavior.

If your company does not reward risk-taking - then you are in the wrong company.

I've told this story elsewhere, but it applies directly to this issue, so I'll recap in short:

Vender is contracted to create an integrated support application for large sums of money ($millions) over a 6 month period; contractor chooses an obscure commercial java framework to build the system on. The application is delivered and appears to work fine for several months, then starts getting sluggish, then a month later the application locks up - and has to be restarted. This progressively gets worse, and is asymptotic with the growth of the underlying customer base - and soon becomes completely useless - shutting down within minutes of being started with a memory exhaustion error.

The main problem we found was the equivalent of a memory leak in Java. The code would instantiate objects based upon the framework in the main loop, and they would never go out of scope. Furthermore the code imported hundreds of libraries that were never used - further impacting clarity and understanding of what the thing was doing.

To make a long story short, since this was already in production and now there was even more pressure to get a solution in place fast (and all the lawyers threats in the world can't replace a knowledgeable developer) - we rebuilt the whole system using perl in a little over 1 week. That solution is still running today - even as we've scaled orders of magnitude since then.

So - to your point - this stuff really does happen, and wastes godawful amounts of time and money, when a more simpler home grown solution would do just as well, if not better.

Programmers have to take more responsibility and think holistically about what they are building - and integrate testing to validate their assumptions against the hard light of the real world. To be a great programmer, you should know how to test and build tests and test rigs as needed. To be a great tester, you should know how to code - so you can automate what you're testing. I think the lines have to blur - a firewall between the two only leads to silos, and limits what can be done if they were to work seamlessly (the quote attributed to Aristotle applies here, "the whole is greater than the sum of its parts").

Of course, in many development shops the 'just a programmer' mentality is baked into the whole process - so as a developer you might feel that you are stuck. That being said, if you know better, then it is in the interests of your business if not yourself to champion the issue and effect change.