SysVinit 3.09 Now Allows Building With musl C Library, Passing Boot Messages To Firmware

[oiaohm]

systemd on musl when

This is the catch of being linked to embedded developers.

https://github.com/openembedded/openembedded-core/tree/master/meta/recipes-core/systemd/systemd

There are patches in openembedded that make systemd work with musl.

When you start looking at those patches you under stand the 2018 response at Systemd.

https://github.com/systemd/systemd/issues/10130

Particularly when you see

+#ifndef __GLIBC__

and worse

https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0005-add-missing-FTW_-macros-for-musl.patch#L27

Yes worse the FTW_CONTINUE is a GCC provided thing that missing.

Notice that the FTW_CONTINUE is not inside the #ifndef __GLIBC__ so lets say there glibc header that provides FTW_CONTINUE has been deleted this patch now masks the issue. Next we don't expect that FTW_CONTINUE define as 0 by glibc will change to some other value but if it does you have just planted a land mine.

Yes using #ifndef __GLIBC__ basically says all libc that are not glibc will be missing this feature... Do you have a crystal ball.

https://catfox.life/2022/04/16/the-musl-preprocessor-debate/

This here covers the problem with Musl. There is no #ifdef__MUSL__ you cannot find out the MUSL version by C macro or by a runtime function.

So this is more not when will systemd support Musl but when will Musl grow up and add the features that at build time we can detect that we are building for a Musl system and enable required quirks without disrupting anything else so allowing clean targeted work around patches for Musl to be added to systemd.

The Musl theory of not providing a __MUSL__ is that all bugs should be fixed in upstream __MUSL__ now this brings a good question why in heck if this is the rule is custom work around patches being added to systemd instead of fixing Musl itself. Yes if this rule is obeyed it should not be when will systemd support musl but when will Musl support systemd.

Musl is a very deep rabbit hole of problems caused by this simple choice not to provide ___MUSL__ macro.

[aviallon]

systemd is hardly perfect. For one thing, even though most of it's extended functionality is modular, even the core "init" system touches on far too many things compared to what an init system should. It's also quite heavy for an init system. Those in embedded spaces or with just lower end PCs might want something far simpler and lighter.

Actually, we migrated to systemd in my company's embedded systems, because it took less space in the end (we only used systemd-pid1 and systemd-logind), and it was also much more reliable to failures.

[Vistaus]

Yes, that list exists and is as follows (for Linux):

• systemd

So runit, S6 and Upstart don't exist? Sure, runit is from 2004, but it's still a good and maintained system and more modern than SysVinit. And S6 and Upstart are much newer and both are still maintained.

[Daktyl198]

Upstart is maintained now by... guess who... Google, because it's the init system for Chrome OS.

Red Hat used Upstart in Fedora 9-14 and RHEL 6. Upstart had numerous design flaws but Red Hat didn't want to fix them because Upstart had a CLA, so they made their own init *without* a CLA. No CLA is what let it gain involvement from other people early on - people seem to forget that 1) Ubuntu and Fedora (and RHEL 6) were the *only* major distros that used Upstart by default, and 2) openSUSE and Arch were the first major distros after Fedora to switch to systemd, both in 2012; just a year after Fedora did. No CLA is also a major reason why systemd won over Upstart for Debian in 2015.

TL;DR systemd won because it was quite literally just better.

Also, it's funny how people scream about Red Hat "controlling" systemd when, thanks to there being no CLA, they quite literally do not control it. Canonical, on the other hand, actually *did* control Upstart...

The CLA has zero implications for anybody downstream of the code itself in this case, and was not at all the reason distros refused to use Upstart. There was no way that Canonical was ever going to change the licensing so that other distros couldn't use the code freely. The CLA was purely to solve many issues that arise in open source development from contributors going MIA and having no way to contact them.

