Adélie Linux
adelielinux.org
adelielinux.org
* Chimera Linux uses BSD userland while Adelie uses GNU coreutils
* Chimera has the dinit init system / service manager while Adelie uses OpenRC
* Adelie uses gcc as far as I can tell while Chimera uses clang as the default system compiler
* Chimera uses the scudo memory allocator rather than musl's default memory allocator. Scudo is apparently faster than musl's default allocator. Not aware of what Adelie does.
In general, it is not clear to me why Adelie should be preferred over, say, Alpine. The differences don't seem that significant to me to make a switch from Alpine, if you currently use it.
Full disclosure: I use Chimera and I like it. In particular, I like (a) clang/llvm usage as default compiler (b) the lovely and elegant cbuild package build system
A recent Chimera Linux article: https://news.ycombinator.com/item?id=38667503
P.S. It would be great if they listed Chimera on: https://oldwww.adelielinux.org/about/compare.html
Clang/LLVM is just an easier platform for code instrumentation, cross compilation, code sanitizers, building your own compiler tool/language, understanding the codebase, good documentation to build your own LLVM based tools...
It's a bonus that any tools/languages etc. you build using the LLVM infrastructure does not virally become GPL also.
Aparently Clang is ~5% faster than GCC (at least on intel's latest chip) -- See https://www.phoronix.com/review/intel-meteorlake-gcc-clang . Though this is not a big deal for me -- it is just nice to know.
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.
Why?
Or maybe GNU just rubs people the wrong way?
* 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.
Indeed. While some GNU projects are high quality many of the projects can be a bit too insular and crufty.
it can only use the primary32 allocator on 32-bit systems, which is fine, chimera uses primary32 universally because it uses less virtual memory while performing more or less the same in practice
it's significantly and visibly faster than mallocng in most things user-facing, effectively anything that allocates and is multi-threaded (e.g. builds - LTO linking times take a third the time, web browsers are snappier, java is snappier, etc)
Adelie is basically alpine but with a much bigger desktop focus. That's its raison d'etre, to stick with the French :)
I think it would be helpful for this to be mentioned more prominently on the webpage. Maybe it is and I haven't spent enough time on the website.
The Adelie webpage should be a bit more technical in nature IMHO -- the front page seemed more targetted at managers than developers. Sadly, the Adelie website feels a bit generic in its current state -- there are so many "corporate" websites like this.
Home pages of Alpine Linux, Arch Linux etc. are ultimately useful to developers I think because the density of information is a bit higher and the marketing messages, while they exist, are not so front and center.
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.
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.
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.
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 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)
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.
Idk i probably wouldn’t use this simply because of this text, but that’s just me.
> Whether you've taken a few photos with your phone's camera or you're a professional photographer with terabytes of digital negatives, Adélie gives you the tools you need to manage and view all your photos.
Translation:
> Adélie installs digiKam by default
I panicked at the first screenshot, which shows Windows 10(?) in a VM. Maybe not the best choice.
That's clearly KDE Plasma, not Windows. I won't fault you for confusing them based on a glance because Plasma is somewhat intentionally similar in style and appearance to Windows.
Edit: oh, you don't mean the screenshot on the front page, but in the screenshot section... that looks like Windows 8(.1) in a VNC session. Yeah, that's maybe not the best choice...
The ability to audit a smaller codebase could be compelling for some sensitive environments.
There is not an urgent or immediate problem with glibc in the HPC space, per se.
That does sound like a pretty niche thing, though.
You might want to look into MX Linux. It's a Debian-based distro that offers a good balance of performance, package selection, administration tools etc. I'm running it on my 10yo Thinkpad right now and it's very speedy without relying on ancient software versions.
Bonus if the distro does not use systemd or is not a copy of Ubuntu. Diversity is good.
https://oldwww.adelielinux.org/about/compare.html
Non-BusyBox Userland (for me, and me alone!) is a slight minus; OpenRC is a strong plus...
The individual Linux user's "mileage" -- will of course vary.
Anyway, welcome Adélie Linux, to the potpourri of Linux distributions!
(Hey, that's a good idea incidentally -- maybe in the future I'll create a Linux distro called "Potpourri Linux" -- it'll borrow something from every other Linux distribution! <g> :-) <g>)
What are some distro specific problems? All problems with Linux in the last years I had were related to:
HP printer/scanner (I upgraded to Brother)
Xorg vs Wayland migration (some manual steps required to get things working OKish)
systemctl not working well with recent bluetoothd
Also for the main page, "Security updates are nearly instant" fell like a big lie.
I also noted that the KDE GUI doesn't start in Gnome Box, but does in Virtualbox.
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.
That's a distracting waste of effort that has little value in 2024.
(Do they need this to bid on some government or other contracts or something?)
Are they installed automatically? Or what do they mean?
But if you do solve it, kudos to you. Your solution will have companies come knocking at your door day and night. It's going to be worth a lot more than the distro.
The ram is only 512M on mine so not especially useful.
Some userspace stuff doesn’t run (firefox, thunderbird) due to instruction set being too old, so I guess mutt + some kind of terminal matrix client on i3 will be the thing of the day