[continued from previous message]   
      
   Sometimes you need to compile it yourself because you need a specific   
   version. Or because you don't trust the provided pre-compiled binary.   
   Sometimes you need a specific compilation with a specific feature.   
   Sometimes you are in a hurry, or just curious to try something you   
   can securely run in isolation.   
      
   So not being able to install it the conventional way is friction in   
   itself. Having to compile something every time is extra friction.   
   Having to recompile on upgrades is more friction. And to not be able   
   to compile or run it even by compiling it yourself, that is just   
   compounded friction with some frustration sprinkled on top.   
      
   ... though I'd rather not   
   =========================   
      
   This is not about Alpine, but it's also inseparable from Alpine.   
      
   Alpine has an excellent, fast package manager that never broke my   
   setup. When things did break, it was able to fix them by itself. The   
   six months release cycle is to me a really sweet spot at which to   
   space versions--not too often, not too seldom. A lot of software is   
   available. Developers are security conscious. It's extremely lean on   
   resources.   
      
   And in the spirit of being so lightweight, Alpine shines on   
   virtualized and embedded systems. This focus on being small is why   
   musl is a great fit, since it's a lot lighter than glibc, among other   
   advantages. For me though, while I appreciate the smaller size, it's   
   not that critical that I'd sacrifice compatibility and versatility   
   over it.   
      
   So I have zero complaints about Alpine, musl aside. It is perfect in   
   everything I signed up for when I decided to try it. It delivered on   
   every feature and never lied to me. It never said to me it was going   
   to be smooth and easy to run glibc programs. So it's not so much that   
   I didn't like Alpine, it's that I wish there were a glibc Alpine just   
   like there is a glibc Void. But I'm well aware that's not happening.   
      
   Choosing a path beyond   
   ======================   
      
   It was excellent to learn hands-on about how Alpine works and what it   
   can offer. I learned a lot about not just its components, such as   
   OpenRC and BusyBox, which were basically strangers to me, known only   
   conceptually. Alpine also taught me a lot about all the things it   
   doesn't have.   
      
   Because, seriously, if you do a chroot installation of Alpine and   
   don't even run its setup scripts, you'll end up with something so   
   trimmed down you'll wonder if you're midway through LFS. You'll have   
   to work your way up to a usable system piece by piece, finding out   
   what you need, why you need it and how to set it up. And that is a   
   huge learning opportunity for those interested   
      
   For now though, I decided to backtrack a little bit and then fully   
   reverse course if I can't find a working compromise. That means   
   giving Void another try and, if stability keeps being a problem, go   
   further back and land on Debian. If I shed the non-systemd preference   
   aside, Debian would deliver on the stability and compatibility that I   
   am looking for.   
      
   You see, I am not looking for the next distribution to try as if it   
   were a hobby and I wanted to try novelty out of FOMO. This is   
   actually a lot of work! I'd rather do other things with the operating   
   system rather than install and configure it, as I mentioned before.   
   And if at the other end of the bell curve it's Debian, whatever.   
   Perfect is the enemy of good and being picky is exhausting.   
      
   I mentioned curiosity is a big factor in wanting to try things too.   
   And frankly, after a while holding this preference for non-systemd   
   operating systems and using systems without it, I might as well seize   
   the opportunity to learn more about systemd as well. At my current   
   internship, systemd is what all the distros we have in production are   
   using. In future work, that is very likely to be the case too. So   
   there is nothing to lose.   
      
   I really wish, though, that package managers were more capable of   
   differentiating between security and feature upgrades. If they were,   
   we could run a rolling distro in "Debian mode" at will. This thought   
   may not sit well with some rolling distributions, say, in Arch Linux   
   you have the notion that "Partial upgrades are unsupported". There   
   may be the expectation that the whole repository at any given time is   
   the end state for all machines subscribed to it, but if dependencies   
   could also be at the version and not only package level, that could   
   also be solved, though I won't undersell the consequences and added   
   complexity in such a change.   
      
   Just like mail clients, all operating systems suck. Some just suck   
   less for some specific use case.   
      
   * * *   
      
   [1]   
   Also, if you find out how to reclaim that identity, do share. Asking   
   for a friend.   
      
   [2]   
   It's no surprise a distribution's main init system has better   
   support, as it sure is a lot of work for packagers to support and   
   test multiple init systems.   
      
   From:    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)