I have this simple question.
You have distro X, and you would like to change something and give it a new way / philosophy or whatever. Which one would it be?

For example, if I had to fork a distribution (not now, but someday) would be Lunar Linux.
I really love it. But I would do some changes:
A) No more systemd. Maybe sysvinit or even Busybox init.
B) Builds on home.

That's it. Sorry for my english :P

Lunar looks interesting. So it is basically a source-based discontinued distribution with a new package manager.

I probably wouldn't fork any distribution, Void is pretty nice, as well as OpenBSD and 9front. I can imagine contributing to 9front some day (if I am deemed acceptable by the lead developers).

(09-01-2017, 07:44 AM)pranomostro Wrote: Lunar looks interesting. So it is basically a source-based discontinued distribution with a new package manager.

Lunar is still maintained. Btw, isn't really a famous distribution, and doesn't have an active community.

I would fork TENS - Trusted End Node Security (linux distro provided by the DoD and the Air Force Research Lab, with a file encryption wizard, pdf reader, web browser, and mail client built in, and drivers/setting preconfigured to be able to use a smart card reader for CAC login on .mil websites, and a VPN client)

https://www.spi.dod.mil/lipose.htm

I would add office software (likely libreoffice), switch the WM to openbox, add an installer (right now, it's intented to be ran live from USB, no installer provided), and start a campaign to have the new distro ("Air Force Linux", as I would call it) replace Windows 10 on the average Air Force users' desktop.


Edit: It already has libreoffice, whoops.

I would fork Slackware and replace the horrible kernel by something that works.

(09-01-2017, 03:08 PM)jkl Wrote: I would fork Slackware and replace the horrible kernel by something that works.

Amen brother.

I would fork Void Linux and change the package manager to pacman or apk (from Alpine Linux). When I first read about Void Linux, I was so excited, but I found the package-manager so counter-intuitive, from what I was used to, that I ditched very fast. Writing this, I think, I should give void another try, maybe today the documentation is more accessible for me :)

I'd fork crux, for the simplicity of it's base system/service handling and port syntax. I'd use either apk from alpine, or my own pack manager when it will be ready.

(09-01-2017, 03:08 PM)jkl Wrote: I would fork Slackware and replace the horrible kernel by something that works.

I used Slackware as my main distro some time ago.
My experience:
5 minutes booting. 20 minutes compiling stuff from Slackbuilds. 10 minutes using those.
And that in a fast day.

(09-01-2017, 03:39 PM)asyncial Wrote: I would fork Void Linux and change the package manager to pacman or apk (from Alpine Linux). When I first read about Void Linux, I was so excited, but I found the package-manager so counter-intuitive, from what I was used to, that I ditched very fast. Writing this, I think, I should give void another try, maybe today the documentation is more accessible for me :)

(10-01-2017, 07:20 AM)z3bra Wrote: I'd fork crux, for the simplicity of it's base system/service handling and port syntax. I'd use either apk from alpine, or my own pack manager when it will be ready.

As a guy who never tried Alpine, what makes APK good?

(10-01-2017, 07:59 AM)Mrat Wrote: As a guy who never tried Alpine, what makes APK good?

It's simplicity. If you've never used it, all you need to understand it is one command. From there, all other commands make sense:


A statically compiled version of the binary is available to bootstrap alpine, and it's really all you need.
It is simple, has sane default and does whatever you'd expect from a pack manager, without getting in your way. No need to learn it, read the docs or whatever.

(10-01-2017, 10:56 AM)z3bra Wrote:

(10-01-2017, 07:59 AM)Mrat Wrote: As a guy who never tried Alpine, what makes APK good?

It's simplicity. If you've never used it, all you need to understand it is one command. From there, all other commands make sense:

Code:

apk add apache
apk del coreutils
apk search busybox
apk update
apk upgrade
...

A statically compiled version of the binary is available to bootstrap alpine, and it's really all you need.
It is simple, has sane default and does whatever you'd expect from a pack manager, without getting in your way. No need to learn it, read the docs or whatever.

It's similar to the new package manager on FreeBSD (I'm using it now).

Also, NetBSD's pkgin.

(10-01-2017, 07:20 AM)z3bra Wrote: I'd fork crux, for the simplicity of it's base system/service handling and port syntax. I'd use either apk from alpine, or my own pack manager when it will be ready.

agreed. the weak packaging system although its heart is in the right place is outdated now. i'd probably change the default init too.

