If you want to sniff on switched networks, stop being so cheap.
You'll need a managed switch with the ability to designate a specific switch port as a SPAN or mirror port (http://en.wikipedia.org/wiki/Port_mirroring). This will allow you to monitor any other traffic that is passing through the switch.
Those days aren't gone, they merely got a whole lot more expensive.
In any case, it's more likely that you'd do monitoring at the egress point(s) of your private network, not on a particular switch.
Yet, you state he should not be returned to be questioned, so how can there be an investigation?
The evidence is their word. His defense is his word. Who knows what other evidence there is? Perhaps they have the broken condom with his and her DNA.
Actually, I think you'll find that their "word" is an allegation, not evidence. There's this funny concept that still exists (in name at least) called "Innocent until proven guilty"
Even a broken condom with viable DNA isn't proof - all that means is that they likely had sex at some point in the past. It does mean he likely had the opportunity, but sadly for you, it does not prove motive or intent. To achieve true justice, you'd need to combine all three to secure a conviction, not just the possibility of one. Hell, we all have many opportunities all day to rape, kill, steal, and cheat, but that doesn't mean we did any of those.
If he did it, then nail his balls to the wall, but sadly for you we don't yet live in a distopian police state paradise of the future and based on the alleged evidence so far, there isn't a case to answer.
Actually, didn't Sun sue Microsoft for their usual Embrace, Extend, Extinguish tactics when they added proprietary extensions to their Java version and claimed it was still Java, thus violating Suns patents/trademarks/copyright/license terms/whatever?
They didn't sue just because MS created their own runtime/JVM, they sued because MS distributed an incomplete Java implementation, and then passed it off as the Java, something which only Sun had the legal right to do.
Define "safe and secure" in the context of your internet connection.
In the context of a safe deposit box, it means that only you or your properly authorised agent should get access to the contents of the safe deposit box. The sole purpose for a safe deposit box is to keep people out.
In the case of an ISP who, if you look at things like the DMCA, it has already been established that they are merely a conduit, then "safe and secure" suddenly has all kinds of connotations and hidden subtleties. The primary purpose of an ISP is to give you access to the Internet.
As others have asked - it also depends where the ISP equipment ends and where yours begins. If you own the router, then the case can be made that the ISP has no right to be changing the password. If they own it, then you have no right to prevent them from managing their equipment even though it's wholly within your property.
Now, what you expect from your ISP unfortunately means absolutely nothing, it's what is stated in the contract that matters. In the case of the bank, it's going to be a big, non-negotiable clause that they keep your property away from unauthorised people. In the case of an ISP, you'll probably find that they delegate responsibility for maintaining the security of the communications and equipment to the customer, while at the same time reserving the right to take technical measures to address what they may consider to be security issues.
For what it's worth, I agree with your point and would even suggest that all ISPs have a responsibility to be more proactive about network security - I just don't think your bank manager example was very good as the situations are too different.
Does it really make sense to spend the bulk of the cost on maybe a 15% performance improvement, by moving data between disks a lot?
It can, for example, if your application is spending 85% of the time working on a small subset of your storage. Move that hot data to SSD and you could revolutionise the performance profile of the app.
FWIW, pick the right I/O profile to migrate to SSD, and you can expect far more than a 15% performance improvement. OLTP style I/O profiles (many, small random I/O) with a highly parallel RAID layout (say, RAID5 15+1 or RAID6 14+2) could net you a significant performance improvement over typical traditional layouts.
It's not a magic bullet, but for the right I/O profile even only a single RAID5 3+1 raidset on SSD can demolish much bigger raidsets on magnetic disk in terms of performance.
You still use the vendour name to create the input arguments for your 2nd invocation. How is that any better than
It's better because you're at least asking the runtime to describe itself instead of asking Windows to describe a DLL file. A DLL that you may not be able to trust is the correct DLL. If the runtime is lying to you, then you have much bigger issues to worry about and this whole point is moot.
In the previous post, you also said...
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.
So even if the Eclipse devs followed your advice, it still would have been broken, because you have to update at least something.
Actually, no it wouldn't, and here's why: from the first link in the summary:
An engineering side note: The "Java" property values for java.vendor and java.vm.vendor were never changed in the jdk6 releases and will remain "Sun Microsystems, Inc.".
and
The Windows specific exe/dll file "COMPANY" value is what is at issue here, not the Java properties. It came as a surprise to us that anyone would be inspecting or depending on the value of this very platform specific field.
So, while I totally agree that if the reported vendor changes, and if there aren't sufficient checks to handle this then yes, this exact same problem would still be there.
However, JDK and it's updates will "never" change the vendor string. If the Eclipse devs had taken the more correct route of determining the properties of the actual runtime they would be running under, we would never have seen this problem.
Also, from the first link:
Note that the jdk7 releases will eventually be changing to Oracle, including the java.vendor and java.vm.vendor properties.
So, we know also for a fact that with JDK 7, even java.vendor, and java.vm.vendor will change. Well, so what? We have plenty of notice, and the Eclipse devs could add code in *right now* to also allow "Oracle" in the vendor string and use the same workaround. That's what I would do.
If the workload of ensuring that your Java IDE (of all things) works with the new releases of the major JVMs is too much for you, then frankly, you're in the wrong business. Now, I accept that this change was difficult to predict, but the devs took such a short-sighted and broken view of what defined the JVM vendor that they really have to accept the blame here. Worse than that - they created an overly complicated proprietary mess to deal with it when they could have achieved the same with about 3 lines of code - code that would be cross-platform and not a special case hack.
You rant quite a lot about how incredibly bad the Eclipse devs did this job
Actually, I ranted about how there's a much better way, and somebody on the cross-platform Java IDE development team really should have known about it since it's also the class that provides you information about the nature of the freakin platform you're running on. Though, now that you mention it - yes, I agree with you, they did do an incredibly bad job, overcomplicating the whole issue, and guess what - they screwed up. Any change, intentional or not in the "COMPANY" field of the DLL (assuming they are even checking the DLL that the runtime is using - that's not even certain) will render their application totally unusable. So yes, they did do an incredibly bad job on this small part of it.
but your "solution" would have resulted in exactly the same situation.
As I've shown, my "solution" would have worked perfectly in this case, since the return value from the API has not changed. Since we also know that it will change with JDK 7, if they were using my "solut
I'm not near my usual machine so can't write any proper code, however, take a look here, the relevant parts seem to be:
System.getProperty ( "java.version" ) - Java Runtime version System.getProperty ( "java.vendor" ) - Java Runtime vendor System.getProperty ( "java.specification.version" ) - Java Runtime specification version System.getProperty ( "java.specification.vendor" ) - Java Runtime specification vendor System.getProperty ( "java.specification.name" ) - Java Runtime specification name System.getProperty ( "java.vm.version" ) - Java VM version System.getProperty ( "java.vm.vendor" ) - Java VM vendor System.getProperty ( "java.vm.specification.version" ) - Java VM specification version System.getProperty ( "java.vm.specification.vendor" ) - Java VM specification vendor System.getProperty ( "java.vm.specification.name" ) - Java VM specification name
I'd guess that the VM versions are more relevant for Eclipse, though the VM specification may be the best bet since (I assume, I haven't actually researched that bit), it will likely uniquely identify the Sun/Oracle VM better than the vendor string. Of course, this way means there is more work involved maintaining a database of VMs and their required tweaks.
This kind of stuff isn't publicised well as well as I would hope, but is by no means super-secret hidden knowledge meant only for the elite. Given that I hunted it out when creating a cross-platform (Solaris/AIX/Linux/Windows) utility at my last job just last year, and a quick check here shows it's been in Java since JDK 1.0, I find it utterly unbelievable that nobody on the Eclipse dev team realised there was a better way to get the JVM vendor information.
The -X options are non-standard and subject to change without notice.
Since a nonstandard switch is required at launch by the JVM, the only way to know what set of switches to pass is to query the JVM vendor string. It's not a clean solution, but it's a solution dictated by the platform.
No, it's not the only way and it certainly isn't the best way.
How about we query the runtime to determine which (if any) switches are required and then use that information to construct the command line for the real app?
If you must, you could even query the vendor string from within the runtime, but querying it from such an ephemeral location as metadata from a Windows DLL? Are you absolutely sure of your position that it's dictated by the platform that you must do it that way?
Quite so. It's also a potential marketing error. Sun's hardware and software engineering, pre-Oracle, had one of the best reputations in the industry (even if their sales organization wasn't so highly regarded).
McDonald's owns Chipotle, but that doesn't mean you can only buy McBurritos there, because that would likely send exactly the wrong message. Just like McDonald's, Oracle's brand has various negative connotations. Another example: Microsoft is very careful about this - for example, Xbox marketing materials often carry no Microsoft branding.
Ownership certainly does not mean you must piss all over everything to mark it as yours.
No, but it does mean you can, because it is yours - that's what "ownership" means.
But, what went wrong in this case is contained within a small bootstrap application for starting the VM. How are you supposed to use reflection to identify the set of custom startup options your application needs in order to function within a specific vendors JVM implementation?
Here's a thought - write the bootstrapper in Java, have it use reflection to get all the good stuff you're looking for, and then execute the real application with sane options.
With just a tiny little bit of lateral thinking, it really doesn't have to be a chicken and the egg scenario. You may still need a wrapper to get the bootstrapper running, but that's not a big deal when you look at the alternative.
Unfortunately, the Eclipse devs, and many people right here on Slashdot don't seem to grasp the simplicity of the solution, instead getting themselves caught in the chicken and egg trap.
I agree that Eclipse is at fault here, and that they should fix their app instead of hacking the JVM, but the fact remains that the crash is a *direct* result of an"unexpected but still valid string".
No, their detection logic failed because they were lazy and wanted nerd kudos for extracting the vendor string from a DLL.
Simple: Java stub to do the runtime detection and output to STDOUT the correct command line for starting the main application.
How on Earth could they not possibly figure this one out instead of whining that they can't detect the JVM without starting the JVM????? Well, start the freakin JVM, do the detection you need and use *that* information to start a new JVM.
Really, I'd like to know how they could be so short sighted!
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.
Some other reasons it was probably all a dream: (A) The hotel rooms when his wife was on the ledge were mirror images of each other, one destroyed, one not.
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.
(B) the references to his action packed espionage lifestyle being far fetched,
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...
(C) His token was actually HERS, and (D) her token was her burred secret.
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.
But there's no need to rely on the statement about thieves so it isn't really the logical fallacy you traduce.
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.
Honest people think most other people are honest
Is a perfectly valid, self consistent statement, no need to criticise that one.
If you see any kind of DRM on anything, you can be pretty sure its creator is a thief
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.
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.
What a ridiculous line of reasoning. The money is in lots of different systems. Unix, Windows, but largely IBM Mainframes running OS's like MVS.
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..
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.
The company sold him a device that includes software for which the license is GPL, but is not respecting his rights under the GPL.
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.
Slashdot Mirror
If you want to sniff on switched networks, stop being so cheap.
You'll need a managed switch with the ability to designate a specific switch port as a SPAN or mirror port (http://en.wikipedia.org/wiki/Port_mirroring). This will allow you to monitor any other traffic that is passing through the switch.
Those days aren't gone, they merely got a whole lot more expensive.
In any case, it's more likely that you'd do monitoring at the egress point(s) of your private network, not on a particular switch.
Why yes, yes it does. It's not until you are convicted at trial that you are legally guilty.
Until then you are just accused.
Yet, you state he should not be returned to be questioned, so how can there be an investigation?
The evidence is their word. His defense is his word. Who knows what other evidence there is? Perhaps they have the broken condom with his and her DNA.
Actually, I think you'll find that their "word" is an allegation, not evidence. There's this funny concept that still exists (in name at least) called "Innocent until proven guilty"
Even a broken condom with viable DNA isn't proof - all that means is that they likely had sex at some point in the past. It does mean he likely had the opportunity, but sadly for you, it does not prove motive or intent. To achieve true justice, you'd need to combine all three to secure a conviction, not just the possibility of one. Hell, we all have many opportunities all day to rape, kill, steal, and cheat, but that doesn't mean we did any of those.
If he did it, then nail his balls to the wall, but sadly for you we don't yet live in a distopian police state paradise of the future and based on the alleged evidence so far, there isn't a case to answer.
Going public with this stuff essentially defeats the purpose.
Well that kinda depends on what the purpose is, doesn't it?
My guess is either:
1. Free publicity
2. Misinformation
3. All of the above
We'll probably hear in a few months how they launch an IPO and the owners/CEO makes $$$$$.
Actually, didn't Sun sue Microsoft for their usual Embrace, Extend, Extinguish tactics when they added proprietary extensions to their Java version and claimed it was still Java, thus violating Suns patents/trademarks/copyright/license terms/whatever?
They didn't sue just because MS created their own runtime/JVM, they sued because MS distributed an incomplete Java implementation, and then passed it off as the Java, something which only Sun had the legal right to do.
Define "safe and secure" in the context of your internet connection.
In the context of a safe deposit box, it means that only you or your properly authorised agent should get access to the contents of the safe deposit box. The sole purpose for a safe deposit box is to keep people out.
In the case of an ISP who, if you look at things like the DMCA, it has already been established that they are merely a conduit, then "safe and secure" suddenly has all kinds of connotations and hidden subtleties. The primary purpose of an ISP is to give you access to the Internet.
As others have asked - it also depends where the ISP equipment ends and where yours begins. If you own the router, then the case can be made that the ISP has no right to be changing the password. If they own it, then you have no right to prevent them from managing their equipment even though it's wholly within your property.
Now, what you expect from your ISP unfortunately means absolutely nothing, it's what is stated in the contract that matters. In the case of the bank, it's going to be a big, non-negotiable clause that they keep your property away from unauthorised people. In the case of an ISP, you'll probably find that they delegate responsibility for maintaining the security of the communications and equipment to the customer, while at the same time reserving the right to take technical measures to address what they may consider to be security issues.
For what it's worth, I agree with your point and would even suggest that all ISPs have a responsibility to be more proactive about network security - I just don't think your bank manager example was very good as the situations are too different.
That's different, because you're paying the bank to keep whatever you put in the safe deposit box safe and secure.
Does it really make sense to spend the bulk of the cost on maybe a 15% performance improvement, by moving data between disks a lot?
It can, for example, if your application is spending 85% of the time working on a small subset of your storage. Move that hot data to SSD and you could revolutionise the performance profile of the app.
FWIW, pick the right I/O profile to migrate to SSD, and you can expect far more than a 15% performance improvement. OLTP style I/O profiles (many, small random I/O) with a highly parallel RAID layout (say, RAID5 15+1 or RAID6 14+2) could net you a significant performance improvement over typical traditional layouts.
It's not a magic bullet, but for the right I/O profile even only a single RAID5 3+1 raidset on SSD can demolish much bigger raidsets on magnetic disk in terms of performance.
You still use the vendour name to create the input arguments for your 2nd invocation. How is that any better than
It's better because you're at least asking the runtime to describe itself instead of asking Windows to describe a DLL file. A DLL that you may not be able to trust is the correct DLL. If the runtime is lying to you, then you have much bigger issues to worry about and this whole point is moot.
In the previous post, you also said...
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.
So even if the Eclipse devs followed your advice, it still would have been broken, because you have to update at least something.
Actually, no it wouldn't, and here's why: from the first link in the summary:
An engineering side note: The "Java" property values for java.vendor and java.vm.vendor were never changed in the jdk6 releases and will remain "Sun Microsystems, Inc.".
and
The Windows specific exe/dll file "COMPANY" value is what is at issue here, not the Java properties. It came as a surprise to us that anyone would be inspecting or depending on the value of this very platform specific field.
So, while I totally agree that if the reported vendor changes, and if there aren't sufficient checks to handle this then yes, this exact same problem would still be there.
However, JDK and it's updates will "never" change the vendor string. If the Eclipse devs had taken the more correct route of determining the properties of the actual runtime they would be running under, we would never have seen this problem.
Also, from the first link:
Note that the jdk7 releases will eventually be changing to Oracle, including the java.vendor and java.vm.vendor properties.
So, we know also for a fact that with JDK 7, even java.vendor, and java.vm.vendor will change. Well, so what? We have plenty of notice, and the Eclipse devs could add code in *right now* to also allow "Oracle" in the vendor string and use the same workaround. That's what I would do.
If the workload of ensuring that your Java IDE (of all things) works with the new releases of the major JVMs is too much for you, then frankly, you're in the wrong business. Now, I accept that this change was difficult to predict, but the devs took such a short-sighted and broken view of what defined the JVM vendor that they really have to accept the blame here. Worse than that - they created an overly complicated proprietary mess to deal with it when they could have achieved the same with about 3 lines of code - code that would be cross-platform and not a special case hack.
You rant quite a lot about how incredibly bad the Eclipse devs did this job
Actually, I ranted about how there's a much better way, and somebody on the cross-platform Java IDE development team really should have known about it since it's also the class that provides you information about the nature of the freakin platform you're running on. Though, now that you mention it - yes, I agree with you, they did do an incredibly bad job, overcomplicating the whole issue, and guess what - they screwed up. Any change, intentional or not in the "COMPANY" field of the DLL (assuming they are even checking the DLL that the runtime is using - that's not even certain) will render their application totally unusable. So yes, they did do an incredibly bad job on this small part of it.
but your "solution" would have resulted in exactly the same situation.
As I've shown, my "solution" would have worked perfectly in this case, since the return value from the API has not changed. Since we also know that it will change with JDK 7, if they were using my "solut
I'm not near my usual machine so can't write any proper code, however, take a look here, the relevant parts seem to be:
System.getProperty ( "java.version" ) - Java Runtime version
System.getProperty ( "java.vendor" ) - Java Runtime vendor
System.getProperty ( "java.specification.version" ) - Java Runtime specification version
System.getProperty ( "java.specification.vendor" ) - Java Runtime specification vendor
System.getProperty ( "java.specification.name" ) - Java Runtime specification name
System.getProperty ( "java.vm.version" ) - Java VM version
System.getProperty ( "java.vm.vendor" ) - Java VM vendor
System.getProperty ( "java.vm.specification.version" ) - Java VM specification version
System.getProperty ( "java.vm.specification.vendor" ) - Java VM specification vendor
System.getProperty ( "java.vm.specification.name" ) - Java VM specification name
I'd guess that the VM versions are more relevant for Eclipse, though the VM specification may be the best bet since (I assume, I haven't actually researched that bit), it will likely uniquely identify the Sun/Oracle VM better than the vendor string. Of course, this way means there is more work involved maintaining a database of VMs and their required tweaks.
This kind of stuff isn't publicised well as well as I would hope, but is by no means super-secret hidden knowledge meant only for the elite. Given that I hunted it out when creating a cross-platform (Solaris/AIX/Linux/Windows) utility at my last job just last year, and a quick check here shows it's been in Java since JDK 1.0, I find it utterly unbelievable that nobody on the Eclipse dev team realised there was a better way to get the JVM vendor information.
The -X options are non-standard and subject to change without notice.
Since a nonstandard switch is required at launch by the JVM, the only way to know what set of switches to pass is to query the JVM vendor string. It's not a clean solution, but it's a solution dictated by the platform.
No, it's not the only way and it certainly isn't the best way.
How about we query the runtime to determine which (if any) switches are required and then use that information to construct the command line for the real app?
If you must, you could even query the vendor string from within the runtime, but querying it from such an ephemeral location as metadata from a Windows DLL? Are you absolutely sure of your position that it's dictated by the platform that you must do it that way?
Quite so. It's also a potential marketing error. Sun's hardware and software engineering, pre-Oracle, had one of the best reputations in the industry (even if their sales organization wasn't so highly regarded).
McDonald's owns Chipotle, but that doesn't mean you can only buy McBurritos there, because that would likely send exactly the wrong message. Just like McDonald's, Oracle's brand has various negative connotations. Another example: Microsoft is very careful about this - for example, Xbox marketing materials often carry no Microsoft branding.
Ownership certainly does not mean you must piss all over everything to mark it as yours.
No, but it does mean you can, because it is yours - that's what "ownership" means.
But, what went wrong in this case is contained within a small bootstrap application for starting the VM. How are you supposed to use reflection to identify the set of custom startup options your application needs in order to function within a specific vendors JVM implementation?
Here's a thought - write the bootstrapper in Java, have it use reflection to get all the good stuff you're looking for, and then execute the real application with sane options.
With just a tiny little bit of lateral thinking, it really doesn't have to be a chicken and the egg scenario. You may still need a wrapper to get the bootstrapper running, but that's not a big deal when you look at the alternative.
Unfortunately, the Eclipse devs, and many people right here on Slashdot don't seem to grasp the simplicity of the solution, instead getting themselves caught in the chicken and egg trap.
I agree that Eclipse is at fault here, and that they should fix their app instead of hacking the JVM, but the fact remains that the crash is a *direct* result of an"unexpected but still valid string".
So, actually, you and cbhacking are both correct.
No, their detection logic failed because they were lazy and wanted nerd kudos for extracting the vendor string from a DLL.
Simple: Java stub to do the runtime detection and output to STDOUT the correct command line for starting the main application.
How on Earth could they not possibly figure this one out instead of whining that they can't detect the JVM without starting the JVM????? Well, start the freakin JVM, do the detection you need and use *that* information to start a new JVM.
Really, I'd like to know how they could be so short sighted!
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.
Some other reasons it was probably all a dream: (A) The hotel rooms when his wife was on the ledge were mirror images of each other, one destroyed, one not.
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.
(B) the references to his action packed espionage lifestyle being far fetched,
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...
(C) His token was actually HERS, and (D) her token was her burred secret.
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.
But there's no need to rely on the statement about thieves so it isn't really the logical fallacy you traduce.
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.
Honest people think most other people are honest
Is a perfectly valid, self consistent statement, no need to criticise that one.
If you see any kind of DRM on anything, you can be pretty sure its creator is a thief
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.
What a ridiculous line of reasoning. The money is in lots of different systems. Unix, Windows, but largely IBM Mainframes running OS's like MVS.
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.
The company sold him a device that includes software for which the license is GPL, but is not respecting his rights under the GPL.
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.