Next steps for Mere Linux

[jhuntwork]

Hello All,

This is an open request for comment. I'm considering the next major steps for Mere Linux and here are my current thoughts:

1. Make the system more generally usable. Up to now, most of the publicly available resources have been conceptual and usability has been limited to very specific use cases. I believe there is room and interest to move to a more stable implementation that is immediately usable. To that end, I think some of the more experimental ideas I had in mind for the project are best put to the side to focus on stability. More on that later.
2. Add bare-metal and possibly desktop support. Admittedly, this goes against some of the core principles I outlined in the current documentation. But there is surprising interest in the use case, especially among those who would prefer a non-systemd distribution. I am uncertain at this point how this would look, but I am open to input. Definitely I would want to continue to make simplicity and minimalism a primay goal.s
3. Switch to LLVM/clang over gcc/binutils as the main compiler and linker for the system toolchain. LLVM seems to be both more standards-compliant and forward-looking than the GNU counterparts, and in my testing I have had good success.
4. Consider a new package manager. These are the experimental ideas I was referring to in the first point. pacman is great, but there are challenges to both local development and long-term dependency management that I feel might be solved by a different package manager. I began exploring some of these ideas in the mere project, but there are still a lot of open questions and heading down this path exclusively would derail efforts to make this project stable and usable. If anyone is interested in the specifics, I'll open up another thread to discuss the current design ideas.

Beyond the above, I'm open to hearing from any of you how Mere might be useful or interesting to you, and how best to shape its next steps.

Thanks!

JH

[subnut]

My thoughts on the above -

2. Ah, yes. The very first line of the documentation, and I missed it 🤦.
   Well, maybe we can keep this distro container-focused, and start a similar distro for general use cases? 🤷
3. perfect! 👍
4. KISS package manager of KISS Linux may be of interest to you. It is very flexible. It has concepts like installing to a separate root and installing packages as a general user.

[jhuntwork]

I believe extending support for alternative cases is fine for now, especially if we keep the core design decisions focused on the places where Linux shines the brightest. I have already done a fair amount to extend it for my own personal machines, so taking the next step shouldn't be too bad. We can always re-evaluate as needed in the future.

Thanks for the pointer towards KISS. Definitely looks interesting. I think to keep forward momentum, it would probably be best to stick with pacman for now, but I would like to revisit some packaging concepts in the future. I am especially interested in the idea of package immutability and in cases where dynamic linking is required, using explicit version dependencies.

[jhuntwork]

The basic system toolchain has just been updated to the latest version of musl and to use llvm as the compiler and linker. From here, my next plan of action is:

1. Go through and review all existing packages, either upgrading them if necessary, or removing the package if no longer used. I've heard reports of incorrectly linked packages still in the stable repo. Mostly these are leftovers from experimenting with libz vs zlib. This should uncover and resolve those.
2. Add support for modules and an initrd in the kernel. This should make it more usable on bare metal.
3. Provide very basic install instructions for bare metal. Start small, we can automate parts and improve it over time.
4. Document how I currently develop locally so others may do the same/similar.
5. Sync the testing repo to stable as a new release.
6. Begin a process/discussion on how to add in desktop support, including what sorts of packages to officially support.

[lufv]

I think you should add all these points into projects to keep track of them all easily.

[jhuntwork]

Thanks @lufv. Nice idea. I have had the habit of working offline, alone, but that won't work well going forward. I'll experiment a little with the projects feature.

[lufv]

I'd really love to use this as a desktop. There are a few really good musl Linuxes, but taking it even further to clang and LLVM as main compiler toolchain would be awesome. I've seen one or two clang distros as well but they've failed because of too little interest in contributing. You already have few people on here so I'm really positive about this one though.

Also I've read in docs that you're aiming for statically linked binaries. I guess this is good for server-oriented distro as you planned but as for desktop, it could actually be a real pain having to recompile binaries every time some library has an update. As for me, I'd like to have it dynamically linked for a desktop, I'm not really sure about servers though.

Your distro kinda reassembles Alpine Linux to me. Alpine is technically server-oriented but it's perfectly usable as a desktop and provides a lot of desktop packages that are already compiled for musl libc. If Mere Linux is willing to kind of get inspired by Alpine and pushing it further with clang, that would be the best idea in my opinion.