As for other distros adopting systemd, that was because many pieces of software (e.g. Gnome's login manager) started requiring functionality that only systemd had. Eventually, alternatives to that exclusive functionality came about, but by the time that happened many distros just got tired and adopted systemd anyway. I remember Debian specifically having months of debates about the downsides of switching to systemd but ended up doing it anyway, causing forks like antiX/MX Linux to spring up.

If you think Red Hat doesn't tightly control any and all software under it's umbrella, you're deluding yourself. Just because software doesn't have a CLA doesn't mean anything. Red Hat could implement functionality in systemd's core or a module tomorrow that's licensed under something other than it's current license, and then make Gnome or any of it's other projects hard depend on that functionality and none of the other contributors could say a single thing about it. Red Hat does whatever it wants with it's software and doesn't care about anybody else. They only care about Red Hat and Fedora, and everybody else just gets strung along because Gnome requires other RH software to function.

And yes, Canonical is the same way. They are both profit-driven companies who don't care about you. Yet for some reason the Linux community as a whole (you're a shining example) has decided to suck on RH's dongle and throw shit at Canonical. Just funny is all.

[oiaohm]

The CLA has zero implications for anybody downstream of the code itself in this case,

This is not always true because you have missed something.

The CLA was purely to solve many issues that arise in open source development from contributors going MIA and having no way to contact them.

This is ignoring the side effect where incorrectly written CLA you may not get the contributors or issue reporters because of the wording of the CLA..

Lets say you are a developer/system admin at some company you hit issue you locate the issue in the code you design a patch to fix the problem. Now you wish to report upstream. Something like GPL/LGPL can be some trouble to get past legal department. CLA can be worse to get past the legal department.

https://assets.ubuntu.com/v1/ea46173e-Canonical_Contributor_Agreement_ver_2.5.pdf

The old CLA 2.5 and before of Canonical yes one prior July 2011 has problem with most legal departments.

Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms.

So yes Canonical can release the code closed source with improvements that you can never access with this line.

Yes this is also stated in the FAQ.

https://ubuntu.com/legal/contributors/faq

One difference between the two is that the old agreement was a copyright assignment agreement (where the contributor granted ownership of the contribution to Canonical), while the new one is a copyright licence agreement (where the contributor grants permission for Canonical to distribute the contribution). One new element is a promise back to you to release your contribution under the licence in place when they made the contribution. The new agreement also features some refinements in the language around software patents and how you disclaim warranties.

Yes the old 2.5 Canonical Contributor Agreement and before you have zero chance to get past most companies legal department due to giving away ownership. Depend on companies legal depart something like the old Canonical CLAs can result in you not being able to open issues in the open source projects issue tracker due to the CLA. Yes downstream people wanting to report a bug can be blocked by their own companies legal department because of a CLA.

Next problem once bit twice shy problem. So a companies checks out Canonical CLA before July 2011 and blacklists their personal from interacting with Canonical it may take a decade or more of company to look at this policy and the new CLA and remove the blacklist.

Canonical CLA mess up is a very good warning to be very careful if you think about putting a CLA on a project.

The reality is in a lot of cases a CLA that gets past most legal departments end up only making small difference to if you just stuck to GPL and never had a CLA in the first place. Do note Canonical new CLA they still have to keep on releasing the code under the license the code was submitted to them under so new license does not end up fixing the MIA cases where you wish to re-license the code base.

Daktyl198 like or not the early CLA on upstart when systemd started is a legal problem child. Yes roughly a year after the release of systemd did Canonical fix their CLA. But remember the decade delay problem of lot of companies legal departments so upstart dies out of usage before it gets to the point of being past the damaging effects of unacceptable by big business CLA.

Yes the effect of Canonical original CLA screwed up multi Canonical projects not just upstart. Writing a CLA from scratch is a really dangerous thing todo.

[Daktyl198]

So yes Canonical can release the code closed source with improvements that you can never access with this line.

I never said they couldn't. I only stated that they would never deny access to Upstart as a whole to the general Linux public. They very well could have released a closed source "Enterprise" version, but CodeWeavers does that exact thing with Wine and nobody cares.

Daktyl198 like or not the early CLA on upstart when systemd started is a legal problem child. Yes roughly a year after the release of systemd did Canonical fix their CLA. But remember the decade delay problem of lot of companies legal departments so upstart dies out of usage before it gets to the point of being past the damaging effects of unacceptable by big business CLA.

Again, whether or not big companies want to officially support the development of a project with a CLA has nothing to do with the adoption of said project by community maintained free and open source distributions. Also, getting small patches into a project with a CLA is extremely easy to get by legal of your company. Hell, most companies would never require you to even pass through legal to submit code to a FOSS project with a CLA especially on your own time.

