Thoughts on the K1SS Distro

CarbonChauvinist · 2020-04-13 23:32:35

I've been tempted to try the K1SS distro lately. Has anyone else played around with this distro at all?

It seems interesting, and I know the primary developer behind it is quite young but already has authored a bunch of programs/tools a lot of people use (sowm, fff, pfetch, neofetch, pywall, etc. etc.)

Looking at some of the distro's "guidestones" there will have to be some changes in the future as/if it continues to grow I suppose...

There must always be a sole commander-in-chief in charge of the distribution. There must never be a below governance structure.

The number of packages in the repositories shall never exceed that which is maintainable by a single person with minimal effort.

Also, there appears to be a strong editorial decision for POSIX standards only and completely removing all of the following:

The following list of software must never make its way into the repositories as their inclusion will opens the floodgates for software which unoptionally depends on them.
* dbus, systemd, polkit, gettext, intltool, pulseaudio, pipewire, pam, wayland, logind, ConsoleKit, libsn, electron and all DEs.

While it seems interesting I'm a bit unsure if I align with it's overall ethos (okay, I don't at all). It's firmly planted in X and I love Wayland. The difference between musl and standard c libraries will not affect me in any way as a non developer. The rejection of systemd is fine on face, (though I'm a big systemd proponent) as I understand what that means from a use perspective going in. But like, not having PAM? (I guess less important if you're not using a DE?). IDK.

Also the refusal to support an initrd (though apparently he's now working on an init generator in POSIX sh) is... interesting?

Curious on others' thoughts?

Last edited by CarbonChauvinist (2020-04-13 23:34:31)

fukawi2 · 2020-04-14 00:33:03

Sounds like a great way for a person to send themselves insane trying to achieve that.

The following list of software must never make its way into the repositories as their inclusion will opens the floodgates for software which unoptionally depends on them.
* dbus, systemd, polkit, gettext, intltool, pulseaudio, pipewire, pam, wayland, logind, ConsoleKit, libsn, electron and all DEs.

Who is the target audience of a distro with such a restricted package base?

eschwartz · 2020-04-14 01:24:37

Banning gettext seems quite stupid. Does this mean the musl libc.so "gettext" symbol, or merely the development tools required to create software exhibiting message catalogs? If the latter, that would ban programs which require msgfmt at build time to turn source .po files into binary .mo files, as the libc gettext symbol needs the latter but the former is what you typically find in git repositories and distribution tarballs.

Is this about forbidding shell scripts which use the /usr/bin/gettext program due to the unavailability of invoking a C library function from bash? Most scripts I have seen which use gettext also check if gettext is available and otherwise define the no-op gettext() { printf "%s\n" "$@"; }

I guess this distribution hates people from non-English countries?

CarbonChauvinist · 2020-04-14 02:13:00

fukawi2 wrote:

Sounds like a great way for a person to send themselves insane trying to achieve that.
...
Who is the target audience of a distro with such a restricted package base?

These are my questions too. It does seem like they've taken a pretty deliberate stance on some of the more recent "hot button" issues that have cropped up in the Linux world:

K1SS Guidestone wrote:

There shall never be rules centred around speech or the way in which one must carry themselves to communicate. Do unto others as you would have them do unto you.

Which is maybe neither here nor there, I'm just uncomfortable with the thought those purposely controversial/divisive (and contrived) issues were the (or some of the) catalyt(s) for this distro - especially since they've taken stances I personally consider misguided.

Also I'm really against what appear to be very arbitrary restrictions on loc like these:

K1SS Guidestone wrote:

The package manager must not exceed 1000 lines of code. This number excludes blank lines and comments which make up around 50% of the program's current size.

eschwartz wrote:

Banning gettext seems quite stupid
...
I guess this distribution hates people from non-English countries?

It's illuminating reading your reaction and seeing the flow of the thought process. I'm assuming you haven't the skimmed the website yet, but sure enough your suspicion is spot on:

K1SS Guidestone wrote:

Only target the English language. English is the World Language. What we write our code in and what we use to communicate.

I also think it's interesting to me because one tends to associate for instance anti-systemd vehemence and a reverence for POSIX standard sh as being more of an older unix neck-beard type thing. The fact that this distro exists (which, with all due respect (sincerely) appears to be more of a personal love letter to F(L)OSS than a true "distro" right now at least in the traditional sense of things) and is driven by such a young core is ... unexpected.

It does seem like a true concern to be as portable as possible, though there is *one* exception so far:

K1SS Guidestone wrote:

All distribution tooling and shell code must be written in a portable way. Otherwise, the user will be locked into a single coreutils and shell.
One exception is made for 'sed -i' as it is too useful to let go of. The '-i' flag has rather good support across implementations regardless.

Trilby · 2020-04-14 02:34:59

fukawi2 wrote:

Who is the target audience of a distro with such a restricted package base?

Me.

Seriously. I'd never heard of this distro before, but I love everything about it except having to build *everything* from source ... I've got low-spec hardware.

It's basically the alpine system I have when I ditched openrc for my own simple init script. The only thing keeping me from running that full time now is that widevine is not available for musl.

While I'm not sold on a *distrubution* tossing aside services for non English locales, it's a no-brainer to do it on any given system. And I reject and resent the suggestion that it represents a hatred of speakers of other languages. This reminds me of Lennart Pottering being asked about some tool specifically to provide service only to visually impared people being hardwired into some part of systemd and required on every system: his response was "do you hate disabled people?". The fact that he was not being tongue-in-cheek or sarcastic about that was disturbing. I don't hate speakers of other languages or disabled people, or even people who use big DEs, but there's no reason for these things to be installed and running on MY computer when I don't speak other languages, can see just fine, and don't use a DE.

But given that from my perspective, this only really checks boxes already well checked by alpine, and alpine provides binary packages, I don't see any use for KISS for me.

Last edited by Trilby (2020-04-14 03:40:36)

CarbonChauvinist · 2020-04-14 03:01:14

Trilby wrote:

Seriously. I'd never heard of this distro before, but I love everything about it except having to build *everything* from source ... I've got low-spec hardware.

Believe it or not when posting this your avatar did run across my mind. I noticed you'd posted recently about considering other distros and I wondered if this was one.

Trilby wrote:

While I'm not sold on a *distrubution* tossing aside services for non English locales, it's a no-brainer to do it on any given system. And I reject and resent the suggestion that it represents a hatred of speakers of other languages.

I understand your point and agree overall with the sentiment, I think it's become more a turn of phrase on the internet and doesn't literally mean one thinks there is actual malice involved (your lennart example notwithstanding). And that's why, in reading about this initially anyway, it seems like an intensely personal project - really interested to see how this continues to develop.

--Edit:
Also, they've implemented the "alternatives" feature that is in the pipe line for pacman (or at the very least being discussed internally by Arch devs, I don't claim to know any further, lol).

Alternatives system
The package manager now includes an "alternatives system". This feature allows you to change the provider of a specific file or set of files.
For example, a user can now swap from busybox to the GNU coreutils by running a simple command.
This works in an entirely dynamic way and required zero changes to the package format or the repository files themselves! [1]
When a conflict is detected between another package during installation, the conflicting files become "choices" in the alternatives system.
Running kiss a or kiss alternatives will list all available choices that can be made.
-> kiss a
-> Alternatives:
ncurses /usr/bin/clear
ncurses /usr/bin/reset

Which I must say is pretty awesome and a feature I can't wait to have implemented in Arch. It's almost as if someone read the pacman write-up and instead implemented in this distro.

Last edited by CarbonChauvinist (2020-04-14 03:22:32)

eschwartz · 2020-04-14 03:15:38

    # NOTE: 'readelf' is used in place of 'file' as
    #       it allows us to remove 'file' from the
    #       core repositories altogether.

Later on it turns out the POSIX shell script used for both building and installing packages, is untar'ing packages to a temp dir, then making use of rsync --chown=root:root to merge those files into /. I would like to point out that the file utility is a base requirement of POSIX, it is not something wishy-washy like User Portability Utilities. rsync is definitely not in the POSIX manual, and given the practical requirement on tar for handling source archives, it seems like it should be possible to use that for extraction instead. Admittedly makepkg does require the fakeroot utility in order to fake permissions when generating the archive, whereas this rsync call just stomps all over the permissions by setting everything to be owned by root.

(I don't mean to cast doubt on rsync. rsync is a wonderful tool. But I am curious why it is necessary to fully purge a POSIX utility from the distribution, then bake the most comprehensively feature-laden file moving utility with literally all the knobs ever, into the "KISS" package manager.)

It then proceeds to do this:

    # Install the package again to fix any non-leftover files being
    # removed above.
    { pkg_rsync --; pkg_rsync --; } ||:

As a developer for a package manager myself, I am genuinely fascinated to learn what set of circumstances led to this being necessary. Installing the package 3 times to make sure it is properly installed?

Last edited by eschwartz (2020-04-14 03:20:26)

eschwartz · 2020-04-14 03:48:27

Trilby wrote:

While I'm not sold on a *distrubution* tossing aside services for non English locales, it's a no-brainer to do it on any given system. And I reject and resent the suggestion that it represents a hatred of speakers of other languages. This reminds me of Lennart Pottering being asked about some tool specifically to provide service only to visually impared people being hardwired into some part of systemd and required on every system: his response was "do you hate disabled people?". The fact that he was not being tongue-in-cheek or sarcastic about that was disturbing. I don't hate speakers of other languages or disabled people, or even people who use big DEs, but there's no reason for these things to be installed and running on MY computer when I don't speak other languages, can see just fine, and don't use a DE.

FWIW: I would generally consider it a reasonable goal to make something like this not "required", but stating that "such software must not under any circumstances be permitted to be packaged as an optional package" does indeed seem like hatred. It's not about making users be able to avoid something they don't personally need -- it's about saying users shouldn't be able to use it if they want to.

It's not clear where this line is drawn, either. This purity of intentions doesn't seem to extend to applying libc patches to strip out the {,dc,dcn,d,dn,n}gettext symbols, but having msgfmt available is forbidden? How consistently is this enforced, many programs ship with .gmo prebuilt files in autotools release tarballs, so those are probably getting installed even though, well, they're total wastes of space on English-only systems. (I have pacman.conf NoExtract rules to solve this problem for you!) But programs built with meson or cmake need to have the build system modified to make any install targets for .mo files become a no-op. https://github.com/mesonbuild/meson/com … 71ad216245

(This annoys me. Now I need to make projects which distribute translations do manual checks to ensure gettext is installed at build time, when the build system was advertised as doing things for you so you don't need to micromanage.)

Binary distros are the solution to this problem (the other solution being Gentoo USE flags and a configure switch to the build system), have the build system depend on msgfmt and generate packages which only care about the presence of the libc.so symbol and the presence of the distributed *.mo in /usr/share/locale/. And as I mentioned above, well-written shell scripts make gettext an optional runtime bonus with the one-liner `command -v gettext >/dev/null || gettext() { printf "%s\n" "$@"; }`.
The solution isn't "The distribution targets only the English language".

That's just flat-out saying people from non-English countries aren't welcome to be involved in the KISS community (such as it is).

It's the difference between Lennart saying if you disagree with systemd baking in "some tool specifically to provide service only to visually impared people" you must hate disabled people (???), and me saying if you don't have "some tool specifically to provide service only to visually impared people" available with a pacman -S foo away, you must hate disabled people.

I would be willing to be forgiving about it if the message being relayed was "lack of manpower, I encourage you to package it". This is clearly not the case. The KISS website states it as a philosophical sticking point.

Last edited by eschwartz (2020-04-14 04:05:50)

CarbonChauvinist · 2020-04-14 03:58:27

eschwartz wrote:

I am curious why it is necessary to fully purge a POSIX utility from the distribution, then bake the most comprehensively feature-laden file moving utility with literally all the knobs ever, into the "KISS" package manager.)

They do try to explain that they are curating which at times necessitates a choice

* Prefer less software over more software where possible. e.g If all a library does is make the cursor spin while waiting for a program to launch, it should be purged.
* Favour usability over ideals. If software B is simpler than software A but is missing essential functionality (for all users), software A shall be the default provider.

The information re: file and POSIX base specifications are interesting.

Interesting, here's someone who implemented their "tinyramfs" which can handle lvm and luks for use with K1SS.

Last edited by CarbonChauvinist (2020-04-14 04:26:53)

Head_on_a_Stick · 2020-04-14 11:41:18

I really like KISS, the focus on minimalism appeals to me. Shame about the source-based nature though, I've never managed to build a kernel myself that works on my laptop (lame, I know).

The testimonials page is particularly epic, for example:

Just as I thought. No actual simplicity, just some neckbeards complaining about software evolving in the last 20 years.

The one thing that really bugs me though is this line in the style guide:

Use 4 spaces for indentation.

Wtf? Surely everybody knows that 3 spaces are $DEITY's own indentation method

eschwartz wrote:

I would like to point out that the file utility is a base requirement of POSIX

AFAICT Dylan has no particular focus on POSIX-compliance, he just prefers using POSIX scripts for portability reasons.

Trilby · 2020-04-14 12:48:59

eschwartz wrote:

The solution isn't "The distribution targets only the English language".
That's just flat-out saying people from non-English countries aren't welcome to be involved in the KISS community (such as it is).

First, I cannot and would not defend the author of KISS, but here I don't think your argument holds water. No project can be everything for everybody. I think it's good to define a project's purpose and intended audience and stick to it.

In fact, there is a well known project that includes the following in their wiki:

The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.

That's just flat out saying people with no linux experience and without a do-it-yourself attitude aren't welcome to be involved in the Arch community (such as it is).

And this would be an accurate statement. Such people are quickly shown the door, and for good reason. There's nothing wrong with that. This is a good thing.

The owner of a Big And Tall store does not need to hate fit people. Nor does he need to see them as undeserving of clothes. But it's simply not his goal nor responsibility to provide clothes for fit people. And an athletic association confronting the owner of the Big And Tall store for discriminating against them would be laughed off any stage they got on to. The Big And Tall store owner provides products to a certain group of people. There is no hatred, not uncivil exclusion, just simply a defined purpose.

While not allowing certain options does seem heavy handed, it's often necessary. There are countless examples (even just within arch) where some optional feature that many users would not want simply became so popular that countless other package started depending on it resulting in that "optional" offering that just happened to be in the repo if someone wanted it now becomes a de-facto requirement. A heavy-handed dictatorial statement on what will never be allowed staves off feature creep.

Just like the Big And Tall store owner might be pressured to offer some choice. Why not offer those new slim-fit suit coats, they're so popular. So they put some on the rack. And because they are popular, they sell like hotcackes. And the store starts selling more and more slim-fit which crowds out their previous wares (wearable wares). Soon enough, the large people have just as much trouble finding clothes at the Big And Tall store as they did everywhere else.

Drawing a philosophical line in the sand can be protection against the tyranny of the majority, or of the popular.

Last edited by Trilby (2020-04-14 13:07:16)

CarbonChauvinist · 2020-04-14 22:29:00

Head_on_a_Stick wrote:

Shame about the source-based nature though

Agreed.

Head_on_a_Stick wrote:

The testimonials page is particularly epic

Indeed, along with this gem...

K1SS Testimonial wrote:

Ok, what’s your point. You have have musl and libc on a system. Not to mention the developer of [K1SS] is a outspoken anti systemd fud spreader.

As you can see from this picture on their site, this is something that cut them to the bone, lol...

Head_on_a_Stick · 2020-04-15 16:59:45

Dylan is now selling those t-shirts: https://teespring.com/stores/k1ss

I do like his attitude. And his MG :-)

kilix · 2020-07-06 11:11:37

Hello,

Anybody actually tried to use it? I am very curious, if I have time I might give it a spin (maybe just in VM). I am curious about any experiences, there is no K1SS linux review or something like that on the internet.

Comrade_Stalin · 2021-03-05 23:48:16

I'd love to check it out but it looks like the website is down

Scimmia · 2021-03-06 00:03:50

If you'd stop digging up and bumping old threads, you probably wouldn't run into this. It's almost a year later, the distro could very easily be gone.

twobooks · 2021-03-06 01:37:22

for those who dislikes systemd, artixlinux.org is the way to go.
I've been using artix for about a year.
I don't really know much about the difference, but with OpenRC I feel everything is under my control

Last edited by twobooks (2021-03-06 01:41:55)

GaKu999 · 2021-03-06 06:06:35

twobooks wrote:

I don't really know much about the difference, but with OpenRC I feel everything is under my control

I don’t really know about the difference, but when I punch the bits directly into the hard drive I feel everything is under my control...

Tbh that is a weird argument against systemd.

Still how long did K1SS lasted? They can’t blame it on the name like Yggdrasil.

fukawi2 · 2021-03-09 00:52:58

Well the website for the original discussion topic appears to be MIA; I think this thread has run it's course on the Arch Linux forums.

Closing.

Arch Linux

#1 2020-04-13 23:32:35

Thoughts on the K1SS Distro

#2 2020-04-14 00:33:03

Re: Thoughts on the K1SS Distro

#3 2020-04-14 01:24:37

Re: Thoughts on the K1SS Distro

#4 2020-04-14 02:13:00

Re: Thoughts on the K1SS Distro

#5 2020-04-14 02:34:59

Re: Thoughts on the K1SS Distro

#6 2020-04-14 03:01:14

Re: Thoughts on the K1SS Distro

#7 2020-04-14 03:15:38

Re: Thoughts on the K1SS Distro

#8 2020-04-14 03:48:27

Re: Thoughts on the K1SS Distro

#9 2020-04-14 03:58:27

Re: Thoughts on the K1SS Distro

#10 2020-04-14 11:41:18

Re: Thoughts on the K1SS Distro

#11 2020-04-14 12:48:59

Re: Thoughts on the K1SS Distro

#12 2020-04-14 22:29:00

Re: Thoughts on the K1SS Distro

#13 2020-04-15 16:59:45

Re: Thoughts on the K1SS Distro

#14 2020-07-06 11:11:37

Re: Thoughts on the K1SS Distro

#15 2021-03-05 23:48:16

Re: Thoughts on the K1SS Distro

#16 2021-03-06 00:03:50

Re: Thoughts on the K1SS Distro

#17 2021-03-06 01:37:22

Re: Thoughts on the K1SS Distro

#18 2021-03-06 06:06:35

Re: Thoughts on the K1SS Distro

#19 2021-03-09 00:52:58

Re: Thoughts on the K1SS Distro

Board footer