Journal subscription fees (and scientific publishing business models) have nearly nothing to do with pharmaceutical research and safety/effectiveness testing costs. Troll harder, please.

When you need the stuff bad enough, pretty much anything goes. http://www.theatlantic.com/infocus/2013/02/diy-weapons-of-the-syrian-rebels/100461/

Even if the submitter kinda implies he or she wants to learn by doing (or, "the hard way"), I can't get a feeling out of my chest that all this learning by doing would be much more effective with at least some reading homework before and/or during the doing. For that, I recommend at least skimming through this: http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html

Yeah, there's some stuff the submitter probably already knows or isn't all that interested about for now... and that's why it's a good idea to skim through first.

Actually, nevermind the "shortage of IT workers/cheap labor" issue, I think it would be very beneficial for humanity and geeks in general if most people had a passing knowledge how the magic boxes are instructed to do fancy stuff. Maybe such knowledge would help citizenry at large understand things like why DRM is fundamentally broken concept, that an ability to give general purpose computer your own instructions should count as one of the most important features and an important form of expression and self-determination, which would help us make sure stuff like "Trusted Computing" never sees any significant success in its owner/user-hostile form.

My personal pet peeves about Unity:

1) Half-assed implementation of application switching - especially / mostly when dealing with multiple windows from same application (TERMINALS!!)

2) System-wide menubar (and I'm a long-time Mac user, for chrissakes!)

Now, let me elaborate on both of these. I admit I haven't yet mucked around with settings, and I'm actually using unity on a University lab computers where BOFHs are mostly responsible for the state of things, so reality might not be the same for you:

1 - application switching: Previously, every window of an application was a "program" in it's own right for alt-tab switching. I could switch to whatever window I exactly wanted to, quickly. That quickly is a keyword here. Because now, if I want to get that-one-terminal-I-directly-want, I have to raise the application switcher on screen, alt-tab on it, WAIT FOR A SECOND, and only THEN I get to actually choose the exact terminal I want up.

On Mac (up to 10.6 at least), cmd-tab raises all of the windows of a single app up. Even THAT would be preferable to Unity, because then I at least I get the terminal I want quickly and smoothly. That wait, as short as it is, is infuriatingly jarring and I can't fathom how anyone claiming to be UX engineer would come up with it. App switching happens all the fucking time and introducing a jarring delay onto it is unbelievably stupid. They also decided to get rid of the win95-style application switcher, so I can't even choose my exact program instance from there. Gee, thanks a lot.

Then there's the fact that this stuff doesn't play nice with multiple workspaces/virtual desktops. Try launching an instance of a program on another workspace when you already have one open on somewhere else, you'll see what I mean.

2 - System-wide menubar: Well, I kind of get what it wants to do. But let me say it, it's a stupid idea. It was and is a stupid idea on Mac, and it is stupid idea here. It really only works on a premise you always use every program in maximised window. On Unity, it's made even more stupid by the fact that it's hidden by default and you only get to see the menu by moving your mouse there. So if I want to select something from the menu, I need to move my mouse over there even before I can move my mouse over the exact menu I want to use! I know, this is a small issue, but still. When you're mucking around with user interfaces, these small things MATTER.

Well, it has worked for Apple well enough...

Signing is easy, it can be done over internet as in Finland, people have been conditioned to use their e-banking for identification.

These days, president of Finland has been mostly stripped of his power other than to talk in grave voice about problems and visit other heads of state occasionally.

Apples and oranges, as parliament elections are divided by voting districts and this citizen's initiative thing is national.

I do know this is pedantry, but wasn't Webkit originally KHTML fork?

(not that this makes GP's point any clearer...

Well... if I own the company, I should be able to do quite whatever I want with it, no? Because the Board is elected in our out by the shareholders, right?

Maybe you meant if I'm a CEO of a company?

ahh.. pedantry. Part and parcel of being a slashdotter. ;)

Paper ballots are a system that can be verified as "working as it should" by any adult layman.

Go ahead and try to offer a firmware+machine code+source code bundle and motherboard schematics of a electronic voting machine to a layman for verification.

And better yet, try to find a viable way for the layman (who just happens to be a tech professional and able to understand the above) to verify that the box of electronics in the voting booth is actually the same as the infodump he just read. Preferably without breaking it apart, also it should be done to a significant fraction of units in use, if not all of them.

I believe that within Apple, it's called "Real artists ship"?

A cynical answer is that even if the language or framework author/project head was a technical writer worth his or her salt, it makes more sense to write a book and sell it. Because asking money for the language (compiler/interpreter+libraries) itself is not going to fly in the flooded market of programming languages unless it is really really good and only very few of them are actually that good. Maybe not even then, because the price tag of non-zero value is poison for easy availability which is a must if you want someone to look into your project or language on his or her free time. With frameworks you might get more leeway but not much, especially not if you count on having a hobbyist/hacker community to flourish. Of course, getting someone like O'Reilly to greenlight your book about your own virtually-unknown language or framework might prove to be tad difficult too... Of course, if you're someone like Apple or Facebook or Microsoft or Google who offer a platform with sizable userbase with monetization prospects, this isn't really a problem.

And then there is the fact as noted in submission that writing a good manual takes a different skill set than designing and implementing a good programming language. If you don't have it, someone else has to take up that work if it's going to be of any use. And for that to happen, the language or project has to exist in some kind of usable, stable state long enough for those "outsiders" to actually study and learn how this thing actually works.

Which brings me to the last point. The really good books about a given programming language or framework give also "learned in real world use" insights about the pitfalls, deficiencies and suggested "usecases to avoid and the usecases to strive for" of the language which might only be discovered afterwards. This also might or might not be easier for someone who is not intimately knowledgeable with the inner workings of the language or framework by the virtue of being the one who created it. You kind of become blind for the real merits and sore spots in your own work, so to speak.

And fwiw, I actually have no problem with the idea of paying for a book to help me learn a language / framework I want to know how to use. I have even done that! I do, sometimes, lament the fact that online documentation is lacking because looking up things is usually easier on those than on dead tree (or PDF files simulating dead tree).

I do share some of the sentiments of TFA though. Most infuriating is when there's a "quick and easy tutorial"... which also doesn't cover very much beyond the simplest of use cases and then theres a very terse api reference. And virtually nothing in between. At that point I usually ask myself "do I really have to / want to (+ have time to) learn this thing, and is there a good book on it?"

So, the basis for denying GPL code made by others in proprietary-closedsource-only software is based on emotion, not principle? Or there doesn't exist any "principles" outside of the scope of Free(beer) vs. Libre(freedom) vs. Paid-and-proprietary?

The copyright holder has every right to allow or disallow any use of his/her work as he/she sees fit, and they are under no obligation to justify their decisions or the basis of said decisions. Of course, after a license has been granted, it binds the copyright holder but excluding certain uses on whatever basis while allowing other uses certainly falls within the rights of copyright holders. The audience can either take it or leave it as it is.

Now, we might argue whether or not the guy should have anticipated stuff like this and expressly deny all religious marketing with his work, but given the infringing parties response so far it might not have done any difference.