SpaceCadet

Well he wrote it like he wanted to be applauded for it or something.

I also find the irony of your comment extremely funny ... although that's probably lost on you.

Later, dude.

You are strawmanning, and your links are not countering any point I made. I never disputed the depreciation as fact, and I never recommended that beginners should use egrep over grep -E

I disputed your claims that the egrep command has just been a distro hack all these years, when in fact GNU to this day still distributes egrep through its source tarballs and only very recently started to warn about it through the wrapper script. And again, the only "portability problem" here is the fact that they deprecated it in the first place, i.e. a self-inflicted one.

Then as a Linux and Unix veteran I gave my subjective opinion by lamenting and criticizing the fact that this depreciation happened, and how changes like this always feel like unnecessary pedantry to me. Yes it's an expression of frustration, but I am allowed to feel frustrated about it. I don't need people like you invalidating how I feel about breaking changes in software that I use daily.

GNU grep, the most widespread implementation, does not include egrep, fgrep and rgrep for years. Distributions (not all, but many) provide shell scripts that simply run grep with corresponding option for backward compatibility. You can learn this from official documentation.

It seems you need to read the official documentation yourself. While it's new information to me that egrep is no longer a symlink, as it used to be a couple of years ago, but a shell script wrapper to grep -E instead, the egrep command is to this day still provided by upstream GNU grep and is installed by default if you run ./configure; make; make install from source. So it is not a backward compatibility hack provided by the distribution.

You can check for yourself. Download the source from https://ftp.gnu.org/gnu/grep/grep-3.11.tar.gz, unpack and look for src/egrep.sh or line 1756 of src/Makefile. Apparently the change from symlink to shell script was done in 2014, and the deprecation warning was added only last year.

In any case, my larger point is that the depreciation of egrep was a pointless and arbitrary decision that does not benefit users, especially not veterans like myself who have become accustomed to its presence. I don't mind change, but let's be honest, most people are not in the habit of checking the minutiae of every little command line utility they use, so a change like this violates the principle of least surprise. It's one thing if things are changed with a good reason and the users do not only suffer the inconvenience of the change but get to reap the benefits of it as well, but so far I haven't found any justification for it yet, nor can I think of any.

So if there is a portability problem with using egrep now, it's a self-inflicted portability problem that they caused by deprecating egrep in the first place.

Also, my scripts are not full of bashisms, gnuisms, linuxisms and other -isms, I try to keep them portable unless it is really necessary to use some unportable command or syntax.

Good for you. Do you want a cookie or something?

nowadays egrep is not recommended to use. grep -E is a more portable synonim

Not directed at you personally, but this is the kind of pointless pedantry from upstream developers that grinds my gears.

Like, I've used egrep for 25 years. I don't know of a still relevant Unix variant in existence that doesn't have the egrep command. But suddenly now, when any other Unix variant but Linux is all but extinct, and all your shell scripts are probably full of bashisms and Linuxisms anyway, now there is somehow a portability problem, and they deem it necessary to print out a warning whenever I dare to run egrep instead of grep -E? C'mon now ... If anything, they have just made it less portable by spitting out spurious warnings where there weren't any before.

I ditched Ubuntu LTS for my homelab virtual machines around 20.04 when they started to push snaps, netplan and cloud-init, meaning I would have to spend a significant amount of effort redoing my bootstrap scripts for no good reason and learning skills that are only applicable in the Ubuntu ecosystem. I went with debian stable instead, and was left wondering why I hadn't done that sooner. It's like Ubuntu without all the weirdness.

Not sure if this is the root cause of your boot failure, but underscores in hostnames are not allowed. A- Z, 0-9 and - are the only allowed characters.

I think it's a good tool to have on your toolbelt, so it can't hurt to look into it.

Whether you will like it or not, and whether you should move your existing stuff to it is another matter. I know us old Unix folk can be a fussy bunch about new fads (I started as a Unix admin in the late 90s myself).

Personally, I find docker a useful tool for a lot of things, but I also know when to leave the tool in the box.

Huh? Your docker container shouldn't be calling pip for updates at runtime, you should consider a container immutable and ephemeral. Stop thinking about it as a mini VM. Build your container (presumably pip-ing in all the libraries you require) on the machine with full network access, then export or publish the container image and run it on the machine with limited access. If you want updates, you regularly rebuild the container image and repeat.

Alternatively, even at build time it's fairly easy to use a proxy with docker, unless you have some weird proxy configuration. I use it here so that updates get pulled from a local caching proxy, reducing my internet traffic and making rebuilds quicker.

postgres

I never use it for databases. I find I don't gain much from containerizing it, because the interesting and difficult bits of customizing and tayloring a database to your needs are on the data file system or in kernel parameters, not in the database binaries themselves. On most distributions it's trivial to install the binaries for postgres/mariadb or whatnot.

Databases are usually fairly resource intensive too, so you'd want a separate VM for it anyway.

what would I gain from docker or other containers?

Reproducability.

Once you've built the Dockerfile or compose file for your container, it's trivial to spin it up on another machine later. It's no longer bound to the specific VM and OS configuration you've built your service on top of and you can easily migrate containers or move them around.

Because you're bored. It says so right in the title.

Personally I don't see the point of changing the shell either. Bash is more than good enough for my use and any other shell is going to have the disadvantage of not being the ubiquitous standard so it is always going to have an uphill battle to dislodge bash.

That said, if people want to play around with a new shell just for the sake of it, why not? I like to play around with exotic window managers myself, not because my regular plasma desktop doesn't suffice, but because I like to try something different every now and then.

That's just retconning/backronyming it.

/usr does historically stand for user. It's where the user home directories were on old Unix versions.