R.I.P. Debian, you have been a faithful friend for many many years. And there's dark forebodings for the whole of Linux, too. As an environment where I could always agree with the important choices that were taken, I mean.
Debian and RedHat were born roughly at the same time. I remember how sad I was to see a split in the Linux world, but a good option was available to me: I could let the jacket-and-tie folks go the way of RedHat, and keep navigating on the interesting seas that Debian was heading towards.
Now, no more. The Debian spirit is all but extinguished,and we are bound to have two RedHats for the price of one.
Pity. Occasion lost.
Now, what will I do with my beloved Debian tee shirt?!?

Actually, it's possible to remove all errors and imperfections, if you would be satisfied with being boring.

No. Software for which you can guarantee that no error exist is not only boring: it is useless.

To prevent the next Heartbleed, it's more productive to donate to LibreSSL.

You do not get my point. You may succeed in rendering it less probable. But you cannot prevent it.

One of the many eye-openers that reading Douglas Hofstadter's "Gödel, Escher, Bach" book has provided me, all those years ago, is that, no matter how much we humans may try, we may *never* be sure to have removed all errors or imperfections from anything that's even marginally worth of our interest. In a nutshell, if you can prove that something has reached perfection, at the same you prove that it is not interesting anymore.

We cannot write complex bug-free software. PERIOD. OpenSSL is not windows. Headlines about OpenSSL bugs are not such a common occurrence. One bug happened at the wrong time, wrong place. This could have happened even if the world had opted for a proprietary library for this critical role. The only difference is that there would have been somebody to sue. Big consolation.

New theories come out of IT faculties around the world at regular intervals, that promise, if strictly followed, the holy grail of bug-free software. All of them eventually prove non-effective.

The only concrete effect of all these tactics is that the job of the programmer becomes more tedious, less interesting. One thing I can tell you from direct experience is that, the lowest the level of interest of the programmer, the higher the possibility will be that bugs may slip into his or her code.

So, the question is wrong. We cannot prevent the next Heartbleed. What the world needs to (re)learn instead is how to cope with unexpected events without reaching for your phone and calling your lawyer.

Many thanks go to all free software contributors, including OpenSSL ones, for what they do!

It depends on what life's ultimate goal is. If it is as I trust it to be - personal growth - enforced "good" behaviour brings nothing at all to me, and thus it is not good at all. Not only do I not grow by blindly obeying orders, but my discriminating capabilities are progressively dulled.

Our uniqueness as human beings is that we are provided with free will. The "bad" option must be available to me if I am to develop my ability to choose what's good for my personal growth.

(what's more: the decision about what's good and what's bad is bounced up (or down?) the power ladder. If you don't trust yourself for that decision, would you trust some remote politician? They are human, too. And often, they are found to be wanting on the ethical plane...)

Most important is who will manage the system. You talk about a NGO. It may base its existence on some set of ethical values. Find a person who developed sufficient net skills, and who shares the values behind the NGO.

I manage my own home site. Domain, mail server, web server. For presence online, one fixed IP address, plus some friend with a second fixed address somewhere else, is enough. No opaque clouds to block my view. A small PC which is always powered is enough.

If requests are kept reasonable - i.e., not pretending to be able to handle thousands of contacts per second, not pretending to maintain multi-million contact mailing lists, and especially not pretending to aspire to the useless utopia of assured 24/7 fault-free presence - half a day per week of paid maintenance plus the emergency intervention here and there should keep your ONG afloat.

You should be able to provide whatever PC-dependent functions you want the 20 people to make use of with Linux apps. Your in-house Linux expert, if adeguately motivated, will be eager to write small scripts (or even huge applications) to cater for your specific needs. Of course, workplace PC's should only be used for work-related activities...

This only works for ethically motivated entities. If you manage a purely for-profit concern, no matter how small, you can only motivate experts to manage your network and machines with money, and there will always be someone who can offer more money than you. For good experts who base their choices on money, it will be a no-brainer to abandon you. What you will be left with are unskilled people with some vague point-and-click experience. You can opt for the cloud, but remember that, whenever an even vaguely important concern is raised, the survival or even the well-being of the entity providing the cloud services will always come before yours. ALWAYS! They are big and you are less than small.

The solution: either become a huge money-printing concern and get the best people available on the market, or much better, BE ETHICAL.

