3 Jun
2013
3 Jun
'13
7:22 a.m.
On Jun 3, 2013, at 8:53 AM, Liam Proven <lproven at gmail.com> wrote:
For embedded stuff? Quite possibly. Especially once you consider
what commercial entities will fork over for a turnkey solution
with support. MontaVista Linux seemed to be pretty successful,
even if it was pretty much garbage. Is it still around?
In a lot of cases, it is. It's meant to be an embedded OS. In
my experience with our clients, I've learned to see a focus on
embedded Linux as a warning flag. There are some cases where
it's entirely warranted, but a lot of the things people do with
it amount to killing flies with orbital bombardment, and they
end up spending more development time maintaining a distribution
image than they would writing a simple event loop on a tiny ARM
in C or assembly to do what they're trying to do.
So there's that aspect of the discussion. I suffer from cohort
bias, because usually there's a reason we're contracted to do
work for our clients, and it's not because they don't have
*enough* employees. :-)
- Dave
On 2 June 2013 17:21, Tothwolf <tothwolf at
concentric.net> wrote:
That's not always a safe assumption. And quit calling me Shirley!
More seriously, though... the Internet is not the only threat
vector, and software vulnerabilities can often be contributors
to long-term reliability problems (since they're still generally
bugs that can be exploited by accident as much as on purpose).
Moreover, there are lots of genuinely useful things (like mDNS)
which have common implementations (Avahi, in this case, though
there are more limited, smaller ones like Apple's reference
code) which require things from more modern kernels. It's
enough to make smarter companies (i.e. not the ones who just
throw more hardware at the problem) move to proper embedded OSes
like VxWorks or RTEMS.
In my attic full of pipe dreams, I have ideas for a small OS for
running older machines with modern desktop concepts (mDNS, modern
language support, etc.) at a reasonable speed. It'll probably
never happen, though, because the demand is so low compared to
the breadth of hardware it would have to run on to be worthwhile.
The Linux kernel is still only as big as you compile it. It can still be
built pretty small. The issue of dropping i386 is a different matter -- some
developers were "inconvenienced" by some of the old code, and rather than
redesign it so that they could handle some newer stuff while still
supporting the i386, they simply removed that code entirely.
I'm sure you're right, but nonetheless, I think my reasoning still
stands. There are far better choices for embedded CPUs than an 80386
these days.
For an old device, use an old Linux. Most of 'em won't be
Internet-connected & so security fixes should not be an issue, surely? There is no
reason why a modular Linux distribution such as Debian can't
support both cases, and handle both very well.
Sure, but is it worth the additional developer effort for an edge case? Not even
decades old, some as little as 5 years old (or less) can't handle
more than 256MB or 512MB of ram. Embedded boards generally aren't marketed
for applications that require multi-GB of memory. Many of these (fanless)
boards are designed to remain in service for decades.
And why shouldn't their software remain in service for decades, as well?
It's not my field but I would have thought that something like QNX was
a better fit for that kind of thing, anyway.