Musl Distros - GNU/Linux
xikuuky
Hey guys! I really like Musl but I'm having trouble finding good distros that support it. I really liked Alpine but I can't get it to boot. Any ideas? I would prefer stable distros but if a experimental distro is stable enough that's okay too. Can Crux be a Musl system?

Thanks! - Xikuuky
xikuuky
UPDATE: I think I am going to make a distro that fulfills my needs. It will probably run inside another system using Busybox/Toybox and Musl. Maybe with something like (B,C,H)LFS?
Houseoftea
(27-12-2015, 06:02 AM)xikuuky Wrote: make a distro

Keep us updated also please see the thread: https://nixers.net/showthread.php?tid=1741
There are others doing similar things to you, I know z3bra posted in the other 'smallest distro' thread but he was messing around with musl and the like, you should talk to him about this.

Thought I should add this:

http://wiki.musl-libc.org/wiki/Projects_using_musl

List of all the projects using musl, lots of distros on there you can pull inspiration from
sth
void! stable, rolling release, actively developed, musl-flavor.

https://voidlinux.eu
z3bra
Alpine is not experimental, it's definitely stable (My personnal server runs alpine, and I never ran into a problem.
Voidlinux has a musl flavor as sth said.

For crux, musl isn't supported, and if you go down this route, you will certainely have to patch a bunch of softwares.
xikuuky
(27-12-2015, 01:41 PM)sth Wrote: void! stable, rolling release, actively developed, musl-flavor.

https://voidlinux.eu
I already use Void. A bunch of the packages on it can be jokes for Musl, I build everything by hand.
(28-12-2015, 04:22 AM)z3bra Wrote: Alpine is not experimental, it's definitely stable (My personnal server runs alpine, and I never ran into a problem.
Voidlinux has a musl flavor as sth said.

For crux, musl isn't supported, and if you go down this route, you will certainely have to patch a bunch of softwares.
Alpine does not like install medium (a very old 16GB drive and I have no CD drive or CD's.
(27-12-2015, 12:55 PM)Houseoftea Wrote: Keep us updated also please see the thread: https://nixers.net/showthread.php?tid=1741
There are others doing similar things to you, I know z3bra posted in the other 'smallest distro' thread but he was messing around with musl and the like, you should talk to him about this.
Thought I should add this:

http://wiki.musl-libc.org/wiki/Projects_using_musl

List of all the projects using musl, lots of distros on there you can pull inspiration from
I can do that! :) I'll look at that.

Here, an update.
==================

Looked at many proejects that use or will use musl plus a lot of lightweight distros and I have a bit of a idea on how I will accomplish this. I'm going to try LFS then BLFS, and eventually ALFS (unless people can just install from what I give them [doubt it but possible]).

For packages I will supply a package manager I wrote myself that builds packages from git using shell scripts. It is a less flexible system but it works for what I'll do. We are going to probably be 64bit exclusive (sorry ARM, x86, and MIPS users). If it isn't hard to cross compile, I may add x86. I'll have the base system preinstalled hopefully and I'll hopefully be able to update it with ease. Make + autotools will install, uninstall, and configure software. The package manager runs on Git and Make so it works perfectly. Users will have a .software or .packages or ~/Code/Soft(ware) area that holds the source of the packages. I'd like feedback. Thank you!

Also, I'll include Toy/Busybox hopefully and have bash and zsh installed by default and scripts already on the machine to build things like Python, Python2, Vim, and the such. :)

I looked at Solyste and I like the idea of mksh as the default shell. In my experience that is very fast. Also, how hard is it to compile X?
z3bra
xikuuky Wrote:For packages I will supply a package manager I wrote myself that builds packages from git using shell scripts. It is a less flexible system but it works for what I'll do.

"Wrote"? Did you write anything yet? 'cause I'd be interrested in reading what you've done so far. I'm currently working on a package manager myself I already have a "working" solution using shell script, but I'm not satisfied with it, so I'm rewriting everything from scratch in C, focusing on different concepts.

xikuuky Wrote:We are going to probably be 64bit exclusive (sorry ARM, x86, and MIPS users). If it isn't hard to cross compile, I may add x86.

x86 is a CPU architecture, which uses either 32 or 64bits. So you're probably opposing x86_64 to x86 there. Beware the wording is such a pedantic forum ;)

xikuuky Wrote:I'll have the base system preinstalled hopefully and I'll hopefully be able to update it with ease. Make + autotools will install, uninstall, and configure software. The package manager runs on Git and Make so it works perfectly. Users will have a .software or .packages or ~/Code/Soft(ware) area that holds the source of the packages. I'd like feedback. Thank you!

It's the simplest way to go indeed, and if softwares were done properly, we wouldn't need package managers. The problem is that not all software use a makefile, and even if they do, not many propose the "uninstall" target.
This is why package manager were created in the first place, they track files intalled by each package, and allow the user to easily remove/update them. It later handled package dependency, which became an issue when dynamic linking started to kick off.

You should take a look at how other people solved those problems. here are a few links to get you started:
xikuuky Wrote:Also, I'll include Toy/Busybox hopefully and have bash and zsh installed by default and scripts already on the machine to build things like Python, Python2, Vim, and the such. :)

Choosing the default set of packages is always a hard task ;)
I'd personally go with the bare minimum: init, device manager, shell, coreutils, netutils and that's all. I'll certainely have to add the package manager and curl to the live usb though, to make bootstraping easier.

xikuuky Wrote:how hard is it to compile X?

really hard if you need to package everything yourself.
xikuuky
(28-12-2015, 08:46 AM)z3bra Wrote: "Wrote"? Did you write anything yet? 'cause I'd be interrested in reading what you've done so far. I'm currently working on a package manager myself I already have a "working" solution using shell script, but I'm not satisfied with it, so I'm rewriting everything from scratch in C, focusing on different concepts.
Sadly the code is gone but it just downloaded a script and executed it line for line. I found a way to easily uninstall stuff with make. Just type make -n install and it tells you what stuff will be modified. Maybe I'll go without a package manager or I'll just get something like emerge on here(go ports! :) ). I really like just compiling everything.
(28-12-2015, 08:46 AM)z3bra Wrote: x86 is a CPU architecture, which uses either 32 or 64bits. So you're probably opposing x86_64 to x86 there. Beware the wording is such a pedantic forum ;)
Thank you so much! Now I won't look like an idiot. o/ :)
(28-12-2015, 08:46 AM)z3bra Wrote: It's the simplest way to go indeed, and if softwares were done properly, we wouldn't need package managers. The problem is that not all software use a makefile, and even if they do, not many propose the "uninstall" target.
This is why package manager were created in the first place, they track files intalled by each package, and allow the user to easily remove/update them. It later handled package dependency, which became an issue when dynamic linking started to kick off.

You should take a look at how other people solved those problems. here are a few links to get you started:
I'll definitely go through this list. Thank you so much buddy! :) I'm new to C[++,go] and the such (I can read it just fine) so it would be a big deal if you would read my source code for me. I want to use a compiled language for speed (Python is fast but C can be faster).
(28-12-2015, 08:46 AM)z3bra Wrote: Choosing the default set of packages is always a hard task ;)
I'd personally go with the bare minimum: init, device manager, shell, coreutils, netutils and that's all. I'll certainely have to add the package manager and curl to the live usb though, to make bootstraping easier.
I think I'll do bare minimum plus a little extra. :) Extra being a few shells and make, autotools, and musl. What is typically in netutils? What if I made the package manager the user's choice to install? I've seen installs like that (I once made a Ubuntu install use Emerge XD). I might include curl but then again, wget is a core package in both busybox/toybox. I use Curl personally but Wget is very popular.
As for init, I see the big options as: SystemD (not happening), OpenRC (I'm open to it), or Runit (my favorite). This is my distro so if I want to add Runit I can right? This is meant to be for my needs (and anyone with needs similar to mine).
(28-12-2015, 08:46 AM)z3bra Wrote: really hard if you need to package everything yourself.
I am not packaging X. Packages, or even a package manager will (possibly) be left to the package manager the user installs.

UPDATE:
========
Elder Scrolls Online is still downloading. It is almost done so I'll hopefully get to boot into Linux tomorrow/tonight GMT+7 (Jakarta).
Decisions:
Init (Runit or OpenRC)
Minimal Core Utils (Busybox or Toybox)
?Package Manager? (user choice or I write one or I include one)

That's all.
Houseoftea
Init (Runit or OpenRC) :: runit
Minimal Core Utils (Busybox or Toybox) :: toybox
?Package Manager? :: packlim
z3bra
OpenRC is indeed a shitty service manager. I really can't see the hype behind it. The fact it's used in gentoo doesn't make it a good system, more people should understand this. Runit on the other hand implements way more good practices, even though some people reported issues with it when dealing with systems with a lot of services (especially with service restarting/failure detection).

For the core utils, you neither busybox nor toybox are POSIX compliant, making them poor alternatives to coreutils which is POSIX-compliant (but adds a shiton of useless/bloated features on top of their utils, making them unreliable and bug-prone).
There is the suckless base which is fairly good and POSIX-compliant. They also provide a way to build a sbase-box binary if that's what you really want.

Regarding the package manager, packlim is indeed fairly interresting, but I don't know how one would integrate it in another project than rlsd2.
I like the way it handle packages though. This result in a really simple format for packages, and it even has package signing.
I don't understand much why the author added a TCL interface though.
There is also no documentation for the build system, which seems interresting, but makes use of many different technologies, resulting in a big mess to me (makefile, shell scripts, TCL, json, ...).




Members  |  Stats  |  Night Mode  |  Help