awilfox

There are many, many users for every one of us packagers. We (at least the four I am aware of, including myself) are not doing 'gotta catch em all', we're doing "we have been notified by users that this package (is not|no longer) working". And it looks like 'gotta catch em all', because there are so many users, still.

There are new users asking how to get Raspberry Pis into aarch64be mode in the Gentoo Arm project channels. There are thousands and thousands of Power Macs. SPARC servers with ridiculous amounts of cores and computer power are super cheap on eBay because Oracle ended support for them - and this is a great way to get a huge thread count cheap, if your software actually runs on it.

Make the BE CI optional if you need to. That way, the maintainer has time to find and fix it, and you can still merge other changes while it runs. What binutils did was have the BE CI run separately and specifically ping the BE maintainers - that way, they know the build's failing, and no one else is bothered with it.

Ooh, another +1 for reasons to maintain 32-bit support. Thanks for the tip.

The systemd journald test is the longest one on my 3 GHz Power9 system, nearly timing out:

    1475/1475 systemd:libsystemd / test-journal-verify                                    OK              28.44s

but on x86 it runs in under 1s. Not sure the deal there.

That would be amazing, but I don't imagine that malloc internal probes would be readily accepted to musl even if they were improved. One of the things musl admits is the ability to swap allocators around; you can just LD_PRELOAD a new one. Or even, with Chimera, replace the stock one too! Having internal debug probes would mean every allocator you want to use would need to provide those same APIs, and I don't find that particularly reasonable.

It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made.

And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well.

At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people.

Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.

A lot of people care about BSDs and embedded Linux systems. Such as: Netflix (FreeBSD), anyone with a Linux-based router or cable/DSL modem, and so on.

That said, parallel startup is possible on those systems too. There was an out-of-tree patch for parallel rc(8) on FreeBSD some time ago, and dinit is parallel, etc. I think OpenRC should move towards making parallel startup stable and supported so that those systems can do that as well.

And Windows now has WSL to implement the open API, because it's so popular. And implements SSH and sudo, because they're so popular. Etc :)

I care deeply, and was one of the early adopters of the Talos. I do my graphics and design work on an iMac G5, still. Power is the hill I'm willing to die on, technologically speaking. The bi-endianness matters a lot to me. I prefer to do my development on BE, and I get hardware accelerated LE VMs for free on Power.

But the rest of this thread is correct: right now it is a huge cost sink. I recommend people buy Apple Silicon Macs for new hardware unless they really need the owner controlled firmware of a Talos. There's just no denying the M2/M3 spank the Power9 core in every bench, single and multi thread.

I'm eternally optimistic - I was told I was crazy in the dark days of P7 and P8, then the Talos came. Maybe the LibreSoC or PPC Notebook projects deliver? Maybe Talos 3 isn't stupid high cost? I hope, but I don't hold my breath.

* GNU tools are often bloated, with extensions that the vast majority of people do not need or want. While we don't have quite the same focus on "must be small binary size" as Alpine, needless waste is still needless waste.

* GNU tools use gnulib, which is frequently incompatible with musl, and is a moving target for both building packages and passing tests. The number of patches I've personally had to write to make gnulib-based software work at all is dizzying.

* GNU projects have a lot of odd contribution hurdles: I've still never managed to connect with GRUB maintainers despite trying the Savannah page and the mailing lists. It was a chore to upstream other things.

LibreOffice is a known pain point we are trying to resolve. Flatpak is on my list of things to package. Firefox and Thunderbird 102 need Rust toolchain updates that are queued but not yet live.

Chromium is a non-starter: it doesn't support musl libc, and even if it did, it doesn't support 3 of our 5 Tier 1 architectures. It also has significant issues regarding reliability, security, portability, and a rapid release schedule that would severely drain our presently limited resources testing all of the patch sets we would need to ship with it to make it work for us. But, when we have Flatpak available, you can always <s>punish yourself with</s> run Chromium via that, I suppose.

I'll look in to Gnome Boxes; thanks for the report.

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.