How To Use Systemd For Application Sandboxing & How To Easily Crash Systemd

[starshipeleven]

sigh, still unapproved post above

[F.Ultra]

If you don't want to visit the OpenWRT wiki, here's a list I collected that shows the specs for each device supported by the latest OpenWRT along with averages and maximums for Flash and RAM. https://postimg.org/image/pgg1ac6mx/

But what are you really arguing about? That systemd is not the ideal piece of software for all different devices and systems out there? That is a "no shit Sherlock!" moment right there. Most of these devices does not run sysv init either.

[caligula]

But what are you really arguing about? That systemd is not the ideal piece of software for all different devices and systems out there? That is a "no shit Sherlock!" moment right there. Most of these devices does not run sysv init either.

My point was to explain that systemd is too bloated for most officially supported OpenWRT routers. I can safely say that probably only two of the officially supported devices have the resources to run systemd unless you boot using an USB drive as root. OpenWRT compatible routers are a significant class of embedded hardware. Android tablets and phones could also run systemd, but they currently won't support it. There's not that much useful embedded hardware that could run systemd for the public audience. So, for us users it doesn't seem like a viable option at the moment.

[caligula]

Here, table of hardware for you, filtering routers with 128MB https://wiki.openwrt.org/toh/views/t...+MB*%7E%5D=128
There is a buttload with 128MiB, like 70 units if I filter out the NAS and other stuff.
Sure most aren't supported yet or fully (usually there is no ac), but that's normal for ac routers. Only atheros ones have decent support.

Exactly. Why would you spend money on devices that aren't supported? Sometimes you can hack it yourself and make it usable. For example even if your ARM Linux distro doesn't run on Banana Pi, you can still make it run quite easily with a custom kernel. Here, not support means that you'll buy a wifi AP which doesn't work as a wifi AP. If 802.11n is good enough for you, well ok. That's nice. The rest of us need 802.11ac devices and they don't come with systemd enabled stock firmware nor is systemd an option if you install your own firmware unless you build from scratch and plug in some external storage. Of course this is considered too hackish and won't be supported officially.

We weren't talking about full hardware support from LEDE but just about availability of new hardware with decent storage, so I'm not going to give a shit if many are partially supported or WIP or whatever.

Fine, if the vendors start using systemd on stock firmwares, there might be some hope, but currently the usable hardware with official support and free drivers doesn't really encourage systemd adoption.

[starshipeleven]

Exactly. Why would you spend money on devices that aren't supported?

How is that relevant to the point?
I only said that most modern hardware has larger flash storage, so having systemd run on that isn't an issue because of storage.

How does the fact that most wifi ac routers (not using atheros SoCs) aren't supported because there are no drivers becomes an argument in favor or against systemd? That's 100% unrelated.

The rest of us need 802.11ac devices and they don't come with systemd enabled stock firmware nor is systemd an option if you install your own firmware unless you build from scratch and plug in some external storage. Of course this is considered too hackish and won't be supported officially.

Can you please stop shifting the goalposts here? My point was about storage being sufficient for having also systemd in there, and that happens to be true.

If drivers are there or not to run the wifi ac without blobs is unrelated.

Fine, if the vendors start using systemd on stock firmwares, there might be some hope, but currently the usable hardware with official support and free drivers doesn't really encourage systemd adoption.

And the point of stating this is?

I already said OpenWRT/LEDE is using Procd which is a bit similar to systemd, has a tiny footprint but lacks most advanced features, Procd works also in 4-8 MiB flash routers that are the bread and butter of their fleet of supported devices, so they don't really need systemd for a long while.

Here the one that wants hard to have systemd EVERYWHERE (even in microcontrollers or other stuff where it makes 0 sense as there is only ONE bare metal firmware) is you, not me. Why dat bro?

[ssokolow]

No, it just expect that other glibc implementations have the same glibc extensions that they use. ulibc-ng is working on that so it will probably replace Musl everywhere in the embedded world, since the Musl lead developer is a foaming-at-the-mouth systemd-hater and probably will refuse patches that support systemd, even if they become Posix standard.