If Perl, Python, and Ruby are unable to match Java's performance, I'll take their portability, ease of development, lack of overhead and succinctness over Java any day.

Java's currently used for a lot of different things -- the scripting languages are a good fit to replace some, but not all and I wouldn't even really say most, of it.

For Perl or Python I cannot speak. But it is now more than 5 years that I switched, for my development work, to Ruby as my main language. I talk about more than 150.000 lines of Ruby, mostly for big interactive art installations (have a look at the web page of my best client to have an idea of what I am talking about).

How have I solved the evident performance problem? First of all, Ruby version 1.9 made the language much snappier. But if you need as much performance as you can get, Ruby makes it easy and comfortable to merge sections written in C within programs. If the partition between the two languages is made with intelligence (i.e. limiting C to machine-intensive small "engines"), you can really obtain the best of two worlds. C outperforms Java, and Ruby is much nicer to work with than Java.

The holy grail is to know at any moment where every subject is, with as much precision as possible.

Obviously it is impossible for any kind of authority or goods provider to guarantee for you an accident-free future. Statistics may show an improvement (although statistics may be easily shaped to say what you want them to say). But they will never represent an assurance that you will be spared the specific pain or annoyance tomorrow.

On the other hand, to know at any moment where every subject is (and in this case, to eventually be able to remotely control their means of transportation) gives, to a more and more remote, less and less humane form of government, the possibility to steer the herd of primates with less effort.

Not evil - just plain lazy. If, at the expense of personal liberty, humans are restrained from committing what the government decides to forbid, law enforcers have less work to do. But I don't like it. To behave correctly because you are forced to does not bring about personal growth, and I am here on this earth to grow, not to own the latest volvo...

Wouldn't your average "sensible thinker" maybe end up risking his cozy well-fed professorship by adopting a controversial position? As well as his friends, maybe, and that network of relations that he invested so much time and energy into building up? Conformism pays a lot. Especially where much much much money is involved. Think of this: who gives out official "climatologist" labels?

The "nutbag" is currently busier trying to make out how the WTC towers could collapse at free-fall speed while having to destroy floor after floor of massive steel pillars on their way...

I completely share your disappointment at Python's usage of indentation as syntax. I gave python a deep review when it appeared, around '97 or '98. I was fascinated by the concepts, I could see there was some important element of progress in it. But I concluded that I could never use the language because of the indentation problem. It was (and is) unacceptable that I would end up changing the logic of a program by inadvertently deleting an invisible tab. It is the duty of the editor to fix the right indentation of my code, and it is an invaluable debugging tool to press tab in my Emacs screen and find out what the right indentation should be. This is obviously impossible if it is the change of indentation itself that marks the end of a loop or of an if clause. Really really really impossible to adopt.

I had hopes that the Python developers would eventually give in and allow the (maybe facultative) usage of a reserved word for closing loops and clauses. This has not happened. Worse: it has become a matter of pride, a distinctive aspect of the language.

I went on with my mostly C with limited Java usage. Until in 2005 I decided to give Ruby a try. From that moment, all my projects have been written in Ruby, with substantial C inserts. After writing almost 100.000 lines of Ruby code, I am more awed than ever about the qualities of the language. It goes without saying that you use keywords to close loops and clauses in Ruby (either the end keyword, or C-like curly brackets, at your choice.)

A few reasons for giving Ruby a try:

• Ruby is from the same generation of Python, only newer. Same zeitgeist, better implementation.
• Ruby comes from Japan, where it is developed with typical pragmatic attitude. The language contains what is useful, often with more than one possible alternative (you can create your own distinctive style).
• Ruby implements the object-oriented paradigm in a full, no-compromise way, which is at last capable to deliver the results (in terms of ease of coding and adherence to thought processes) that were promised by the theoreticians.
• Ruby has a lean, very efficient way of including C code. it is really possible to have the best of both worlds. If you need to use a C library, it is easy to write your own bindings, provided they have not already been written by someone else.
• Ruby is very net-aware. Generic tasks can be implemented in a few lines of code.

You should take great care to distinguish between Ruby and Ruby on Rails. The first one is the language. The second one is an application based on the language. While it is obviously good that RoR gained such a notable momentum, it must be remembered that Ruby is a language as of itself, with great qualities that can be harvested even if one does not use RoR. I, for one, do not use RoR.