A Linux distro with a focus on simplicity and the concept of less is more
kisslinux.org
kisslinux.org
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?)
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.
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.
That would be true if "infinity" meant 2.
So, PHP, then.
It is (or at least originally was) certainly not the pinnacle of good design.
You speak of this as it should be something that is relevant for the state of PHP and the community that uses it to this day.
It is not. The community moved on, maybe it's time the haters did as well.
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.
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.
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.
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.
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.
I recommend JSON5 or maybe TOML if your data is very flat.
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.
1. https://github.com/kisslinux/kiss/commit/d296b90b75d02ee81ec...
space-delimited entries of plain text, one entry per line
In addition, up until [1], not only was the syntax simple, but so were the semantics.
[1]: https://github.com/kisslinux/kiss/commit/d296b90b75d02ee81ec...
For me, this niche has always been filled by the venerable Slackware distro.
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.
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.
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.
Nowadays it has an installer [Disclaimer: never used it]
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.
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.
If I told someone I’d found a simple distro, I wouldn’t expect them to prep to compile their own kernel
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.
Please don't, I understand that "more" is simpler but I like the ability to scroll up.
> 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.
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.
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.
...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.
that's an awesome approach. Here is usually where idiosyncratic complexities arise. Instead focussing on the inevitable that's there anyway – wonderful!
Any idea what the benefit of KISS linux would be over alpine?
Inquiring minds want to know!
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.