(12-01-2017, 10:00 AM)Wildefyr Wrote:

Quote:I'd fork crux, for the simplicity of it's base system/service handling and port syntax. I'd use either apk from alpine, or my own pack manager when it will be ready.

agreed. the weak packaging system although its heart is in the right place is outdated now. i'd probably change the default init too.

Don't get me wrong, I'd keep the port system exactly like it is. I'd simply add apk on top of that, to add a "binary dimension" to the distro. As for the init system, well, it doesn't get in the way at all, so it's fine too me.

As others have said I dont think that I would fork any distribution right out. OpenBSD fits my needs quite well and I have been using it for a year and half or so now. If I had to say I would probably try and write my own package manager that focused on simplicity as an excercise and build it up ontop of Crux.

Thats my $0.02

Slackware :) I used a lot for desktop and servers, so its comfortable to fork.

I would not mind creating a lightweight desktop distribution for i386 and PowerPC based on Sabotage Linux. Ideally, it should provide a preconfigured fvwm or icewm desktop.

I'd fork debian. Technically, my installation already have several properties of a fork...
But what would I change?

* better integration of runit and svlogd, to allow getting rid of sysVinit and rc.d remains and benefit from logs in their own places by default (stuff I already have and just takes me, like, 3 minutes to do per daemon, but still);
* dodge the usrmerge bullshit: this change is due *only* because systemd is unable to properly handle mountpoints, which a lot of bug reports on the topic can be found (notably encrypted or network file systems create problems apparently);
* make the source builds easier. Right now, debian uses a pretty complicated and "rich" stack, mixing autotools, perl, python, bash, patch, and whatnot. I think there is no reason for a build mechanics to integrate all this, really. All one should do is rely on upstream's build system, take the *output* instead of messing with options, and build a set of packages from it...
* reduce the usage of pre/post inst/rm in packages. This is mostly done so that packages may support various configurations (and notably init systems) but really there is no need for scripting. Instead, avoiding automatic enabling of services at boot, and eventually move those files in a dedicated package. I suspect this way, minor patches would enable dpkg to install things in user's homedir.
* ban gtk4 and all applications depending on it. Purely and entirely. Gtk3 is still tolerable, gtk4 is not.
* maybe try to migrate to muslC, as this have a huge impact on memory usage. IIRC, we're talking about ~700KiB per process, here. Varying depending on random parameters (and thus between each launch of the same process), because glibc. I.e. `ps` reports that I have no `runsv` process taking less than 772KiB RSS, while using a statically linked or musl, it is exactly 4KiB, the minimum. That means that glibc allocates *a lot* of memory for nothing. May not be a problem on servers or personal computers, but for embedded systems, it's a lot less nice. My systems are relatively lightweight, only 30+ services running around. The total amount of wasted memory is far from negligible, when compared to the overall resource usage of my system. I'm not ecologist, but this kind of resource waste annoys me a lot. And for those who wonder, when I measured systemd's rss usage a whille ago, it was around 30megs, not changing much if adding or removing services.

There are probably some other things I'd change, but those are really the big spots. Ofc, I'd also change the installer, the one I remember is a huge bad joke, almost if done by someone out of spite because tired of reading it was hard to install. The thing forces the operator to stay close to computer by asking a question, doing something, asking next question, etc, except that "doing something" may very well take quite a time, and that questions are never really depending on the success or result of last operation: do you really need to have your partititions done to select what you want to install? Nope. That is just one example, of course.

freem: Sounds like you want to make Debian Void.

(09-01-2025, 10:12 PM)jkl Wrote: freem: Sounds like you want to make Debian Void.

Well, no, because void's integration of runit was bad when I tried it, and their package system is not good neither. Dpkg have features such as the "recommends" for example, which are very handy. It's database (in /var/lib/dpkg) is in a format readable by both humans and machines, unlike void's xml thing. Tooling is also more developed, I notably like aptitude's ncurses interface a lot, because no, I can not manage 150000 packages with just CLI tools. Or rather, I can, but it takes 10 times more efforts, so it sucks.
Note that if void's database was in a sane format, I would have tinkered a TUI script with dialog or perhaps even in C++ directly to handle this lack, but XML... no, thanks. Really no.
Oh, and, ofc, I do not exactly enjoy rolling release.

The only good thing about voidlinux is really that it have a muslC build, in the end. I would be more likely to move toward alpine linux, in that regard, seems much simpler (from a technical point of view).