r/linux • u/AcidOverlord • 1d ago
Historical Why did Docker take off, but Nspawn didn't?
Topic title. Docker is so ubiquitous these days in the public dev space that it's almost unreal to me. It seems like a good 70% of FOSS requires it - and with it all the loquaciousness of YAML and Docker compose. I use it, because I have to.
But whatever happened to the humble systemd-nspawn container? It gives you roughly comparable size to most Docker containers, is (IMO) a heck of a lot easier to configure and run, is portable across systemd systems everywhere, and has been a native part of the Linux ecosystem for over a decade. Was it just Kubernetes coming out the gate swinging that caused Docker to take over the world? I still prefer nspawn, and use "full stack" containers for deployments of things like edge ingress nodes because its fast, simple, intuitive, and hard to screw up.
156
u/whiprush 1d ago edited 1d ago
User/developer experience.
https://nspawn.org (the website) does a great job selling nspawn but that only recently started existing. If you wanted to use this stuff you had to go deeper into linux.
K8s didn't help with docker adoption it forced docker to cede container standards to the community (Which they did with OCI, splitting up, containerd, etc). Docker had already "won" the developer hearts and minds, that part of the war was scalability and monetization.
Nspawn and friends are more getting more attention now because agents need to be hard-sandboxed and there's nice tooling in place already there.
EDIT: this chapter of the k8s documentary is a good summary: https://youtu.be/BE77h7dmoQU?si=yC_zj9WXNQap51IA&t=178
EDIT2: There's tons of activity in this space right now with sandboxing in general. gVisor's getting donated to the CNCF (app sandboxing), and tons of things that were boring are now interesting to people again. There's a ton of these coming out of AI startups, etc. I think with podman you can just with krun and be ok? (Do any of you know?)
14
u/TheNeronimo 1d ago
nspawn sandbox > docker sandbox?
14
u/edgan 1d ago
I am personally using Incus. The persistence and the ability to SSH in are very nice.
8
u/Britzer 1d ago
I also use Incus.
I think the use case is different from Docker. I believe Docker is an app deployment tool like Snap or Flatpak, while Incus is a virtual machine host like KVM/Qemu. The technology says otherwise, but to the sysadmin it looks that way.
I don't know what category Nspawn falls in. I suspect also vm and not app, which explains Docker's position.
3
u/_Masked_ 1d ago
Incus just organizes the configs and networks for qemu, lxc, and oci containers. It doesn't do anything special under the hood (in terms of containers and such)
3
u/GolemancerVekk 1d ago
Incus is a management tool on top of LXC and KVM that provides a unified interface.
There are 3 levels of abstraction that are typically sought: app containers, system containers, and virtual machines. Docker manages app containers, Incus the other two.
The difference between app and system containers is first of all logistic and organizational, but there are also differences in the engines that run them. While the kernel capabilities are the same, the engines are different in what features they expose.
7
u/TampaPowers 23h ago
Every piece of software that went "just grab the docker container bro" I have found hostile to admin in the long run. Either these containers behaved more like Schrödinger's cat or they just randomly, for no reason at all, decide to fail just consistently enough that you had to monitor things. Sure you supposed to do that anyways, but I have never seen nginx just outright explode just idling around for months or years.
I admit, I'm not a fan of the container idea, especially when it is applied liberally despite not being strictly necessary. I get that everyone hates dealing with things like grafana cause that never works right even if the system has all the deps it wants, but in certain cases the whole container setup added more complexity and a layer of failure that just isn't needed.
Same problem with snaps and LXC or even appimage. So much of this is to solve a specific problem a way that exchanges one issue for another. What wins is what ends up having the easiest way to make it look like a problem was solved. Even if that creates new ones down the line. A lot of the success also came from the microservices nonsense that everyone got so high on they'd microservice their metabolism if they could. Early docker failed a lot, but because tools existed to mask that it never got a bad rep about it outside of memes, at least with the folks that didn't have to deal with the fallout of the failures.
It being somewhat independent also helped. Association ends up a big factor in a lot of software choices. After their recent screw ups I'm certainly not interested in anything Canonical comes up with, even if it solves a problem I have. Reputation there goes a long way.
1
2
u/AcidOverlord 1d ago
This was kind of my gut thought as well. Even just the name "nspawn" kinda sounds like a VD parasite. My use case is different from most - I run them without veth, close to bare metal, limits matched to the host, and with the full stack built inside and preconfigured. Upload it and a oneliner command and our network has a new node with very very little container overhead. I love it.
If I was installing a single fat app somewhere then I'd give it to Docker. But Nspawn beats it in convenience for installing a full stack environ in one shot so easily. JMO.
2
u/mralanorth 17h ago edited 17h ago
I didn't know `nspawn` was a separate project now. I used systemd-nspawn ten+ years ago for a bit and liked it. These days, if something needs a container I use podman though. I prefer the ergonomics of podman to Docker. I will have to look into nspawn though to see how it's changed.
2
u/zapman449 1d ago
DevEx is key. Open sourcing the docker registry also was key… before quay or ECR, self hosting a registry was easy. Made adoption super easy.
3
87
u/razorree 1d ago
there is also Podman, quite big as well.
41
u/92838388292 1d ago
+ 1 for podman, rootless
6
u/TheG0AT0fAllTime 1d ago
+1 again for podman rootless containers out of the box are great. Changing to it from docker was an easy experience.
And I've run a few containers with an init system too which is very nice. You can even ssh into them which is perfect. Though these aren't podman-exclusive features.
2
u/Die4Ever 1d ago
I need to try to move my Lemmy instance over to Podman, I love the idea of rootless
27
u/sndrtj 1d ago
love podman with quadlets
17
u/stormdelta 1d ago
I love them for what they enable (straightforward rootless containers), but fuck quadlet syntax and how buried errors and failures are. You practically have to build your own front end with scripts to do anything with it.
Not to mention the incompatible option syntax between runtimes. Also even though it's not podman's fault, I hate that two of the major runtimes look like typos of each other (crun vs runc).
14
u/tomikaka 1d ago edited 7h ago
What? You configure quadlets like you would any systemd service. You use journalctl to inspect logs.
I don't understand your problem.
8
u/stormdelta 1d ago edited 1d ago
You configure quadlets like you would with any systemd service
That's part of the problem, systemd syntax isn't meant to handle the kind of complex configuration you run into with containers. There's a reason kubernetes uses JSON-compatible formats.
It's also a messy multi-step process to do almost anything:
The files have to be in a specific common directory separate from your actual project or config. Yeah you can use symlinks but it's awkward
You have to remember to call daemon-reload between nearly every single action or change, with no feedback
You have to manually stop and start individual containers to apply changes, there isn't a way to group containers like with k8s or compose
Errors in quadlets result in systemd acting like the service no longer exists, you have to manually dig into systemd state or manually call the quadlet generator yourself
Startup errors require manually inspecting systemd state and status, and there's no way to get that output in something structured like JSON
You have to pass extra flags to nearly everything, e.g. journalctl's output is unreadable without the flags to re-enable text wrapping, both journalctl and systemctl require
--useron every call, etc.6
u/JebanuusPisusII 1d ago
A couple of nit-picks.
Poznań supports Kubernetes YAML files. Not all of its functionality, but for a local group of containers it's great, and you can have a kube quadlet with everything set up properly in there.
Also, containers listed in that pod are grouped and reloading and restarting them gets the whole bunch.
Otherwise yeah, there are many things which could be done better
2
u/stormdelta 12h ago
Poznań supports Kubernetes YAML files. Not all of its functionality, but for a local group of containers it's great, and you can have a kube quadlet with everything set up properly in there.
I wasn't aware podman had this feature, that's interesting - I'll have to try it out later, as this would dramatically simplify management of my home setup + I'm much more familiar with k8s.
Also, containers listed in that pod are grouped and reloading and restarting them gets the whole bunch.
Supposedly but I kept running into issues with it - I don't recall offhand exactly, but I ended up wrapping it with my own scripts to manage the individual containers and haven't revisited it.
5
u/todd_dayz 1d ago
You could fix a lot of these issues with some bash aliases. I agree that deploying quadlets is very annoying though, I have the same issue and I was going to make a thread about it because there’s go to be a better way of editing and deploying quadlet changes than manually copying.
2
u/Minkipunk 1d ago
There is grouping, it's called podman pods and it's working fine with quadlets. I use it for homeassistant with a few additional containers in a shared network namespace.
2
u/Business_Reindeer910 1d ago
The files have to be in a specific common directory separate from your actual project or config. Yeah you can use symlinks but it's awkward
I bring this one up and everybody who has ever replied does not understand why it is a problem.
I just want to use it as a replacement for docker-compose, but they don't get it :(
3
u/sndrtj 23h ago
There is podman-compose as well.
I do think compose and quadlets solve really different problems. Compose is great for quick iteration, local development etc. I agree quadlets are annoying when you need to build your own containers. Quadlets are great if you want to run some containers long term and have them managed by systemd.
2
u/Sentreen 14h ago
Quadlets are great if you want to run some containers long term and have them managed by systemd.
I am in the process of moving my openrc + compose over to systemd + quadlet for exactly this reason, and the improved integration is just so much nicer. Agree that debugging it is a bit of a pain though.
1
u/Business_Reindeer910 18h ago
The thing is, it''d be nice to have those filse local to a project, but still plugged into the overall systemd based system so it knows what is running and isn't and can follow the same service dependency chain
2
u/MufasaChan 15h ago
In other words, pro's is systemd, con's is systemd. Sure the curve is steeper and not every usage benefits from systemd. Notably if you just want a compose. In other quadlet is not "handy container-based tool", it's "manage your container how you would manage your systemd services"
You can group with systemd ordering, just the quadlet abstraction leaks, you have to know that quadlet generates systemd unit services, which is transparent. Also there is the pod thing. lnav has been a big W for my journalctl.
1
u/boomertsfx 9h ago
Can you easily do stacks like docker compose (and the related interdependencies, networks, etc? I love the rootless concept and prefer bind mounts vs volumes, but I’ve heard horror stories of subuids and all that fun stuff..
6
u/Adept_Percentage6893 1d ago
for what the OP is talking about, Docker and podman fit into the same "OCI" category.
24
u/fbn587 1d ago
All the image building and sharing stuff with the Hub helped a lot for adoption and leading to creation of some standards like OCI, creating an ecosystem around it. Docker Compose also played an important role. One last thing that played a role is that it "replace" somehow the Linux packaging stuff which is terrible overall, especially the build experience of DEB and RPM. I never understood how to build a f*cking deb, put some files here and there and call Perl wrappers with weird name all around... should be fairly easy no ? Docker is clearly not a perfect solution but the ease of putting binaries in a sharable tar.gz from a glorified script (that's an OCI image basically) was enough.
nspawn in other hand was a testing tool for systemd development at it's core and never implement such things, with an UX that feels less friendly tbh. I really like what nspawn can do, I used it for quite some time but I now prefer LXD/Incus for those kind of deployments as they recreate this idea of shared images from an image server, with a more or less similar UX to Docker overall.
4
-3
u/Kriemhilt 1d ago
I never understood how to build a f*cking deb, put some files here and there and call Perl wrappers with weird name all around
This just sounds like a skill issue, there are plenty of debs to look at, and lots of documentation.
I haven't even done it very often, so it's not muscle memory, it's just not that hard. It's only building an archive.
0
15
u/natermer 1d ago
systemd-nspawn container
You are comparing apples to oranges.
Docker provided a cheap and effective way to do Linux containers, it provides a file format, it has tools and commands for writing and building container images, it has desktop application, and a way to distribute images.
systemd-nspawn only provides one of those things. It was originally designed to provide a alternative to chroot().
Docker comes from a older "Virtual Linux Server" developed for web hosting providers. Things like Linux VServer and OpenVZ were designed as a lightweight way to isolate many webserver environments on a single system image. Much more efficient then doing virtual machines. However they required special Linux kernels to work.
IBM developed LXC as a reference implementation for Linux namespaces + cgroups when those features were being added to the Vanilla Linux kernel. Docker was originally based on LXC, but quickly developed its own improved engine.
This is why docker got popular. It replaced already popular solution, but this time it didn't require a special kernel modifications.
In addition to this...
Nowadays "Docker images" are not really docker images anymore. The container image is standardized as "OCI images". It is pretty much the same as older docker image format, but just standardized. Nobody uses the original format. There really isn't much difference, though.
Everybody and their mom supports OCI images.
Kubernetes, docker, podman, and even systemd-nspawn and LXC support it nowadays.
OCI images can be built using docker commands, but there at least a half a dozen other common ways they are built.
Hosting OCI images is drop dead easy nowadays, as well. It is pretty much standard part of any software that does any sort of CI/CD/Git stuff. Github supports hosting images as build artifacts.. as does Gitlab, Gitea, Forgey, etc. etc.
OCI images are used as part of distrobox and toolbx. Systemd has native support for OCI through both nspawn and through quadlet podman configuration. You can use ansible to configure that sort of stuff pretty easily.
Flatpak can use OCI images.
You can even boot OCI images from bare metal using boot-c, if they are built to include kernel/init/etc.
45
u/nonFungibleHuman 1d ago
Why didnt jails take off...
8
u/gplusplus314 1d ago
My theory is because of the BSD licensed kernel. As painful as the GPL is in certain situations, it does create a level playing field in the Linux kernel.
Lots of stuff has been effectively stolen from the BSDs, completely legally, which is a double edged sword. Yes, it’s “more freedom” than Linux, but it also means it’s a total free for all. Having an upstream kernel that all corporate entities must agree on to cross-function is what enabled these bigger, more impactful projects.
-1
u/idontchooseanid 1d ago
So where are those perfect, really expensive containerization OSes all stolen from BSDs?
Linux was at the right place at the right time and it being GPL saved GPL. BSDs having a lot of legal trouble with ATT didn't really help them so the corporate contributors (who wanted a free of charge Unix system to bundle with their servers to get US government contracts) went to Linux. Without IBM and Intel's early (and continued) contributions, Linux wouldn't be what it is. They took it from an academic and hobbyist system to an actual well-optimized OS which attracted other companies to also support it with developers. Once Linux had enough critical mass, there is not many people left to contribute to BSDs and it was too late when the legal hurdles were resolved for the BSDs.
Note that the majority of the components you use on your very Linux desktop are permissively licensed not GPL.
5
u/GolemancerVekk 1d ago
BSD's legal hurdles lasted from 1992 to 1994. In 1994 the Linux kernel was just reaching version 1.0.0, while BSD was already an accomplished OS well into its 4th generation and benefiting from all the UNIX experience before it.
The USL lawsuit may have helped Linux make up for some of BSD's head start but it's not fair to blame it for everything.
There was a lot of in-fighting for example among the contributors to 386BSD which led to it being forked into FreeBSD and NetBSD in 1993. It often gets mentioned that if Linus had BSD on the 386 he wouldn't have started writing Linux but he did that in 1991 and 386BSD started in 1989.
2
60
u/imbev 1d ago
Dockerfile is a universal syntax for declaring images based on every distro. Docker images are pulled from DockerHub and may be run in a single command on any host system regardless of container base image.
systemd-nspawn (and chroot, jails, etc.) are simply less convenient to build and share
21
u/tadfisher 1d ago
systemd-nspawn is a tool to start and manage namespaced processes, and one of the formats it supports is OCI-compliant container images, e.g. Docker images from DockerHub. Images are more-or-less exactly as convenient to build and share as images built with Docker tools. You can also use podman or even a distro package manager to make them.
24
u/mikaelld 1d ago
Since OCI wasn’t a thing yet when Docker took off I kinda doubt systemd-nspawn had that possibility back in the day. It’s probably a good alternative for running container images on systemd hosts nowadays though.
16
12
u/pastelfemby 1d ago
It does support oci containers but actually grabbing the layers, extracting, and configuring it up ends up being more convoluted than what other oci compatible container setups enable.
That said they are working to make it a lot easier, see: systemd-oci
16
u/pastelfemby 1d ago
I do use nspawn and like it a fair bit. That said:
Deploying oci compatible images from registries isnt nearly as simple
Most people assume wrongly that nspawn is only for "machine" or "system" containers and not application containers, much less distroless ones.
GPU usage is a bit more convoluted with all the binds rather than just using nvidia's oci runtime or similar.
Nspawn cant leverage oci runtimes like gvisor or kata containers for further isolation. Nspawn also originally had a lot more limited configuring of security parameters and for a while wasn't considered "production ready" in terms of that.
However nspawn is something just about every modern linux system has. iirc Meta uses it with Muse for isolation, Microsoft has their Azure unbounded for k8s using nspawn, and I'm sure theres various other uses of it by larger entities.
For better or worse nspawn mostly ends up being more a tool used by developers, rather than a tool used for deployment.
14
u/strawberrycreamdrpep 1d ago
Because docker has a cool name and a cute little whale mascot thing
3
u/SwizzleTizzle 1d ago
Yeah, and people love to shorten things when talking colloquially.
"Hey man, check out this docker I made"
I'm not sure many people would go "hey man, check out this systemd-nspawn I made"
6
u/james_pic 1d ago
Docker wasn't the first tool to do the things it did. LXC is older, and IIRC the early version of Docker were essentially wrappers around LXC with a better developer experience. And the better developer experience (opinionated defaults that aligned fairly well with common user needs, a straightforward image build process, tools to share and reuse images) meant it won out.
Systemd-nspawn is also older, and also tried to do the same things, but its adoption was likely hampered by the fact that Systemd was only available on RedHat in the early days. Debian and Ubuntu didn't adopt it until 2015, by which point Docker was well established, and some distros still don't use it.
1
u/NeverMindToday 20h ago
Yeah Docker's initial claim to fame and hype wasn't being able to run containers, as that bit wasn't new.
It was the packaging story and repeatable workflow around building and distributing images so anyone could just run stuff the same way anywhere. Hence all the container ship imagery - it was about shipping and their messaging was comparing Docker to the introduction of standardised shipping containers vs the old way of every cargo needing to be handled differently.
The image filesystems built on layering and diffs combined with a central image hub was their breakthrough - not the container runtime part. Not only were their early versions built on LXC, but LXCs runtime used all the same kernel functionality Dockers own one later did.
3
3
u/bubblegumpuma 1d ago
There's not as much prominent documentation for running ready-built application images inside of nspawn containers as Docker/Podman containers, and translating a Docker container to run as a systemd-nspawn container isn't exactly easy as far as I've tried.
I personally learned about nspawn from this relatively new page on OpenWRT's wiki about setting up a build environment. This is a great introduction to the chroot-on-steroids use of nspawn IMO but it really doesn't cover how one would start containers from boot to run applications like web services, for example. I'm on NixOS on many of my systems, so I've primarily done that via NixOS interfaces for nspawn containers, but that is obviously not a standard thing.
3
u/bprfh 1d ago
because docker containers did a few things:
-Centralized container registry
-A nice configuration format
-Network configuration and storage management
Technically a linux administrator will do everything above farily easy with standard linux tools, but docker enabled developers to "forget" about the envirnoment and only care that docker is installed and runs, it abstract a part of the stack.
4
u/h0uz3_ 1d ago
Docker, as a tool itself, had to compete to other tools like Vagrant. The connection to k8s is not necessarily that k8s used Docker in the past, but moreso that k8s, Rancher, OpenShift, Docker, Podman, Apple Containers etc. bring implementations of the common OCI standard.
So Docker started this type of containerization and the wording is still mostly based on Docker (Dockerfile, Docker Compose, etc.) but it technically is one of many OCI implementations.
Jails, nspawn etc. are very different in what they do and how they work. Just as Vagrant fell out of fashion a few years ago I can imagine other Container-standards can rise to the top within a few years.
2
2
u/Dwedit 1d ago
What about LXC/LXD?
1
u/TampaPowers 23h ago
Found that a lot less hostile to use than docker so it's a mystery to me why that isn't preferred
3
u/EizanPrime 16h ago
I actually saw lennards talk about nspawn in fosdem years ago and talked about it with him.
The goal was never to replace docker, it was first of all to make it easier for systems developers to develop. Its more for thinkering with your machine rather than do developpement and deploy stuff like docker and podman.
Like in the case of docker/podman those declarative Yaml and docker files suck if you just want to run firefox in a container, but are useful if you want to deploy stuff on the cloud.
4
u/lazyhustlermusic 1d ago
Why did VHS beat Betamax?
8
u/AcidOverlord 1d ago
Adult content, as the old history used to say, lol
2
u/za72 1d ago
Same with HD-DVD vs Blu-ray - Blu-ray had adult content
4
u/RC2225 1d ago
I think thats just to big of an oversimplification as is my comment . VHS was cheaper and had longer recording times. Bluray was shipped with any PS3. So a lot of people had already player then. Also i would argue that DVDs even won over Blurays. They are still way cheaper than a 1080p bluray
4
2
2
u/steakanabake 1d ago
im sad the porn industry didnt help VR take off better. D:
1
u/stormdelta 1d ago
It sort of did honestly, but:
cheaper VR hardware was tied to companies like Facebook nobody would reasonably want to do anything porn-related with
Better or more independent VR hardware is expensive
Earlier VR hardware required a lot of setup
Most VR headsets are still pretty heavy and awkward. I think the Steam Frame is literally the first standalone headset under 500g, and even less than that for the weight on the face since it's also one of the only ones to put the battery on the rear of the head for balance
1
u/stormdelta 1d ago
The five syllable name didn't do HD-DVD any favors on the marketing front either, especially as there's no obvious shortening of it.
Pretty much all widely used media formats I can think of are three syllables or less in the version commonly used.
2
u/mr_dfuse2 1d ago
why did git became more popular as mercurial? marketing, branding, ease of use with an ecosystem like github
9
u/BradGunnerSGT 1d ago
GitHub didn’t exist for years after git was created. At first you just declared one instance of the repo as the “master” by convention and everyone used SSH to get to it.
There were several “forge” type apps that grew after git became popular and GitHub was the one that won the popularity contest.
0
u/mr_dfuse2 1d ago
yeah i know, i used to admin git servers for companies back in the days. really took off with github though
3
1
u/urbanignition3623 1d ago
Docker basically became the "it just works" button for developers. The whole layered filesystem thing meant you weren't shipping a full OS image every time you tweak a config file, and the registry made sharing containers stupidly easy. Plus once the CI/CD pipelines started baking Docker in, it was game over.
nspawn is great for what it is, but it never got that glossy developer experience layer. Most people don't want to think about cgroups or systemd units when they're just trying to ship an app.
2
u/_shulhan 1d ago
My assumptions is most of the big company and developers out there are running Windows/macOS, either for compliance or they just used to it.
Linux is run on the server/cloud that only some people can touch, aka sysadmin
When the "DevOps" get its hype, this new people wants to bring the prod environment closer to dev. Somehow, the people behind Docker built around that time and their very closer to mainstream developers (read Silicon Valley). Both of them connected, and spread at the same time.
The same question to why PHP is so prevalent while ago, while Perl is only on certain area.
1
u/fuhry 1d ago
I always saw them as fundamentally the same technology (containers) but aimed at two very different use cases.
I use systemd-nspawn for long-lived, bespoke containers that behave more like virtual machines. They're created manually and use bridged networking, so they have their own IP addresses are first-class citizens on the network. Remote access occurs via SSH, and they are managed using Puppet like my other bare-metal hosts (migration to Openvox in progress).
This makes sense for my fairly-traditionalist setup, where one starts by picking a distro, getting it installed and booting, then installs the necessary packages, assembles configuration files, and enables and starts services.
Docker-style containerization does a complete 180° turn on this traditional "systems administration" workflow. You start by picking the application you want, and the container image comes with the entire application and its dependencies already installed and ready to launch. The distro is basically irrelevant.
The nspawn command discussed here brings the latter workflow to the former use case, and honestly, I don't see the need that it's filling, at least for me. Docker, podman, etc. already satisfy the need for OCI based workflows. I see systemd-nspawn as filling a different niche.
1
u/Adept_Percentage6893 1d ago
You can run docker containers on windows and they were, one upon a time, going to support BSD jails as well. I don't think the latter ever happened, though.
Docker just had a novel approach regarding ephemerality. When Docker first came out you could pretty much guarantee two things would get mentioned "the containers are ephemeral/stateless" and "layers" because both approaches were seen as advantages.
The OCI build model is also just inherently friendlier to professional use because it means your container definitions can be version controlled to that extent because they're ultimately text files in a git repository.
1
u/UnluckyDouble 1d ago
Nspawn is better suited to be used for OS containers than application containers (though it can handle both). Unfortunately, the entire idea of OS containers is niche by comparison to application containers.
1
u/todd_dayz 1d ago
I use nspawn on my home server as a binary package host for my Gentoo laptop, I love it, a lot less hassle than I had trying to do the same thing in Podman.
1
u/Cryptikick 22h ago
Docker is horrible, so is Kubernetes.
I use systemd-containers nspawn daily.
Sometimes I also use LXD/Incus but nspawn just works and is very light.
1
u/the_bighi 19h ago
Because systemd-nspawn isn’t available on 99% of computers. It’s hard to become a popular tool with those restrictions.
1
-13
u/ButterflyMundane7187 1d ago
Docker overhyped, with paid YouTubers, influencers helping create HYPE.
Docker appeard more commercially valuable than its underlying business justified, driving expectations and valuation upward. It was a scam to make verry few people rich.
I tried Docker, and I found it completely useless for anything professional.
9
u/CyclopsRock 1d ago
Don't you find it's weird that so many professionals use it, then?
-4
u/ButterflyMundane7187 1d ago
I do not know anyone that use it. Its banned at my company non of our client use it. Who use it outside the bots of reddit and youtube?
3
u/CyclopsRock 1d ago
My company has 110,000 employees and we use it, but I don't think personal employment anecdotes are that useful. Ultimately the proof is in the pudding - if it wasn't popular, something else would be more popular!
-1
5
u/mr_dfuse2 1d ago
docker was hype before youtube was so prevalent in tech
1
u/ButterflyMundane7187 1d ago
After shady investors around 2014–2015, the hidden marketing with influencers exploded.
And there was a lot of tech influencers way before that time.0
u/pickle9977 1d ago
It’s the same damn playbook everytime too
Mulesoft was the same story, there is an open source service that does the same thing, you think it’s what mulesoft was built off of just sold as a service
But god damn if every Fortune 500 company didn’t sign some big ass extremely expensive license and then tens to hundreds of millions of dollars rewriting software to use it.
0
u/kimoisune 23h ago
Docker is a whole suite of containerization and distribution service while systemd-nspawn is just a container spawner. You are comparing a plumber tradesperson to a pipe wrench.
223
u/DonkeyTron42 1d ago
Marketing probably. I've known about Docker for a decade but never heard of Nspawn.