This destroys C++ (or any other software implementation) for performance.

Of the top of my head:

• * Java doesn't allow management of packed arrays of structs. This means you can't do things like cache optimisation of data structures. You can kind of get there by using nio buffers and ugly map to offset style things, but it's just ugly and unwieldy. Cost for no reason.
• * Java suffers from predictability problems. Jitter introduced by the system management threads and mutexes causes stalls to threads that you have no control over. There is a realtime Java VM, but it's not really "Java" as you can't use standard Java libraries and classes.
• * Related to the point above - in code with strict scheduling deadlines, you can't use dynamic memory allocation (this goes for C++ as well as Java), but using any of the standard Java libraries and/or objects allocates memory all over the place. You can use things like the Javolution collections to get around these issues.
• * Java's GUI toolkit (swing) allocates memory all over the place meaning all the hard work you put into a no-allocation loop in your code is wasted when using a JTabbedPane allocates massive amounts of memory just by moving your mouse over it.

I like Java as much as the next Java programmer, but the picture isn't that rosy when it comes to things needing real performance. C++ provides quite a few tools that can blow Java out of the water, purely because there's no runtime overhead and you have deterministic overhead. Add in the ability to manage cache line access and C++ will quickly run away with the title.

C++ doesn't make you pay for anything you aren't using and offers quite a few tools that allow micro-management of performance in a way Java simply cannot.

Are there really modern (ie within the last 2-3 years) computers that don't support WOL?

In all honesty I'm not sure - but there is the network card firmware, network card drivers and possibly the BIOS and/or EFI all that have the possibility to get in the way of this working out of the box.

The OP mentioned they are rentals - not owned - which makes things a bit tricky. They may have to purchase this functionality if it is available.

> we are required to have them on for the AV scans and backups, as well as automated Windows Updates.

I was under the impression this is what wake-on-lan functionality is for. Maybe your machines don't support this?

Can you imagine if you'd started playing doom and halfway through the game you had an accident and ended up with Anterograde Amnesia?

The use of emulators would allow you to groundhog day that same level for the rest of your life with the same pleasure as if it was the first time around.

(Yes, I feel bad. At least I didn't make a forking dick joke.)

I don't know the date of their tools release, but doing a "one shot" installation if you want to play around is pretty easy:

tar zxf gcc-4.8.0.tar.gz
cd gcc-4.8.0
./contrib/download_prerequisites
cd ..
mkdir gcc-4.8.0-build
cd gcc-4.8.0-buid
../gcc-4.8.0/configure --prefix=/SOMEINSTALLDIR --disable-multilib --disable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran
make -j #NUMPROCESSORS
make install

then add to PATH, LD_LIBRARY_PATH etc

That'll get you up and running.

So did I misintepret your comment:

I infered from that that Red Hat and NVidia actively looked to stop it. I apologise if that wasn't what you meant, it just came off that way.

Moving to Xegl would have been steps backwards until appropriate approaches for the problems I mentioned could be found. (How would existing stereo 3D GLX applications work? Very important to the people that use them. Video was a mess, too, what about multi-screens...) David was rather flippant about these problems at that time, but they were real roadblocks.

AIGLX provided a simpler route that didn't lose functionality in the meantime and didn't require writing a new driver. It wasn't just Red Hat / Nvidia bullying their way through here (your premise up the thread) - it gathered momentum as it was (at that time) the simpler way forward that didn't break anything. I think some of the Mesa drivers were first to implement AIGLX.

I'll agree Xegl did show promise in providing a single simple approach for driver development though.

So, given the nature of open source - if Xegl was superior, why didn't someone keep working on it? Why aren't we discussing Mir and Xegl instead of Mir and Wayland?

The disagreement was purely technical.

The XGL approach caused a bunch of peformance problems for various rendering scenarios (stereo3d, overlays like video) - XGL forced everything through a pixmap to be rendered by GL.

No acceleration using the GPU for video / scaling or anything else.

XGL was cool because it was first and everyone got googly eyed at the effects. It probably was a catalyst in getting the right solution (AIGLX), too.

I'm afraid the real world has a few more shades of grey than hacked or not hacked.

The bad guys get caught with varying levels of "in" in the DMZ. High value single account targets are of interest to the bad guys too. A shotgun approach of attack can set off alarm bells where a surgical strike can go unnoticed for a bit longer.

Banks in particular have improved over the last few years with two factor auth and dropping the "smart client" (java / flash) mess, but the bad guys are just as inventive - social engineering has been on the rise to counteract some of these advances.

I realise I'm not going to convince you without any factual backup. On the other hand, I'm not willing to put former colleagues and employers in the spotlight.

I'd agree that the standard JVM / JDK is anything but realtime, but Sun (Oracle now of course) created a JSR specifically tackling the shortcomings w.r.t. real time:

• Sun's real time VM implementation
• JamaicaVM
• IBM's real time VM
• Atego's real time VM

Having worked for a couple of banks in my time and had the ear of some of the security chiefs, I can tell you that it does happen. Unless it's a particularly visible breach (multiple account details stolen, loss of funds with transfers), very little of it makes it to the media. For obvious reasons.

What makes you think you'd hear about it if happened? Most companies will only hold up their hands and admit problems when the evidence is undeniable. See Sony.

As entertaining as a finger pointing "these guys don't know what they're doing" exercise can be, with the best will in the world you're always just one mistake away from letting the bad guys in.

It sounds like they have a pretty good system in place (salted hashes, intrusion detection mechanisms and notification) and they aren't being coy about a problem.

At the very least their internal security team now gets a nice big stick to beat management with to stopping cutting certain corners.

VIM users would call, but a phone isn't in the orignal VI editor, so they don't have one.

Funnily enough, the french word for reluctant is "reticent". (Arrrgh, it's 2012 and Slashdot still doesn't do UTF8 properly...)

Maybe the original poster has fallen for this common faux pas. The less said about the editors the better.

I think we're on the same page.

No way am I going back to C programming. Enough years tearing my hair out over my own malloc/free problems to want to deal with other peoples .-)

The bindings I'd written allowed me to instantiate the rhythmbox DB and query it, create a wrapping shell for the rhythmbox main components (gui and other) - and all in far, far less lines of code than the equivalent C.

The rhythmbox developer told me "I find vala annoying".

I mean, GObject in C isn't annoying?