Forgot your password?
typodupeerror

Comment: Re:ZoneAlarm and NetBarrier (Score 2) 164

by RivieraKid (#36021826) Attached to: Marlinspike's Droid Firewall Kills Tracking

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.

Comment: Re:Yo dawg, I heard (Score 1) 840

by RivieraKid (#34620734) Attached to: Assange Secret Swedish Police Report Leaked

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.

Comment: Re:Should have been completely hush-hush (Score 1) 457

by RivieraKid (#33522282) Attached to: Film Industry Hires Cyber Hitmen To Take Down Pirates

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 $$$$$.

Comment: Re:How ironic (Score 5, Informative) 510

by RivieraKid (#33237828) Attached to: Oracle Sues Google For Infringing Java Patents

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.

Comment: Re:uhhh (Score 1) 545

by RivieraKid (#33147602) Attached to: Verizon Changing Users Router Passwords

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.

Comment: Re:IT Department Pricing to You, not TCO to Compan (Score 1) 420

by RivieraKid (#33121934) Attached to: Internal Costs Per Gigabyte — What Do You Pay?

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.

Comment: Re:Using a company field to extract key VM info? (Score 1) 397

by RivieraKid (#33082184) Attached to: Oracle's Java Company Change Breaks Eclipse

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 "solution" and it still broke, then yes - they would still be doing an incredibly bad job, because they still didn't take into account that the vendor may change.

You know, I really don't like the quotes around solution - since I actually have produced a solution that would have prevented this issue, and would be easy to maintain in future if the devs are doing their due diligence properly, I think it's fair to remove those quotes, don't you?

My solution also has the benefit that should similar tweaks become necessary for Solaris, or MacOS, or Linux, or whatever in future, well the framework to deal with that is already in place and it's totally platform agnostic. No need to write a special case each and every time - one size fits all since we're using publically documented Java APIs instead of some proprietary API that will only work on one platform.

Comment: Re:Using a company field to extract key VM info? (Score 1) 397

by RivieraKid (#33081616) Attached to: Oracle's Java Company Change Breaks Eclipse

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.

Comment: Re:One line fix (Score 1) 397

by RivieraKid (#33081420) Attached to: Oracle's Java Company Change Breaks Eclipse

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?

Comment: Re:How about uname? (Score 1) 397

by RivieraKid (#33081350) Attached to: Oracle's Java Company Change Breaks Eclipse

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.

Comment: Re:Oracle Responded Well (Score 1) 397

by RivieraKid (#33081170) Attached to: Oracle's Java Company Change Breaks Eclipse

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.

Comment: Re:IT'S ALREADY FIXED!! (Score 1) 397

by RivieraKid (#33080796) Attached to: Oracle's Java Company Change Breaks Eclipse

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!

Some programming languages manage to absorb change, but withstand progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Working...