1. 26
  1.  

  2. 15

    Glacies looks really cool. I’ve been following your progress with Eltanin for a while since it shares a lot in common with my own Linux OS project.

    For those who might dismiss this as “yet another distro”, note that Glacies is actually quite unique, and not just a repackaging of the same software you find everywhere else.

    It includes its own implementation of POSIX tools (ecore) which uses its own standard library (tertium), mostly independent from libc, and a lot more coherent. tertium looks to be inspired by djb libraries, similar to skalibs (used by s6) and others. Upon brief skimming, the code looks quite good and clean, too. I think one of the biggest problems with C is its poor standard library, so it seems good to build upon a more solid foundation like this.

    Also notable is the preference for rc (plan9’s shell) scripts, which is quite a bit nicer than POSIX sh, in my opinion.

    I’m curious if you’ve considered using pkgsrc to supplement the base system with larger software like Xorg and firefox. It seems like a great way to extend your base system with a huge repository of packages, while allowing you to stay focused on the core components. I’ve been using it this way on my own system, and it’s been working great.

    1. 5

      Thanks : )
      About tertium it is completely independent from libc, it will use it only for unsupported environement (ARCH/OS), which should reduce with time, and even then only macros would be used (for machine specific values).
      About pkgsrc, i have considered using it, initially as default source-based pm, but found it too complex and wrote “ports” (that changed a lot). The problem is that it would have bad interoperability with the system package manager, but i will reconsider it, because it could make the system usable while its “ports” grows. I have tried to add Xorg to my ports, it weren’t too hard, the problem is compiling it statically; so i may need to give more attention to support obligatory dynamic linking cases before adding bigger packages

    2. 4

      Very nice!

      We need more than one way to get things running to make sure our ecosystem works. That is how we know all our software stack does not only work on Debian, but works on everything that supports a few standards and conventions (and identify accurately which parts break and what still works).

      What about having a look at Wayland? I do not like fanboyism, but this talk (by the one of the few guys that deal with the problems of X11) changed my mind: https://www.youtube.com/watch?v=GWQh_DmDLKQ

      Talking of wayland and @mcf: https://github.com/michaelforney/swc

      1. 5

        I have considered, and in fact i prefer it than X.Org X11 (which is terrible), but for now X.Org support will gain focus because it already has a good support. After that, the focus will be on the replacement, and in this phase i will consider Arcan and Wayland

        1. 1

          I did not remember Arcan. Thanks!

      2. 3

        The whole system is statically linked

        I’m curious: What benefits does this have, in practice?

        1. 4

          The dynamic linking adds a few performance overhead which defeat the disk usage benefits (and memory usage benefits are tiny), but let’s say we do not care about a “tiny” (I don’t really know how much) performance overhead.

          This adds complexity to the toolchain, and saying “we got that working anyway” means I am not the one dealing with the problem, not that this is not a problem. :)

          • How to update libcurl or libc library while still being sure you will not break your package manager (and therefore, the ability to rollback!),
          • How deal with an upgrade of a library that /will/ break the binaries (temporarily) until you also upgrade the binaries (in case of ABI change).
          1. 2

            Sounds cool. Really great to avoid the problem of partially updating your system, leading to a breakage

          2. 1

            for me the best thing is portability, and not dealing with versioning of libraries (as josuah cited about painless updates). others benefits may include:

            • speed gain (no time to load libraries)
            • more secure (no ldd exploits)
            • reduce space usage (because you won’t need to keep entire libraries when only a single package depends on them)