1. 40
  1.  

  2. 24

    Ouch! This is very interesting and also a bit sad. A few extra comments; be careful that they are fairly uninformed, as I know neither the author of the post nor the details of most of the projects mentioned:

    • This is an interesting post-mortem and the project still sounds very exciting. Nicely done.

    • The work described here is part of a mindset that I would describe as “don’t build on top of bad systems”, or “nice design all the way down”. To get working systems in practice most people incrementally, creating a nice environment (as nice as we can) on top of the current/existing software stack that supports most feature people want in practice. The “nice design all the way down” approach works by consider all possible foundations for someone’s work, and picking the best one not in pragmatic terms of feature or usability today, but in terms of solid design and ideal vision for the future. Personally I love this approach and I try to apply it in my thinking (and in my work when appropriate), but of course it comes with the cost of constantly working with pre-alpha tools that are hard to use and lack many useful features.

    • This specific work tries to combine a bleeding-edge “nice design” OS (Genode), a bleeding-edge “nice design” configuration language (Dhall) and a bleeding-edge “nice design” package/OS management/configuration system (Nix), extending all three of them well beyond their current comfort zone. As you can guess, the main take-away of the post-mortem is something like “it’s a shitload of work and the result is extremely painful to use because all these tools are not quite there yet”. But wow, cool!

    • I don’t know the author, but one thing that made me cringe is that sense of personal guilt that exists in this post-mortem. Is this a burnout announcement? One red flag for me in particular is the mention that the author, despite having secured funding from a NLnet grant (nice people btw., the amount of exciting research they fund is impressive), decided to not actually get paid for this massive amount of work because it was a failure. It’s a radical decision, probably correlated with the idealism and radicality of the technological choice, but it’s also I think completely the wrong way to think about these kind of blue-sky grants (if the funder wants to support risky futuristic technologies, of course they expect some of them to not work out in the end, the money is not conditional on project “success” by an unrealistic idealistic evaluation), and also, if I can risk judgment here, terrible personal hygiene.

    1. 8

      constantly working with pre-alpha tools that are hard to use and lack many useful features

      The median project age of Nix, Genode, and Dhall is 10 years, but yes, not a lot of stack-overflow surface area.

      One red flag for me in particular is the mention that the author […] decided to not actually get paid for this massive amount of work because it was a failure.

      Well I think paying people to make technology that doesn’t actually improve peoples lives is a very dangerous thing to do. Also, there is hardly a correlation between hard work and getting paid.

      if I can risk judgment here, terrible personal hygiene

      Haters gonna hate.

      1. 6

        Well I think paying people to make technology that doesn’t actually improve peoples lives is a very dangerous thing to do. Also, there is hardly a correlation between hard work and getting paid.

        I’d be very interested to get to know more about what you are meaning here, if you are willing to elaborate. In my understanding the NLnet PET is more of a research fund and your endeavor definitely shows and teaches us something about OS development going forward. What were the projects own goals? Interactive demos? The packaging thing?

        Haters gonna hate.

        Maybe I misread, but I personally would have interpreted OPs as a sign of compassion rather than hate.

    2. 7

      Making any changes to the Libc triggers a mass rebuild. Modifying system headers causes massive rebuilds.

      This point should be repeated whenever people discuss the pros and cons of statically linked executables.

      1. 8

        Although this was not because of statically linked executables but because of the way nix works. For instance, if you change a license (or any comment line) in a header file you don’t need to rebuild anything. But you will have to with nix, because the hashes are now different.

      2. 2

        Expensive evaluation: Evaluation is slow and consumes massive amounts of memory. I would often restart evaluations because of memory exhaustion.

        The official Nix binaries have serious code quality issues in the evaluator.