Open Collective
Open Collective
Back to conversations

Be Frank: How important is musl to your support of Serpent OS?

Ikey Doherty

Posted on September 22, 2020

We're at a point now where we're benchmarking glibc vs musl performance with Serpent OS, so we're putting the question out there: Is musl what drew you to Serpent OS?

Now, there is a lot of friction in terms of merging musl into Serpent OS, and with the support packages we've come up with it feels a bit like writing a new libc, which isn't what we were going for. It's also recently come to our attention that there are cases with the Linux kernel where clang compilation is causing serious bugs, so we will need the ability to optionally use GCC on a small number of packages (Even elfutils.)

So, given our key differentiator is in fact our package manager, moss, linked with our philosophies, is musl something you absolutely need to see in the core system, or are we all open to deferral of integration?

Our proposal would be a somewhat hybrid approach: GCC built glibc + binutils for ld.bfd only. GCC built kernel + modules until regressions disappear, and primarily Clang/libc++/libunwind/etc built distribution.

By friction I of course mean the ever-evolving needs of libc-support and libwildebeest, and many corner cases where runtime is affected vs compilation.

Let's have a chat first.

Sam H Smith

Posted on September 22, 2020

You can't sell a distro based on it's package manager only. A distro is an ecosystem of many ideas that work well together. To me musl is one of them. We face real and difficult problems, just like every innovator in history. We should not expect the future of Linux to be handed to us on a plate. We are here to craft it. Others, due to herd mentality, will call it reinventing the wheel. This assumes glibc is like a wheel, a perfect solution that can not be improved. Let's not fool ourselves, there is plenty of improvement's to be made. Glibc is *a* solution. And it's important we dare to pursue something better instead of settling for the status quo.

Ikey Doherty

Posted on September 22, 2020

Nice reply, Sam H Smith. My counterargument is we're not actually selling anything, and there is plenty of opportunity for innovation outside of the package manager. The package manager is actually the update solution and sets many policies for the OS, such as capabilities, read-only rootfs, automatic hardware enabling, etc.

On IRC you said if we're not fully happy with glibc we should up and leave. I don't think anyone is fully happy with the Linux kernel either, this is why they contribute upstream to improve the projects ,instead of throwing out the kitchen sink :)

Robert Griffiths

Posted on September 22, 2020

Personally I don't care. I just want a want a distro done properly: a package manager with rollbacks and software solutions to everyday issues that the other distros simply leave because so many people know the workarounds or the CLI. 

To me it's more about your apparent intention that leads to quality: things working cleanly, properly, helpfully and with common sense. This is what drew me to Solus.  TBH I had to read what musl and  glibc were and I still don't know if or why I should care.
👍️  1

Ikey Doherty

Posted on September 22, 2020

I think you hit the nail on the head, "I still don't know if or why I should care" - as an end-user, likely not.

It's something we can pin for future implementation, and encourage community development around when a solution matures :)
👍️  2

kevin henderson

Posted on October 27, 2020

For what it's worth, yes musl was a draw to Serpent for me, but I *don't* find it critical for the bootstrapping you're doing now. Mostly I'm interested in supporting the https://www.pine64.org/ and https://postmarketos.org/ ecosystems (along with void, alpine, manjaro-arm, etc)
because of the mobile convergence and open hardware aspects. Even though it's of course a very far off vision, anything that can be done to inch us closer to that integrated end is worthwhile in my books. Also, as more robust system languages like Rust, D, Zig, etc. continue adoption then wider, safer C integration support would also pay dividends.

Conversation followers