Kiss Linux (2020)(web.archive.org)
web.archive.org
Kiss Linux (2020)
https://web.archive.org/web/20200528200318/https://k1ss.org/
31 comments
Also incredibly cool project from the author is the Pure Bash Bible: https://github.com/dylanaraps/pure-bash-bible.
Some of it sounds similar to now defunct Crux Linux https://crux.nu/ but with rolling release
my favorite KISS Linux is Tinycore http://www.tinycorelinux.net
It's even more opinionated and architecturally simpler than this. Every package is simply a tree fused into / with the union file system. It runs from ramdisk and can live in a fat formatted thumb drive.
[deleted]
> Has a "Bus factor" of N/A (0?) thanks to the above points. Full power to the users and the community.
On an archived page.
On an archived page.
Would a bus factor of 0 not also be extremely bad, meaning that the project is in danger even if no one is actually killed by a bus and all developers are fine? :D
Agreed; I've been on projects that I would count as having a bus factor of 0, because all the people who knew how to do any number of critical functions had been laid off. This is an attempt to make everything so simple and well-documented that that could never happen because anytime somebody wants to work on it they can pick it up and immediately be able to do everything.
0 is often (ab?)used like this, e.g. 'never stop' where it ought (by some sort of logic) to mean 'stop immediately' or whatever other time or repetition based thing.
Oh you're right XD I think "bus factor of infinity" is what they're going for!
well the project will stop dead right in tracks if a bus carrying the entire population of earth were to crash into a river, so I'd say the bus factor is very much finite.
The current page seems to be up, though (https://kisslinux.org/). I'm not sure why we're looking at the archive page.
FWIW - the bus factor statement proved true. Dylan vanished without a trace a few years back. No message in IRC, the blog, source control, or anything.
And the community just kept trucking.
Have since confirmed he is alive and well.
And the community just kept trucking.
Have since confirmed he is alive and well.
:-*
This seems to be where the project site has migrated to: https://kisslinux.org
Thanks for that, I was under the impression that it was now dead due to the link to archive.org.
Maybe the url of the original post should be updated.
Maybe the url of the original post should be updated.
So alpine with extra steps?
KISS is a fantastic piece of software. Arguably a better learning tool than LFS IMH(umble)O. It’s tiny footprint and git backed package manager really helps you get a sense of what a Linux distribution really is without much to distract you.
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.
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.
The original creator/BDFL (Dylan Araps) has been a bit off and on with activity over the last year or so, so the official repository is a bit out of date. The community has kept up to date main and community repos at https://github.com/kiss-community/ though. Come chat with us at #kisslinux on libera.chat!
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.
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.
If "simple" makes you think of "less capabilities" then you are way off the mark.
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.
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.
It's perfectly reasonable to say "I'll take fewer capabilities in specific areas, if there is far less complexity". Those "missing" capabilities can be hard blockers for you, and that's fine as well.
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.
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.
In many ways, a lot of the complexities in computing are born from the lack of capabilities.
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.
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.
That reads like an argument for static type checking languages and against runtime dynamic languages, and I'm generally in the same camp as you, but obviously it's not impossible to use either to write a good program if it's only 1000 lines (they also state they use shellcheck, which is not nothing). There's absolutely something to gain from their approach.
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.
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.
> 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.
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.
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 not objecting that someone wants to create a toy project that lacks important capabilities.
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'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.
Removing capabilities makes something simpler, almost by definition. Less moving parts, fewer things that can fail.
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.
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.
The audio system in linux desktop being broken all the time is in great part due to the complexity of the system. It's not that audio is inherently complex and difficult. It's just the basic model that these systems assume is broken.
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?
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?
"Completely removing" audio would be silly of course, but you can "simplify" the audio system, maybe making some trade-offs in capabilities (e.g. no mixing, effects) but still having a functional and usable audio system.
(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.)
(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.)
> For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language.
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.
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.
[deleted]