1. 37
  1. 34

    This will be good for Wayland, musl, and clang support for all their supported packages. Typically a distro that goes out of the beaten paths will bring a few patches to the upstream projects that make them more generic and resilient to diverse environments.

    It’s not super clear to me what the appeal for the distro itself is, as a user. They seem to be focused on a set of technologies to use and it’s unclear what capabilities this will bring that aren’t available elsewhere.

    1. 1

      capabilities this will bring that aren’t available elsewhere

      In my opinion, the challenge of a distribution/os is how software is brought to users (which might be admins or end-users), not what is bundled.

      But I agree that there might be facilities that the OS provide.

      “just doing it right” is a good enough selling point to me, while some might look for “extra features”… All about tastes.

    2. 11

      From the “truly modern” headline and the “not trying to be” start I thought this was going to be some bold new attempt, or something novel.

      Instead it’s… just another distro.

      1. 5

        Ah, “truly modern”, the “all natural” of technology.

        If only this distro was both truly modern and ergonomic it would really have some legs.

        1. 4

          What would have satisfied you? I don’t think “another distro” is a bad thing

          1. 5

            Oh, I didn’t mean to imply that it’s bad… just… boring compared to the headline and tone of the article which seem to think the project is some kind of revolution.

            You may doubt if Serpent OS will see the light of the day and if it would be able to keep all the promises it made.


        2. 5

          All fine points - any work this distro does will benefit mainstream Linux as well, so that’s good.

          However, as an end user I’d be hesitate to commit my infrastructure to this given Ikey’s recent track record of bouncing from project to project ever since he ‘left’ Solus :)

          1. 6

            Very nice to see the fully-LLVM thing, especially libc++.

            1. 10

              Why’s that nice? I have nothing against LLVM, but I don’t feel it’s better than GNU either, so I’m curious about your reasoning.

              1. 12

                I use FreeBSD, so my main selfish reason: I want Linux people to adopt libc++ more so that they stop writing software that fails on libc++! Often that’s due to silly stuff like missing includes (relying on libstdc++’s incidental transitive includes).

                1. 1

                  I thought they fixed that in gcc 10?

                  1. 1

                    That’s a cool change, but I’m not sure stdexcept is the only such thing. And of course not every developer has tested everything on this version of libstdc++ yet..

                2. 4

                  I like to see software built with many different kind of compiler, linkers, assemblers, kernels, libcs, other libs… as a way to reveal bugs or unportable features.

                  Also, I like to see multiple implementations of some essential components, partially an indicator that the good abstraction was found as it is easy to re-implement.

                  1. 2

                    LLVM has nicer debugging tools for certain things, a C++ interpreter among them :)

                    1. 1

                      Not the OP, but the fact that there are plenty of other distributions stressing the GNU toolchain means that LLVM gets short shrift, to some degree.

                  2. 2

                    This looks very cool. I’m curious to find out how package management will work, as well as its init system.

                    1. 1

                      now these are the big questions :)

                    2. 2

                      I clicked with little in terms of expectations. Turns out, this is actually interesting.

                      There’s other distributions using musl, but as far as I am aware, they are all desktop or embedded oriented. AIUI opensuse uses llvm/clang. But ?nobody? is using libc++, and it’s been nagging me for a while that it hasn’t been tested on unconstrained environments on anything else than Apple OSs.

                      I don’t think I’ll adopt it soon (I can’t afford to mess around with Linux, my messing around is focused on other OSs like dragonfly or genode), but it will no doubt help the Linux ecosystem move forward.

                      1. 2

                        Not 100% sure about MUSL-stuff, but other than that it seems like nice concept. I hope for better approach to the packages as well, something like Gobo Linux or Nix. I would also love to see that it would restart the concept of FatELF in Linux.

                        1. 8

                          Having a distro based on musl is a good thing, because it introduces some diversity and will likely benefit other non-glibc-based OSes. Also it will certainly speed up bug fixing in musl (we’ve hit some musl bugs before with the CHICKEN project, which are frustrating because you don’t expect libc to be broken :P).

                          1. 1

                            I am not saying that having MUSL-based distro isn’t good for MUSL. To be honest, I would much more prefer if Linux would go the way the most other OSes went, where there is no stable sys call interface and instead everyone should use system-provided library for interaction with OS.

                          2. 3

                            better approach to the packages as well, something like Gobo Linux or Nix

                            This style of packaging:

                            • require no SAT solver,
                            • permit multiple versions to be built and installed alongside,
                            • still has good performance, solve “/etc/alternatives” along the way,
                            • isolate files from each package install,
                            • avoid the need to have package named python2 and python3 (just python v=2 and python v=3),
                            • works very well with 3rd-party packages: no need for /usr/local
                            • permit go v=1.4 to be a dependency of go v=1.14
                            • permit to introduce some immutability for builds (caching, reproductible builds, easy distribution…).

                            So yes, let’s do this!

                            1. 2


                              Is there really a point to make binaries portable if the source code is already portable?

                              1. 2

                                e.g. booting all sorts of hardware (with different ISAs) from a single system image.

                                1. 2

                                  I only had execution of programs in bind, and forgot about other places where ELF was being used.

                                2. 2

                                  Yes, if you do not distribute the packages in form of source code. With tooling like Nix it doesn’t do that much, but if there would be “classical” approach to the file tree, then it allows removing split between lib and lib32.

                                  1. 1

                                    I am fine with being exposed with compilation, and exposing compilation to end users (may it be “we are preparing your applications” so that end-user does not see the scary “warning:” going by).

                                    Now that is another string to the bow to have, maybe I will face a situation where I want to deliver the same binary without looking at the architecture (I must admit that now I only can imagine “the user does not know what to pick on the download page” scenario :P).

                                    1. 1

                                      Side effects:

                                      • FatELF binaries and multiple architectures are definitely nicer than trying to having only x86_64 with many tiny extra sub-features that may or not be enabled.
                                      • May FatELF become widespread, cross compiling can become better supported.
                              2. 1

                                I mean, there are enough Linux distributions trying to be Solaris already. A different take would be welcome.

                                1. 9

                                  If we’re gonna open that can of worms I’d also assert that rather than creating new distributions it’d be awesome if folks would pour their efforts into improving one of the umpteen skittledezillion that already exist.

                                  However, that’s the beauty of open source right?

                                  1. 5

                                    The beauty and the tragedy of open source.

                                    1. 4

                                      I don’t like distro proliferation, either.

                                      But this doesn’t fit the “New DE with distro centered around it” pattern nor the “Let’s make another Debian/Arch derivative and market it as user friendly so that some suckers donate to us” pattern.

                                      This one seems to have some merit to it, by going llvm/libc++/musl.

                                      1. 1

                                        Why not, say, an Ubuntu variant though? Or a spin of Fedora?

                                        SOMETHING to help these new developments broaden an existing community.

                                    2. 2

                                      Which ones? I’m curious.

                                      1. 1

                                        That was poorly phrased. I was thrashing around for the idea that they’re a lot of distributions trying to do the same thing, not so much that they’re trying to be like Solaris.