It's a bit of a shame- most web apps don't have "Help/About" screen with an easter egg showing the dev team...

And I'm not even going to mention the time spent on systems that communcate with other systems over say web-services. Or systems developed for internal use...

They are the only ones that can lay fiber and invest into last mile, and they stubbornly refuse to do that.

I hate them so much for it. UK is falling further and further behind the rest of the world, it's just ridiculous.

--Coder

How many times do I have to repeat this. ALMOST ALL THE VULNERABILITIES TARGET JAVA APPLETS THAT RUN WITH JAVA PLUGIN INSIDE BROWER. This is not java the language in general, this is not even the JVM, this is the stupid applet sandbox. And nobody uses applets for anything anymore, this is obsolete technology maintained for backwards compatibility.

95% of Java today is running on the server-side. And there are very few security problems there.

Given the amount of articles and FUD targeted at Java on Slashdot in recent months, they could have gotten this right by now. Editors, please be explicit about this being java APPLET/BROWSER PLUGIN vulnerability every time this comes up. This is not Java language vulnerability.

--Codera

These are java APPLET or BROWSER PLUGIN vulnerabilities. Completely different thing.

Slashdot should stop with this misinformation. Java the LANGUAGE is OK. Java Virtual Machine is OK. Servers using Java as server-side language are OK. Java desktop applications are OK.

Java the BROWSER PLUGIN is vulnerable. But Java Browser plugin should never have happened in the first place and should be killed with fire.

So stop with the whole bashing of Java in general. Java is a very good and mature language, with the fastest JVM on planet today, lots of open source 3rd party libraries, servers, frameworks and tools. It's very very good for server-side development.

--Coder

I mean, if you get read some official statement prepared by a PR committee, how much can you trust it to be accurate? Even if they get facts right, the stated reasons behind it (save the kids, not because we just got bribed) or the declared outcome (cavity searches in airports will protect us from terrorists) are usually lies.

All of the official news could hugely benefit from croudsourced background checks, source verification, etc. We need something like a "lexical analyzer" described in Asimov's "Foundation". To discard all the cruft and extract the essence of official statements.

--Coder

I'm glad. Struts 1 wasn't such a good framework. It was first framework a lot of Java developers used these days, and one of the first frameworks available, and back then there wasn't that much choice. But today we have much more and much better ones. If you are still using Struts 1 in this day and age, you're doing something wrong... Even for legacy systems, there was plenty of time to refactor.

--Coder

Hi,

Nice specs, but please keep the Insert key. It's useful for copy & paste. It's also critical to select files in Midnight Commander/Far Manager/Any other 2 panel file manager. So I wouldn't be able to live without an Insert key.

--Coder

Hi,

That's not really true. If this study is true- and it is definitely more accurate than the North Korean "sea of fire" claims, there would be ~30k civilian casualties, or even as little as ~1k in best case. A war would still be horrible, but not as bad as North Korea claims.

http://us4.campaign-archive1.com/?u=0de7e0e84dc3aff619f936a70&id=c284fb3f9b&e=9d45c18d86

The actual war would be terrible, but the initial artillery barrage wouldn't be that bad all things considered. And the study doesn't say much about total casualties throughout the war.

--Coder

Strange, I'm outside US, and I'll probably stay away from S4 as I'd like my next phone to have a Qualcomm chip. They are both powerful enough for a phone.

Octocore has PowerVR GPU which is absolutely hostile to open-source driver support. While Qualcomm at least has Freedreno.

On top of that this won't be supported by Cyanogenmod out of the box. I'll probably get a nexus 4 (or maybe nexus 5?) for my next upgrade.

--Coder

Of course they did. This threatens their business model. A corporation will do ANYTHING to defend its cashflow. Any corporation, even Google. You want to play in their walled garden- you have to do it by their rules.

I'm quite glad Android is not completely closed, and projects like F-Droid exist:
http://f-droid.org/

It's not half as good as official Google store at the moment, but it's open source, and it will get improved.

As for me, I won't be happy until I can apt-get install apps on my mobile :)

--Coder

Um, Iraq was about profit of selected American corporations. Some of them profited from oil, some of them from "rebuilding" Iraq, some of them from military contracts, some from manufacturing arms and equipment. It was a huge money laundering operation on scale of trillions designed to enrich selected people & corporations at the expense of US and Iraqui people. Nothing more and nothing less.

The political situation did NOT warrant intervention, the outcome of the war is NOT worth all the cost and it was obvious to anyone with half a brain that nothing good would come out of this from the start. There were no WMDs, there were no connections with Al-quaida. All the intelligence that was used to justify the war was fabricated, and that was completely obvious and is now proven beyond doubt.

--Coder

I have read an article where there was an in-depth analysis of the situation. I cannot find it at the moment, but really, it's not really as bad as we think.

First of all, only part of NK artillery is high range and can really reach Seoul. And even then most of it can only reach northern suburbs which don't have that high population density.

On top of that, it cannot be all concentrated on Seoul, they have to think about defending their border. So it will be spread out and less guns would be firing on Seoul.

Third, they cannot sustain high rate of fire for long. First is logistical problem of supplying ammo to artillery batteries, especially when facing enemy with aerial superiority. Add countebattery fire and bombing of batteries themselves. Add simple mechanical failures and attrition- the artillery wouldn't last long.

