> On Thu, 6 Jan 2000, David Schwartz wrote:
>
> > Design obsolesence into the hardware and then blame it on
> the software.
> > Wonderful. IMO, anything we can do to make this technique work
> better is
> > ultimately self-destructive. If you design in just the hardware that the
> > software needs today, your embedded system should break.
>
> Well, money talks and ... you know the rest.
That's hardly the problem of the kernel and library developers, though.
> The writing of efficient program and the writing of clean programs are not
> mutually exclusive. Of course, your attitude is what allows me and others
> to get nicer margins - a lot of people design unecessarily expensive
> hardware.
No, they're not mutually exclusive. But what happens when a programmer is
faced with inadequate hardware is that the cleanliness of the code goes
down.
Ask yourself this question -- why don't we write in assembly language
anymore? It's not just because of having better tools (compilers and
optimizers). It's also because the potential performance benefit assembly
code might give us is not worth the difficulty of maintaining assembly code.
Code written in the 70's was heavily optimized because it _had_ to be or it
wouldn't ever finish. The trend in programming has been away from 'last bit'
optimizing and toward efficient algorithms and clean, maintainable code.
> If you manefacture anything in larger scale the manefacturing price is
> everything. Most devices are not really changed or at least their taks it
> not changed. I have no interest in having my elevator control being able
> to play mp3:s, I just want it to move me between floors safely.
Do you really think that this is all you'll want out of an elevator in
2038? Your crystal ball must be clearer than mine.
> Anyway, I am convinced there will still be a lot of older architectures in
> use by 2038.
I don't think so. I think by then (or at least shortly after then), almost
all computers, embedded or not, from microwave ovens to supercomputers, will
be heavily interconnected. With luck, some portable language (like Java, but
improved in 38 years) will allow code to be much more mobile between them.
Obviously, you can't design for this now, it's not here yet.
The point is, you can't anticipate what people will want in 38 years. So
you can do one of two things -- design in room for whatever they might want,
or design for obsolesence.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:07 EST