How's this: write a short Java stub that detects the runtime environment from within the VM and passes back a guaranteed consistent string to the wrapper that then decides how to start the Java VM and run the main application.When your supported VMs are upgraded by the vendor - you've got a tiny little Java app to update and the rest of the behemoth is never touched.

Hell, you could even have the runtime detection code return the actual command line to start the main application so that the wrapper can be as simple as possible.

Is this rocket science? No.
Is this difficult? No.
Is this inefficient? No - it's about the best option when you can't change the VM runtime parameters at runtime. You've got one more VM invocation for an app that will probably run for 8 or more hours at a time.
Does this suffer from the schoolboy error of accepting arbitrary unvalidated variable input and assuming it is 100% correct, immutable, and altering your whole user experience based on it? No.
Does this have the geek credit associated with extracting the vendor string from a Windows executable? No.

Considering that the alternative is so simple, and would be cross-platform to boot, I call shenanigans on the Eclipse Windows devs and assume the last point was the one that drove them to do it the way they did.

It doesn't help your confidence in their development skills that their way is also a classic security blunder. Since there's no way to validate the input, they shouldn't be even considering using it without sanitation, and even then - there's no way to know if it's correct. The runtime detection I have described will at least give them the configuration of the *runtime* which is, after all, what they are looking for. While the Java VM may protect them from certain kinds of vulnerability - the fact that their mindset is such that they are happily relying on unverifiable, uncontrollable data as a means to control the entire behaviour of their application is astonishing and makes me question the security of the whole app.

I don't think we can assume that any scene from his memory of his wife are necessarily 100% accurate - he was clearly shaping the dream world of her so the similarity of the rooms could just be artistic license on his part. Plus, I've stayed in hotels in Tokyo with a similar layout - look out the window and what you think is a different hotel is actually the same on and those rooms were fitted out identically. Most hotels would do that and especially rooms on the same floor would most likely be the same size and therefore have the same internal layout.

What "action packed" lifestyle? He was an "architect", and he's on the run so must keep on the move. Maybe it's just semantics, but I wouldn't call that action packed espionage...

