[continued from previous message]   
      
   > it's still friction. And it's hard to shake the feeling that, if you   
   > were running a more compatible system to begin with, that wouldn't   
   > even be something to think about.   
   >   
   > Getting software from the distribution's package manager is the way   
   > to go for numerous reasons. But sometimes that is just not an option.   
   > Sometimes the package is just nonexistent in the repositories.   
   > 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)