The Most Prolific Packager For Alpine Linux Is Stepping Away (phoronix.com) 37
Michael Larabel, reporting at Phoronix: Alpine Linux remains one of the most popular lightweight Linux distributions built atop musl libc and Busybox. Alpine Linux has found significant use within containers and the embedded space while now sadly the most prolific maintainer of packages for the Linux distribution has decided to step down from her roles. Alice "psykose" who is easily responsible for the highest number of commits per author over the past year has decided to step down from maintaining her packages.
These Alpine aports stats put her at 13,894 commits over the past year. In comparison, the second most prolific packager saw just 2,053 commits... Or put another way, psykose has 6.7x the number of commits as the next packager. The 13.8k commits is also about half of the 26.8k commits seen in total over the past year. Over the weekend I was alerted to the fact that psykose/nekopsykose has begun dropping maintainership of packages she maintained. All of her recent alpinelinux/aports commits two days ago were removing packages she oversaw.
These Alpine aports stats put her at 13,894 commits over the past year. In comparison, the second most prolific packager saw just 2,053 commits... Or put another way, psykose has 6.7x the number of commits as the next packager. The 13.8k commits is also about half of the 26.8k commits seen in total over the past year. Over the weekend I was alerted to the fact that psykose/nekopsykose has begun dropping maintainership of packages she maintained. All of her recent alpinelinux/aports commits two days ago were removing packages she oversaw.
I'm interested in taking over (Score:4, Insightful)
What does something like this pay?
Re: (Score:2)
I suspect nothing.
Re:I'm interested in taking over (Score:4, Funny)
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
Re: (Score:2)
The job pays nothing.
Bus factor strikes again (Score:5, Interesting)
Re:Bus factor strikes again (Score:5, Insightful)
Re:Bus factor strikes again (Score:4, Informative)
Even Chocolatey on Windows has this problem, so it's definitely an issue with relying on unpaid volunteers. No matter how popular, in the end it comes down to one person having the interest in keeping things up to date.
Re: (Score:3)
and the problem with expecting unpaid workers to support vital infrastructure.
Alpine will almost certainly survive, as others will step up (at least for core packages), but that does not address the issue you are raising in the long term.
The larger problem is arguably those who are the pure takers and do not contribute back or pay for licensing/support equivalent to the value they receive, resulting in a dependency on those unpaid workers. One can dislike the companies such as Microsoft or RedHat that directly or indirectly derive revenue from sales, but they pay their workers an
Re: (Score:2)
You're right, everyone should switch to Oracle Linux.
Re:Bus factor strikes again (Score:5, Insightful)
Right, you were looking for a linux distro for your kids, and someone's political opinions aren't yours... You're looking for free open source software, and you're insulting someone who's done the work voluntarily, while you've never done *ANYTHING*.
You're no "nerd", you're just a selfish, stupid propaganda spreader who isn't even beng paid for your work.
Re: (Score:3)
Just install what you use. Maybe a different DE? or something.
Seems like a lot of work to go looking for a "childs OS"
Prolly just a nazi wanting to scream woke at something they don't like.
Re:Bus factor strikes again (Score:5, Informative)
Good luck making one unified operating system that addresses every possible concern. Even Microsoft had a fork in their path with the whole family of Windows CE / Windows Mobile / Windows RT / Windows Phone / Windows 10 Mobile. With varying degrees of sharing of the codebase between the NT family and CE family. As well as subtle variants to their own base desktop distro, such as Windows 7 Starter not supporting changing of the desktop background and being bundled with very few things. Breaking compatibility with some software that needed some DLLs or command-line utilities to function properly.
The reason stuff like Red Hat, SuSE, and Debian exist is because Slackware was too vanilla and the release schedule was erratic due to being understaffed.
The reason stuff like Gentoo and Arch exist is because making up-to-date packages for Red Hat is a real pain in the neck. Debian is no treat either, as there are a dozen different tool sets for making a deb depending mostly on personal preference.
The reason Alpine came into existance is to embed into stuff in a way that is not as special purpose and minimal as OpenWRT. And OpenWRT is/was quite chaotic of a distro to piece together for a target board. Making one image that runs in multiple places is a big value add. Alpine is also a complete distro, which in some ways makes is less suitable as a distro for embedded than something like Yocto. Yocto is more of a toolbox and process for cranking out a custom distro.
The real reason Alpine is still around is because it fits in neatly with container based workflows. It is tiny and starts up fast, and is often exactly what you need for a base container for some utility job on Docker/podman/Kubernetes. Especially in K8s where everything is a container, even if you want to run a shell script, you need to stuff that in a container. Alpine is very good at these short running maintenance jobs on a cluster. Yes, I know Red Hat and Ubuntu offer their own minimal base container. Some find those are still quite unwieldy and don't do anything more than what Alpine does.
Re: (Score:1)
Good luck making one unified operating system that addresses every possible concern.
Debian as close as anything I've seen.
Debian is no treat either, as there are a dozen different tool sets for making a deb depending mostly on personal preference.
You could just use whatever is currently documented as being current on the site, which I have always found to work.
The real reason Alpine is still around is because it fits in neatly with container based workflows.
https://github.com/bitnami/min... [github.com]
I actually run Devuan, but it's not very far from the tree. I've had to write (or source) some init scripts and such, but otherwise everything for Bullseye works on Chimaera.
Re: (Score:3)
I used to roll embedded Debian professionally. The tooling for packaging is certainly less painful now, but it's no where near as slick as Yocto (which can make deb through a sort of meta build system). And no where as easy to modify and build as Gentoo ebuild. Mostly the restriction I found with Debian in the embedded world is that a minimal installation was still too big. And once you start altering some base packages to make it fit, a lot of dependencies break and you end up rebuilding the distro from th
Re: (Score:1)
Yep, all those redundant package formats. I really don't see the reason for inventing a new one every time. In the early years, sure, dependency management was new, and Debian came along and fixed that. But since then?
I was just trying Alpine on the Raspberry Pi over the weekend, because Postmarket OS is based on Alpine, so I figured maybe they're onto something, and maybe there would be some advantage to having my Librem 5 be part of a network of devices with a compatible distro and architecture. But i
Was she paid or just volunteering? (Score:5, Insightful)
If that's the case, that's not really surprising (lots of OSS projects live from a single person efforts) but it's not a viable long term operational mode for any revenue critical project as Alpine is for container users.
Linux has made many strides into the corporate world by having the corporate suits ponying up part of the tab, and having people paid to work full time in open source projects of their interest.
And all the docker denizens benefitted by Alpine have an interest in having a replacement pronto.
Re: (Score:2)
Is there any reason to think Alpine can't keep up with maintaining the packages that have been added? If they are just able to merge fixes other people makes then the fact Alpine development slows down a bit is sad but doesn't really matter. More people will have to learn to fix or update packages, but that should be a good thing.
Small Linux trivia (Score:2)
1. Wikipedia handily has a table listing lightweight distributions. https://en.wikipedia.org/wiki/Light-weight_Linux_distribution [wikipedia.org]
2. Within that table, typically one will see the oldest processor supported is the 486. That's because it introduced the atomic CMPXCHG instruction, which Linux relies upon. I assume the one 386 OS listed, Tiny SliTaz, uses a workaround involving the XCHG instruction such as https://lists.freebsd.org/pipermail/freebsd-current/2009-April/005533.html [freebsd.org].
Re: (Score:2)
I began using linux with X display on a 386 around ~1990 with 12MB RAM. So Linux hasn't always relied on "the atomic CMPXCHG instruction" apparently. Linux never really supported 286 or 8086 although. 386 was always the minimum I believe. IIRC, 386 introduced on new pin on the CPU for an interrupt to be able to preempt a running process or something like that thus enabling proper preemptive multitasking.
Re: Small Linux trivia (Score:2)
Re: (Score:1)
My 386 only had 5 MB if memory serves (I think I started out with 2MB, it had 8 slots which had to be used 4 at a time, so then I got 4MB and had to remove 1MB). I put a couple of old 5.25" hard drives in it and used it as a server, after having gotten the shiny new 486 for my main machine. The 386 ran a web server on dialup for ecloud.org. I had an ISP that was letting me get away with it. All just for fun. I forgot whether I successfully ran X on the 386, but I'm sure I tried it. And I think I start
Re: (Score:2)
Re: (Score:2)
That's because the 386 had a memory management unit, which basically means the hardware supported "virtualized" memory. The memory addresses were contiguous and all of it was accessible. This is a really desirable hardware feature for linux systems, because conceptually, its not designed to account for the unique idiosyncrasies of every different hardware platform manufacturer. The CPUs before the 386, did not have a MMU. So they would have "banks" of memory sections, and you'd have to know what bank ju
Too many distributions (Score:2)
Damn, I didn't even know that Alpine Linux was an low memory use, embedded Linux distro until this Slashdot article.
Re: Too many distributions (Score:2)
Alpine is very common as a base for containers, and it is excellent for this. Outside of that, I haven't seen it used much.
Re: (Score:2)
I agree that there are too many distros, but Alpine serves a useful niche. It's not like one of the million Debian/Ubuntu/Arch repackage deals that could have just been created with an install script on those OSes.
Re: (Score:2)
Well, Alpine runs off musl, which hopefully means in theory that it can run on MMU-less chips. It also has implementations for ARM chips. Finally, it will even run LXDE, for those who can't live without a windowing manager. It does seem to run "fat" (128MB needed for install, according to wikipedia), but it also support netboots(!), which hopefully means it can be installed with much less required RAM, as well as the distribution run "in RAM".
Tinycore, by comparison, claims to install as little as 48MB.
38 commits a day (Score:2)
13,894 commits over the past year.
Obviously there's more to the story than that. They aren't making 38 unique feature / bug fixes a day, for 365 days in a row. I'm assuming this something like cherry picking fixes from upstream or something.
Re: (Score:2)
Having just stumbled into the area a few days ago, I would not be surprised if most of the work was about getting stuff to compile against musl libc. Which I guess, if you know what you are doing, might not be that difficult most of the time.
Re: (Score:2)
That's all there is to the story.
Sounds like the work of an algorithm (Score:2)
Without having sufficient interest to verify it, I'm guessing the vast majority of the commits are generated by a search and replace. Probably adding an #ifdef block.
Re: (Score:2)