Devuan Jessie beta released

Posted May 1, 2016 20:39 UTC (Sun) by bronson (guest, #4806)
In reply to: Devuan Jessie beta released by jaromil
Parent article: Devuan Jessie beta released

This is a disappointing response. Back in the oughts I spent some time working on embedded Linux set-top boxes. The number of workarounds we had to stick in our init scripts just to get a sub-1-minute boot time was out of hand. I can only imagine how much easier it would have been with systemd.

So, I was looking forward to hearing nonobvious ways that systemd makes embedded harder. Except in extremely memory-constrained environments (which tend to use hand rolled rc scripts anyway), it seems like a clear win to me.

I hope you'll explain your evidence at some point. I'm still curious.

to post comments

Devuan Jessie beta released

Posted May 1, 2016 21:31 UTC (Sun) by pizza (subscriber, #46) [Link]

> So, I was looking forward to hearing nonobvious ways that systemd makes embedded harder. Except in extremely memory-constrained environments (which tend to use hand rolled rc scripts anyway), it seems like a clear win to me.

I too was interested in this, as my experience was remarkably similar to yours.

Incidentally, classic rc scripts turned out to be pretty bad memory-wise too; we had to do a lot of custom coding to ensure we didn't spawn too many things at once. We actually integrated some extra stuff into busybox to save memory (and yes, delivered the complete corresponding source code as per the GPL). As it turned out this also greatly sped up boot times by eliminating much shell script parsing and many forks that were now all handled internally to busybox's shell. The price was a slightly higher baseline idle memory usage, well worth the effort.

We also had to play (not always successful) games to capture console logging, had to write our own service status/monitoring/respawning tools, had endless fun trying to ensure clean shutdowns so we could perform firmware upgrades, and yes, even had to modify a few daemons so that they would properly detach from the console or otherwise behave better. Oh, and handle dynamic events, restarting/reinitializing whatever services were affected (of course, respecting all dependencies) depending on which operational mode we were in.

Systemd wouldn't have necessarily solved all of these issues for us -- we'd still have had to dynamically generate a set of unit files based on the system configuration (aka our own "business logic") but we wouldn't have had to [re-]invent and maintain so much low-level infrastructure.

Then again, the fact that this stuff was so complicated is what kept us in business... so maybe it's a good thing that systemd didn't come along until well after the company shut down.