Last I heard, Rich Felker (musl guy) hates SystemD because he considers almost all code except for Musl and SQLite3 (SQLite3 is used in avionics) to be unacceptably bad. He singles out SystemD because he believes PID 1 and libc must be held to a higher standard than other userland code, but writing Musl to solve the problem for libc is already eating up all of his time, so he can't also fix PID 1.

As far as I know, he still plans to implement all of the remaining missing extensions in Musl to broaden the range of situations where it can replace glibc's horrible flawed-ness.

[interested]

He singles out SystemD because he believes PID 1 and libc must be held to a higher standard than other userland code, but writing Musl to solve the problem for libc is already eating up all of his time, so he can't also fix PID 1.

systemd, especially systemd(pid1) is being made to a much higher standard than normal userland code, and by looking at the severity of the CVE's, systemd is actually doing a better job than Musl. And this despite systemd is used everywhere among all major distros and is heavily code audited, while Musl is decidedly a fringe option used by few outside the embedded world.

And it speaks volume of the lack of professionalism in the Musl project that severe vulnerabilities aren't reported to Mitre org, but only local bug-trackers like CVE-2015-1817, so you can bet that a lot of embedded projects using Musl are running unsafe at the moment, just because the embedded developers are unaware of this severe stack overflow.

As far as I know, he still plans to implement all of the remaining missing extensions in Musl to broaden the range of situations where it can replace glibc's horrible flawed-ness.

No, that link has nothing to do with the glibc extensions that systemd uses. These may or may not be a part of an upcoming ISO/Posix standard, but are informal at the moment. I really don't think the Musl author is inclined to include those.

That the author of a competing project like Musl trash talk the competition (glibc) doesn't make glibc bad, It only shows his bias. Musl is never going to replace glibc as the standard Linux libc library. It has a niche market in embedded, and it is probably going to be replaced there too by eg. ulibc-ng since that libc implementation is working on being systemd compatible.

[pal666]

I had the impression that systemd is supposed to be used everywhere. From Raspberry Pi style hardware to computer centers. They don't clearly state that they don't want to support low end hardware.

they fully support rpi, you made some idiotic conclusion

The only fact you can infer is that they like glibc and glibc/gnu extensions which make systemd compatible with minimal/standard compliant C libraries like musl. So apparently instead they hate POSIX and low end hardware.

we already established that they like rpi-kind low end hardware. and if by 'hate posix' you mean 'support stuff not mentioned in posix' then everyone hates posix. you could start with throwing away your kernel, lol

About the hardware.. there are plenty of router boxes which come with 4-16 MB of flash and even support 802.11ac.

and redhat conspiracy forces you to run systemd on them via gnome dependencies? why stop at 4mb, there is hardware with kilobytes of storage, so every other init together kernel itself hate you

OpenWRT is actually moving to musl and systemd isn't compatible with musl since they expect some GCC/GNU extensions and not POSIX libc. Either 1) OpenWRT becomes irrelevant as hardware keeps improving 2) OpenWRT moves to a stripped down version of systemd with minimal services and switches back to glibc 3) 2 + OpenWRT patches musl with GNU extensions to make it work with systemd 4) 2 + systemd / musl folks fix their stuff 5) OpenWRT adopts two libc libraries, one for systemd and the other for all other software.

adopting two libcs is counter-productive. if they want musl, they have to fix it. or they could use some other init. you can't demand stopping progress with arguments like "because openwrt"

The most popular hacker friendly IoT devices are Arduino and ESP8266 chips which won't even run Linux.

they are soldering iron friendly and the reason they won't run linux has nothing to do with linux storage requirements. difference in price between "amount of storage enough for running linux with systemd" and "less of storage" is zero

I have my doubts that Linux will ever get there

why are you concerned with linux basesystem then?

[pal666]

please see ad hominem fallacy....

lol, it is first fallacy of systemd haters

[pal666]

Last I heard, Rich Felker (musl guy) hates SystemD because he

is lunatic. and you used capital d just to show that you have no idea what are you talking about