Not sure of the point you're trying to make here - your totem only really has to be an item you can keep with you that only you know intimately. It's implied that no living person can know of it (since a dead person cannot create or enter dreams. The fact that it used to be hers and that she tried to forget her past life (which the totem was the last symbol of) are completely consistent.

Whether honest people believe that other people are honest is wholly irrelevant to the reality of whether people are honest or not.

The presence or absence of DRM on a software product is rarely, if ever a decision of the actual creators of that product, rather, it is a property of the distribution channel. Now, you could make the point that the big game producers want to have the DRM - but that's their distribution arm making the requirement, not the creative arm. The game producer as a whole requiring DRM is not the same as the creative people behind the game requiring it.

Nothing you've said contradicts my statement. Just believing that somebody is a thief does not make you yourself a thief, and this is easily provable.

Do you believe that the bankers who caused the recent economic crisis were thieves?
Do you believe that the bankers who gladly too taxpayer's money as bailouts and then promptly gave themselves huge bonuses with it are thieves?
Do you believe that Bernie Madoff was a thief?

If you answered yes to any of those, well congratulations - by your argument, you're also a thief regardless of whether you stole anything or not.

There's every reason to concentrate on that statement since that's the one with the error in it, and is the central point to the argument.

Is a perfectly valid, self consistent statement, no need to criticise that one.

Is the central argument and is provable totally bogus and should rightly be criticised. Based solely on the arguments presented, the *only* thing you can be pretty sure of is that DRM is present. DRM says nothing at all about whether the creator is a thief or not - absolutely nothing. Now, it may very well be that the creator is in fact a thief, but the existence of DRM is wholly incidental to that fact. DRM implies an unhealthy, obsessive desire to control what people do with your product long after you have sold it and therefore by most standards should no longer have control over it. It does not necessarily imply the creator/producer/distributor is a thief. Theft requires that you are taking somebody's property with the intention of permanently depriving them of it.

You could argue that the recent Sony debacle with OtherOS is theft, and I might even agree with you, but much as I hate DRM myself, I can at least see clearly enough to realise that while DRM can enable control, it is up to the rights holder to exercise it.

No, they are not mutually exclusive, and while I agree with your general point I think your example was flawed. It depends (like most scams) on people (honest or otherwise) being fooled. There is no requirement for the victim to be honest.

That's a logical fallacy.

Just because thieves think everyone is a thief, it does not follow that if you think someone is a thief, then so are you.

Well, before starting my own IT and Enterprise storage consultancy company last November, I just spent 2 years in global storage engineering for a global investment bank - one of the few investment banks that actually remained profitable during the recent market crash.

Trust me, they didn't have a single mainframe in their estate.

Prior to that, I worked at (then the #2, now the #1) global news/financial data agency for two years. Prior to that, I was in professional services at the world leading enterprise storage vendor, with many internationally trading banks as clients.

Enterprise SAN is the only way you're going to get the levels of redundancy, resilience, and accountability necessary to satisfy people like the SEC.

In total, I've probably worked in six or seven bank data centres.

In my experience at least, the ratio of banks that have mainframes exclusively in the back-end money-making flow is about 50/50 at best. Every single one of them has Solaris (or possibly AIX) and Oracle as a core component of their back-office money making operation.

I'm not trying to get into a pissing contest, and you have a perfectly valid point of view, it's just not the only way, and not even necessarily the majority way.

Now that's where you're either wrong, or just plain didn't understand what dAzED1 was saying.

Yes, the front office systems are a mix of Windows, Unix, and mainframe - but that's not where the "money" is. Those systems are just the management interface to the back-office systems where the real money (such that it is) actually is. Those back-office systems are largely Unix, typically Solaris, and given the nature of the banking industry, they'll be SPARC based.

As for the back-office systems, the mission-critical systems that handle all the trades and foreign exchange? Well, actually, it's not unusual for those to actually be 10 year old systems running 10 year old software, on a 10 year old OS. It's not unusual to run those on Solaris 8, with extended paid support from Sun/Oracle.

The reason such old systems are still in use? It's the same reason that until relatively recently vacuum tubes were still in use by the military - the characteristics are known, and the system works. You don't want to risk your billions of dollars a day of trades by using a new, untested system.

Having said that, you are totally right about the multi-layered security and how you get a better return/risk ratio from compromising a huge number of desktops for a small payout each than one bank system for a huge payout..

Except the Librarian won't be standing over you making sure it's your thumbprint you're using - after all, the system is infallible, right?

All it would take is one or two extra thugs to cause a distraction, and Bingo!

As you say, copyright holders cannot assign standing to third parties other than by transferring the copyright. The problem is, is that as copyright legislation stands, only the copyright owner can sue for copyright infringement.

Even if the next version of the GPL included such terms as you suggest, they would be unenforceable because they would be neutralised by copyright law. That's why you don't see such terms in licenses - they would be legally unenforceable, and that would hurt the GPL more than situations such as the one the OP is discussing.

No - I'm not a lawyer etc, but after a quick perusal, in the UK and US at least, as copyright legislation stands, only the copyright owner can sue for copyright infringement. Otherwise, you'd get a situation where I could sue you for copyright infringement for the latest hit console game, even though I have no connection to you or the game company - it'd be chaos. Of course, there wouldn't really be a problem in the proprietary world, but then you lose all of the freedoms that the GPL grants you.

Even law enforcement does not (or at least, isn't supposed to) actively enforce copyright - even if it's criminal copyright, unless the copyright holder has asked for action to be taken.

Of course, he could still sue, though if he makes copyright the sole grounds for his lawsuit, it's probably going to be a very short case, and it won't end in his favour.

If he's in Europe, he may be able to sue on the grounds of our stronger consumer protection laws, but even then - I seriously doubt he'd get past the first hour before the case is dismissed.

You're absolutely right, but one right the GPL does not transfer is the *copyright*. You get the right to do pretty much what you want with the software, so long as you play nice and transfer those same rights to anybody you distribute the software to, but you don't get the copyright on that code.

I totally agree, and I may be being anal here (it does happen - a lot), but I find it dangerous to make a sweeping generalisation just because nobody has bothered to do it any other way. GP was using FUD to suggest that the GPL (and, by implication/association open source software in general) is incompatible with a commercial business. Really, "commercial" just refers to the scale of the business, and to a certain extent the fact that you pull in a bunch of revenue. It just so happens that keeping everything proprietary makes this a whole lot easier.

As you say, for pure software products the only thing left to sell is the services. Other types of product, while gaining in popularity, are still effectively niche products - my N900, set-top boxes, routers, Tivo - all of these are able to monetise open source software via the hardware and likely also some services too, (though with the exception of Nokia with the N900, as far as I know, most companies who make the others don't fully understand the implications of the GPL initially), but they are still relatively niche players.

My problem with the statements above, is that if nobody challenges them, they tend to condition people to believe that they are true, so for every comment like that, you get a hundred people believing that GPL is Darth Vader to their Luke Skywalker.

He can't sue, because he has no standing. He's not the copyright owner.

Since the OP has given us no details as to the specifics of the two cases, it's impossible to offer any kind of rational comment.

Though, for your information, the GPL does not "infect" anything. It is a copyright license like any other except that it puts most of the control in the hands of the beholder. To the extent that it "infects" anything, that's all the choice of the developer. Don't want to follow the terms of the GPL? Simple, don't use code that is covered by the GPL in your product. It's exactly the same as any other copyright license. If you don't agree to the terms, don't use it. It's not rocket science, and it's not some kind of virus that needs to be stamped out.

By the way, due to the lack of information from the OP, it's not even clear if the FSF has any standing here - mentioning that they are not willing/able/prepared to fight the good fight is worthless when they may not even own the copyright allegedly being infringed.

I'm more inclined to believe this is something the FSF simply don't have the right to push for the reason mentioned above.

Are you confusing commercial with proprietary?

You see, there's the problem right there: Exactly what clause are these alleged companies accused of violating? They've provided the source code, Hell, the OP doesn't even mention what version of the GPL they think the companies are violating. I mean, really - how are we supposed to discuss the issue in such a scenario?

Actually, playing Devil's Advocate here - your original post didn't state that your ext2 partitions were legacy partitions and that the application is so mission critical that you can't afford the downtime to upgrade the filesystem, and that therefore you don't consider that journalling offers you any advantage.

Your original post does indeed imply that you are specifically choosing ext2 (hence, effectively disabling journalling).

You failed to explain the reason for using ext2 so people had no choice but to make assumptions.

I've been there myself. I used to work in engineering for a multi-national investment bank. Even now, they have mission critical, customer facing applications running on Solaris 8 and 10 year old hardware that you can't even get approval to open the cabinet in the data center, never mind upgrade to something even remotely supported.

A tiny bit of non-confidential background would have made all the difference.

Just saying.

That's probably because the data wasn't flushed from cache when the crash occured. Ext4 writes file metadata pretty quickly (possibly even immediately), but the actual data is cached and not written until later.

It's a known issue with the interaction of certain programs and the filesystem. Specifically, KDE had big issues with it because it would perform filesystem atomic operations on config files, but would neglect to flush the new data. If the system crashed, the atomic operations had completed but the data wadn't been flushed so all your config files were nicely truncated when you rebooted.

You could argue both ways for whose fault it is, but at the end of the day, the application was making assumptions that the filesystem wasn't agreeing with so bad things happened.

This has been mitigated by the default interval between flushing the cache being reduced from 15 to 5 minutes (I believe), but there's still a window of opportunity for the application to screw up if it makes the same assumption.

To be safest, you have to flush the cache on every write while possibly changing the way the application handles files, and that would absolutely slaughter performance - effectively bypassing the cache altogether.

Speed or data integrity - pick one.

It sucks, but there you have it.