Absolute nonsense. As long as you dither correctly (which by by now should be industry standard) there's no 'distortion' created by 'decimating' to 16-bit sound.
The main problem with modern mastering is too much dynamic compression (not data compression which Owsinski seems to be confused by in the FTA). Given a light touch on Waves L3 (or whatever rinky-dinky limiter the mastering engineer prefers), there is no difference between 16 and 24-bit to even 'golden ears'.
Sounds great. Looking at it raises a couple of questions though:
1) When are they going implement this? Googling 'Chrome' from machines in Switzerland, Miami and Chicago still gives the 'Download and install Google Chrome' link in the prime position.
2) Wouldn't any other company have been banned and have to resubmit?
Re:Do you not like to use Occum's Razor theroy
on
Is the Earth Special?
·
· Score: 1
"Created for a reason" is a very complex explanation for Earth's origin: because you have to explain the creation of the creator(s).
It doesn't matter how trivial it is since MAC filtering adds no security at all and is a waste of time. A "long non-trivial password" is the only security measure you can take (or need to take) with WPA2.
You're generally correct, but your example of differences of 10^-70 seconds is way off (yea, I know, you just pressed the zero key for 'some time'). These relativistic effects are at about 10^-14 seconds and anything below plank time (10^-44s) is meaningless in current physics.
Why can't you write 255::1? The argument (by the OP) about hex being easier to convert to binary than decimal is lame. It may be harder for his 11-year old sister...
It's not ridiculous for this reason: the LCD screen has a much lower resolution than the either the sensor or your eye looking through an optical path. You can't focus accurately with current preview screens, yet this is trivial with any SLR viewfinder (since you're experienced, of course I'm talking matte screens here rather than split image).
Well, we are talking about Java after all (and surely not 1.0 which only has historical interest). Mutable locals are easily achieved by putting them in a collection - the collection reference is final and immutable but its contents aren't.
Nonsense. In Java just wrap it in a class. E.g (Let's call the class lambda and have it predefined with a single func method, say in a library):
List<Lambda> myListOfLambdas = new ArrayList<Lambda>();
public void letsMakeALambda(){ final String localContext = "A proper closure sees the local context"; myListOfLambdas.add(new Lambda(){public Object func(Object o){ return localContext; }}); }
public void letsUseALambda() for(Lambda l: myListOfLambdas){ System.out.println(l.func(null)); } }
The language doesn't matter; the runtime does. If lambdas or functional transforms or dynamic objects matters to you, you will already have implemented it in some cool libraries and got on with shipping stuff (my 20% is my weekends...).
All I can say is That JVM has excellent performance and compatibility for the OSes I use on the server side (and indeed the Java language has all the primitives I need); if Oracle can give me something significantly better, I'll be prepared to pay for it.
There's not even the slightest chance that ARM will compete with X64 in servers in the medium term. Your fundamental argument ("it's CISC, not RISC") becomes ever more irrelevant withe each ML cycle since the CISC overhead is a constant (rather than a proportional) factor of the total number of transistors.
Only the most skillful or lucky human driver would the survive your mountainside scenario. The experience of assisted driving aids so far (ABS etc) is very positive apart from the decrease in driver awareness such aids engender.
I don't think fully automated driving is very far away apart from social and legal acceptance factors - anti-skid, weather sensors and satellite relief maps combined with some sensible heuristics developed by skillful drivers might even make the mountainside situation survivable (of course, a robot car coming the other way shouldn't be in the middle of the road anyway because it won't have been drinking).
Slashdot Mirror
Absolute nonsense. As long as you dither correctly (which by by now should be industry standard) there's no 'distortion' created by 'decimating' to 16-bit sound.
The main problem with modern mastering is too much dynamic compression (not data compression which Owsinski seems to be confused by in the FTA). Given a light touch on Waves L3 (or whatever rinky-dinky limiter the mastering engineer prefers), there is no difference between 16 and 24-bit to even 'golden ears'.
That's surely 10^12 microphones.
Wow. So they went from top position to (er...) top position. They're really stamping their authority on this one.
My point is: shouldn't the whole site (google.com) be completely removed from the search indexes?
Sounds great. Looking at it raises a couple of questions though: 1) When are they going implement this? Googling 'Chrome' from machines in Switzerland, Miami and Chicago still gives the 'Download and install Google Chrome' link in the prime position. 2) Wouldn't any other company have been banned and have to resubmit?
"Created for a reason" is a very complex explanation for Earth's origin: because you have to explain the creation of the creator(s).
I have never confused a Samsung product with an Apple product; only a true idiot (or a German judge - same thing) would.
Please! Graham's number is something a kitten would play with. I prefer to use TREE(3) in a power tower that's TREE(3) high.
It doesn't matter how trivial it is since MAC filtering adds no security at all and is a waste of time. A "long non-trivial password" is the only security measure you can take (or need to take) with WPA2.
That's why the smart companies get themselves a fancy European office and do deployments at 03:00 am Eastern with wide awake support engineers.
You're generally correct, but your example of differences of 10^-70 seconds is way off (yea, I know, you just pressed the zero key for 'some time'). These relativistic effects are at about 10^-14 seconds and anything below plank time (10^-44s) is meaningless in current physics.
Why can't you write 255::1? The argument (by the OP) about hex being easier to convert to binary than decimal is lame. It may be harder for his 11-year old sister...
Why can't your visitors also enter by boat?
That the Philippines, Palau, Canada and Micronesia are the USA's bitches? Of course, the only true date format is the blessed monotonic one: yyyyMMdd.
Each of your premises is almost perfectly wrong. Wonderful stuff!
But fiber optic transmits information better. And information is power...
Nobody will be interested in stealing fiber. Sounds like a win-win (except for AT&T's insurance company).
It's not ridiculous for this reason: the LCD screen has a much lower resolution than the either the sensor or your eye looking through an optical path. You can't focus accurately with current preview screens, yet this is trivial with any SLR viewfinder (since you're experienced, of course I'm talking matte screens here rather than split image).
Well, we are talking about Java after all (and surely not 1.0 which only has historical interest). Mutable locals are easily achieved by putting them in a collection - the collection reference is final and immutable but its contents aren't.
Nonsense. In Java just wrap it in a class. E.g (Let's call the class lambda and have it predefined with a single func method, say in a library):
List<Lambda> myListOfLambdas = new ArrayList<Lambda>();
public void letsMakeALambda(){
final String localContext = "A proper closure sees the local context";
myListOfLambdas.add(new Lambda(){public Object func(Object o){
return localContext;
}});
}
public void letsUseALambda()
for(Lambda l: myListOfLambdas){
System.out.println(l.func(null));
}
}
The language doesn't matter; the runtime does. If lambdas or functional transforms or dynamic objects matters to you, you will already have implemented it in some cool libraries and got on with shipping stuff (my 20% is my weekends...).
All I can say is That JVM has excellent performance and compatibility for the OSes I use on the server side (and indeed the Java language has all the primitives I need); if Oracle can give me something significantly better, I'll be prepared to pay for it.
Tell me about it! Every bloody telco an hour early.
There's not even the slightest chance that ARM will compete with X64 in servers in the medium term. Your fundamental argument ("it's CISC, not RISC") becomes ever more irrelevant withe each ML cycle since the CISC overhead is a constant (rather than a proportional) factor of the total number of transistors.
I love my Nexus One too, but there are limits.
POWER7 is too expensive, NEC is nowhere in the (software) market, and what did you say about Itanium...?
Only the most skillful or lucky human driver would the survive your mountainside scenario. The experience of assisted driving aids so far (ABS etc) is very positive apart from the decrease in driver awareness such aids engender.
I don't think fully automated driving is very far away apart from social and legal acceptance factors - anti-skid, weather sensors and satellite relief maps combined with some sensible heuristics developed by skillful drivers might even make the mountainside situation survivable (of course, a robot car coming the other way shouldn't be in the middle of the road anyway because it won't have been drinking).
I'm a child of the seventies...