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.

FWIW, that is an unofficial mirror repo and very old. gcompat lives at https://git.adelielinux.org/adelie/gcompat.

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.

> Either way, super cool. What's the likelihood that this ends up getting upstreamed?

High: <https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3A...>.

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.

They have ConsoleKit2 support patched back in.

libudev-devd - a stub implementing UDev APIs atop FreeBSD devd: https://www.freshports.org/devel/libudev-devd/

You do realise avahi-client is a standalone CLI resolver, and Avahi is what both Gnome (gvfs) and KDE (kio) use to find mDNS clients on the network?

There's also nss-mdns at https://github.com/avahi/nss-mdns but it is mostly unmaintained.

KDE really, really needs logind - it can't really use ConsoleKit any more. Same with SDDM, though I think the CK2 backend is still writhing in agony somewhere in its codebase.

And KDE's touchpad integration relies on libinput, which relies on udevd. I think libinput might work with mdev if you really try hard enough?

I am not aware of KDE having dependencies on any other bits of systemd, at least Plasma 5 LTS doesn't.

We started a separate BSD userland project before Chimera even existed, but we didn't feel the port was up to our standards of quality, so we shelved it. Removing our dependence on GNU software is a definite goal of mine, though it is relatively low priority and likely far off.

Scudo can be faster in some workloads. However, I recall Scudo is woefully underperforming on 32-bit systems (it may not even work?). Replacing the memory allocator is definitely something you can do, but it introduces another variable into the mix, and I personally feel that would also compromise our goal of reliability.

Differences between Alpine also include: NLS enabled everywhere, so translations work and are functional. No use of GNU gettext, only musl's gettext. A focus on providing a more "full" experience to users over optimising for smaller binary sizes. There are more differences obviously. For some uses Alpine would be better, and for some uses Adélie would be better.

Also: that comparison page is on the oldwww. domain, which means it isn't a part of the current site, which is why it hasn't been updated.

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.

This has more to do with systemd trying to be a "system layer" project for Linux, and influential projects (initially Gnome, then KDE, and now a lot of other things) going along with it.

Honestly, I see no reason a distribution couldn't support multiple service managers. Indeed, Gentoo officially support OpenRC and systemd and do just fine. However, you need to have the resources to do it and the desire. I think there are multiple distributions with one or the other, but Gentoo is likely the only with both.

Yes, there is some progress it seems: https://skarnet.com/projects/service-manager.html

I like the off-by-one there, and choose to interpret it as intentional.

The fourth item is what I find to be the most interesting. I really hadn't thought about it that way before. I remember the discussion in Fedora mailing lists around systemd and iirc the criticisms were mostly actually answered and handled. But in Debian it really wasn't and it fractured the community a lot.

It is perhaps the case that the "anti-systemd" crowd wouldn't be "anti-systemd" if they felt like they had been heard. Perhaps that's the bigger lesson we should all be learning: to listen closely and respond respectfully.

Thanks! I hadn't considered that use case.

I'm unaware of any Linux distribution using SMF. If there was, I would have been running it. I didn't really like pfexec (it felt bolted on and not quite there yet), and I really really hated ZFS (and still do), but SMF made Solaris administration a joy.

I don't think any distribution was using runit before systemd, but it was available in Gentoo as a sysvinit replacement and ISTR it was used in the Rails community for supervising Unicorn.

The monoculture problem is one that I really tried to cover in the article, indeed.

While I do agree that a "super server" listening to the network could be a new (or old, with (x)inetd) concern, a well-written and well-designed pid1 doing this isn't much more risky than having the services manage themselves. The listener could/should be just as unprivileged as the target daemon, nominally using the same uid/groups and root directory as the target as well. And indeed, systemd's .socket files support the same environment control variables (User=, Group=, SupplementaryGroups=, RootDirectory=, WorkingDirectory=, et al) that services do.

So that boils down to "are people writing socket activation units correctly", which is probably "no", but could be "yes".

I'm going to be honest here: Bluey means a lot to me, as a 32-year-old childless woman, because this show has really touched me in ways that may not be obvious at first:

I've felt more in touch with my own imagination since I started watching Bluey. I've actually been writing music and sketching in my spare time again, which is something I haven't done since before the pandemic.

It's actually helped me piece together things that I felt as a child that I never properly dealt with, or even knew how to voice back then. I've been able to find healing and peace, and articulate stuff in therapy a bit better.

In general, I just feel a bit happier and a bit better after watching an episode of Bluey. Sometimes I just want to watch something to feel positive emotions without it being overly-happy fluff. There's a realism to Bluey that makes it easier for me to "let my guard down" and feel happiness.

I do kind of live vicariously through Chilli, with my hope being that I can be a mum some day.

Oh, and my cat now has a nickname: Muffin. Make of that what you will.

> with heavy-handed social messages infecting what should be simple cartoons.

I kinda giggled at this, because I just last night saw "Pass the Parcel", which to me was the one time they sent this up and they did it so well.

> It's not all happy, singsongy, bright-colored drivel

"Oh man, the songs." - Bandit, "Movies".

I don't know if I really agree. The creator has stated that the point was to appeal to kids and adults, and I think Bluey pulls that off perfectly.

This is similar to Friendship is Magic, which I'm surprised nobody else has brought up yet. A kid's show that doesn't write "down" to them, and is written by people who are creating what they wanted to see when they were that age. That's how you make truly good entertainment!