I agree. I am as much a content user of Linux as the next guy here, but it could easily have been any decent OS doing the same thing. Even the Raspberry PI has alternatives here. There is no need to glorify Linux as something special in this regard, it's just a completely typical (for Tannenbaum fans, completely atypical, of course) run-of-the-mill half-modern (monolithic kernel debate again) operating system. There is no magic involved in Linux other than the fact that it is essentially the largest crowdsourcing code project of our short computing history. There is nothing it can do that say Windows cannot, technically.

To follow up on my post above, let us consider Thomas Edison, a famous American inventor and by most accounts, a great person (please, no Tesla-related discussions ;-)

He is reported to be of Dutch ancestry, but his American/Canadian ancestry goes centuries back, and this makes a good case for simply calling him American on most if not all factors. Simpler put, the man is American without a doubt for most discussion cases and purposes.

Whether todays "American" researchers like associate professor Kim (presented in the MIT video above) can be considered American, is debatable, and what is more clear is that they are definitely LESS American than Thomas Edison was.

The problem is not imported researchers - minds migrate all the time, and the U.S. just as Europe has not exited forever, having been built on colonized settlements of "imported workforce" which in U.S.' case is England, Netherlands etc. The point I am trying to make is that arguably there is no such thing as Americans, just as there is no such thing as Europeans and even Englishmen etc. It's all a question about how far back you want to track ancestry before you throw it out calling it "imported".

That said, I personally consider an American a person who has decided in his mind to integrate into a form of American culture (a different thing to label, but nonetheless) and will not consider treason, i.e. selling or giving his work to another country, such as one of his emigrated origin. That obviously is the threat and concern here.

However, there is another thing - if we consider that formal education and early upbringing makes a person, then one would consider an Asian immigrant who were brought up and schooled in Asia, as an Asian, not an American, even if they have gotten a job and lived their entire grown life in U.S. On the other hand, if we consider the adult life as making a person, then this Asian would indeed be considered an American.

I don't think there is one way of looking at this. "importing researchers" is a gross generalization and factors outlined above must be taken into account, in my opinion. Not all imported researchers are alike, and there is no shame admitting that the brain of this or that researcher has been formed elsewhere than U.S. or vice versa.

They do it out of their love for their country!

Not really no, but it's sloppy thinking nevertheless. Take the things that not even half of the people will use, out of the download file.

Some people download on cellular networks and pay per megabyte downloaded, and in any case you cannot predict everybodys usage patterns.

Bottomline - it's a web browser, not an operating system bundled with applications. Just my two cents. I know they are going to make one out of Firefox anyway.

Someone said already - its the inner platform effect. Reinventing the [inferior] wheel.

Then I just hope they don't bundle it with Firefox, so that people who just want the [simple] browser, do not have to download code their computer will probably never run. And if it does, it can download on demand, since it is an addon, just like the rest of them.

So it's basically a so called web application? Like c9.io f.e.?

Because I was under the impression that its more akin to say, Firebug.

I think we would all agree that code bloat goes beyond web browsers, it's a problem for every piece of software, a problem from the future, waiting to happen, somewhere there along the development timeline, when someone with insufficient life wisdom decides for yet another feature, and as features become less related to the core functionality of the original product, the code bloat becomes more of a nuisance.

Since the psychology of developers can hardly be changed fast, especially the inexperienced ones (wisdom does not equal competency here - you can contribute to libevent, but not have a clue about the kind of wisdom I am talking about), I think another solution is necessary.

This solution is to at least try to decouple the features from the core product in such a way that these do not impair loading and runtime times, can be distributed/added/removed separately and generally do not impact the core product. Dynamic library loading, etc - all these things can be used with good measure to combat perceived bloat. But we still need to educate each other on these things.

The good and related principle of high-cohesion low-coupling should also be applied.

