Hacker News Reader

Comment by imiric | Hacker News Reader

They mention focusing on reliability several times, but I don't see what they're specifically doing to make the system reliable. Is the process supervisor (s6) the main thing? If so, how is s6 more reliable than systemd and other process supervisors?

When I think of reliability, my main requirement is for my system to not break after an update, which is so common on Linux, unfortunately. This is a solved problem with Nix/Guix or filesystem snapshots, so any new distro that doesn't address this major concern is not worth switching to IMO. We already have a plethora of distros that don't do this right.

I'm also not convinced why musl is specifically a selling point. IME some software breaks in strange ways with musl, and the glibc compatibility layer doesn't help. If I want a reliable system, I'd choose one with glibc over musl any day.

View on HN

Disclosure: Founded the project, still have a somewhat active role in package maintenance.

Updates/upgrades are a major area of focus and everyone I know who has tried it out was always impressed that they could just `apk upgrade`, reboot, and it'd all still be working fine.

That shouldn't be such a high bar, but there it is, and we manage to clear it.

Reliability is not just about updates. Reliability means shipping stable versions of packages, not betas or unmaintained patches/forks. Reliability means testing on physical hardware of different types, and virtual machines/hypervisors of different types, and seeing all packages working across all of them.

During beta4, me and two others sat at a desk with a PowerBook G4, Power Mac G5, Pentium 4, Core i5, and RPi4, and beat the living ** out of all available packages. We found seven bugs, four of which were reported upstream, the other three being packaging issues we fixed.

That's what reliability means to me.

Thanks for your perspective. It would be good to mention some of that on the About page.

It's great that you focus on testing and stability, but incompatibilities and bugs will still creep through. There are infinite combinations of hardware, software and configuration, and realistically, you can't guarantee that an `apk upgrade` will be 100% safe every time for all users. It's in those situations that a snapshot-based rollback mechanism saves the day.

I'm not trying to diminish the value of the work you and your team are doing. All of that is commendable. I just don't think we can ignore the benefits of atomic upgrades and safe rollbacks that tools like Nix provide. All distros should have some form of this, especially those that advertise reliability as a primary feature.

I agree that the web site needs a significant amount of rework.

The APK package manager specifically makes all transactions atomic: if `apk upgrade` returns an error, your system is in the state it was before it was executed. If it does not return an error, your system is now updated.

Rollbacks aren't necessarily as easy to do with "just" APK, but we support Btrfs as a first-class citizen and it wouldn't be hard to make snapshots as an APK pre-commit action if you wanted.

this is misleading, apk transactions are only atomic if no pre/post-install/deinstall/upgrade hooks run, as every invocation of a hook requires a commit of everything done until that point

they are not atomic in alpine, i highly doubt they are atomic in adelie, they are almost atomic in chimera, though there is still a couple places left that break that and i'm working on them (some of it also requires apk 3.x features and is not possible with legacy apk which both alpine and adelie are using)

> I'm also not convinced why musl is specifically a selling point

Software does break in strange ways with musl. But the Linux community has come a long way over many years. musl based distributions are much more usable now than they every have been.

The advantage of musl is that it is very clean, easily understandable and has very little legacy cruft. The ability of peer into musl code and actually understand what is going on is very liberating.

Give it a bit more time. clang was very difficult to use at one time on Linux due to various incompatibilities and GNU extensions it did not support. Today clang has caught up and is better in a few respects than gcc e.g. its modular internal architecture based on LLVM.

Process supervisors are inherently problematic because they are at the heart of a microservices model.

Reply on news.ycombinator.com