The only exceptions would be if (A) that company was making a direct competitor to Ubuntu or Upstart or (B) they had hard-patched Upstart for internal use and made significant changes to it's code, and needed to review any outgoing code to make sure it didn't contain any company secrets. Otherwise, company legal departments couldn't care less.

[oiaohm]

I never said they couldn't. I only stated that they would never deny access to Upstart as a whole to the general Linux public. They very well could have released a closed source "Enterprise" version, but CodeWeavers does that exact thing with Wine and nobody cares.

Pardon you need never make this claim about CodeWeavers again. Because CodeWeavers does not do the exact same thing.

https://www.codeweavers.com/crossover/source

Codeweavers has never made a closed source version of wine. Just because someone making enterprise version does not equal closed source. Most people don't go to the effort to build crossover from codeweavers from source but the sources have always been provided if you have wanted to. Of course if you don't have a codeweavers subscription and you are attempting to build that source codeweavers is not going to help you.

Wine project does not have a CLA. The wine project license LGPL is obeyed by Code-weavers even in their enterprise offerings.

Again, whether or not big companies want to officially support the development of a project with a CLA has nothing to do with the adoption of said project by community maintained free and open source distributions.

This is wrong was uptake of upstart before Canonical decided to CLA everything this include Redhat then stall in upstarts uptake until July 2011 when the CLA changed by community maintained and open source distributions.

IThe only exceptions would be if (A) that company was making a direct competitor to Ubuntu or Upstart or (B) they had hard-patched Upstart for internal use and made significant changes to it's code, and needed to review any outgoing code to make sure it didn't contain any company secrets. Otherwise, company legal departments couldn't care less.

That not the case. CLA is a contract you are signing. This why is so much different to a source code license. When you are employee and you are signing contracts for work that over laps with your day job they have to go past the legal department/boss they see you are signing away your work this does not fly. CLA reviewed by legal department is before they even bother looking at the code. This is why the before July 2011 Canonical CLA was such a problem.

Like it or not Canonical changed there CLA in july 2011 because it was causing problems with enterprise legal departments blocking people from interacting with Canonical. Not all legal departments were responding equal either. Some where they could still submit issues and no code, some where no issues or no code... All these issues equal less developers to make upstart development progress. Systemd did not have these issues because like wine they stuck to a simple here the open source license end of problem no contract required to be signed to submit anything so not triggering company legal department.

Yes having a CLA equals people at major companies who can have 20%+ of their work day for personal projects be unable to work on your project until the CLA passes the legal department and if it does not pass you miss out on these people.

Lot of community maintained distributions when you look closer the core personal are able todo work on the so called community maintained distribution as part of their day job at some major company this resulted in lot of these so called community distribution not touching upstart until after July 2011.

Daktyl198 you are underestimating how big of problem bad CLA is. Really looking into canonical CLA caused issues for the one prior to July 2011 gives really good example how 1 wrong term in your CLA can really adversely effect a project if you decide to go the CLA route. The reality here is systemd most likely would not exist if canonical had not put bad CLA on upstart instead Redhat developers would have worked on upstart. In fact redhat developers were working up upstart before the bad CLA.

The CLA Canonical uses today is not as much of a nightmare as the old one it passes most companies legal department review. Please note I said most.

So a company where you can normally submit to a FOSS licensed project can tell you that you are not allowed to sign the Canonical CLA because its a contract that not linked to profitable sales so the legal department is not going to review the CLA so its not a flat no to signing it. Yes this bit can happen with any CLA.

Thing to remember is a CLA is a contract. When you sign up to most business as part of your employment contract any contract you are going to sign as part of your work has to go past legal.

There is a upside to CLA for a project but there is a downside by having a CLA. Having a CLA means you will end up having to deal with the problem of that document having to pass though many different companies legal departments so the CLA better not have glaring flashing alarm in it as the early Canonical CLA did of taking full rights over the submitted code. Yes the CLA if it wrong has way broader effects than you first would presume. Like you presumed community maintained distributions would not be effected you missed that lots of the community maintainers are full time employees for someone who has authorized them to work on the community maintained distribution as part of their job so CLA contracts end up having to pass that person legal department.