My point is, in itself, a gazillion addons is not a problem, as long as a person not wanting one single addon can use the product to their satisfaction where mere existence of plugin/addon/dev-IDE system does not impact his experience negatively. And it shouldn't - if you can load libraries on demand, you can decouple the IDE from Firefox, so that people who never heard of it or do not want it, can live in blissful ignorance of its mere existence.

Javascript is great for prototyping - it even has a keyword/property thing called "prototype", and also another one called "__proto__" :)

Well, isn't it what we wanted pretty much - "right tool for the job" and all that?

I think it is a good sign!

I agree with you on the fact that "all but tiny fraction of Android users buy models where neither carrier or manufacturer really GIVE A DAMN..."

I have an older Huawei Android model I bud borrowed to me indefinitely, and that thing, apart from running 2.x, never gets the important updates because neither Huawei nor Google care. There is no way for me to patch anything on this brick unless sanctioned by either Google or Huawei, or unless I get my hands dirty, which I don't have time for in this case.

This is Windows era all over again. Apple does it right, it's not perfect, but its a solution.

Take into account all the multitude of customization pretty much every phone vendor does with Android, and you can be sure there are exploits targetting it. It's a rats nest of open holes. But, that's what you get for slapping together an "open" platform BEHIND a closed platform. I mean, does any of you have the might to actually patch the source code for your phone AND upload it to your phone to take effect? The cake is a lie.

Shiny new Android 4.x on brand new fancy models from top of the line manufacturers like Samsung are being waved in front of you with all their gimmicks and toy features and you all but forget the apparently important things immediately, while 99% of Android users run software no professional in the right mind would consider remotely secure. Or you just don't care, which makes the point moot, IMHO.

Consumers are not the ones providing OpenSSL, the vendors downloading and installing it on their vending systems, are. And so, it is the vendors who in fact should be afraid of lawsuits, not Robin or anyone else contributing to OpenSSL. But in any case, anyone is free to sue anyone else, the assumption is that the judging party understands what the usage license for OpenSSL implied. Which they are expected to.

If they had resorted to their area of expertise and simply used the malloc provided with the system, like all the regular chaps would do, even in their situation, the code would crash upon running (freed memory access) and the bug would surface already at New Years Eve 2012-2013 when Seggelmann was hopefully test-running it. So, even though indeed the code you quoted is the "bad bit", the real and broader issue probably is the teams questionable approach to development in general, in particular their false belief that someone writing a security library should consider themselves experts in rewriting heap management. Which ultimately cost them and their users. Sloppy sloppy.

This kind of practice of overestimating ones area of expertise - should be frowned upon everytime, for a good reason. We (developers) need to put it in our heads - not all algorithms are equal, and even though you and me may be prime experts at say, writing a perfectly safe implementation of SSL/TLS, we probably should steer clear of the stuff others know much more about, like heap, strings and what not. Time and again, someone comes along with the "brilliant" idea of "optimizing" the system heap allocator through caching memory blocks. True genius. No offense Robin, but WHY?! Yes, maybe the system malloc is slower than you'd like - still it is NOT YOUR PROBLEM. Division of responsibility, man. Let Glibc folks optimize malloc, or submit a patch THEY can review, if you have wonderful malloc improvement ideas.

Thing is, the people really behind the idea to wiretap any- and everybody, i.e. maintaining a big brother society, the people who have interest in this and the mindset to push for these ideas and carry them out - they see the state of the matter today as a hard won victory, decades in the making - and just as anybody who is afraid to loose their newly won property, they are afraid to loose it as well, and will not back down.

In short, getting to where we are with wiretapping today cost a lot of sweat and blood to these people, and the last thing they will allow is a step or steps in backward direction. The system as it is did not just appear out of nothing - a lot of folks have been putting a lot of hours into building it brick by brick, and they want their product to live on and return their investments. There are examples of far more benign ideas being pushed only because the incepting party wants ROI, end of story. This one however, is much more than just a lousy idea - it's a chance for a theocrat to see one of their dreams come to actual fruition.

Weight figures:
Porsche 911: ~1300kg
Tesla Model S: ~2000kg
M4 Sherman: ~30000kg