Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

Comment Re:better late than never (Score 4, Interesting) 76

Actually the points of contention here are:
1. Emergency pumps were marked as checked, but were not actually checked.
2. Diesel backup generators were probably not checked as they experienced a cascade failure when powered on.
3. Post could have been dealt with better (though this is likely more the fault of former P.M. Kann).
4. Company may have mis-used disaster management emergency funds / officials did not act in a responsible manner (EG officials did not take pay cuts / officials did not start working extra hours / generally officials did not show enough responsibility).

Particularly #4 should be looked at as there have been accidents at nuclear plants before - all previous cases had officials immediately responding to the issues ON SITE and seeing the solutions to completion personally. Companies like Touhoku Electric and Chubu Electric have shown extremely responsible oversight to the point of their CEO's taking extreme personal risks to remedy any problems and constantly going beyond government requirements for all safety measures. TEPCO on the other hand seems to be run by greedy d-bags.

Comment Re:Yes. (Score 2) 149

You're an idiot. No such laws exist and there have been constant news stories about Fukushima and agriculture there.

There are radioactive hot-spots in many places all around the world. Just for reference none of the radioactive hot spots in Tokyo come close to the radioactivity of the famous black sand beaches in Brazil.

The vegetables from Fukushima are safer to eat then the FUD you've been stuffing down.

Comment Re: Would you eat it? (Score 1) 149

The rice and vegetables being discussed here are not being raised in the exclusion zone. Fukushima is a 13,780 km prefecture with a very large amount of agriculture. Less than a percent of the total land zoned for agriculture before the quake/disaster in contained in the exclusion zone.

Now please proceed to shove your FUD up your ass.

Comment Re:This ignores the team diet requirements: (Score 1) 149

Actually food is made available in Olympic villages and outside food is often restricted due to concerns over doping. There's tons of stories relating to this from the Beijing Olympics. Usain Bolt even recalled eating nothing but chicken nuggets and cola for two days before his record run because it was the only food available he felt was safe.

Comment Re:Heck no it's radioactive!!! (Score 1) 149

1. The exclusion zone has been shrinking due to cleanup efforts.
2. The rice and vegetables being discussed here are not being raised in the exclusion zone. Fukushima is a 13,780 km prefecture with a very large amount of agriculture with. Less than a percent of the total land zoned for agriculture before the quake/disaster in contained in the exclusion zone.

Now please proceed to shove your FUD up your ass.

Comment Re: Coffee break (Score 1) 93

I'd argue that the reason for low OSS OS adoption on the desktop has much more to do with the target market. Haiku can basically exist as a little niche OS with very few users who only care about their specific hardware configurations because at the end of the day it's an OS for people who were fans of BeOS. It doesn't have some killer feature or some market it's aiming to grab.

Linux on the other hand can be made into what you want. While there are some vendors who build out to catch the desktop market there are a limited number. Furthermore, there is the question of weather or not most devs would want a larger desktop market in the first place. Why have more bug reports, more uninformed support requests, more complaining users when you don't actually monetarily benefit. If we're going to start encouraging a market where Linux will rule the desktop we need to find some way to properly pay the developers of the software that allows it to be a desktop OS.

Comment Re:C++ with Java for networking (Score 1) 296

What I don't like about JNI is how it approaches wrapper generation - essentially assuming you are writing your C/C++ code *specifically* to be used in Java. Case in point being the fact you basically have to directly modify your header files. This can of course be avoided by writing code/headers that include JNI and your native headers - but then on top of that you need to write wrapper headers and wrapper code. Most other wrapper systems don't make this assumption and just let you write an interface or some wrapper code and be done with it.

On top of that actual generation of the wrapped binaries isn't nearly as smooth and integrated as say Ruby native gems. Maybe it can be set up to be cleanly automated so everything will be generated for your build target at compile time but in my currently limited time dealing with Java I've yet to see such a setup.

I would like to point out I'm no expert on JNI and have only used it twice before going all SWIG. Actually if you know of a good example or guide for JNI that could set me straight I'd love to see it.

Comment Re: C++ is never the right tool (Score 1) 296

You're talking about what we would call "managed blocks" in the systems we used. We didn't have malloc even, we literally just had a block and a pointer to the head and we'd write our own new and delete functions that would just mark or unmark sections of a map.

There are however plenty of systems that do have native new and delete that are specifically written as RTOS embedded systems. EG: ITRON which is found in a lot of automotive [sub]systems.

Generally though most embedded systems set up their memory statically, like you pointed out. Parent poster here however is referring to a media system where some blocks (like display buffers) would be static there are probably many different modes so not a single function application and not something where one globally static map would fit all cases.

Comment Re:If you cannot answer your own question.. (Score 1) 296

I'd say you're mostly correct and for the question this guy is posting I'd say you're dead on.

Personally I've fit into the "very few" category you point out with specialized applications / working with a non-standard protocol server / interfacing with network hardware so much that even if I'm writing a standard HTTP client I write the headers and handle the streams myself. With HTTP 2.0 coming though I think I may stop that practice. Still, anyone writing a networking client should at least play with HTTP at least once - it's a very easy protocol to handle with tons of documentation and a myriad of reference implementations.

Comment Re:If you cannot answer your own question.. (Score 4, Interesting) 296

I program raw TCP in C++.

I think maybe you meant to say "do you realize people program raw TCP in C++?" or something like that.

Also, I agree with you that the person asking the question here should probably look for something else. It sounds like they are in over their head and I don't see them optimizing multi-threaded networking applications with real time IO in valgrind any time soon (though it sounds like an interesting Friday afternoon for me).

Comment Re:C++ with Java for networking (Score 4, Informative) 296

JNI is the absolute most awful native interface system I have ever seen. If you absolutely must go the JNI route may I recommend using SWIG to generate things for you. It will require some additional wrapping but at least it won't make you want to end your own life.

As for performance penalties you'll have the additional overhead of a JVM as well. The whole setup you are proposing I'm guessing you've implemented before and are comfortable with but to me it sounds messy and unnecessary - especially with so many good networking libraries available for C++.

Comment ASIO (Score 2) 296

ASIO is in fact part of Boost now and I personally like it. The thing you need to remember though is that ASIO is not an HTTP client or really any type of client at all - if you want to do HTTP you'll need to write the HTTP headers and handle chunking yourself. That's actually not so hard though. For cross platform SSL you just need to use Open SSL which is actually pretty simple in C++.

Basically if you want really fine control of your network streams or are using things other than just HTTP then ASIO is going to be what you want. If you just want to have something handle HTTP for you then there's quite a few other libraries out there you can choose from.

Comment Why not convertables? (Score 1) 435

I'd say not only would windows be nice but the option to take down the roof as well.

Of course I enjoy driving far too much to ever give that up to an automated vehicle. I've been keeping a spider (MR-S) for a while because I really enjoy driving with the roof down. And even though the MR-S is used and beat up and mostly stock I keep it despite the fact my primary vehicle is a tuned GT86 just because it's a blast to drive an MR with the roof down.

If you ask me all these people who are pushing for automated cars should drive an 86/BRZ or an S660 or a Lotus or some other drivers car and see if they reconsider wanting to get rid of the "hassle" of driving. Don't get me wrong; certain automation can be good (EG: Subaru EyeSight) but at the end of the day the actual act of driving should be something enjoyable.

"Old age and treachery will beat youth and skill every time." -- a coffee cup

Working...