Slashdot Mirror

This whole affair of what platforms to use puzzles me greatly. I am of the opinion that the selection process has everything to do with politics and little to do with substance.

I feel a lot of it has to do with a corporate mentality of holding everything blameless with contracts which have to be signed off on before the business will do anything. "Hold Harmless" seems the byword of the day.

I have tried to use Micrium's uC/OS products, based mostly on their certifications for mission critical affairs such as aircraft and life support . For me, this thing is like a "Super Arduino" for embedded applications.

Business will pay for people to play down everything the "leadership" type does not understand, and personal experience tells me that if I do not recommend Microsoft, I will not get the job. Regardless of my belief and experiences to the contrary. Its been my observation that once one gets high enough in corporate hierarchy, one is forced to play CYA, and the only way to play is find someone else to pin the blame on if things go sour - better yet be able to blame someone big - so the guy who hired them does not take the fall for it.

There seems to be a trivial amount of effort expended to mitigate the probability of a breach in the first place.

I am not trying to shill for Micrium - I just like their product and their philosophies of supporting an OS. It is all quite well documented ( link to the book I use all the time ).

NetBurners run this code. This had been the most robust system I have ever studied, yet I find few people who are willing to let me implement it - and for now it runs on a machine I have for my own edification.

My own feeling if anyone wants to hack a bank ATM, go for it. No one's responsible, its just another ledger entry to the bank. If the thing gets too out of hand, the government will make it up to them.

This whole affair of what platforms to use puzzles me greatly. I am of the opinion that the selection process has everything to do with politics and little to do with substance.

I feel a lot of it has to do with a corporate mentality of holding everything blameless with contracts which have to be signed off on before the business will do anything. "Hold Harmless" seems the byword of the day.

I have tried to use Micrium's uC/OS products, based mostly on their certifications for mission critical affairs such as aircraft and life support . For me, this thing is like a "Super Arduino" for embedded applications.

Business will pay for people to play down everything the "leadership" type does not understand, and personal experience tells me that if I do not recommend Microsoft, I will not get the job. Regardless of my belief and experiences to the contrary. Its been my observation that once one gets high enough in corporate hierarchy, one is forced to play CYA, and the only way to play is find someone else to pin the blame on if things go sour - better yet be able to blame someone big - so the guy who hired them does not take the fall for it.

There seems to be a trivial amount of effort expended to mitigate the probability of a breach in the first place.

I am not trying to shill for Micrium - I just like their product and their philosophies of supporting an OS. It is all quite well documented ( link to the book I use all the time ).

NetBurners run this code. This had been the most robust system I have ever studied, yet I find few people who are willing to let me implement it - and for now it runs on a machine I have for my own edification.

My own feeling if anyone wants to hack a bank ATM, go for it. No one's responsible, its just another ledger entry to the bank. If the thing gets too out of hand, the government will make it up to them.

(substitute the greek letter for the word micro)

You may want to google "microC/OS". It is a simple library that you can add to your program. MicroC/OS-II was free for use if you purchase the book "microC/OS The Real-Time Kernel". I think it has since gone commercial at Micrium.

NASA uses Micrium's OS ( U/COS ) on the Mars curiosity rover.

( NetBurners use the same OS )

Here's the book on it... same one I use.

Note how compact an OS can be if all the "consumer fluff" is not included and the OS simply concentrates on the task to do and what resources it has to allocate.

I wonder how a RTOS like Micrium's uCOS holds up to this.

We sure try to control this awkwardly...

Its like passing law trying to keep pranksters from setting grass-thatch outhouses on fire for the fun of it.

Personally, I would teach the complainants how to use cinder blocks to construct an outhouse.

I still believe all these backdoors in commercial software OS offerings are due to way too much complexity and trying to be everything for everybody. I firmly believe a small compact well-understood kernel, such as uCOS/2 could be the core of a GUI front-end for a secure system.

If a limited number of known file formats for multimedia and data exchange are supported, data-only - no embedded executables - then vectors for viral infection are nipped in the bud.

The whole OS should be in ROM, so that once installed, it can't be changed. Flash with write disabled by physical jumper would be great for this. One could physically place the jumper or close a physical switch to allow upgrade of the OS. Yes, it would involve user responsibility. And require standardized interface protocols - which means a lot of IP law has to be changed to hold interface protocols free from legal hostage.

All this "remote administration" stuff gives me the willies, especially when people who can barely figure out how to turn the power onto the machine can pass control of that machine to anyone in the "cloud".

I beg to differ... http://www.micrium.com/page/products/rtos/os-iii http://www.freertos.org/ And, while not real time: http://www.contiki-os.org/p/about-contiki.html

It occasionally decides that one of the other machines has dropped off the LAN even though all other machines can see it and connect to it. When that happens, the only recourse is a reboot.

I found a bug like that once in eCos. Sometimes the embedded system would see other machines on the net, sometimes not. Turned out it was a bug where they had some union for sockaddr* structures in the driver and the space they were allocating for the structure wasn't the max size of all the union's parts, so the ARP table got corrupted. No ARP table entry for a machine, no way to talk to that machine. Apparently, it wasn't a problem if you used DHCP, but since our Linux Priesthood declared that /etc/hosts must be used ("a DHCP server would just be another thing that can break"), so nobody else ever caught it. (It was fun writing an /etc/hosts equivalent function, since eCos doesn't assume a filesystem, but I digress.)

You could fire up wireshark and see if your iCandy machine is sending out ARP packets asking for the machine it claims has disappeared. That's what nailed it down for me.

Of course, since eCos was open source, I had it fixed with the help of some forum posters inside of a week. No problems since. Wonder how that would work out with closed-source stuff, like VxWorks or uC/OS-II. Oh, yeah, they'll charge me $50k or so to get the source so I can fix it myself, or they'll make me send a complete set of test hardware and source code to them for them to look at, and they'll find it in a couple months, and the bug fix will be in the next version six months to a year after that. Can't say I miss those days.