Hacker News Reader

Comment by jason0597 | Hacker News Reader

The author is absolutely right here:

>The developers of the New World Order will assume, always, you are running Linux, as Ubuntu, and you always have Docker.

It sure doesn't seem like these projects are *NIX compatible. What happened to traditional bash scripts, chroot profiles and Makefiles?

It reminds me a lot of the systemd debate. I wonder where the old school sysadmins are to lecture us on the evils of writing everything for Docker and Ubuntu only, like the old Debian neckbeards did against systemd

View on HN

> What happened to traditional bash scripts, chroot profiles and Makefiles?

They're gone, and it's not for the worst. Have you ever tried editing a 1000+ line Makefile or debugging an insanely large bash build script with all these assumptions baked in? Bonus if the shebang requests sh, but it actually needs whatever shell the author has.

Docker is just static linking taken to the max. It's so ubiquitous because it works well. Yes, these Dockerfiles could have been written better, but the equivalent shell files would have been worse.

People fail to realize Docker is about packaging.

If the author uses docker and you don’t use docker, repackage it yourself! Don’t blame the author for not limiting himself.

I’m a big fan of containers, but we oughtn’t hold Dockerfiles on a pedestal. They kind of work, but you have to shoehorn a dependency tree into a linear list of layers in a futile attempt to make build caching work. Moreover, they aren’t reproducible as they tend to rely on arbitrary network calls. To a lesser extent, the semantics are also “imperative commands” rather than “packages to be installed” which is the more natural way to think of composing an image.

I’m of the impression that the underlying BuildKit exposes the requisite dependency tree structure, but it hasn’t found it’s way downstream into the Dockerfile representation (to my knowledge, anyway). There’s also Nix which supports building arbitrary images with an elegant conceptual approach, but everything about Nix in practice seems unworkable for professional software development.

A standard optimization for reducing overhead is to Alpine based images.

Similar quite a lot of official docker images people base their images one are Debian not Ubuntu based.

And a lot of Linux server work in certain sectors is based around RedHat.

Similar docker gets in a lot of areas replaced by podman (through I guess for this discussions we could treat them as being the same).

Lastly outside of server space (and ignoring embedded Linux) Steam Os (Arch based) might have interesting effects in the future (due to the Steam Deck, which IMHO is very promising).

So I'm not really seeing everything written for `Ubuntu` only, through a lot of things will target Docker with whatever they like as a base.

Through then we would need to consider what we mean with "everything".

I mean the situation around Games, multiple Server scenarios, Embedded Linux and multiple scenarios of desktop Linux differs. Sometime quite massively.

E.g. Linux Gaming is/will be eaten up by proton, independent of weather it's proton on Steam Os (Arch derivative) or proton on Ubuntu. Similar in a University related context the large majority of people I meet which did ran Linux did ran Ubuntu. But outside of a University related context it was pretty much the opposite and no one I meet ran Ubuntu (anymore, may did in the past, e.g. in University, but switched and stayed away from it since then).

E.g. if the Steam Deck is not just successful but also stays successful then in a few years more "Desktop" Linux systems might run Steam Os (Arch derivative) then Ubuntu (partially because the university Ubuntu share seems to be eaten up by Windows and their subsystem to some degree).

Steam games that target Linux usually do only target Ubuntu. They work on other distros because Steam bundles a ton of libs internally so that the games use those instead of the host OS's. It's essentially the same situation as if each game was a Docker container with an Ubuntu base image.

Also, given the few host OS dependencies that Steam needs are 32-bit libraries, I find it better to not install 32-bit packages and pollute my OS by just running Steam in an Ubuntu container anyway.

If you don't want portability design exclusively for Docker and specific Linux distributions. Otherwise see what happens when compiling on other OS families like BSD and Windows. Popular tools are broadly available on many different platforms. Why? Because of portability and keeping the number of dependencies as low as possible and optimized to be compiled by numerous compiler vendors. Sticking to Open Standards and time proven RFC's improves the projected lifetime of tools like rsync, curl and ssh to name some examples. Projects going for the narrow audiences and assume the availability of Docker, systemd and dbus limits the users of the software or tool at hand. What's going on with the number of name resolvers on Linux. These truly make simple things less opaque and ever more confusing when compared to the origin of all, UNIX and BSD operating systems. Microsoft 'Love's for Ubuntu will without doubt only stand to gain Microsoft in the long term. The telemetry and always changing the narrative on how things must go forward within the vision of Microsoft will aim to kill compatibility and the power of the users to choose another platform and bring with them the applications they like to run. This freedom is not available when all software assumes one very specific type of MS blessed Linux/win32 honeypot. The telemetry is the most important feature, all else comes second to Microsoft, Google and Amazon. Are you enjoying VSCode and GitHub now? Skip to 2030 and you will absolutely hate it. Freedoms will be taken away, code will be assimilated and terminated, see the YouTube downloader saga as example of things to come.

> The author is absolutely right here:

I disagree. At most the author complains about packaging, and singles out a specific Linux distro as being very popular as a base image for Docker containers. For some reason the same author ignores the fact that Alpine-based images are highly favoured as base images because they allow the same software to be packaged and distributed without requiring hundreds of MB of bloat.

Also, it's irrelevant which base image was used to package an application. All that it matters is whether running '$ docker run <image>' is enough to run the app. The answer to that question is an unequivocally "yes" regardless which Linux distro you're using, and that's the exact opposite of Linux being dead. In fact, Linux is the OS of choice for deploying software, and that isn't really compatible with the notion of being dead.

Docker ecosystem itself is just pure bloat. I already have all the tools to build and use thirdparty software in my host distro. Why should I need another [untrusted] copy.

> Docker ecosystem itself is just pure bloat. I already have all the tools to build and use thirdparty software in my host distro. Why should I need another [untrusted] copy.

I don't find this argument is reasonable at all. Just because someone uploaded their half-baked package into a registry that does not mean you are expected to not package and maintain your own application. In fact, it's crazy to rely your production system on whatever package any random person made available to the world.

Dockerfiles are easy to edit and validate. Building is just as easy. A container registry saves some time in terms of spinning up a new instance but if you've got a vital service running in a container it makes sense to take the time to validate any updates and test any changes before replacing the old one.

How is Docker exempt from this, though?

More likely, you're exposing yourself to more random people, when using docker, because you may now be using Ubuntu on top of Arch Linux host, or whatever.

Exactly. How can I run my FORTRAN projects now? Many distros don't even package a compiler!

Reply on news.ycombinator.com