> 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?)
Alpine is amazing. One of the best distros I've ever used by far. So good for desktop, so good for servers, so easy to use and install, amazing package manager.
Use it as my goto choice for containers and have never had an issue. Tiny footprint and minimal OS means I can minimise attack surface and package update frequency to boot. Really nice versatile distro.
I just wish there was better musl or static linking support in the Linux ecosystem for Alpine. A lot of one-off binaries in my experience were dynamically linked only for the latest Ubuntu's glibc.
Nix it's very common to relink using patchelf, but I don't know if that makes sense linking from glibc to musl. Changing the compile environment from gcc to llvm and/or glibc to musl, means you will be building a LOT of things from scratch because upstream Hydra only builds and caches glibc. There's nothing "wrong" with glibc, but it does cause issues where a compiled binary says `-linux-x86_64` and then doesn't work with your system's glibc. I had a tool I wanted to use in an Alpine container, and switched to Debian or Ubuntu because I didn't want to deal with the incompatibility even if Alpine is smaller and faster. I got the author to put out a paragraph in the README about alternative, non-glibc not being supported by the prebuilt binary (ghc from Ubuntu isn't static).
Flatpak is great, you're able to install and run programs without configuration on most distributions. exept it also (obviously) installs all dependencies, configurations and settings while you usually only need glibc or some other variant to make a program run.
I'd prefer running without flatpak because when something doesn't work you'll be wondering wether its flatpak, the system or the program that is missing something.
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.
That's true, and in fact I'd prefer it if that was the mainstream definition. Given that it isn't, there may be better replacements for the headline, along the lines of "maintainable by one person".
That alternative definition seems less useful, because quite often there are two people who can individually maintain a project, and in that scenario the bus factor is 0 even though there is a risk that both of them will leave the project.
These two measures are probably ended up conflated because they're two ends of the same metric. "How many people need to be hit by a bus", which for simplicity I'll call the "bus factor", measures unusually high levels of resilience, but it doesn't go lower than 0 so it can't measure how fragile a fragile project is. "How many people are indispensable", which for simplicity I'll call "inverse bus factor", measures unusually low levels of resilience, but it doesn't meaningfully go below 0 so it can't measure how resilient a resilient project is. The thing is, a bus factor >= 2 necessarily indicates an inverse bus factor = 0 (if you need to hit two people with buses to take the project down then nobody is indispensable) while an inverse bus factor >= 1 necessarily indicates a bus factor = 1 (if anyone exists that is indispensable, then hitting exactly them with a bus takes the project down). In other words, bus factor = 1 and inverse bus factor = 1 could be viewed as being the same point in the middle of a line on which all projects fall, same way zero is the center between positive and negative numbers.
>same way zero is the center between positive and negative numbers.
More like the way 1 is halfway between 0 and infinity. I think you're nearly there, and the answer to the dilemma is that fractional bus factors are possible. A bus factor of 0.5 means there are two indispensable people.
We might disambiguate the two conflicting definitions by renaming them with suitably inverse words - "redundancy" and "fragility" perhaps (though I suspect the latter is unneccesary). This is basically the terminology we use for RAID arrays and servers.
I agree that fractional bus factors would be better if we could completely redefine the metric, yes - they do a much better job conveying the fact that doubling your bus factor does way more than halve your likelihood of actually getting stopped by losing a contributor. I was stuck reinterpreting existing definitions when I wrote that post, though, so /shrug
I suppose the downvotes may be justified due to your comment being pretty out-of-place, but, just to add some perspective: I'd like to remind everyone that PHP originally used strlen() as a hashing function: https://news-web.php.net/php.internals/70691
It is (or at least originally was) certainly not the pinnacle of good design.
I don't think it's fair to use this fact as a data point -- since that same message you've linked says "This was circa late 1994 when PHP was a tool just for my own personal use". PHP was released to the public 1995.
Eh, I think it is--the creator knew enough about programming to consider (and then actually implement!) storing the functions in a hash table, but I'd say that anyone who knows enough to do that would/should know perfectly well that strlen is a terrible choice for the actual hashing function.
The other thing that's "funny" to me with PHP is that they are adding features a few years after everyone. Right now they're really big on OO when lots of people are slowly moving towards more FP features.
Is the trend of FP still going on? I'm not so sure, feels like it has somewhat slowed down compared to the hype about eight years ago.
There is somewhat a positive trend about immutability, but you don't need a FP language of FP features for that.
My guess which languages that is most popular here at HN, based on rough estimate of number of positive mentions, would be C, golang, rust & python, where neither is a FP language.
Edit: Maybe Erlang should be included in that list of popular HN languages, if that is the case then it is one out of five.
I think it is. Python added pattern matching, Java got records and pattern matching, C# too. React transitionned from class to hooks and is getting (or already got? I don't follow React too much) an effect system. Rust has a heavy FP influence. Go will have generics which may or may not open the door to some FP. From my understanding, the C landscape has a huge NIH and fragmentation bias, which means that ideas take a lot more time to penetrate.
Replacing everything with FP languages is not going to happen, but I think more and more people are coding in a "FP way" if that makes sense.
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.
Yes YAML is a terrible choice, but his point is still correct. Use a standard format, not some custom nonsense you made up that can't even handle strings with spaces in them.
I recommend JSON5 or maybe TOML if your data is very flat.
> Yes YAML is a terrible choice, but his point is still correct. Use a standard format ...
As I said in point 4 above: So, if you're going to advocate for a well-known format that everybody can use, it makes little sense to advocate for YAML.
Are we witnessing the birth of a new JSON/TOML/YAML equivalent that also started as a "all of these formats are too complex, let's just do something simple" and with time added complexity? I hope they at least have a strict grammar.
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.
I didn’t look into Kisslinux but the rather obvious problem with Arch is that the installation process scares people away (regardless whether it is hard or not). The terminal/command line is a scary place for people who didn’t use it before. Otherwise I tend to agree that Arch can be absolutely minimal if you want to. Didn’t use Slackware so I can’t comment on that.
In cases where people simply have to follow instructions, I find the fear of the command line to be disappointing. It is far easier to provide support and that support is far less failure prone simply because you can state exactly what has to be done, rather than describe how to navigate a user interface while hoping that the other person interprets visual cues in the same way.
That being said, there is a deeper problem with the Arch installation process: the user needs to know exactly what they want. I can race through an Arch installation and end up with my desired configuration far faster than I could in any other operating system. Much of that has to do with the ability to dump a list of package names into pacstrap and copying over a bunch of configuration files. There is no fumbling around with a GUI. Yet those who are new to Arch (or, worse, new to Linux) don't have the benefit of that experience. The process is daunting.
I've used Arch for 12 years. But every time I reinstall, it takes me a long, long time to get everything working perfectly. It's painful, and requires a second machine to have the documentation handy. The documentation is good in the sense that it is thorough, but Arch refuses to have a preferred method of install. It refuses to have an opinion.
Rather than a sane default, the installation guide says "Install a bootloader. Click here for a list of 8 bootloaders"
"Click here to see 12 different partition managers" etc..
I feel I have to be an expert in every part of the system (Even things I'll never, ever touch again). It would be much better if the install guide chose the default and said "here's a link for other options if you prefer". Once the system is set up, I mostly just run pacup every day, with very few issues. But the install process seems deliberately complicated, and serves as gatekeeping.
I don't know, I've installed installed arch many times and I still occasionally will forget some step or make a typo or something. Then I have to boot the installation image again, remount everything, fix the issue... it's annoying. GUI installers don't really have this problem.
I have never really asked this before, but... so what? I was 14. I wanted to learn Linux. You know how I did it? By installing Gentoo while reading the documentation. I worked hard (fueled by curiosity and wanting to learn) and it paid off. Were it as easy as a GUI installer, I probably still would have difficulties and not be able to tell you what ">" and "|" are. I would have way less knowledge if I never tinkered around the terminal.
It may scare people away, but you have to ask yourself: what kind of people? I have been teaching Linux to a couple of people, and some hate reading documentation in general. Make of that what you will. :)
That said, I installed Linux on a Windows user's laptop and she was fine with it because all she needed was a browser and something else I cannot remember. I think this covers many people.
There's an installer now, but what drives me away from using it is it's heavy dependence on systemd utils by default. Of course there's forks that fix it, of course you can do things differently, but yeah. There's distros that offer better with less, and are simpler to set up.
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.
Well, blame English. It sucks (and so do all other natural languages).
In software, I'd say that "simple" has come to mean "lack of complexity" rather than "easy". Presumably, the distribution's target audience is software enthusiasts of some sort.
If someone gave me a "simple" API for say networking. I would expect the API to be easy to use. But by your definition, I could give you an API such as "write(byte[])" which just puts bytes on the ethernet wire or into on the wifi radio. It's simple! It's not complex, there's only one API method with only one argument!
But in reality, I'm just shifting complexity to the user. I only consider things simple if they truly reduce complexity rather than if they just shift the complexity to someone else.
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.
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?)