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