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?

Funny you should mention that, as the GNOME foundation actually has a (modernish) langauge that can used to write GNOME programs:

Vala.

It compiles to C with all the appropriate boilerplate for Gnome's libraries and introspection files to allow calling from python / java etc.

Shame very few of the core gnome devs want to use it though. I wrote some bindings for rhythmbox in it that would have allowed the devs to write parts of rhythmbox in Vala - but they are too invested in C and only wanted to use it for a plugin API.

I have the impression that the devs just like the "exclusive club" attitude that C programming brings. Don't know if that's true.

Thanks for writing this. Will use this at some point :-)

It's true the frame rate increases are marginal over typical refresh rates.

However, if you can render frames quicker, the CPU that would have been used for rendering (blocking on API calls / waiting for things to happen) can now be allocated to something else (AI / sound / loading).

Now it's possible you don't gain all of that since GPU offloading takes place, but any extra free CPU has to be good, right?

Cheers, I'll miss you too.

Unfortunately that's just how things go.

I've watched the slashdot audience change from dirty geeks looking for musical visualisation of sorting algorithms into "social media" pro piracy anarchists (yes, I know you call yourselves libertarian).

It used be that intelligent discussion was rewarded. Hell, even the trolls were better.

There's still the occasional nugget of old slashdot, but as another poster pointed out, we're not the demographic anymore.

D

TLDR: I miss my pages being WIDE