> > Sadly, the modern software technology ( and i daresay the modern software > coders' mindset ) is responsible for the shoddy and error-ridden code i see > almost everywhere. > I can only partitally follow you. The problem is not the tool. The problem is the people using it!! The more sophisticated the tool the more ways to use it wrong. The more automatisation in the tool the more likely that some fools use it w/o knowing what they do. And in big projects with many people involved you will have a combination of both... But I know what you mean with mindset. eg. introducing a garbage collection... my mindest is that my code produces no garbage! ;-). Nevertheless high reliability is less a matter of the programming language than of the SW concept! And of OS. Anyway I get the feeling you are more concerned about crashes caused by the OS than caused by your program. Maybe the correct order to start would be 1) Choose OS (Startup time? Latency? GUI? long term support? supporting community?) 2) Define needed supporting functionallity (math, graph, I/O, protocols...) 3) Think about programming language available for 1), able to interface 2) I'm not sure if you have covered all points from 1), yet. If you talk about process control I would immediately opt for an RT OS. But since you want to replace an old hardware Debian is very, very likely fast enough w/o any RT patches -see toyooka_LCJ2014_v10.pdf <http://events.linuxfoundation.org/sites/events/files/slides/toyooka_LCJ2014_v10.pdf> . Nevertheless, you should think about RT OS: I would expect that RT OSs are not only built for low latency but also for highest reliability -but I'm no expert on that. Chilli
-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
