Get off my lawn?

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Alan Mackenzie
Hello Rich, and everybody else, Happy New Year!

On Thu, Jan 22, 2015 at 01:16:53PM -0500, Rich Freeman wrote:
> On Thu, Jan 22, 2015 at 1:06 PM, Tom H <[hidden email]> wrote:

> > Samsung's starting to release Tizen-driven phones, TVs, white goods,
> > etc. Tizen uses systemd and, given the size of Samsung, the number of
> > systemd embedded devices is going to skyrocket in the next few years.
> > Samsung wouldn't have chosen systemd for Tizen if it were too resource
> > hungry for its use case.


> Embedded is a pretty broad term, and it impacts all aspects of a
> device's design.  You can't really put a smartphone and a microwave in
> the same category.

> Phones actually have plenty of storage, RAM, and CPU by most embedded
> standards.  The main issue is battery use, which is mostly about
> ensuring that your software isn't constantly waking up the CPU.  If
> systemd is well-behaved in this regard I'd expect it to work on a
> phone just fine.

> The thing is that most devices that couldn't run systemd would
> probably be hard-pressed to run any kind of generic linux distro in
> any case.  They might not even run linux, or if they did it might be a
> super-stripped-down build with an embedded initramfs containing
> nothing but a single executable built in C which runs as PID 1 (no
> need for even filesystem support, let alone stuff like /proc and so
> on).

> I'm genuinely curious as to how systemd and competing solutions are
> adopted in the embedded world, including phones but especially getting
> beyond this (huge) niche.

Just as a data point, the last project I worked on was an automotive
system, whose controller was a 32-bit Power PC with 768k/64k code/data
flash, and 64k RAM.  It did not run systemd!  Rather than Linux, it ran
Autosar (a special, and somewhat wierd, OS specially for automotive
products).  The sensors in the system were even more constrained, using a
special low-power processor with 16k flash and 1.5k RAM.  They didn't run
Linux either!  In fact, they didn't have an OS - they were coded
directly to the metal, in a single-tasked loop.

My impression is that the embedded world is split roughly equally between
large systems (like smart phones or infotainment systems where RAM is
measured in gigabytes, and full scale OSs are used) and small systems
(such as my automotive system, microwave ovens, TV zappers, elevator
controllers, .... where special OSs, if any, are used, and RAM is
measured in kilobytes).

> I'm also curious as to where ChromeOS ends up going.  It is based on
> Gentoo, but runs Upstart (which isn't used by just about anybody else
> now, and which isn't even in Gentoo's portage).

> --
> Rich

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Thu, Jan 22, 2015 at 3:42 PM, Alan Mackenzie <[hidden email]> wrote:
> Just as a data point, the last project I worked on was an automotive
> system, whose controller was a 32-bit Power PC with 768k/64k code/data
> flash, and 64k RAM.  It did not run systemd!  Rather than Linux, it ran
> Autosar (a special, and somewhat wierd, OS specially for automotive
> products).

I wonder how small linux can actually get in such a world, assuming
you still needed the multitasking, drivers, etc (which would be the
main benefits of running an OS vs just embedding a single program
written in C that directly talks to the hardware).  You can trim a lot
of stuff out of linux that we all take for granted, but I'm not sure
if you can really get it into the 100kb range.

I couldn't really find hard numbers anywhere for the actual minimum
RAM requirements for a linux that contains the minimum features needed
to provide a bit of hardware support and run init with almost nothing
else exposed but the system call interface (no need for /proc, devfs,
/sys, and so on).  It sounds like you're still talking hundreds of
kilobytes to 1-2MB of RAM use in most cases.

So, dedicated embedded kernels are likely to stay around for a while to come.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Walter Dnes
On Thu, Jan 22, 2015 at 04:28:26PM -0500, Rich Freeman wrote
>
> I wonder how small linux can actually get in such a world, assuming
> you still needed the multitasking, drivers, etc (which would be the
> main benefits of running an OS vs just embedding a single program
> written in C that directly talks to the hardware).  You can trim a lot
> of stuff out of linux that we all take for granted, but I'm not sure
> if you can really get it into the 100kb range.

  *BSD would be a better candidate, in terms of a smaller kernel to
start with.  And I'm sure that legal would be a lot happier about not
having to supply source code.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Marc Stuermer
In reply to this post by Tom H-4
Am 22.01.2015 um 19:06 schrieb Tom H:

> Sure. My point was that anyone can claim that systemd is (un)popular
> in the embedded space.

I don't know if it is popular; in embedded systems though the last thing
you need are fast moving targets IMHO, you want to use proven, reliable
tools.

If systemd is reliable or not, this depends on your decision, but it is
a fast moving target.

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer <[hidden email]> wrote:

> Am 22.01.2015 um 19:06 schrieb Tom H:
>
>> Sure. My point was that anyone can claim that systemd is (un)popular
>> in the embedded space.
>
>
> I don't know if it is popular; in embedded systems though the last thing you
> need are fast moving targets IMHO, you want to use proven, reliable tools.
>
> If systemd is reliable or not, this depends on your decision, but it is a
> fast moving target.
>

Do you regularly update the software on your embedded system?
systemd-183 hasn't changed a bit since the day it was released.

