> The distribution is designed to be maintainable by a single person. There is no infrastructure and the entire distribution is merely a few Git repositories.
A very clever approach, mirroring the way FreeBSD, OpenBSD have traditionally managed their core competencies.
I am a lifelong Debian fan but it has always troubled me that I can’t check out a copy of the OS’s metadata — that which is packaged in all of the DSC files or `debian/` directories — in one place.
A monorepo containing all of your business logic is a successful tactic to getting things done. There are some great pieces of behind-the-scenes Debian infra to support this — with SVN, and later git, and internal projects like Alioth — but the first class citizen of the project is still a deb-src apt entry. Inherently a one way HTTP link from the vendor to me with only a published Changelog to track changes. A solid and stable technology for a venerable project, but git-log / git-blame it ain’t.
(Of course, the success of giant open source projects and especially Debian is often because there is no central coordination. The technical and other committees were social constructs to try to keep everyone on track. Do they still function well?)
Bus factor is usually defined as the minimum number of team members that have to be hit by a bus to put the project in jeopardy. The Wikipedia article linked from the site defines it the same way.
So a bus factor of zero would mean that the project is in jeopardy even if all the maintainers are alive.
> There is a rare alternative definition for the bus factor, namely: the number of people who are indispensable for the project.[2] In other words, it is the minimum number of people who are a single point of failure. If using this definition, then a high bus factor is considered a bad thing (since the loss of any person included destroys the project), and zero is considered the ideal bus factor.
I wish they didn’t just take the well established name of a principle and re use it in their distro-name. As much as I appreciate this initiative I think they should consider the importance of naming and branding. An original product should have an original name.
Yeah, distributions often have really crap branding. Eg finding relevant resources for NixOS can be tough because "nix" is often used as a shorthand for the set of all Unix-like systems.
The packageformat is entirely static. A series of plain-text files with fields separated by lines and spaces. Easily parseable via any programming language or with basic UNIX utilities.
And you have to write parsers for it which is PITA even if it's very simple.
Please just stick to well-known formats (even if you don't like them) and make your fellow developers life easier! For example, everyone hates YAML for one reason or another, but if you use it, you are using a format everyone is familiar with it. We know it's terrible quirks, but still well known and every language has parsers for it.
1. There is not a single YAML format. Different parsers support varying formats and specs.
2. YAML is a terrible format for everyone. Even if you don't hate it, you can still fall prey to its poor design and not even know about it until it blows up later. A package manager is especially not somewhere you want such latent bugs.
3. Not everybody knows its terrible quirks. I'd used YAML for years, and was still surprised when I read strictyaml.org's (limited) list of documented bugs in YAML.
4. YAML isn't even the first or most-popular well-known format. So, if you're going to advocate for a well-known format that everybody can use, it makes little sense to advocate for YAML.
My understanding is that kiss only has one non-executable file encoding:
space-delimited entries of plain text, one entry per line
I cannot think of any more familiar format, let along the other benefits (portability, long-lasting, introspectable) which are of varying degrees of better and worse than other encodings.
In addition, up until [1], not only was the syntax simple, but so were the semantics.
Slackware is a complete OS complete with curated set of user land and desktop applications. Although I have a soft spot for Slackware, I’d say arch fills this niche more than Slack: You get the most minimal system as a starting point and build what complexity you need on top - and no more.
Slackware's pkgtools depend on bash and GNU coreutils. As a result, it's impossible to replace bash+coreutils with busybox, toybox, ubase+sbase, ...
Kiss linux has been created with focus on highly portability and user choice. There's no lock-in. Users can replace bash with dash or GNU coreutils with sbase+ubase and vice versa.
Slackware isn't alternative to Kiss linux at all. They have different goals and mindset behind them.
A simple system is not the same as a system that is simple to use. The latter is often described as "easy" rather than "simple" in the development circles I've been in (and I think is also the way rich hickey said it in his "simple made easy" talk that popularized the difference).
To add some context -- project founder has recently came back after a brief disappearance, and is in the process of making some big changes and improvements (eg. move to Wayland).
I think if a distro replaced less with more I would be confused if it differs slightly. That’s pretty entertaining my first read of your comment I was confused took me a moment to let it sink in.
> KISS technically supports booting via an initramfs, it just doesn't require or provide one. As a user you have the means to set this up yourself for your system.
> Full disk encryption is also possible without the use of an initramfs in modern kernels (see dm-mod.create).
> The initramfs concept is an ugly, complicated and largely optional mess. Thank god it isn't a requirement.
The initramfs is really only there to mount the root partition. Given the various ways that people want to do that, it makes a lot of sense to have an initramfs for distros that cater to many different use cases. Consider that a root partition may use LFS, disk encryption, or it may even be a network volume!
I don't think there’s really much of a reason to abandon initramfs other than “maybe you don’t need it.” As far as I can tell, this distro has you compiling the kernel. If you are compiling kernel for your specific hardware, you can remove the need for kernel modules in initramfs. Distros generally compile the kernel for you, so this won’t work so well, in general.
Add weasel words to the above as necessary. Basically, no major advantages to ditching initramfs, and ditching it will leave you with something less flexible. Some use cases (e.g. embedded) there may be no advantage to using initramfs in the first place.
initramfs is very useful if you make a bootable external SSD or USB memory stick, which is intended to be able to boot on any random computer.
After you install Linux on a known computer, maybe using a customized kernel that already includes any required modules for the root device and file system, there is absolutely no need for initramfs, which just slows the boot without any benefit.
Are all the packages linked without dynamic dependencies? That doesn't seem to be the case, since maintaining build rules for enough statically linked packages would have a bus factor of way more than 0, as the project claims.
Is it that the package manager's packages are all stored in a git repo? Tons of package managers nowadays do that.
Is it that the package manager's package definition use a custom format that is not well specified and has enough features to make parsing non-trivial, just because the author doesn't want to use jq or write their own json parser in shell? How is this pile of files more static than json?
If it's none of those things this just seems like a buzzword thrown in for no particular reason.
Maybe/hopefully it means that the package embeds only static data files that are simply unpacked and later removed, with nothing like dpkg's maintainer scripts or rpm's scriptlets.
> There is no requirement or _need_ for infrastructure of any kind.
that's an awesome approach. Here is usually where idiosyncratic complexities arise. Instead focussing on the inevitable that's there anyway – wonderful!
Linux From Scratch is precisely that: a bootable kernel and the necessary tools to get you there from raw source. Period.
BLFS adds specific desirable bits.
But neither LFS nor BLFS offers a yum/apt/emerge package management facility for dropping in large functionality and keeping rhe dependency graphs of the components in check.
[+] [-] gorgoiler|4 years ago|reply
A very clever approach, mirroring the way FreeBSD, OpenBSD have traditionally managed their core competencies.
I am a lifelong Debian fan but it has always troubled me that I can’t check out a copy of the OS’s metadata — that which is packaged in all of the DSC files or `debian/` directories — in one place.
A monorepo containing all of your business logic is a successful tactic to getting things done. There are some great pieces of behind-the-scenes Debian infra to support this — with SVN, and later git, and internal projects like Alioth — but the first class citizen of the project is still a deb-src apt entry. Inherently a one way HTTP link from the vendor to me with only a published Changelog to track changes. A solid and stable technology for a venerable project, but git-log / git-blame it ain’t.
(Of course, the success of giant open source projects and especially Debian is often because there is no central coordination. The technical and other committees were social constructs to try to keep everyone on track. Do they still function well?)
[+] [-] geek_at|4 years ago|reply
[+] [-] saithound|4 years ago|reply
Bus factor is usually defined as the minimum number of team members that have to be hit by a bus to put the project in jeopardy. The Wikipedia article linked from the site defines it the same way.
So a bus factor of zero would mean that the project is in jeopardy even if all the maintainers are alive.
[+] [-] codethief|4 years ago|reply
> There is a rare alternative definition for the bus factor, namely: the number of people who are indispensable for the project.[2] In other words, it is the minimum number of people who are a single point of failure. If using this definition, then a high bus factor is considered a bad thing (since the loss of any person included destroys the project), and zero is considered the ideal bus factor.
[+] [-] donw|4 years ago|reply
So, PHP, then.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] hawski|4 years ago|reply
[+] [-] makach|4 years ago|reply
[+] [-] beermonster|4 years ago|reply
[+] [-] cton|4 years ago|reply
[+] [-] johnisgood|4 years ago|reply
[+] [-] PoignardAzur|4 years ago|reply
[+] [-] kissgyorgy|4 years ago|reply
Please just stick to well-known formats (even if you don't like them) and make your fellow developers life easier! For example, everyone hates YAML for one reason or another, but if you use it, you are using a format everyone is familiar with it. We know it's terrible quirks, but still well known and every language has parsers for it.
[+] [-] pritambaral|4 years ago|reply
2. YAML is a terrible format for everyone. Even if you don't hate it, you can still fall prey to its poor design and not even know about it until it blows up later. A package manager is especially not somewhere you want such latent bugs.
3. Not everybody knows its terrible quirks. I'd used YAML for years, and was still surprised when I read strictyaml.org's (limited) list of documented bugs in YAML.
4. YAML isn't even the first or most-popular well-known format. So, if you're going to advocate for a well-known format that everybody can use, it makes little sense to advocate for YAML.
[+] [-] illiliti|4 years ago|reply
1. https://github.com/kisslinux/kiss/commit/d296b90b75d02ee81ec...
2. https://github.com/kisslinux/repo/pull/286
[+] [-] jedahan|4 years ago|reply
In addition, up until [1], not only was the syntax simple, but so were the semantics.
[1]: https://github.com/kisslinux/kiss/commit/d296b90b75d02ee81ec...
[+] [-] na85|4 years ago|reply
For me, this niche has always been filled by the venerable Slackware distro.
[+] [-] beermonster|4 years ago|reply
[+] [-] illiliti|4 years ago|reply
Kiss linux has been created with focus on highly portability and user choice. There's no lock-in. Users can replace bash with dash or GNU coreutils with sbase+ubase and vice versa.
Slackware isn't alternative to Kiss linux at all. They have different goals and mindset behind them.
[+] [-] hnbear|4 years ago|reply
This is not a trivial, easy, type of simple.
Rather a raw and uncomplex simple.
Not going to assume either is better, but somewhat curious which people default to assuming and/or preferring.
[+] [-] fouc|4 years ago|reply
[+] [-] SahAssar|4 years ago|reply
[+] [-] mro_name|4 years ago|reply
[+] [-] rossvor|4 years ago|reply
https://kisslinux.org/blog/20210711a
[+] [-] GuB-42|4 years ago|reply
Please don't, I understand that "more" is simpler but I like the ability to scroll up.
[+] [-] giancarlostoro|4 years ago|reply
[+] [-] ximm|4 years ago|reply
[+] [-] rnestler|4 years ago|reply
> KISS technically supports booting via an initramfs, it just doesn't require or provide one. As a user you have the means to set this up yourself for your system.
> Full disk encryption is also possible without the use of an initramfs in modern kernels (see dm-mod.create).
> The initramfs concept is an ugly, complicated and largely optional mess. Thank god it isn't a requirement.
[+] [-] klodolph|4 years ago|reply
I don't think there’s really much of a reason to abandon initramfs other than “maybe you don’t need it.” As far as I can tell, this distro has you compiling the kernel. If you are compiling kernel for your specific hardware, you can remove the need for kernel modules in initramfs. Distros generally compile the kernel for you, so this won’t work so well, in general.
Add weasel words to the above as necessary. Basically, no major advantages to ditching initramfs, and ditching it will leave you with something less flexible. Some use cases (e.g. embedded) there may be no advantage to using initramfs in the first place.
[+] [-] adrian_b|4 years ago|reply
After you install Linux on a known computer, maybe using a customized kernel that already includes any required modules for the root device and file system, there is absolutely no need for initramfs, which just slows the boot without any benefit.
[+] [-] steinuil|4 years ago|reply
...what does this even mean?
Are all the packages linked without dynamic dependencies? That doesn't seem to be the case, since maintaining build rules for enough statically linked packages would have a bus factor of way more than 0, as the project claims.
Is it that the package manager's packages are all stored in a git repo? Tons of package managers nowadays do that.
Is it that the package manager's package definition use a custom format that is not well specified and has enough features to make parsing non-trivial, just because the author doesn't want to use jq or write their own json parser in shell? How is this pile of files more static than json?
If it's none of those things this just seems like a buzzword thrown in for no particular reason.
[+] [-] yrro|4 years ago|reply
[+] [-] mro_name|4 years ago|reply
that's an awesome approach. Here is usually where idiosyncratic complexities arise. Instead focussing on the inevitable that's there anyway – wonderful!
[+] [-] andix|4 years ago|reply
Any idea what the benefit of KISS linux would be over alpine?
[+] [-] PeterWhittaker|4 years ago|reply
[+] [-] fouc|4 years ago|reply
[+] [-] mixmastamyk|4 years ago|reply
[+] [-] sebastian65|4 years ago|reply
[+] [-] jdblair|4 years ago|reply
[+] [-] mrkrell|4 years ago|reply
Inquiring minds want to know!
[+] [-] smitty1e|4 years ago|reply
BLFS adds specific desirable bits.
But neither LFS nor BLFS offers a yum/apt/emerge package management facility for dropping in large functionality and keeping rhe dependency graphs of the components in check.
[+] [-] LAC-Tech|4 years ago|reply
[+] [-] agumonkey|4 years ago|reply