Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:But, but... (Score 1) 62

by hibiki_r (#49358589) Attached to: US Air Force Overstepped In SpaceX Certification

I've seem time factor heavily in some road construction: St Louis: I-64 roadwork was going to cause havoc on many people's commutes, as it required closing go the most traveled highway on the city. The contracts took into consideration how long it was going to take, offered bonuses for finishing early and severe escalating penalties for delays. It was finished early.

Comment: Re:Reminds me of one thing (Score 1) 724

by IamTheRealMike (#49352757) Attached to: Germanwings Plane Crash Was No Accident

Because then everyone dies when the computer fails. Autopilots regularly fail and expect the pilot to take over

I think this depends on your definition of "fail". As far as I know true computer failures where the machine just goes crazy and tries to crash the plane are non-existent. What happens more regularly is the autopilot sees that something weird is happening and chooses to disengage itself - presumably an autopilot program could be written that never disengages and always does the best it can to fly the plane, unless deliberately disengaged.

This is particularly problematic when sensors fail, as they did in AF447, and the computer doesn't know what's going on any more.

No, this is irrelevant. If the planes sensors completely fail then the pilot doesn't know what's going on either, and the plane is probably doomed no matter what. In normal operation these planes are flying in a very small speed corridor between disintegration and stalling. If you don't know how fast your going a stall or overspeed is pretty much inevitable, and if you don't know how high you are even basic visibility problems can cause a crash into the surface. Neither human nor computer can succeed in such a situation.

Comment: Java strings overweight? Citation? (Score 1) 479

by kervin (#49343109) Attached to: No, It's Not Always Quicker To Do Things In Memory

People just say things on here and it's taken as fact. How is Java's String implementation overweight?

Java, like C# does use 16 bit char widths, but that actually makes it faster than variable width characters. That's why these languages do so.

So what about Java strings are 'overweight'?

Comment: Re:Check their work or check the summary? (Score 1) 479

by hibiki_r (#49337849) Attached to: No, It's Not Always Quicker To Do Things In Memory

It might have helped in this problem, but nowadays, even assembly language is just an abstraction: You might thing you are doing in order operations on 8086, but they are really being translated to out of order operations inside of the processor that will get the same result, but with very different performance. Branch prediction? Nah, we can run the beginning of BOTH branches, and just discard the computation we did not want, because it's actually faster. And don't get me started on the differences between what you tell a video card to do, and what it actually does.

The distance between what we write in practical, end user facing applications and what happens in the hardware is so large nowadays that it's hard to have any real control over what is going on. The best we can do is understand the performance characteristics that we see in the layer right below ours, and hope things don't change too much.

Therefore, the problem with the original paper is that it fails to really explain what we can learn from the experiment. It's not that disk is faster than RAM: That's just ludicrous. But that we really have to have some understanding of the libraries and VMs we use to get anywhere. It'd not be impossible for the JVM to realize the immutable string is being edited in a loop, that there are no references to it that could escape, and then just optimize the whole thing into a string buffer implementation that should be as good as calling the file writer: It just happens to not do said optimization for us. It's happened in Java before: Code that was seen as terrible because it was very slow is not slow anymore, and easier to read than the old school way of optimizing it.

Comment: Re:I think this is BS (Score 2) 160

by mseeger (#49331369) Attached to: Energy Company Trials Computer Servers To Heat Homes

Nope, Central Europe.

State of the art for a DC is a PUE (Power Usage Effectiveness) value of 1,1 or lower. This means: for getting 1kwh used for a computer, you have to put 1,1kwh (or less) into the datacenter.

This uses the adiabatic cooling, which is some kind of cheating (you are evaporating water). But water is in ample supply here (not being California).

We are currently in the process of designing a new DC and getting the PUE value as low as possible is major design goal.

See: http://www.modbs.co.uk/news/ar...

Comment: Re:And now why this can not be done in the USofA (Score 3, Insightful) 316

Five square metres of solar panel on every single domestic roof in the USA would produce a very significant energy change. 125 million houses * 5Kw is 625 gigawatts. Germany has 23 gigawatts of domestic solar panels, which, on a sunny day, is sufficient to power the whole country. Yes, obviously, it doesn't work twenty-four hours a day, or in bad weather. Yes, obviously, you need to find some way of storing energy, such as compressed air, hydrogen hydrolysis, pumped storage or whatever. None of this is rocket science.

Bottom line: the USA could power its whole economy, including road vehicles, on domestic solar panels alone.

Comment: Re:Kill them all. (Score 1) 332

As you say it was stable under the Ottoman empire, because they took over and kept it, America needs to do the same thing. The US, Canada, Australia, NZ were all British colonies, but the difference is the white people never left, so they remain beacons of progress. Hate to sound all racist here, but there is a strong correlation between those and African, Middle Eastern states that were given back.

I think you should probably read a good history of the British empire, followed by 20th century history, before posting nonsense like this.

The causes of problems in the middle east have a lot to do with the long term history of the "beacons of progress" fucking with the region. Specifically when the Ottoman Empire collapsed the colonialists divided the region up along entirely arbitrary borders that often drew straight lines right through native tribes and populations, then appointed flunkies to rule these new countries. There was zero attempt to make something that worked for the people who lived there. This caused serious long term resentment.

Have you ever watched the ISIS video of them blowing up border posts? The ISIS soldiers keep talking about the end of Sykes-Picot. Even though I actually have read a history of the British Empire, I still had to look that one up. It turns out to be the British-French treaty that created the borders of Iraq. Families in different villages were suddenly divided from each other, etc. The people who live there apparently still hate Sykes-Picot to this day.

Plus, when countries in the region got leaders the western powers didn't like, there were interventions (e.g. Iran). There were invasions. Not to mention the gaping wound that is Israel and the absolutist support for it from the US.

There hasn't ever really been a time when more powerful militaries weren't fucking with people who live in the middle east. Religion certainly plays a part, but the USA is a lot more religious than other western developed countries and it doesn't seem to hurt them much ....

People will buy anything that's one to a customer.

Working...