Forgot your password?

Comment: Re:no capacitors (Score 1) 76

by dshk (#46618903) Attached to: Samsung SSD 840 EVO MSATA Tested
It is not the file systems which mess up the data (at least with journaling file systems), but the SSD drives without power loss protection capacitors. What a journaling file system could do, if it successfully syncs the journal, but after a restart the journal is gone, the result of later partial writes are there? This is the so called serialization error. It happens with costomer HDD drives too, but it is much worse with these SSD drives. Take a look at the publication I linked in my other comment above.

Comment: Re:no capacitors (Score 1) 76

by dshk (#46616423) Attached to: Samsung SSD 840 EVO MSATA Tested
I don't expect total power loss protection. I do expect reasonable behaviour, like data already synced to the drive is there even after a power loss. SSD drives without capacitors fail spectacularly, they are much worse than HDD drives. Just google for "SSD failure modes abstract", for example:

Comment: Re:Damnit (Score 1) 302

by dshk (#46544401) Attached to: Java 8 Officially Released

Actually we also upgraded to Java 7 I just forgot to mention that in my original post.

I am not sure what do you mean on deprecated calls. In new Java releases they deprecate functions or classes but they never remove them. Therefore deprecated functions do not cause backward compatibility issues. As others already mentioned likely you mean calls into JRE internal sun.* classes. Those are never deprecated, because they were never public! No code should call them, except very special applications in very special circumanstances, but then they should always provide a default fallback algorithm, and advertise this issue on the very first page of this documentation. Actually the only software I know which has a good reason to call internal sun.* code is the big data database, Cassandra, which is assumed to manage memory in the hundreds of gigabytes range.

However, I understand you, because with such a large amount of code you likely run into each and every bug in the JRE class libraries at some point in your code. But your situation is definitely not the usual, and based on your disappointed tone, I believe your organisation is doing something strange. You say that you have 74 gigabytes of code, but the entire Java EE codebase is less than 80 megabytes of binary code. It is quite strange that you blame that 0.1% code for all your problems. You should either pay for Oracle support, and receive bug fixes early, or pay developers who can quickly fix JRE bugs themselves, and that will be still a tiny fraction of your IT budget. Java related costs must be compared to the similar cost of some alternative technology, so you could tell whether Java or that alternative is the more cost effective in your situation. I do not know anything else which seems to be better for us.

Comment: Re:Damnit (Score 2) 302

by dshk (#46520589) Attached to: Java 8 Officially Released
I am working on a 80 000 lines long Java web application in the last 15 years. I have upgraded through 5 major versions, from Java 1.1 to 1.2 to 1.3 to 1.4 to 5 to 6. I do not remember a single issue related to any of these upgrades. There vere about 2 minor issues when we migrated from Unix to Windows to Linux (related to the case sensitivity of the file system).

Comment: Re:Workaround (Score 2) 373

by dshk (#46266927) Attached to: Report: Valve Anti-Cheat (VAC) Scans Your DNS History

Players who are frustrated by cheaters are also ready to boycott Steam. If I were Steam, I would serve my frustrated, honest users. We also maintain a gaming site, and you cannot believe how many people get angry because of cheaters.

I have no issue if they only check for domains or only selectively download the list. But I use three different machines for gaming, development, and system administration.

Comment: Re:Call me... (Score 2) 136

by dshk (#46241595) Attached to: Background Javascript Compilation Boosts Chrome Performance

We have the same performance critical application in both Java and Javascript. After doing many optimizations in JavaScript (and therefore running into several JavaScript JIT compiler bugs in different browser versions!), JavaScript is still much slower. JS is indeed a promise, but only because it is in newborn state if we consider using it for larger applications.

It is not an accident that Google tries to replace JavaScript with Dart, which already outperforms JavaScript and is more suitable for larger applications. JavaScript was never intended for such purpose. It is very good however, for scripting a web page.

Comment: Re:Performance (Score 3, Informative) 136

by dshk (#46241341) Attached to: Background Javascript Compilation Boosts Chrome Performance
No, JavaScript is not compiled before execution, because that would delay startup. It starts in interpreted mode. Then the runtime environment gradually compiles frequently running code. I do not know how advanced are the JavaScript runners, but the Java JIT compiler can even compile the same code fragment several times, using different optimizations as it collects more runtime statistics.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun