Live data from Hacker News

A Linux distro with a focus on simplicity and the concept of less is more

kisslinux.org

51–60 of 88 posts

Re: A Linux distro with a focus on simplicity and the concept of less is more

#51
post #19

Earlier quoted context omitted.

> So a bus factor of zero would mean that the project is in jeopardy even if all the maintainers are alive. So, PHP, then.

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'd like to remind everyone that PHP originally used strlen() as a hashing function: https://news-web.php.net/php.internals/70691

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#52
> The package format is entirely static.

...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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#53

Earlier quoted context omitted.

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 surprise…

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#54

> The package format is entirely static. ...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 th…

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#55
post #24

Earlier quoted context omitted.

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 un…

>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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#57
post #26

> 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…

sounds like you'd be happy with Alpine Linux too https://alpinelinux.org/

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#58

Earlier quoted context omitted.

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.

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#59
post #57
post #26

Earlier quoted context omitted.

sounds like you'd be happy with Alpine Linux too https://alpinelinux.org/

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.

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.

Re: A Linux distro with a focus on simplicity and the concept of less is more

#60

Earlier quoted context omitted.

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.

Post reply on HN