If you're interested in something like Adelie Linux, you might be interested in Chimera Linux. Both are musl libc based and both use Alpine's apk.
* 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
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.
scudo requires 64-bit atomics which make libc hookup on 32-bit systems a bit of a pain but nothing that cannot be overcome
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)
* 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.
> 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.
Clang/LLVM allows a lot of tinkering and compiler software development that is more difficult with gcc.
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.
GPL is a positive for me. I am not sure if there is an llvm equivalent in gcc that would pose a "risk" anyways if you embark on such a project. I'll look into the instrumentation and llvm stuff, thanks.
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.
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.
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.
> Your needs are complex—and that's music to our ears because we're constantly looking for new ways to further refine Adélie. Please note that we do not support inherently broken designs.
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.
> 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...
It seems like they're targeting low-end systems (384MB RAM for the desktop version), but also talk about supercomputers? If they can pull that off, it would make it uniquely versatile. Musl is very lightweight, but it's also not especially fast (for example, compare allocator benchmarks). But maybe supercomputer workloads don't really care about libc performance in the first place? I'd be curious to know what aspects they think make this distro suited to supercomputing.
Our aim is to offer a non-glibc Linux platform for supercomputing environments. This involves a tremendous amount of work to be taken seriously and we are currently in the earliest stage of this. Follow our blog (https://blog.adelielinux.org/) for updates in this space.
Diversity in the ecosystem, possible reduction in memory footprint, ability to discover and fix issues in upstream projects that musl-based distros don't currently package, motivation to support CUDA (and other) runtimes that explicitly target glibc, unlock possible sources of funding to pay developers to work on these areas.
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.
In progress. We have access to an ARM-based supercomputer and are actively collaborating with scientists who have access to x86_64 systems. It will be a while before we have results to publish. We need to be diligent in our testing methodologies.
I dunno if allocation speed is that critical to HPC... presumably in that environment, you're allocating big arrays up front and then reusing them. Maybe someone can set me straight on this?
I could see some people being interested in building compute clusters where the individual nodes are cheap, low-memory devices. (Think Raspberry Pi clusters.)
That does sound like a pretty niche thing, though.
That's handy, because I am looking for a fast Linux with small memory footprint, but reliable. I've been using Linux Mint Cinnamon for almost a year, in order to play Minecraft on my old computer (i5 3gen but lots of ram) and I managed to achieve +(10-14) FPS for the game Vs Windows. Also I have a spyware detector installed (a noisy fan) and it goes off constantly on my windows 10, while Linux leaving it mostly silent. Lifetime is also twice. I wonder what does the Windows 10 do to make my computer so noisy and slow. However Linux Mint Cinnamon is failing on standard tasks like configuring WiFi, built-in modem or changing system settings
> That's handy, because I am looking for a fast Linux with small memory footprint, but reliable.
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.
Note that Adélie Linux was begun in 2016. This distro is not new and I'm happy to see continued progress on it. I'll be sticking with Void due to muscle memory, but I'm very glad to see more non-Debian distros continue to mature.
You're probably right. I guess what I'm really looking for is something like ubuntu server but an even smaller attack default attack surface and with apk packaging since that just works and apt and rpm automatic update has either been too complex or buggy and lead to bad outcomes where patches I thought were being applied were not being applied. I'm not married to musl. Some of my stuff I would like to use breaks without systemd though.
The ease at which anyone could create a new Linux distribution is both a good and bad aspect of the operating system in general. There are dozens of larger mainstream distributions in widespread use, as well as dozens of smaller distributions that serve a niche purpose well (e.g., Alpine). Unfortunately, there's also dozens of other distributions that claim to serve a purpose but don't actually do so, or overlap with other distributions that do so better. My initial impression from reading their website is that Adélie falls into the latter category. In other words, it isn't particular clear what niche or purpose Adélie is aimed at solving that other distributions don't already solve.
If there is a community contributing to a distro and those people can daily-drive it, it's perfectly fine for me. A small community is very nice to learn: I tried Adelie in the past and I had to do stuff I never even conceived was necessary on another distro, and the community was helpful. In the meantime, Ubuntu is busy helping newbies run their terminal.
Bonus if the distro does not use systemd or is not a copy of Ubuntu. Diversity is good.
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>)
>We don't attempt to solve every Linux Desktop problem. Because of this, we've already solved 99% of them.
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
I can't think of any distro-specific problems that anyone actually would suffer from, unless it's snapd, but that's self inflicted, so doesn't count.
Fail to see how this is the "answer" for the Linux desktop. "Compatibility" is the third keyword yet, no Libreoffice, Chromium, Flatpak and a barely up-to-date Firefox ESR 91.
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.
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.
No; at the moment we are in beta and this not yet available. We have been experimenting with various strategies to ensure rapid turnaround on security-related issues.
Then I suggest not making this claim unless you solve the problem. Security patches are notoriously difficult to implement and test, one needs to recreate the attacking environment.
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.
I went on and actually did it. Surprisingly everything works on mainline kernel, only the video needed some tinkering. Needs to have pm runtime enable call on gr2d/gr3d devices to run opentegra-video and use new api env to run xorg on it. Nothing compared to where it was last time I checked. The most trouble for me was the block device change somewhere around 6.0 where mmcblk1 became mmcblk0
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
* 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