The NSA really bet that, over time, none of the thousands of employees having access to this data would leak some of it ? That's really stupid at best. If something is weak, it's by design here. Yes, it takes some real guts to do this leak, but that had to happen. I am actually glad it did.

Some people have a near religious approach about what a browser should do, and what it should not. For those guys, the browser is a piece of code that render a "document" ; this is by no mean a way to implement GUIs. The other part of the world is fighting hard to implement GUIs in browsers, and making sure that their GUIS work well in every browser ! Sadly, the standardization groups have many of the first category, and few of the second. And franckly, that really sucks.

Why not aknowledging that a browser, in 2013, is a piece of code that implement rich terminal capabilities and also (mainly?) intend to serve GUIS for apps ? From there, we could add rich UI elements to the totally outdated and pathetic form elements collection that HTML implements. A lot of people spend a hell of time to workaround CSS/DOM oddities or limits, simply because the web technologies was not made for GUIs... Such a move would likely to be way more useful than many recent additions to web standards.

That being said, I don't think CSS and DOM are inherently bad. They allow very powerful things indeed, as well as javascript does.

Backdoors are complex to setup and hide; frontdoors are easyer and can remain unnoticed for very long sometimes.

"All problems in computer science can be solved by another level of indirection"

(David Wheeler)

So true....

42

Jeez, what a scoop. Isn't this feature all about tracking ?

"Flash Can Rob 2 Hours From MacBook Air's Battery Life" should be "Ads can rob 2 hours from macbook air's (and anything else) battery life", I presume.

FYI, "Duke Nukem Forever" is entirely coded in perl6. Hence the delay.

It seems that most people who complain about memory usage don't know how memory is managed on modern operating systems, so they go all apeshit about "OMG HELP linux is using so much memory it sux0rz!!!"

I agree with you on that, but feel like the diagnostic is somehow ... opposite: "it seems that linux developers fail to show memory usage in a way that average user can understand".

6. Dealing with memory leaks on most browsers (ex: ff) is nearly impossible

On your #2 point, my experience is that coding for: FF3, Safari4, Chrome and IE8, is no longer a compatibility nightmare. Dealing with performances and memory remain a nightmare on my view (except on Chrome which rocks on garbage collecting).

Memory usage comes with a bad side effect: memory fragmentation, which tends to eat a significant share of CPU cycles for no reason other than allocate/reorganize/etc memory blocs. That's a problem.

Seeing how well FF shows on TFA is just amazing to me. My own experience tells me the contrary: FF performs bad when it comes to memory usage and, more importantly, leaks. At some point, just exiting FF (usualy because it reached the swap area) on my linux box takes about 30s. ff guys think using the exit() syscall is not good enough, hence ff tries to unallocate everything before exiting, which takes forever and tells a lot on how the memory is badly fragmented with tons of leaked small memory blocs.

I gave safari a run on my web app, which uses a lot of clientside scripting and has been designed to "work" on FF, IE7, chrome. I did not optimize anything for any browser, it was just a test to make sure I would make mac users happy. I was amazed by performances, really. The JS runtime is way better than anything else I've tested, and even beats chrome which is also really good. More importantly, it seems almost immune from memory leaks, compared to ff3 which needs a restart when approaching 1GB.

Your solution might works for 5% of the population; the remaining 95% will keep buying preinstalled machines running windows, macosx and occasionaly linux, and won't have a clue about what is an OS and how to install them. Maybe my numbers are wrong, but the figure is probably accurate and I fail to see how more (some?) courtesy from microsoft would change that. End user education is necessary, but not really practical.

As noted by many Perl fans (like I am) you do not write in Perl - you think in Perl

I usually say something slightly different to people that I'm teaching perl: when writting perl, you think algorythm and data structure more than anything else, and that's what matters. You don't waste much of your time to fight with dumb API, stupid syntaxes or strange behaviors (php anyone). Perl is sometimes intimidating for outsiders, partly due to the way some people overuse its felxibility, but there is an easy way to write clean code without much of the glue you usually need in some alternate languages.

Having arrays, hashes and regexps natively accessible is one of the killing feature. I only miss a better prototyping in method/function calling.