Dave Nebinger <dnebinger <at> joat.com> writes: > > > Thanks for the scripts and help! > > That's what we're here for > > > When I roll out a new TCP/IP based data-logger > > (hopefully this fall) it'll take sensor inputs and control a few outputs. > > No humans will use the devices for anything other than interfacing > > sensors and collecting data. > > As with most other embedded devices, wouldn't these remain fairly static at > the OS level? I mean, would you really want to try to debug why (all of a > sudden) the remote devices stopped functioning because of an errant package > emerge?
Well, yes and no. Yes you do not update remote device as often, but, they do need RTOS/executive/kernel/state-machine updates over time. It's a huge problem for devices with a microprocessor/microcontroller. We often design device to store 2 or more bootstrap programs. That way a remote device can get new bootstrap firmware, and if it fails use the old boot code. DISTRIBUTION aka over ppp or TCP/IP is very much needed. Most embedded companies, particulary in the 8-16 bit micro space, do a pathetic job at longevity maintenance planning on their embedded devices. Suppose your remote 8/16 bit micro supports a fat file system on an 8 bit dsp. It's a nightmare support all of the different vendors flash based cards, so the driver(s) usually use a few select vendors. But the company with those devices, cuts a deal with a new 'hong-kong' vendor. Naturally, their flash card does not work. The driver code, part of the RTOS/executive/kernel/StateMachine has to be updated. Also, newer versions of processors end up in products, so you get your maintenace code now spread over several versions of a processor, much like the AMD-Intel-Via.....saga. There is a need for a robust binary and remote compilation solution for remotely located embedded devices. Flexibility to mix and match is the key. The applications that run on the RTOS/kernel/executive/StateMachine need more freequent updates than the raw OS engine code, but, both need to be maintained. This would also lead to less disposal of microelectronic devices, world wide. The garbage dumps of the world, need a little reprieve, in my opinion, too. > As for learning gentoo at a deeper level, we encourage that. I would > suggest, only because it really made things clear for me, that you look at > Linux from Scratch http://www.linuxfromscratch.org. It will make the entire > process for how to custom build a linux box a lot clearer. Yes this is on my 'todo' list. I consult and work 40-80 hours per week. Soon I'll have a couple of months off..... > > > The experience I gain form helping kids/adults use Gentoo, will help me > > manage thousands of dataloggers across public and private networks. > > Besides if I screw it up, no big deal. They can always use a winblows > > box until I get it fixed. Strict user control semantics will be > > used to limit what they can screw up. > > From an administrative point of view, however, I think you'd be better > served by having one system working, freeze it and then clone it to the > other systems. Skip updates as much as possible. Sure but updates for microprocessors are the simili for eduction. Do you think we should minimize educcation? minimize education for adults? Methinks your indescretions and prejudices against micros, is insensitive to the future, sensate possibilitys of micros and the things they inhabit. micros are entering the human body at an alarming rate. Don't you thing we need mechanisms to keep their interal code robust and current? Nanobots are real and the very near future of medicine. > Basically you'd be taking the same route as other embedded linux products. > My linksys routers, all linux based, have the ability to handle new firmware > (linux distribution) but they do not auto-update themselves. I'm thinking much bigger than router code. My wife if in the middle of a phD in Biomedical. Her area of expertise is firmware. There is a HUGE need to further the paradyme. > > I'm also using jffnms to update and manage all sorts of routers and > > industrial contols embedded devices. After some > > time, I'm sure I'll roll my own solution, but for now, managing Gentoo > > user systems and customizing JFFNMS for router and other snmp devices > > is enough of to keep me busy. > Exactly my point - why introduce even more administrative headaches to have > thousands of gentoo systems automatically emerging packages on their own? Well let me remind you of a lawyer story (you know lawyers make much more money than engineers and computer scientists?) There was a small town with with one lawyer. He was financially starving. Another lawyer move to town, business boomed, and both retired wealthy. Quit canabalizing computer science and electrical engineer so that we die of starvation. The more complex the systems, the more money we can all make..... Beside complex feature-rich systems are wonderful and employ lots of people. Just look at the space-shuttle.... (HUGH GRIN) James -- gentoo-user@gentoo.org mailing list
