A lot of these look like things that I might want to install, but most of them shouldn’t be part of a base system install. There are several things in POSIX that I could live without, such as a C compiler. The standard install should contain enough to boot the system, log in, configure the network, and install packages. Anything else can be driven by meta packages that pull in sets of things that people are likely to want together. Most modern Linux distros install a huge amount of stuff that I don’t want in the base install, yet still leave me reaching for the package install tool immediately afterwards to install the things that I do want.
I guess it all depends on the philosophy of the OS. On OpenBSD you need to be able to bootstrap another OpenBSD system from ground so you need a C compiler. Ubuntu is a dumbed down system so it needs to have as much things as possible stuffed in it. Other Linux distros favor minimalism and come with a very small base install, such as Puppy Linux.
On OpenBSD you need to be able to bootstrap another OpenBSD system from ground so you need a C compiler
I would slightly disagree with the second half of that. You need to be able to install a C compiler. OpenBSD has pkg_add in the base system, so could make the toolchain a separate package. Most OpenBSD systems that I’ve used have been network appliances where I’ve never wanted to compile any code locally, so inclusion of a toolchain by default was actively harmful because the available storage was a small flash card.
The amusing part is that OpenBSD really wants you to install all the sets, even if you’re not going to use i.e. X on your network appliance. The packages are all built assuming everything is installed, and the developers get angry on the i.e. mailing lists if you say you haven’t installed them all. Makes me wonder why they even have the concept of sets if you’re not supposed to change that.
This is based on the assumption that all the hardware on which the OS runs has internet access which isn’t true even if we live in the era of IoT. In ‘93 when NetBSD was created internet connectivity was not a commodity. The fact that the OS lives with this philosophy up until today.. I don’t know if it’s good or bad.
tldr – simplified man pages with practical examples.
Outside of the linux world, these are just called man pages.
I’d also add rg to that list. I’ve found it a pleasure to use no matter what *NIX I was using, especially when I’ve had to deal with non-plaintext documents.
There is also https://github.com/phiresky/ripgrep-all which looks into office documents, PDFs and scanned TIFFs but this is only to prove my point (it pulls in even tesseract for OCR on scanned TIFFs): distributions should be a minimum viable product in the base install.
And… I’ve just now realised I was confusing ripgrep and ripgrep-all. That’s the one I had used previously for searching non-plaintext docs. Thanks for pointing that out.
Indeed but it is worded in such a way that it implies that the reader also prefer non-GNU software and they both know why.
I find it really strange as there’s no drawback to GNU software as long as you don’t plan to make a commercial proprietary platform out of them (which seems clearly out of scope here).
Am I missing a trend where you should try to avoid GNU software? (would be interested to know as I’m on the opposite lifelong trend to try to use less and less proprietary software myself)
A distribution should alway be a minimum viable product - as tiny as possible, but easily extendable.
You should never impose you own preferences onto others, and what you regard as indispensable tool, others might view as useless cruft.
For example, my file selection tool of choice is broot (https://github.com/Canop/broot), but it is certainly not for everyone. And the word choice in the sentence before is about 80% of what linux is all about (or used to be, but I won’t reopen that can of worms again). And this choice might also be to not have something.
Yes I said it… no python, perl, tcl, lua or any other script language in the base install. Only a basic shell and (maybe) a sshd for remote administration. Think busybox and tinyssh. The rest has to be freedom to chose from all of the open source software out there. You should also be able to choose you packaging system!
Those who want a walled garden are served elsewhere, for only n · 99$…
And if anyone in the audience was designing a new way of packaging at the moment:
make an easy way of supressing buildtime dependencies, package system and documentation - if you ever tried to make embedded systems for appliances or minimal container images you’ll know what I’m talking about.
make an easy way of maintaining a personal standard distribution. Maybe lists of package selections on a thumb drive or at an URL which are used during installations.
A lot of these look like things that I might want to install, but most of them shouldn’t be part of a base system install. There are several things in POSIX that I could live without, such as a C compiler. The standard install should contain enough to boot the system, log in, configure the network, and install packages. Anything else can be driven by meta packages that pull in sets of things that people are likely to want together. Most modern Linux distros install a huge amount of stuff that I don’t want in the base install, yet still leave me reaching for the package install tool immediately afterwards to install the things that I do want.
I guess it all depends on the philosophy of the OS. On OpenBSD you need to be able to bootstrap another OpenBSD system from ground so you need a C compiler. Ubuntu is a dumbed down system so it needs to have as much things as possible stuffed in it. Other Linux distros favor minimalism and come with a very small base install, such as Puppy Linux.
I would slightly disagree with the second half of that. You need to be able to install a C compiler. OpenBSD has
pkg_addin the base system, so could make the toolchain a separate package. Most OpenBSD systems that I’ve used have been network appliances where I’ve never wanted to compile any code locally, so inclusion of a toolchain by default was actively harmful because the available storage was a small flash card.The amusing part is that OpenBSD really wants you to install all the sets, even if you’re not going to use i.e. X on your network appliance. The packages are all built assuming everything is installed, and the developers get angry on the i.e. mailing lists if you say you haven’t installed them all. Makes me wonder why they even have the concept of sets if you’re not supposed to change that.
This is based on the assumption that all the hardware on which the OS runs has internet access which isn’t true even if we live in the era of IoT. In ‘93 when NetBSD was created internet connectivity was not a commodity. The fact that the OS lives with this philosophy up until today.. I don’t know if it’s good or bad.
Not necessarily, just access to something capable of storing packages, such as a DVD or a local networked drive.
Outside of the linux world, these are just called man pages.
I’d also add
rgto that list. I’ve found it a pleasure to use no matter what *NIX I was using, especially when I’ve had to deal with non-plaintext documents.There is also https://github.com/phiresky/ripgrep-all which looks into office documents, PDFs and scanned TIFFs but this is only to prove my point (it pulls in even tesseract for OCR on scanned TIFFs): distributions should be a minimum viable product in the base install.
And… I’ve just now realised I was confusing ripgrep and ripgrep-all. That’s the one I had used previously for searching non-plaintext docs. Thanks for pointing that out.
Could somebody explain to me why, for datamash, it is written: “Gnu, I know, but…” ?
Presumably the author prefers non-Gnu software.
Indeed but it is worded in such a way that it implies that the reader also prefer non-GNU software and they both know why.
I find it really strange as there’s no drawback to GNU software as long as you don’t plan to make a commercial proprietary platform out of them (which seems clearly out of scope here).
Am I missing a trend where you should try to avoid GNU software? (would be interested to know as I’m on the opposite lifelong trend to try to use less and less proprietary software myself)
A distribution should alway be a minimum viable product - as tiny as possible, but easily extendable.
You should never impose you own preferences onto others, and what you regard as indispensable tool, others might view as useless cruft.
For example, my file selection tool of choice is broot (https://github.com/Canop/broot), but it is certainly not for everyone. And the word choice in the sentence before is about 80% of what linux is all about (or used to be, but I won’t reopen that can of worms again). And this choice might also be to not have something.
Yes I said it… no python, perl, tcl, lua or any other script language in the base install. Only a basic shell and (maybe) a sshd for remote administration. Think busybox and tinyssh. The rest has to be freedom to chose from all of the open source software out there. You should also be able to choose you packaging system!
Those who want a walled garden are served elsewhere, for only n · 99$…
And if anyone in the audience was designing a new way of packaging at the moment:
unfortunately it doesn’t support BFS
BFS as in breadth first search?
yes