Professional software engineer, musician, gamer, stoic, democratic socialist

  • 4 Posts
  • 143 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle
    • Has a simple backup and migration workflow. I recently had to backup and migrate a MediaWiki database. It was pretty smooth but not as simple as it could be. If your data model is spread across RDBMS and file, you need to provide a CLI tool that does the export/import.

    • Easy to run as a systemd service. This is the main criteria for whether it will be easy to create a NixOS module.

    • Has health endpoints for monitoring.

    • Has an admin web UI that surfaces important configuration info.

    • If there are external service dependencies like postgres or redis, then there needs to be a wealth of documentation on how those integrations work. Provide infrastructure as code examples! IME systemd and NixOS modules are very capable of deploying these kinds of distributed systems.










  • Agreed.

    And sometimes code is not the right medium for communicating domain knowledge. For example, if you are writing code the does some geometric calculations, with lot of trigonometry, etc. Even with clear variable names, it can be hard to decipher without a generous comment or splitting it up into functions with verbose names. Sometimes you really just want a picture of what’s happening, in SVG format, embedded into the function documentation HTML.




  • There are plenty of good resources online. Here are some topics you probably wouldn’t see in an intro algos course (which I’ve actually used in my career). And I highly recommend finding the motivation for each of these in application rather than just learning them abstractly.

    • bloom filter
    • btree
    • b+ tree
    • consensus algos (PAXOS, RAFT, VSR, etc)
    • error correction codes (Hamming, Reed Solomon, etc)
    • garbage collection (mark+sweep, generational, etc)
    • generational arena allocator
    • lease (i.e. distributed lock)
    • log-structured merge trees
    • min-cost + max-flow
    • request caching and coalescing
    • reservoir sampling
    • spatial partition (BVH, kd-tree, etc)
    • trie
    • write-ahead log

  • I’m not in the market, but I’ve actually had similar thoughts of building a project on top of NixOS that’s focused on self-hosting for homes and small businesses. I recently deployed my own router/server on a BeeLink mini PC and instead of using something like OpenWRT, I used NixOS, systemd-networkd, nftables, etc.

    DM me if you want to discuss more. I think the idea has potential and I might be interested in helping if you can get the business model right (even if it just ends up being some FOSS thing).








  • Yea I agree. Good UX is a lot of work, and I think FOSS projects rarely prioritize it. Even good documentation is hard to come by. When you write software for your own use case, it’s easy to cut UX corners, because you don’t need your hand held.

    And good UX for a programmer might be completely different from good UX for someone that only knows how to use GUIs. E.g. NixOS has amazing UX for programmers, but the code-illiterate would be completely lost.

    I believe that the solution is “progressive disclosure”, and it requires a lot of effort. You basically need every interface to have both the “handholding GUI” and the underlying “poweruser config,” and there needs to be a seamless transition between the two.

    I actually think we could have an amazing Linux distro for both “normies” and powerusers if this type of UX were the primary focus of developers.