Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:almost tempted to buy some shares (Score 1) 424 424

Capable has nothing to do with carrier appetite. Carriers want to control and build their own silos complete with lock-in, nothing about "he we can run android apps too, but with 10x the number of OS versions and 20x the number of device devices to support" makes good business sense for a carrier.

Comment: Re:He wouldn't be paying income tax on that (Score 3, Informative) 650 650

Indeed, clearly higher European tax rates lead to a better recirculation of the wealth and overall fiscal health superior to the US. Unless you actually look at the data. Belgium, Ireland, the UK Spain, Portugal and Greece all have higher private debt defaults than the US as a percentage of GDP, Germany is statistically equivalent. All of those states aside from Germany, despite higher taxes have a higher debt to GDP ratio and again, Germany is roughly equivalent. The Europeans may "love" their higher taxes, but they aren't any better at controlling their spending or debt, quite the opposite. http://online.wsj.com/article/SB10001424052748704140104575056751636031606.html

Comment: Re:True for JAVA, but not generally true... (Score 1) 270 270

This may be true for Java. It isn't true for C/C++.

With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates. It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches. I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.

I've seen similar arguments against using hyper-threading with Java. Curious, have you tried limiting the number of threads to prevent the thrashing or a pbind equivalent to keep a thread closer to a cache pipeline?

Comment: Worry about their own house first? (Score 1) 236 236

Honestly, the MF has bigger issues they should be focused on. If they were killing it, Chrome wouldn't even make the front page. Bloat continues to overtake their software and they're being out-engineered by smaller teams backed by big companies. They should turn their attention inwards first and worry about Chrome second.

Comment: Not "Buying" It (Score 4, Insightful) 199 199

Small to mid-sized shops who get by with less than a dozen SAs and who don't have WAN volume replication concerns might go this route, but there is too much risk for Fortune 500. It mostly boils-down to 3rd party applications, hardware and drivers. If you're a F500, you probably have proprietary storage of some sort and you probably rely on volume replication across the WAN. You want to hook into that storage from Linux, you need a "certified" platform and that ain't going to be an arbitrary set of Ubuntu packages. Sure it will probably work from Ubuntu, until you get kernel panics under load. Then your in-house Linux "experts" call support for the storage vendor and they ask what distro version and driver you're using. When you say "Gutsy Gibbon recent" they laugh and refuse to support you. At that point, your idea of community support doesn't look quite so hot considering nobody in the community can repro your hardware/driver issue.

Any programming language is at its best before it is implemented and used.

Working...