Linux is dead, long-live Docker monoculture
antranigv.am
antranigv.am
>The first one that came to my mind was Gatus.
Gatus's readme heavily implies it's meant to be run inside Docker, let alone be built inside Docker. The "Deployment" section only lists Docker-based methods, points to an examples tree that only has Docker-based methods, and has a "Using in production" section that redirects to the "Deployment" section. They've clearly intended for it to be run in a Docker, and thus Linux, environment.
>Here’s another one, it’s called statping
The default Makefile target builds Linux binaries, but even from the README one can see that it supports OSX, and within the Makefile one can see OSX-specific targets. Sure there's no FreeBSD target, but the software clearly wants to support more than Linux.
>The developers of the New World Order will assume, always, you are running Linux, as Ubuntu, and you always have Docker.
The developers of the "New World" write software for the OSes they use, same as the old world. Linux users write Linux software. FreeBSD users write FreeBSD software. Only when they cooperate on the same software does that software work on both OSes.
Unix is less portable than the author thinks. Source code usually isn't 100% compatible between any of the BSDs, let alone between FreeBSD and Linux. If I were the author of statping and was asked to support FreeBSD, I would require not just code and makefile support but also CI support to ensure its quality. Why should I be expected to do that on my own instead of a FreeBSD user contributing it?
> While tweeting with anger, Daniel pointed out that I should tell them kindly and it’ll work out. I’m sure it will. Let’s hope I can make it work first. I don’t like just opening issues. I’d rather send a patch directly.
Sending patches directly is a non-collaborative approach to open source. Issues are made for discussion, and PRs for resolutions; as a matter of fact, some projects state this explicitly, in order to waste maintainers' time with unproductive PRs.
Disliking issues implies (in a way) disliking collaboration. Maintainers who don't respond to issues are unlikely to respond to PRs/patches anyway.
EDIT: Extra context: the maintainers are very responsive to PRs (see history of closed ones¹); writing a rant instead of opening issues and/or PRs is... hm.
¹=https://github.com/TwinProduction/gatus/pulls?q=is%3Apr+is%3...
I don't agree. A PR does not automatically mean that the changeset is good or well thought-out, or matches the architecture. Refusing to discuss a problem or exchange ideas regarding potential changes also raises a red flag regarding the nature of said contribution.
Keep this in mind: just because you believe your patch scratches your itch, that doesn't mean your itch is the problem.
Moreover, it wasn't that long ago that the Linux project had to remove PRs from the repo because a team was caught abusing the PR process.
The PR is nothing more than a request to discuss the changeset. The point is that trying to start a discussion on a problem by skipping the discussion of the problem and instead jumping onto a changeset that's proposed without considering neither the problem nor the constraints can and very often is a complete waste of time for all parties involved.
Let's frame it the other way around: what is there to gain by not getting up to speed on the design constraints by refusing to onboard or even engage with the maintainers?
This makes no sense. Why does the subject of a PR have to be a specific version of a specific changeset? Why can't the discussion be the subject, with the supplied code changes be considered a supporting "attachment" for the discussion? PRs allow for commentary and discussions.
In fact, PRs let you do everything an "issue" let's you do, but not vice versa. You can't "attach" code changes to issues. Not without creating a PR anyway.
----
Let's not forget what GH-style "issues" and "pull requests" were supposed to emulate and replace: email threads. While GH's UI elements are better at most things than emails, they're not better at everything. Emails are a lot more flexible and powerful, even if not as "pretty". PRs? They can't even let me suggest code changes (when reviewing someone's PR) using my IDE/editor. Or even suggest a code change that's not contiguous. Diff-of-diffs is a concept that GH has barely understood, but one that's just obvious with plain emails.
Usually my only engagement with maintainers is when their library doesn’t do what I want it to do for whatever reason and is in the form of a bug fix (or less commonly an added feature).
I don’t want to ‘onboard’, I just want to use the software and since I spent the time figuring out why it was failing me I ‘pay it forward’ with what I found —- which is usually a diff of my changes.
Absolutely no desire to attend committee meetings to discuss the social ramifications of my changes or whatever they get up to these days…
This requires that:
1. The patch come with no commentary that says it's a WIP; and/or
2. The maintainer(s) do not read any attached commentary (when and why did we stop reading commit messages?!); and
3. The maintainer(s) do not read/care that the patch is wrong.
----
In short: your scenario works only when everyone does their job poorly.
So, your point is that something is bad because it's /possible/ everyone involved with it could be terrible at their jobs? If that's your point, then I can't imagine why you'd try to make it, because it applies to nearly everything in the universe of "doing things".
Similar to your original comment of "You've now made a patch that you don't understand.", you've now made a point that you don't understand.
In fact, I do this even when reviewing code: a branch that I can pull from & push to is a lot more welcome than a word vomit I have to interpret and translate to (or from) code.
I'm all for doing things the maintainer wants, but to say not using issues is non-collaborative is pants.
This is the way I’ve always done it —- find a bug, figure out a fix and shoot off a patch attached to a bug report. Or, software doesn’t do what I want, hack it into submission then send a PR with a patch.
Worked well so far. Sometimes they don’t like my code for whatever reason but that’s OK, I tried.
The only real exception was when I contributed on a regular basis to one of the larger FLOSS projects where I’d usually run my changes by the module owner to get their feedback before committing since it was just good practice. Not always though.
The rant leaves out all the important parts. I am curious to see what those reasons are beyond personal pet peeves and if they actually outweight the benefits of standardization so that people can worry about bigger issues.
I'm not sure about this idea. Usr local is where you'd install something you've compiled & installed locally:
"The /usr/local hierarchy is for use by the system administrator when installing software locally." from https://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALH...
So usr local could be fair game for whacking stuff in your firms base docker image that you then layer your firms product applications on top of. It'd be your unix engineering person putting stuff in /usr/local, not your app dev.
"/opt is reserved for the installation of add-on application software packages." from https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC...
Opt would be a better fit if we're sticking to the FHS. Think about what you'd usually install in /opt, maybe your veritas binaries. Maybe your AV solution. Maybe your ERP software product. etc. etc. Opaque binaries you got from a vendor.
That's a better match for an application product you're shipping - which is what you're doing with the second docker image (the bit starting "from scratch") in the article's example dockerfile.
That said, the FHS evolves based on conventions and /app for docker containers has become a convention. I wouldn't oppose just using /app but i do oppose chucking everything in /usr/local - it's a misguided attempt to preserve convention without grasping the convention.
I agree on this, it's a better fit. But I think /usr/local is not a bad fit either as it's fundamentally a "local" installation of a program.
For me it always felt that /opt mainly exists for programs which don't follow the split required by the rest of the file system (bin, include, lib (, lib32, lib64), local, sbin, share, src) and I personally would prefer if /opt simply wouldn't be a think.
Either way for a single application container image placing that specific applications into /app seems fine tbh.. Through sadly as far as I can tell it mainly is that way because it's shorter to type in a Docker file then to repeat /opt/<package> all the time.
At the same time it does feel like there ought to be a more standardized way of converting packages between operating systems. I look forward to the blog post for next week where they detail how to get it all working.
The first victim is security.
Linux distributions like Debian do stable releases and painstakingly backport security fixes to give you both feature stability and security improvements *at the same time*.
The cultures of docker and of static linking makes this increasingly difficult every day. The result is a world where you can only chose between:
- update to the latest release of an application or a library used in a build: Lose feature stability and get newly introduced security issues.
- keep an old container or fat binary around, with all the known security issues unfixed.
Needles to say, this is completely untenable in many high-risk environments. Banks, Health, industrial automation, avionics, trains, cars, military, and so on.
I love docker because I can treat the security of the system separately from the application. As long as I can update Docker with the system I can keep the root OS secure and work individually on each container service. I don't run the risk of updating the server and causing the app to puke. if I update the app and it pukes, I can roll back to the original container while I resolve the problem.
In addition, all my services are slightly more isolated from the underlying OS, which limits exposure if an inherent security flaw is leveraged by a hacker. I guess I don't see why there is so much hate for docker.
By the millions. If you work in security and do assessment for large companies you can find plenty. Then if you add non-Linux system it's order of magnitudes.
> I can treat the security of the system separately from the application > all my services are slightly more isolated from the underlying OS, which limits exposure if an inherent security flaw
Not at all. Docker has a huge attack surface compared to all the sandboxing systems that run rootless and without any daemon.
Also, sandboxes/containers provide limited security and isolation anyways compared to VM.
Furthermore, sandboxes are not alternatives to VMs. E.g. lot of OS services/daemons are sandboxed by default and at the same time the whole OS is deployed in a dedicated VM.
Finally, tons of critical infrastructure runs on bare metal, with one service/application per device. Running a container there is a net negative for security.
The OP's lack of familiarity with Docker, and desire to re-invent the wheel into a different shape, is not anyone else's problem but that of the OP.
There is a reason that the Docker-on-macOS or -Ubuntu monoculture exists: it works (darwin-arm64 aside) without a significant amount of effort, and is generally well-supported by the larger OSS community.
Personally, I'd love to find a batteries-included FreeBSD distribution that is as simple to install as Ubuntu. Not everyone is a true believer, so the barriers to entry should be minimal.
Linux isn't dead. Containers, as RedHat loves to say in their marketing material, _are_ Linux. What is dying is the common ground upon which Linux and other UNIX-like operating systems used to exist, but that's been on the horizon forever with systemd choosing to use new Linux features over portability.
You are always picking an ecosystem alongside your operating system. If you don't like how constrained it is, maybe you need to either work on improving it or jump ship.
This just seems very unproductive.
When I blow away the unwanted containers there is no crap left on my system, no script changing my network behaviors or cron tasks. It's like it was never there. I have no idea how people can have a problem with a system like that. What a time to be alive.
> Of course it requires apt! Because not only we all run Linux, be we all run a specific distribution of Linux with a specific package manager.
At least this code actually spells out the packages it requires and makes it easier to look up the equivalent for yum or apk. I've struggled so much trying to find the right dependency to install before a supposedly simple ./configure, make, make install...
> First of all, let’s talk about the fact that this Makefile is used as a… script. There’s no dependencies in the targets!
As a sidenote, I actually like this style of Makefiles. No need to assume execution permission, and quite frankly it is easier to parse visually than a shell script with if's, case's and getopt.
I'm not sure how docker is a monocultur?
I mean when people speak about docker what they mean is often Linux containers used in a certain way.
But wrt. to the implementation of using such containers there are by now multiple competing implementations, on different abstraction levels (e.g. podman as a docker CLi replacement). To me it looks like docker specifically is currently quietly and (very) slowly replaced/superseded by this alternatives.
Then wrt. docker images there is also not a mono-culture, through it can't be denied that a lot of images are based on just a small handful of base images (Does anyone have any statistics about it?), either way that "small handful" are still enough images to say it's not a monopoly nor very close to it.
I guess the place closest enough to a monopoly is the Docker Hub? But that's easy to replace if necessary.
IMHO UNIX didn't win, somewhat UNIX compatible systems did (like Linux) and UNIX was one of many stepping stones/tools/gears for them do archive what they did archive, and only that. Through yes especially at the beginning it was an important gear.
I would even argue that UNIX never did had a chance to win, it always was only one gear of many in systems with increasingly more gears which become increasingly less dependent on that gear (through it's still quite useful so no reason to remove it).
It's not. Docker uses Linux kernel features such as namespaces and cgroups, and doesn't virtualisation. The only way to run Docker on macOS or FreeBSD is through a Linux-based VM for those Linux kernel features.
PS: why would anyone use Windows for IoT stuff? Seems like a complete waste of resources. And in general, Windows containers are very rare in the wild
Additionally many new security features make use of containers as part of their design, e.g. Driver Guard or SafeKernel.
But that is not enough! It seems they are obligated to write portable code and support all OSes and distributions people happen to use.
I just wrote a small lib to talk to a service I use. I am on macOS and use python 3.9. I suppose it can run I linux or even windows, but I haven touched windows or Linux in 10 years.
Instead of keeping it in my hard drive, I posted it on GitHub. Now people can use it if they want.
If some random guy appears and rant about how dork I am for not making it work with free bsd out of box, I’m pretty sure I’ll be calling names.
Same for me but being on Linux. It's awesome that for certain kind of applications modern programming languages and frameworks will provide you with an API which is most times OS independent.
>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
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.
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.
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.
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.
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 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.
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).
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.