The fast-moving target bit is only an issue if you want to keep
updating it.  That said, systemd doesn't change THAT much between
versions as far as the key interfaces go.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Alan Mackenzie
Hello, Rich.

On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote:
> On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer <[hidden email]> wrote:
> > Am 22.01.2015 um 19:06 schrieb Tom H:

> >> Sure. My point was that anyone can claim that systemd is (un)popular
> >> in the embedded space.


> > I don't know if it is popular; in embedded systems though the last thing you
> > need are fast moving targets IMHO, you want to use proven, reliable tools.

> > If systemd is reliable or not, this depends on your decision, but it is a
> > fast moving target.


> Do you regularly update the software on your embedded system?
> systemd-183 hasn't changed a bit since the day it was released.

systemd-183's velocity is unchanged from the day it was released, and it
isn't slow.

> The fast-moving target bit is only an issue if you want to keep
> updating it.

Quite the contrary - the fast-moving bit is an issue if you _can't_
update it, or if updating is expensive, which is frequently the case for
embedded systems.  Fast-moving software is likelier to be buggy than well
established traditional software.

> That said, systemd doesn't change THAT much between versions as far as
> the key interfaces go.

But busybox changes even less.

> --
> Rich

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie <[hidden email]> wrote:
>
> On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote:
>
>> Do you regularly update the software on your embedded system?
>> systemd-183 hasn't changed a bit since the day it was released.
>
> systemd-183's velocity is unchanged from the day it was released, and it
> isn't slow.

You'll have to define what you mean by velocity here, not that it
really matters since we can quibble over definitions all day long.
systemd-183 today is identical to systemd-183 the day it was released.
It is a snapshot in time.

>
>> The fast-moving target bit is only an issue if you want to keep
>> updating it.
>
> Quite the contrary - the fast-moving bit is an issue if you _can't_
> update it, or if updating is expensive, which is frequently the case for
> embedded systems.  Fast-moving software is likelier to be buggy than well
> established traditional software.

You do test your embedded devices before you release them, right?

>
>> That said, systemd doesn't change THAT much between versions as far as
>> the key interfaces go.
>
> But busybox changes even less.
>

It is also used far less.  Do you really think that you're less likely
to have problems with busybox mdev and busybox init than with whatever
version of backported version of systemd RHEL is using six months
after release?

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Alan Mackenzie
Hi, Rich.

On Sat, Jan 24, 2015 at 12:58:48PM -0500, Rich Freeman wrote:
> On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie <[hidden email]> wrote:

> > On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote:

> >> Do you regularly update the software on your embedded system?
> >> systemd-183 hasn't changed a bit since the day it was released.

> > systemd-183's velocity is unchanged from the day it was released, and
> > it isn't slow.

> You'll have to define what you mean by velocity here, not that it
> really matters since we can quibble over definitions all day long.
> systemd-183 today is identical to systemd-183 the day it was released.
> It is a snapshot in time.

When you take a photograph (a snapshot) of a fast moving thing, the photo
may give the false appearance of the thing being stationary, whereas it
is in reality a fast moving object.  That is my feeling about systemd.
But I agree, the point is not worth quibbling over.

> >> The fast-moving target bit is only an issue if you want to keep
> >> updating it.

> > Quite the contrary - the fast-moving bit is an issue if you _can't_
> > update it, or if updating is expensive, which is frequently the case
> > for embedded systems.  Fast-moving software is likelier to be buggy
> > than well established traditional software.

> You do test your embedded devices before you release them, right?

Absolutely.  They are tested most searchingly, both by us and by the
customer.  However software not written by us is assumed to be fully
tested by its suppliers, hence is only tested by us at the "System
Integration" level.  Generally, that's a safe assumption when speaking
about proprietary embedded OSs.

Clearly, SW which incorporates GPL bits must itself be GPL, and I have no
experience of working on any such embedded SW.  

> >> That said, systemd doesn't change THAT much between versions as far as
> >> the key interfaces go.

> > But busybox changes even less.

> It is also used far less.

Are you sure?  I had the impression that busybox was very widely used on
embedded devices, such as routers, which are made in very large numbers.

> Do you really think that you're less likely to have problems with
> busybox mdev and busybox init than with whatever version of backported
> version of systemd RHEL is using six months after release?

Yes, I do, certainly on an embedded system.  Even on a desktop, mdev
works well.  I've used it.  The only reason I gave up on it was because a
package I use (I can't remember which one any more) suddenly acquired a
hard dependency on udev.  :-(

> --
> Rich

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Tom H-4
In reply to this post by Marc Stuermer
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer <[hidden email]> wrote:

> Am 22.01.2015 um 19:06 schrieb Tom H:
>>
>> Sure. My point was that anyone can claim that systemd is (un)popular
>> in the embedded space.
>
> I don't know if it is popular; in embedded systems though the last thing you
> need are fast moving targets IMHO, you want to use proven, reliable tools.
>
> If systemd is reliable or not, this depends on your decision, but it is a
> fast moving target.

It's not necessarily a fast moving target. RHEL 7 uses an
upstream-maintained "208 stable" (and AFAIR Debian 8 will also use
it).

For embedded systems that never used sysvinit, systemd is unlikely
ever to be an option but for others anyone can claim either that
systemd is the best choice possible or that it's the worst choice
possible without any proof either way.

123