111–120 of 145 posts
I’m not familiar with Kiss but it looks interesting; what’s the benefit of Kiss over something like Arch Linux which is already minimal?
I loved the idea (git everything!) until I read this: "How do I remove a package and all of its dependencies? [...] The package manager does not do recursive dependency removal on removal of a package. This error-prone automation will not be added to the package manager. "
I made my own 'autoremove' in about 15 minutes for kiss. Its up in my repo https://github.com/jedahan/kiss-repo , and relies on having a package with all your system targets (in my case, named after my hostname) as dependencies: while kiss orphans | grep -qv $HOSTNAME; do kiss remove `kiss orphans | grep -v $HOSTNAME | tr '\n' ' '` done This was much easier to implement in kiss than other package manager extensions i…
sudo pacman -Rns $(pacman -Qqdtt)
Earlier quoted context omitted.
Seriously? There's a link "Ports (non-x86-64)" in the side bar. https://k1ss.org/ports
Sorry, but to use the port for the PineBook pro on a RPI4, NanoPI, Odroid, Beaglebone, whichever ARM else YOU are the porter. Which may be simpler, because K1SS , but it isn't readily available...
30 years ago, trying out the distribution of the month was kind of cool, nowadays they just contribute to the endless fragmentation of GNU/Linux ecosystem. I bet that during high time of UNIX wars no imagined it could get even worse.
Unfortunately, the developers of many of these experimental distributions don't seem to acknowledge that they are experimental distributions ...
I’m not familiar with Kiss but it looks interesting; what’s the benefit of Kiss over something like Arch Linux which is already minimal?
Arch is far from minimal. It literally ships systemd, and all kernel options enabled. Not to mention glibc, and a shitton of other crap...
But if you contextualize it a bit differently I think you might find it is super valuable.
One of the challenges the Linux community has is that there are so many distributions or 'distros' to choose from. What is more, the feature sets of those distros form a non-planar non-directed graph of nodes for which it is very very difficult to reason about their feature content.
Consider for the moment if you could reason about distros like you can reason about genomes. In modern genetics we can look at flora, fauna, bacteria, etc and talk about them as a base class "foo" with specific genetic changes that get them to be a "bar", we can talk about speciation where the genetics are different enough such that hybrids are infertile or impossible.
This effort tries, and I think largely succeeds, in capturing the "minimum viable Linux system" (all up kernel + user land). It gives you a way to reason about two different distros like
Ubuntu is Kiss plus (list of things) and for each item in the list of things, it has dependencies, recursively until you have completely described the genome of Ubuntu as a linear directed graph from Kiss. You could do the same thing for Fedora, or Mint, or any distro.
Two such graphs could give you a complete list of differences to get from distro to distro and the simple algorithm of walk back (remove items) from , then walk down the graph (add items) to would always "work" because they all share a common ancestor node, Kiss.
As a software developer you could reason about all of the changes to a distro you would need for your software to work, and this would tell you if those changes included removing something that was part of the canonical set of things in a distro, your software would not work on that distro.
Today, individual package managers do this in a distro unique way and let you work on one distro. As a software developer you end up with the "Fedora/Redhat" version, the "Ubuntu/Debian" version, maybe the "Arch/Gentoo" version.
But if the Linux community settled on a common understanding of the "genetic code" if you will, you could do that for all possible distributions. That would be a powerful thing.
* repo
* community
* kiss
Which package is the Linux kernel build stuff related? I recently wanted to bundle a quick Alpine install into a shareable `qemu` image. I couldn't figure out how to add a simple kernel module that was not included in the stock config. I would love to get this problem solved.
Earlier quoted context omitted.
Arch is far from minimal. It literally ships systemd, and all kernel options enabled. Not to mention glibc, and a shitton of other crap...
While I agree that Arch is far from minimal, it is one of the distributions that encourage people to build their system up to meet their needs. This is a far cry from the attention grabbing desktop distributions that may or may not offer a server version that can be built upon (which I, perhaps unfairly, interpret as discouraging the build-up approach).