Anyway, thank you for your work on this project. I'm looking forward to see how this develops in future and also to contribute in some way.

[jhuntwork]

Nice feedback @lufv, thank you!

In the testing repo, clang and LLVM already works well and does indeed seem promising. I'm anxious to get those ready for pushing to the stable repository.

Regarding static vs dynamic, I think generally I agree. Mere started out oriented around servers and containers. Even before Alpine really took off, Mere was starting to take shape around those goals. Unfortunately, I didn't have the bandwidth or help to take it to the level that Alpine quickly progressed to. But you are absolutely correct, there are a lot of good ideas and patterns in Alpine, and I'm happy to learn from them.

I've started building some desktop components, and you're right, the sheer number of libraries and dependencies will make maintenance a heavier burden if everything is strictly built statically. However, I do still like having a core set of tools and utilities statically compiled, so that if you want a very minimal server or container, those core components will make it clean, simple and even portable.

Taking on the extra use case of a desktop system will certainly require some adjusted thought. I will start trying to organize better here some roadmaps/plans for how to approach filling out the desktop support, and I am definitely open to specific ideas about how to approach it. Even recommendations for specific software, window managers, etc are welcome.

[fungilife]

I think if you consider expanding the horizon towards even a single window manager and a few basic tools, it might be helpful to align mere policy with either arch (pacman pkgbuilds readily available) or void (due to musl based system and their work). To support X amount of X toys and candy and keep chasing upstream runners will be futile, and you would have to quit your day job. :) Look at Obarun, they have about 30-40 pkgs of their own creation to maintain, and another 100-120 of arch's packages that needed de-systemd-ization. It is a constant chase with tongue hanging out ... trying to keep up. But it is a distro with 20-30k packages available, because of Arch. It took artix 3 years, their maintainers team is in double digits I believe, and by employing the dreaded elogind and other systemd parts (esysusers etmpfiles) their job is much easier than obarun. But after 3 years they were able to drop arch repositories, or leave it up to the user to decide.

If you want to provide support for someone's plasma brightness adjuster not working, go right ahead :) .... not to say their telemetry not functioning properly (kuserfeedback) SCARY !!!

[jhuntwork]

Yeah, definitely good points. I certainly won't be able to grow this and maintain it alone. Aligning with another project is interesting, but obviously has consequences. For example, while aligning with Arch would open us up to a huge amount of available packages to build, it would also mean adjusting some of the fundamental policies. I believe they don't actually do much -dev package splitting, right? And it would lock us into pacman for the long-term. I'm not familiar enough with void to understand the impact of aligning with them. Anyway, definitely good food for thought, and I'm interested in hearing opinions. There are a few, rather impactful decisions like this that could/should be taken now as the project starts to get some momentum.

[jhuntwork]

Going back to what @lufv mentioned: aligning with Alpine may also interesting.

[jhuntwork]

Update: The first project here https://github.com/jhuntwork/merelinux/projects/1 has been closed. The testing repository was promoted to the new core repository, and new Docker images for mere/base and mere/dev have been built and pushed. I believe the core system is stable enough now to move on to other, new features, like full desktop support. I'll create a new project to track the work of building out a first, basic version of desktop features, and interested parties can begin drafting issues to put in the project.

In the meantime, I'll be working on the following, somewhat unrelated items:

• Add install instructions. There will be a usable raw disk image and an iso that could be used as starting points, though both can use some additional instructions.
• Set up a mailing list server. I think there's quite a few that are comfortable with that form of communication, so I'll add something as soon as I can.

[jhuntwork]

Issues #362 and #10 respectively

[jhuntwork]

Update: I have added a post to the new mailing list, here: https://lists.merelinux.org/core/0003.html

The short summary is that I believe Mere should begin making itself compatible with Arch Linux recipes and make it easier to build those in a Mere system, while keeping its fundamental differences, e.g., musl, s6, llvm/clang and busybox.

Feel free to respond here if you have a comment and Github is easier, although I would prefer if you subscribe to the list and add your reply there.

[jhuntwork]

Lots of thought and discussions later... unfortunately kind of back-tracking on that decision. The thread has more details, but overall I think it would fundamentally change Mere too much.

In the meantime, locally I have gotten a more complete desktop setup with Wayland, sway, greetd/gtkgreet and firefox, and of course all their dependencies. I'll begin adding those package definitions soon.