Kiss Linux (2020)
web.archive.org
web.archive.org
Also as pointed out in other comments, the main URL is https://kisslinux.org now. Dylan never could seem to settle on a domain name for whatever reason, so there are many dead links, and I don't blame the OP for not finding the most recent one.
Maybe the url of the original post should be updated.
From there, expanding out to larger and more complicated tool chains is a trade-off conversation.
I learned a lot from KISS and I’m glad it exists.
On an archived page.
And the community just kept trucking.
Have since confirmed he is alive and well.
The challenge is to create something with more capability but architeturally more simple.
I don't understand why they brag about supporting "only English". I'm also not sure what it means: does it mean the system does not even support utf-8 strings? Or is it just about the lack of UI translation to other languages? In either case, it's nothing to brag about. You're just removing capabilities for no reason.
It's important to understand why simplicity is desireable: it's not desireable for itself, it's desireable because, everything else being equal, a simple system is easier to make reliable and robust.
For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. It's not simple. Errors are not reported until runtime. It's worse than dynamic languages because shell scripts often create permanent changes to the system. If a script fails mid execution, it might very well leave the system in a broken state.
Now, obviously when dealing with systems that's always possible even if the program is written in a compiled language with static typing and very good compiler error messages. But there's no need to exacerbate the problem by writing a core utility in a shell script that's several hunderd lines of code.
I also don't think much of your argument about shell is particularly strong, as it provides plenty of good facilities for dealing with errors (exiting subshell on first error, `trap`, etc.). The only reason I might expect an implementation in another language to be at least more correct in the ways you describe, is because the barrier to entry of those languages is higher, so the programmers may be more professional (in the good way, not in the meaningless way). Given there's just one developer here, we can skip rules of thumb like that and just assess that person and their modestly sized code.
C is a simple language. It's so simple it has no concept of modules/packages. So as a hack you can 'include' header files.
But this simple hack creates all sorts of complexities.
Things would be simpler if the compiler had a concept of modules or packages.
Ruby is so simple you don't need a compiler! You just need packages to exist in your system which you can install using the command line.
Except now to ship a program you have to ship the entire environment with it, so you create Docker.
But things would be simpler if the language had a compiler that can produce a self contained packaging of the program.
Supporting only English makes things simple until people from other countires come along and they independently try adding support each for their own language, and you end up with tons of encodings and code pages and all the mess that was there before unicode.
Regarding shell, actually the shell language has a quite a high barrier to entry, but only because it's cryptic. That's not my problem though. My problem is even if you add error checking and all that, you don't know if it actually works. There's no compiler that will report errors for you. It's very easy to write incorrect code and get absolutely no feedback about it.
There's really nothing to gain from doing this.
And shell is not particularly cryptic, it's just taught awfully -- the main problem being that lazy tutorials just don't mention how quoting/tokenizing works. Using shellcheck almost always pushes you in the right direction.
Good support for different encodings, locales, etc. is actually quite hard, and also imposes some amount of burden on developers of the system, as well as users who don't use these features.
Of course, these things are also very useful and if you want/need things like that then that's fair and KISS probably isn't for you. But not every project needs to cater to every need; I think "simple = less capabilities" is fine, although obviously not for everyone but it doesn't need to be.
> For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. It's not simple. Errors are not reported until runtime. It's worse than dynamic languages because shell scripts often create permanent changes to the system. If a script fails mid execution, it might very well leave the system in a broken state.
I never used KISS and don't know anything about their package manager, but I did write my own package building tool in shell script, and it builds things to its own chroot and as a last step if everything worked it moves the files over. It's not really atomic, but also not like any error in the script will "leave the system in a broken state".
It's great that better package managers exist, and there are a lot of situations where it's good to use them. But for other use cases it's just fine to use a (much) simpler system which isn't entirely perfect (but a lot simpler). Not everything needs to solve all possible problems. My own package builder doesn't do things like dependency tracking either because I don't need it, but obviously this is a very useful thing to have in many scenarios – but not all scenarios.
We really need to move away from the view that every project/system should cater to every kind of use case and every kind of user.
I'm objecting that they are presenting their work as "simple".
Simple describes the internal architecture of the system as having fewer parts to achieve a particular goal.
What you're doing is not simplyfing the system. You are keeping the system mostly the same, but removing some capabilities (and along with them, removing the parts of the system that were put in place to support these capabilities).
The way I see things, these are all different axes. Sort of orthogonal, but not really (they influence each other, but in theory they can be thought of as independent):
Easy ------------ Difficult
This axes is about the user and what they need to learn to be able to operate the system. If they have to learn many new things and intricate details, it's difficult. If they can operate the system perfectly while only learning fewer things, then it's easy.
Obviously there's a degree of relativity. So you can only define this in terms of a target demographics. e.g. "college students who are familiar with smart phones", or "corporate employees who have basic knowledge about computers and can use some office software".
Simple --------- Complex
This axis describes the internal architecture of the system. The parts its composed of and their interactions. Simple systems have fewer parts and fewer interactions. Complex systems have more parts and more interactions.
Reliable -------- Fragile
This axis describes the robustness of the system and its sensitivity to changes in the environment. Fragile systems break down when small things change in the environment.
Poor --------- Capable
This axis is about the features of the system and what it can do.
The things that I see in this KISS distro all point in the wrong direction:
- Fewer capabilities
- Difficult to use
- Robsutness is qustionable
Is it simpler? It may be simpler than a more capable version of the system, but what's the point?
Simplicity is only desireable in so far as it helps make the system more robust.
I have never used KISS, but it doesn't strike me as very difficult to use if you're reasonably experienced with Linux already. It's not for everyone, obviously, but that's okay. "Easy" is one of those terms that's hard to really say much about in general terms, because it really depends on the audience (both objective skillset, and subjective preferences and expectations).
It also doesn't strike me as particularly unrobust; one of the virtues of being simpler is that it's easier to understand and figure out what's going on. As an example, setting real-time priority on my system is currently broken, and between Pulseaudio, rtkit, Polkit, and dbus I can't figure out why. For my desktop, I'm actually just fine with just always allowing pulseaudio to set real-time permissions without a rtkit/polkit check so I don't really need these capabilities, but they are preventing my system from working correctly.
Windows and macOS for the most part don't suffer from these problems.
Now, you can completely remove audio support and claim you have a simple system, but how useful would that be?
(Audio on Linux is not "broken all the time" in my experience by the way; for the most part, it works pretty well out-of-the-box without mucking about. My particular problem is only a practical problem with one particular game that just barely runs on my system anyway.)
Shell is a bad language, but it is a language especially fitting for that purpose. File manipulation and external tool execution is much simpler and concise in it that in most other languages.