Re:Family is all that matters in life.
on
Disillusioned With IT?
·
· Score: 5, Insightful
Tell me then... what exactly did his parents sacrifice for? Is his child expected to also sacrifice his happiness, so that his grandchildren can be happy? What of them?
I say, find balance and moderation in all things. Don't give up on happiness, but don't pursue only that. Lots of people manage to make career changes and support a family, and many of them are happier for it.
/. is being an awfully depressed and pessimistic bunch today.
They *can* offer recommendations one way or the other. You certainly shouldn't trust them to. I've seen it happen, though -- I served on a grand jury issuing indictments, and we would pay attention to the officer's opinion. We almost always handed back what both the DA and the officer wanted, but there were a couple cases where the DA asked for several indictments and we only handed back some of them basically because the officer asked us to. I'm absolutely not saying you should trust the officer or count on him putting in a good word for you -- but he has more influence than just being a witness, if he chooses to use it.
(The county I'm in has a relatively rare grand jury system for regular felony indictments (ie not an investigative grand jury). They have two juries, each of which meets one day a month to hear potential indictments. Jurors serve for 12 months, and hear a couple dozen cases each day. So I saw half of the indictments in the county for about 8 months (I moved before the year ended), and there were a few such cases. Rare, but not unheard of.)
I basically agree, but the police officer has somewhat more influence than that. They can ask the prosecuting attorney to do something, or offer opinions if asked by the indicting grand jury. Those carry weight, even though they aren't legally binding. Of course, that does *not* mean that the officer is telling the truth when he offers to help you out -- but, if he was being sincere, his opinion will carry some weight.
I don't know of an easy way to figure out what the GC is cleaning up. -Xloggc and such may help, or may not. I would say that much waiting is a bad thing -- you should likely be doing less of it, though how to accomplish that I can't say without seeing the code.
You say you're doing text crunching; I'd look for string ops as possible culprits for the GC activity. Remember, for Strings, a = b + c involves a hidden new -- and therefore a GC operation if a has been initialized before (all string objects are constants). If you're doing any sort of modification of strings, ie not just reading numbers but breaking strings up into lines and such, you probably want to consider using a CharBuffer, or possibly a char[] array, depending on what you're doing.
The dirty hack method of reducing GC time (only sometimes works) is to give the JVM too much memory at invocation (-XmxBIGNUM -XmsBIGNUM), and then call System.gc() occasionally and hope to do your garbage collecting in large chunks.
Oh, almost forgot, and it's a big one -- assuming you're using Sun's JVM, are you running server or client mode (-server or -client)? It can make a big difference on some apps, and it's worth trying both ways. My guess is your app does better under the server JVM, and it defaults to client...
Anyway, good luck. Java performance tuning isn't too hard; just watch out for hidden operations. There are much better tools available, but just running -Xprof is a pretty decent start.
Even after it loaded, it was sluggish with poor response to the controls. In native Java there'd be a load time, but if done well it would be quite snappy after that.
Don't get me wrong, I'm quite impressed. But I'm impressed in the "damn that's neat" sense, not in the sense that I'd ever contemplate using it for anything.
For anyone trying to make a Java program run faster, the first thing I always do is look at the profiler output (java -Xprof Foo) and see how much time is spent in the GC. If it's more than a couple %, you've got too many new's and too much garbage collection going on -- and 5% time in the GC represents far more than a 5% performance hit, thanks to thread switching overhead and thrashing the CPU caches. Basically, never ever have a new in an inner loop -- you wouldn't put a malloc there in C, so don't put a new there in Java.
If you've taken care of that, and it still runs slow... Look to what API calls you're making. Are you adding single characters to Strings a lot (they're final; there's a hidden new and lots of copying in that operation)? Making lots of system calls that produce context switches? Basically, attack it like you would a C program, and you'll get good results. Why people manage to optimize C code well and not Java is beyond me, given that they use similar tools to do so...
Replying twice, bad form I know, but I forgot to mention:
If you really care about floating point precision, it's trivially easy to get in java: use the strictfp keyword on the relevant class or method, and java will generate code that *exactly* implements IEEE 754 arithmetic on all hardware. I don't know off hand how to do that in other languages; I imagine some make it easy and some make it hard to impossible. I can't see it being much easier than specifying a single keyword with the appropriate scope, though. (There will, obviously, be a performance penalty involved if the underlying hardware is not inherently IEEE 754 compliant.)
Floating point numbers are expected to behave like that. It's an inherent limitation of the base conversion combined with finite precision and any exact equality test. 8.12 gets rounded off to a number slightly less than 8.12 when stored as a float; when multiplied and cast it gets rounded down to 811.
#include <stdio.h>
int main(int argc, char* argv) {
double val;
int upper;
double newval;
printf("val: %e\nupper: %d\nnewval: %e\ndiff: %e\n", val, upper, newval, (val - newval));
return 0;
}
evand@Desktop:~/test$ gcc --version
gcc (GCC) 4.2.3 (Debian 4.2.3-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Java and C are both behaving exactly how they're supposed to. First rule of working with floating point numbers: never do an exact equality test on the results of calculations. That includes testing the edge case of rounding, which is what you're doing. If you're rounding off to an int, you had better be prepared to have very small errors get magnified on occasion.
It's kinda silly to find a fault with one language, and then use that fault as basis to switch to another language without first checking whether it has the same fault. And in this case, the fault is not with the languages.
Why wouldn't I code in Java? For most things I code, I see about a 10-20% performance penalty vs C, plus a modest load time (that I don't care about usually). I also see a noticeably reduced development time; for me that's a trade worth making under most circumstances. Now, I'm not coding user interfaces, and I am paying attention to performance of my Java code (unlike many Java developers). I'm also emphatically not claiming it's a good environment for everything (but I'd say the same about any language / platform). For what I do, it does a good job of balancing speed and ease of development and a number of other things.
If you'd like to claim that Java is universally slow, I have a program spec you're welcome to implement in the language of your choice for comparison. I'll warn you, though, the last time someone implemented it in C++ it came out slower (though once I pointed out the subtle algorithmic difference between our implementations, the C++ won by 10-20%).
Tetris performed better on my Gameboy (an 8-bit, 4.2MHz x80 CPU with 8KB RAM) than this clone does on my 32-bit 1.4GHz Athlon. And it had sound. Tetris shouldn't load "quickly" it should load instantly.
This is a very clever hack, and I admire the work -- but it is in no way practical for anything. I find the idea of using it for "real work" apalling -- and I code in Java by choice!
In general, you're wrong. The people stealing from houses that we heard about got caught either because someone called it in in progress, or because they did a bad job selling the stuff. The video surveillance tended to be at convenience stores in the poor, high-crime parts of town; in one case that I remember, the convenience store installed video cameras after the second breakin, and caught the guy on the third.
Police aren't interested in investigating burglaries where no one got hurt, be they poor neighborhoods or well to do ones. Perhaps the police take more interest in the truly wealthy, but for the merely well off upper middle class, you've got approximately zero hope that the police will do any real investigative work.
He was the one who attached the trailer, not the owner. Both were sitting in the driveway, with keys in the car -- he'd been breaking into cars all down the street, and got "lucky." So I suppose it's both a stupid crook and a stupid owner story...
Exactly. I sat on a grand jury a couple years ago and heard numerous burglary indictments. Most of the cases the police clearly weren't terribly interested until the perp happened to hit a place with good surveillance, and then they usually knew who it was immediately and the case went very quickly.
The county I'm in does grand juries a little oddly -- they have two standing grand juries for all felony indictments (investigatory grand juries are different). You serve one day a month for a year (one jury meets at the start of the month, the other in the middle), and you hear a couple dozen cases each day. So I saw plenty of burglary cases, and the ones that actually came to us tended to have either video surveillance or an ID from a pawn shop. There were some stupid crook stories too (hint: if you're stealing a car, with boat attached, remember to hook up the trailer lights), but mostly the indictments came from video footage accompanied by a comment from the officer that they thought the perp was responsible for several other area breakins but couldn't prove it.
I sat on a grand jury a couple years ago. (Not an investigatory one; we issued general felony indictments. The county I live in does things a little oddly -- they have a pair of standing grand juries, each of which meets once a month to hear potential indictments. You're on the jury for a year, and hear a couple dozen cases each day, so I saw a bunch. All felony indictments go through one of the two.)
The most common case for small time burglary was that there would be a set of crimes that the police were convinced were related, and then finally the thief would hit some place that had video cameras that were placed well enough to produce a usable image -- at which point, odds were they had already had dealings with that person, and the case got fairly easy. So usually they would present it to us as an indictment for just the one crime, but explain that the investigation was being treated as part of a group.
So if you want the guy caught, there's really no substitute for good video surveillance. Sure, plenty of cases were based on things like the thief pawning stolen goods, but video was the most prevalent and easiest to work with.
If they apologize for calling their fans thieves, then yes. They got it wrong; everyone makes mistakes, and sometimes they're big ones. If they're willing to admit it, then I can forgive them; if not, then they're just out to make a quick buck.
I want the industry to get it right; I feel no need to be vindictive. But if they're just jumping on the next bandwagon, then they haven't actually changed at all.
But in all seriousness, even if it were relevant, that's a case where the *past* itinerary is relevant -- which has absolute zero legitimate reason to be classified, imho. Security concerns are valid for future itinerary, but not past. I think most such plausible state secrets defenses are similar.
There is nothing that both needs to be secret and is the only defense in a lawsuit they would otherwise lose. There's plenty that should be secret / classified / whatever, as you say. But under what possible circumstances is the President's future itinerary a key component of a lawsuit defense? Seriously. If it looks so wrong from the outside that they're going to lose a court case over it, then there isn't much that should be secret that could also make it not be an illegal act.
FMS is much more widely used these days; Toad did a (very cursory, I believe) code review and is now using it. There's a list of all newsgroups that people you know of have posted to; it's not very long, generally, so searching isn't particularly required (and is your newsreader's problem anyway).
With or without the darknet mode, the anonymity is good but not 100%. Especially for large files (or groups of files) there are statistical attacks (eg, if I'm getting requests for a large fraction of file, I'm probably closer to the requester). They're nontrivial to implement, but they're much harder on a darknet. Perfect anonymity is either impossible or very close, but Freenet is doing pretty well for many purposes. Stronger anonymity guarantees, and resistance to attackers with more substantial resources, are among the goals for 0.8.
Has it ever occurred to you to try, you know, moving to someplace with a better normal:kiddielover ratio? Someplace less like Freenet, in other words?
There's plenty of abhorrent material on any P2P network. In my experience, Freenet is not particularly different, for better or for worse.
What Freenet does have more than its fair share of are conspiracy theorists and related weirdos. But I count that as neither surprising nor particularly problematic.
Exactly. The problem with getting bored / distracted isn't so much that you make errors, but that you don't usually notice until after you start making mistakes -- but the distraction is already clearly present, and I see no reason it shouldn't be detectable.
And as soon as the launcher starts to move, the weight is no longer all that meaningful. Everyone in the industry uses metric -- though you'll still see rough numbers quoted in Imperial units, mostly for marketing though. Basically any time 1kg = 2 lb and g = 10m/s^2 aren't accurate enough, people use metric. OP is right,/. should be using metric here.
If we can put it off for a few thousand years by not screwing up right now, that's a big plus. I doubt we can even imagine where technology will be then, and that's a relatively short time frame for natural climate change. Maybe not manmade change, though...
Tell me then... what exactly did his parents sacrifice for? Is his child expected to also sacrifice his happiness, so that his grandchildren can be happy? What of them?
I say, find balance and moderation in all things. Don't give up on happiness, but don't pursue only that. Lots of people manage to make career changes and support a family, and many of them are happier for it.
/. is being an awfully depressed and pessimistic bunch today.
That would be my point. Ulterior motives or not, the officer has more influence than merely as a witness.
They *can* offer recommendations one way or the other. You certainly shouldn't trust them to. I've seen it happen, though -- I served on a grand jury issuing indictments, and we would pay attention to the officer's opinion. We almost always handed back what both the DA and the officer wanted, but there were a couple cases where the DA asked for several indictments and we only handed back some of them basically because the officer asked us to. I'm absolutely not saying you should trust the officer or count on him putting in a good word for you -- but he has more influence than just being a witness, if he chooses to use it.
(The county I'm in has a relatively rare grand jury system for regular felony indictments (ie not an investigative grand jury). They have two juries, each of which meets one day a month to hear potential indictments. Jurors serve for 12 months, and hear a couple dozen cases each day. So I saw half of the indictments in the county for about 8 months (I moved before the year ended), and there were a few such cases. Rare, but not unheard of.)
I basically agree, but the police officer has somewhat more influence than that. They can ask the prosecuting attorney to do something, or offer opinions if asked by the indicting grand jury. Those carry weight, even though they aren't legally binding. Of course, that does *not* mean that the officer is telling the truth when he offers to help you out -- but, if he was being sincere, his opinion will carry some weight.
I don't know of an easy way to figure out what the GC is cleaning up. -Xloggc and such may help, or may not. I would say that much waiting is a bad thing -- you should likely be doing less of it, though how to accomplish that I can't say without seeing the code.
You say you're doing text crunching; I'd look for string ops as possible culprits for the GC activity. Remember, for Strings, a = b + c involves a hidden new -- and therefore a GC operation if a has been initialized before (all string objects are constants). If you're doing any sort of modification of strings, ie not just reading numbers but breaking strings up into lines and such, you probably want to consider using a CharBuffer, or possibly a char[] array, depending on what you're doing.
The dirty hack method of reducing GC time (only sometimes works) is to give the JVM too much memory at invocation (-XmxBIGNUM -XmsBIGNUM), and then call System.gc() occasionally and hope to do your garbage collecting in large chunks.
Oh, almost forgot, and it's a big one -- assuming you're using Sun's JVM, are you running server or client mode (-server or -client)? It can make a big difference on some apps, and it's worth trying both ways. My guess is your app does better under the server JVM, and it defaults to client...
Anyway, good luck. Java performance tuning isn't too hard; just watch out for hidden operations. There are much better tools available, but just running -Xprof is a pretty decent start.
Even after it loaded, it was sluggish with poor response to the controls. In native Java there'd be a load time, but if done well it would be quite snappy after that.
Don't get me wrong, I'm quite impressed. But I'm impressed in the "damn that's neat" sense, not in the sense that I'd ever contemplate using it for anything.
Exactly. JIT'ed code performs quite well.
For anyone trying to make a Java program run faster, the first thing I always do is look at the profiler output (java -Xprof Foo) and see how much time is spent in the GC. If it's more than a couple %, you've got too many new's and too much garbage collection going on -- and 5% time in the GC represents far more than a 5% performance hit, thanks to thread switching overhead and thrashing the CPU caches. Basically, never ever have a new in an inner loop -- you wouldn't put a malloc there in C, so don't put a new there in Java.
If you've taken care of that, and it still runs slow... Look to what API calls you're making. Are you adding single characters to Strings a lot (they're final; there's a hidden new and lots of copying in that operation)? Making lots of system calls that produce context switches? Basically, attack it like you would a C program, and you'll get good results. Why people manage to optimize C code well and not Java is beyond me, given that they use similar tools to do so...
Replying twice, bad form I know, but I forgot to mention:
If you really care about floating point precision, it's trivially easy to get in java: use the strictfp keyword on the relevant class or method, and java will generate code that *exactly* implements IEEE 754 arithmetic on all hardware. I don't know off hand how to do that in other languages; I imagine some make it easy and some make it hard to impossible. I can't see it being much easier than specifying a single keyword with the appropriate scope, though. (There will, obviously, be a performance penalty involved if the underlying hardware is not inherently IEEE 754 compliant.)
Floating point numbers are expected to behave like that. It's an inherent limitation of the base conversion combined with finite precision and any exact equality test. 8.12 gets rounded off to a number slightly less than 8.12 when stored as a float; when multiplied and cast it gets rounded down to 811.
#include <stdio.h>int main(int argc, char* argv) {
double val;
int upper;
double newval;
val = 8.12;
upper = (int)(val * 100.0);
newval = ((double)upper)/(100.0);
printf("val: %e\nupper: %d\nnewval: %e\ndiff: %e\n", val, upper, newval, (val - newval));
return 0;
}
evand@Desktop:~/test$ gcc --version
gcc (GCC) 4.2.3 (Debian 4.2.3-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
evand@Desktop:~/test$ gcc test.c
evand@Desktop:~/test$
val: 8.120000e+00
upper: 811
newval: 8.110000e+00
diff: 1.000000e-02
Java and C are both behaving exactly how they're supposed to. First rule of working with floating point numbers: never do an exact equality test on the results of calculations. That includes testing the edge case of rounding, which is what you're doing. If you're rounding off to an int, you had better be prepared to have very small errors get magnified on occasion.
It's kinda silly to find a fault with one language, and then use that fault as basis to switch to another language without first checking whether it has the same fault. And in this case, the fault is not with the languages.
Why wouldn't I code in Java? For most things I code, I see about a 10-20% performance penalty vs C, plus a modest load time (that I don't care about usually). I also see a noticeably reduced development time; for me that's a trade worth making under most circumstances. Now, I'm not coding user interfaces, and I am paying attention to performance of my Java code (unlike many Java developers). I'm also emphatically not claiming it's a good environment for everything (but I'd say the same about any language / platform). For what I do, it does a good job of balancing speed and ease of development and a number of other things.
If you'd like to claim that Java is universally slow, I have a program spec you're welcome to implement in the language of your choice for comparison. I'll warn you, though, the last time someone implemented it in C++ it came out slower (though once I pointed out the subtle algorithmic difference between our implementations, the C++ won by 10-20%).
Tetris performed better on my Gameboy (an 8-bit, 4.2MHz x80 CPU with 8KB RAM) than this clone does on my 32-bit 1.4GHz Athlon. And it had sound. Tetris shouldn't load "quickly" it should load instantly.
This is a very clever hack, and I admire the work -- but it is in no way practical for anything. I find the idea of using it for "real work" apalling -- and I code in Java by choice!
In general, you're wrong. The people stealing from houses that we heard about got caught either because someone called it in in progress, or because they did a bad job selling the stuff. The video surveillance tended to be at convenience stores in the poor, high-crime parts of town; in one case that I remember, the convenience store installed video cameras after the second breakin, and caught the guy on the third.
Police aren't interested in investigating burglaries where no one got hurt, be they poor neighborhoods or well to do ones. Perhaps the police take more interest in the truly wealthy, but for the merely well off upper middle class, you've got approximately zero hope that the police will do any real investigative work.
He was the one who attached the trailer, not the owner. Both were sitting in the driveway, with keys in the car -- he'd been breaking into cars all down the street, and got "lucky." So I suppose it's both a stupid crook and a stupid owner story...
Exactly. I sat on a grand jury a couple years ago and heard numerous burglary indictments. Most of the cases the police clearly weren't terribly interested until the perp happened to hit a place with good surveillance, and then they usually knew who it was immediately and the case went very quickly.
The county I'm in does grand juries a little oddly -- they have two standing grand juries for all felony indictments (investigatory grand juries are different). You serve one day a month for a year (one jury meets at the start of the month, the other in the middle), and you hear a couple dozen cases each day. So I saw plenty of burglary cases, and the ones that actually came to us tended to have either video surveillance or an ID from a pawn shop. There were some stupid crook stories too (hint: if you're stealing a car, with boat attached, remember to hook up the trailer lights), but mostly the indictments came from video footage accompanied by a comment from the officer that they thought the perp was responsible for several other area breakins but couldn't prove it.
I sat on a grand jury a couple years ago. (Not an investigatory one; we issued general felony indictments. The county I live in does things a little oddly -- they have a pair of standing grand juries, each of which meets once a month to hear potential indictments. You're on the jury for a year, and hear a couple dozen cases each day, so I saw a bunch. All felony indictments go through one of the two.)
The most common case for small time burglary was that there would be a set of crimes that the police were convinced were related, and then finally the thief would hit some place that had video cameras that were placed well enough to produce a usable image -- at which point, odds were they had already had dealings with that person, and the case got fairly easy. So usually they would present it to us as an indictment for just the one crime, but explain that the investigation was being treated as part of a group.
So if you want the guy caught, there's really no substitute for good video surveillance. Sure, plenty of cases were based on things like the thief pawning stolen goods, but video was the most prevalent and easiest to work with.
If they apologize for calling their fans thieves, then yes. They got it wrong; everyone makes mistakes, and sometimes they're big ones. If they're willing to admit it, then I can forgive them; if not, then they're just out to make a quick buck.
I want the industry to get it right; I feel no need to be vindictive. But if they're just jumping on the next bandwagon, then they haven't actually changed at all.
:)
But in all seriousness, even if it were relevant, that's a case where the *past* itinerary is relevant -- which has absolute zero legitimate reason to be classified, imho. Security concerns are valid for future itinerary, but not past. I think most such plausible state secrets defenses are similar.
There is nothing that both needs to be secret and is the only defense in a lawsuit they would otherwise lose. There's plenty that should be secret / classified / whatever, as you say. But under what possible circumstances is the President's future itinerary a key component of a lawsuit defense? Seriously. If it looks so wrong from the outside that they're going to lose a court case over it, then there isn't much that should be secret that could also make it not be an illegal act.
Indeed. Here's one of the better writeups.
FMS is much more widely used these days; Toad did a (very cursory, I believe) code review and is now using it. There's a list of all newsgroups that people you know of have posted to; it's not very long, generally, so searching isn't particularly required (and is your newsreader's problem anyway).
With or without the darknet mode, the anonymity is good but not 100%. Especially for large files (or groups of files) there are statistical attacks (eg, if I'm getting requests for a large fraction of file, I'm probably closer to the requester). They're nontrivial to implement, but they're much harder on a darknet. Perfect anonymity is either impossible or very close, but Freenet is doing pretty well for many purposes. Stronger anonymity guarantees, and resistance to attackers with more substantial resources, are among the goals for 0.8.
There's plenty of abhorrent material on any P2P network. In my experience, Freenet is not particularly different, for better or for worse.
What Freenet does have more than its fair share of are conspiracy theorists and related weirdos. But I count that as neither surprising nor particularly problematic.
Exactly. The problem with getting bored / distracted isn't so much that you make errors, but that you don't usually notice until after you start making mistakes -- but the distraction is already clearly present, and I see no reason it shouldn't be detectable.
And as soon as the launcher starts to move, the weight is no longer all that meaningful. Everyone in the industry uses metric -- though you'll still see rough numbers quoted in Imperial units, mostly for marketing though. Basically any time 1kg = 2 lb and g = 10m/s^2 aren't accurate enough, people use metric. OP is right, /. should be using metric here.
If we can put it off for a few thousand years by not screwing up right now, that's a big plus. I doubt we can even imagine where technology will be then, and that's a relatively short time frame for natural climate change. Maybe not manmade change, though...