Does this have more to do with 'evil chinese hacker swarms' or more to do with poorly secured networks being abused by parties unknown? Seriously, I'm no hacker but I'd have enough brains to never launch attacks directly from my loc when there are perfectly weak targets to channel attacks through. And lets forget entirely about TOR because systems attacks through TOR could never be a thing.

Separating desktops and servers (which in this case is quite relevant):

Servers can be Windows / Linux / etc. and it doesn't really matter. if I wanted windows, I'd spoool up a windows VM. If I wanted a Linux server, i'd spool up a Linux server instance in a VM. I ONLY WANT Windows/Linux because of the applications that run on them. Server dev environment choice in that respect don't really matter unless you're deeply entrenched in a given vendor's server API stack. I've personally never seen companies do anything OS-specific services outside of a few DCOM based components like 15 years ago. If you have customers that want your server offering, they'll spool up whatever OS/hardware necessary to run it.

For desktops, this certainly matters a lot, since most consumers don't have multiple desktop OS's unless you're dancing with tablets/phone OS's as well. All that said, I see little interest for 'windows apps' or 'Linux Apps', 'Mac Apps', etc.. The web has really gutted the native platform applications market. Never eliminated obviously, but significantly maimed in the consumer space.

Lastly, desktop applications for Enterprise are generally still thriving, and .Net/Java/C++/etc.. zealots in companies still fight tooth and nail for the next project.

Sorry, some people want to have real discussions about things that matter instead of being bombarded with mail chains from Mom and Aunt Betsy.

Spoken by a true pragmatist. I'm glad you're not my hiring manager (though sadly there are many who work under the same broken assumptions). I hate programming languages as much as the next zealot, sure. To assume a systemic bias against those with a specific set of language skills (disregarding experience/domain knowledge/people management/customer interaction/raw productivity/hipster hat collections) may be a little short-sided to the extreme.

Realistically speaking, you'd be truely astonished about how much code actually gets written behind the scenes that never show up in 'things you see'. It makes a big difference when determining the true scope of software development as a whole. According to Google, there's around 18 million software developers in the world. They all aren't writing front-ends to your latest social media web site.

Its not surprising that PHP is a popular deployment platform for one painfully obvious reason: Hosting. Well, and some very well maintained popular PHP software platforms targetting said hosting environments (Ok, thats 2).

Erm, Java has Real-time extensions, so I'm not sure how applicable your rant on medical equipment are. They -apparently- fire frigging missiles with RT-java
http://stackoverflow.com/quest...

"it's horrible to program in, but it saves companies from the effects of having truly stupid engineers and even more incompetent managers who don't allow programmers to document their code let alone require it."

Quite the opposite for me. I love Java because I can sit down hammer away at solving problems instead of worrying about bull-shit minutia wasting days of my life writing code I could've solved in an afternoon using Java (though results obviously vary depending on the specific projects involved). This is someone who came from almost entirely C development (never gave C++ a chance and in retrospect, I'm glad from what I hear).

"But a good programmer can accomplish a lot more in a more powerful language."
Details please. How can said individual work more effectively and in which specific languages please? Your single-pointed rant with 0 clarification makes you come off as a troll at best, and an irrationally biased individual at worst.

I'm sorry, your argument for NOT using a tool that changes over time (JavaVM) is that they're just as bad as another tool that changes over time (IE/Windows). And yet, please who release windows 8/10 related services are somehow forgiven from your black hole of hate?

Pretty much every piece of generally iused software has bugs. Sure, if you have 0 use for Java, Flash, Video codec playbacks, document viewers, etc. then absolutely don't use them. But don't presume to think Java is in any way less secure than any other platform that allows for script execution. Just make the common sense approach of not auto-running arbitrary scripting code, including JavaScript if you're concerned about being hacked.

For instance: https://msisac.cisecurity.org/...

You seem to indicate that these two futures are somehow mutually exclusive.

  transparent, efficient, and accountable

All of which are different, but lets break them down:
Transparent: Yes, the US government is going extremely down the wrong path, though mostly involving strong-arming other nations through secret negotiations, and the fact that you can be tried, sentenced, and convicted for crimes you didn't even know existed. That's pretty facist.

Efficient: The vast amounts of money the US gov spends are relating to milliary growth, sustenance, pensions, and debt. All the others (from a macro level) are relatively core. Democrats or Republicans, there's little chance that the government will ever get much leaner per GDP. That said, the only people that bitch about efficiency in government are the same fronteersmen / libertarian ideals that will never come back (baring a nut job with nukes mind you), because quite frankly most people enjoy comfort over self-reliance, and that won't be something you will ever change (unless you find some nukes lying around).

Accountable: Well, I see this article being a boon for accountability. The government is made up of people, and a high ranking person of said government was found to (alledgedly) commit a serious crime. The guily are punished. I can't see this being a bad thing, unless you're saying bad people that break laws shouldn't be punished. Next time we have a global financial meltdown due to bad actors breaking the law, or the pick pocket for stealing your wallet, just don't flip your opinion. Hypocracy is a taint.

I beg to disagree. I don't know what your dev env is, but any ORM will cause dynamic table / column labels. This isn't a bad thing. This means you don't spend countless hours hand sculpting selects/updates.

ORM Advantages:
  - Considerably faster to write and maintain queries / persistence
  - Significantly less code / DB coupling
  - Makes DB refactors easier to handle (depends on how much you leverage static DB-metamodels but that's another discussion)
  - Eager/lazy fetching makes foreign relations stupidly easy, like legitimately night and day
ORM Disadvantage:
  - Often less efficient because its harder to pull in subsets of a table row vs. just fetching full rows (though totally doable, people generally don't bother)
  - Depending on the SQL abstraction, you can get some bad JOIN's if you don't know the gotcha (but these are generally poorly constructed large queries, but they do require debugging to fix)
  - Eager/lazy fetching can cause SIGNIFICANT poor performance if you aren't aware of what your queries / related code are doing

If you want to know what's being pushed into the DB, put in breakpoints into the ORM layer or add persistence listeners to trace what's being stored / when (then turn it off for prod). If you're using raw JDBC, you don't have no excuse for traceability. Your problem isn't in the language, its about your ignorance about the framework / libraries your project is using.

Plus, at least with Hibernate, it'd use bind variables, not poor performing literals unless your code itself is being written with native SQL queries in JDBC. The one thing not trivially easy in most ORM's is DB-side batch updates. I generally hand code my SQL in those cases, but it can be done.

Don't blame a language for the mistakes of the developer. Don't blame the language for 'selecting bad developers'. Blame underperforming developers for underperforming, or blame management for not managing / training / filtering them very well.

I did a very large COBOL port a few years ago, and I must say it was very well written. We were increddibly lucky that the developers were maintaining the project for decades and wrote their code very consistently (though they significantly lacked in comments) and were quite comfortable with helping learn the in-s and outs of the system. The actual business logic of the product was factors more difficult to grasp than any simple technical issues with COBOL itself.

Much in the same veign as C, COBOL's whole memory model is like a big block of crap, being able to remap memory blocks willy nilly over existing ones, sending memory blocks across programs, etc.. makes tracing memory much more difficult unless you had some sort good static analysis tools for tracing (which we didn't). The processing code was straight forward but obviously very simple, which meant that there was a lot of boiler plate (but completely drop dead simple since the same code was used consistently throughout the project).

Joe rocks my Linux CLI editing world, but that's about it. The highest level of 'coding' I do with it is the occasional bash script. At least I can log into the latest centos and not have to spend 10 years editing the keyboard shortcuts anymore -- win!

For real work, I use Eclipse for Java. Frankly, if I did what I do in Java in any test editor, I'd probably loose close to 5-10x productivity. I know the tools and what they can do for me, and that's a lot.

1. Have a universal number, lets call it a SIN number for simplicity
2. Have a web site / physical record of casted votes with the casted vote and the voter's unique id hashed by something like MD5/SHA & date/time of casted vote in the incredibly rare case of hash collisions (correction, see below)
3. Send a mail-in pamphlet that provides a seed so that only the voting registry knows your unique (no reverse SIN guess in case your SIN was compromized by 'influencing' parties)

Me: Joe Blow
Issued SEED: 1234567890
SIN Number: 32323
Vote: Mad-like-hell Libertarian

Public Government Site Record:
| Mad-like-hell Libertarian | 8e63860d2a80a5d32d95345592697328 | May-14-2015 / 08:54pdt
(Example hashed from seed+sin / MD5)

The only problem being that the public needs to know (or rely) on the hash magic, but if you really care about your vote being untampered with, you can learn how to use basic tools to make it work.

For independent audits of the voting office, all SIN/seed hashes are to be retained for a number of years (or forever depending on data retention blah blah) so that independent audits of SIN numbers to actually viable voters, etc.. can be verified.

(Correction, because the registry can pre-calculate the hashes of everyone, they can re-generate a new seeding number until it doesn't collide with existing generated hashes)

Well, Sunni's and Shiites are also largely ethnic in nature as well as religious, so its arguable if that would matter. The same with Israel and Palestinians, but realistically, England wouldn't have cared about a displaced ethnic group (see gypsys) so they never would've repartiated their lands after WW2.

As for the territorial / violence, etc.. Its nothing at all to do with Religion. As another commented posted, the ingroup/outgroup dynamic is a lot stronger when there's a clear selection bias (skin / religion / socio-economic / 'birth caste' / left-handed / (wo-)man).

Of course the best solution is to educate people and hope that their own affirmed hypocracy guilts them into changing their opinions, or at least shutting their mouths from perpetuating the bias.

"Had it done to me"

Pardon? You signed a contract, and if they didn't honor your agreement by paying for your proscribed hours, take them to court for breach of contract. The only retarded thing that you could've done was have a fixed maximum hours worked, in which case they can't demand your time in excess. As a contractor, you sure as hell aren't bound by the same "work till you drop" technique salaried employees are legally subjected to.