Fourth, artillery isn't THAT deadly. On top of that, after the first salvo most people will be in cover or in bomb shelters (apparently there are plenty of those in Seoul), and people will evacuate ASAP as well. So continued fire will have less effect.

In summary if I remember correctly the article estimated the number of casualties at around 1k-40k (best-worst case scenarios). Even that would be horrible, but Seoul wouldn't be consumed ir a sea of fire or flattened.

--Coder

It's not as bad as you think. From a machine point of view, if the code is compiled or not doesn't make much difference. Let's say you have to execute code in a sandbox. Which would be more secure?

* Interpreted source code.
* Interpreted source code with a JIT compiler that produces native implementations of hotspots.
* Interpreted intermediate representation of source code
* Bytecode that's executed in a virtual machine
* Native code that's executed in a sandbox

In all these cases, you are running untrusted code. In all these cases there is a chance that your VM/interpreter will allow an an attacker to get through. Consider a Java JVM- it's quite big, hence the chance of a vulnerability hiding somewhere is quite big. I don't believe current JS interpreters with JITs are that simple either. So you could even argue that if your sandbox is very low level and close to hardware, it can have fewer possible attack vectors, the defence against them is simpler and hence the whole thing is safer. We have been using virtualization, protected pages and NX bits and related for a while now. And doing static analysis on any of these things is identical from machine point of view, so no difference there.

I'm still wary of Google NaCl, but not because of underlying idea. It's just too new and unproven for my taste yet. And it doesn't run on all browsers. And like making sure my apps are cross-plaform, I like my apps to be cross-browser, so that is a deal-breaker for me.

--Coder

I'd love to have programming-language agnostic scripting on a broser- PNaCl looks quite interesting. However, application development on the browser can only advance as quickly as IE features advance. IE still has huge marketshare, so if your website (web-app to be more precise) doesn't run on IE, you are excluding a huge customer base. This is all changing quickly with tablets and mobiles (which mostly run webkit) but IE is still very big. This will put pressure on Microsoft, and hopefully these features will get incorporated into IE sooner or later.

In my opinion the whole application on a browser thing happened because MS has (had?) a monopoly on desktop. So if you wanted to develop something cross-platform that has a UI, you had following options:

* Do it in a cross platform language that has UI programming. The only one I know is Java. 10 years ago, computers were much slower, and Java on desktop was quite worse than it is right now, so this would result in sub-par applications.

* Do it in C/C++ and use a cross-platform tookit. The only ones worth talking about are wxWidgets and Qt, and again, 10 years ago they weren't mature. On top of that you need to deal with tons of "backend" programming hassles, as windows is not really posix compatible. Again, cross-plaform toolkits like Qt or wxWidgets help here, but only some.

* Use some kind of thin client technology and do all the heavy lifting on the server. This basically evolved into a web server + a browser as a thin client. And until AJAX, your applications could not offer much interactivity.

All thigs considered, for many things browser-as-a-thin-client model makes a lot of sense. You always get the latest version immediately, you don't need to install anything (installing/removing/updating software is a huge hassle on windows. I'm appalled windows still doesn't have any package management and repositories). You get decent security- you can trust a web page will not screw up your computer (well, except some exploits in the browswer, but that's nothing compared to installing and running a native app from untrusted source).

Looking back I always think if this could have been done better. HTML+JS is quite nasty from an application development point of view. First of all, JS works differently on different browsers, and these differences are hardly documented. Things like GWT or jQuery help, but the problem is still there. Again, Microsoft and IE screw things up badly for everyone time and time again. Another two things- running inside a browser you don't have propper networking support and access to local storage. Both are required for complex interactive applications. HTML5 is an attempt to improve both, but it remains to be seen how successful it is. HTML/CSS layout is hard. There are still few to none WYSIWYG tools to drag and drop UI elements and construct a web-app in this way. And web-apps have a different look & feel than native apps- you still need to think in terms of URLs, "back" buttons, tabs, browser menus, etc. And not all hotkeys work either.

In general, I think a browser using HTML/JS/HTTP is a bad to mediocre thin client for applications. The only reason its so widely used is because it comes preinstalled on all new computers/tablets/mobiles shipped. If Microsoft wasn't a monopoly, it would have been possible to ship some other better thin-client with all the machines sold, and we would not have to deal with all this mess. I would probably prefer to have a browser just for reading PAGES, and a dedicated thin client for running remote apps. Hopefully things will get better with HTML5, and Microsoft has less influence on internet standards these days...

Sorry for the long rant,
--Coder

Sorry, I meant to say "actual communism never happened IN USSR". You are right, some primitive societies and small communes probably managed to achieve it, at least for a limited time. One of my friends was interested in joining or starting a self-sustaining eco-commune, so he studied things like this quite a lot. Apparently things like shared property can be made to work as long as community is tightly knit, shares ideology, and is smaller than 50 persons. It's almost impossible to scale it successfully.

Not that I support communism or USSR. USSR and Czarist Russia before that had occupied my country twice and they did lots of genocide and oppression there. I grew up behind the iron curtain hating USSR and Russia,and believing USA was some land of freedom and fairness and prosperity and opportunity. I am so sad to see USA go the wrong way for last ~15-20 years. Although maybe my initial image of USA was too idealized- they did quite a few dirty things in the cold war as well.

--Coder