>>110320672
Maybe it isn't as shit as you think it is.

>>110320672
podman
kubernetes for clusters

I just have a dedicated server and install things on it.
No idea why i would need docker as a layer in between.
When there is a vulnerability, it seems to be extra hassle to update the containers AND the system below it, rather than just the system.

The docker salsemen didn't manage to convince me.

>>110320672
how is it shit exactly? it's basically just a rootfs+some package+scripts to run itself, hell i bet you could replace this shit with only chroot and some bash scripting, some program thats hardcoded to check pid 1 might complain or refuse to run, but workaround exists.
you're just angy because you got filtered.

>>110320672
a lot of programmers like things to be as complicated as possible

File: .png (678 KB, 2550x1650)

678 KB PNG

>>110320796

>>110321023
This. It's usually the stupid ones that like complexity.

File: .png (539 KB, 2550x1650)

539 KB PNG

>>110320993
>it's basically just a rootfs+some package+scripts to run itself
wrong

File: 1768179071115745.jpg (12 KB, 250x246)

12 KB JPG

>>110321056
Containers are a stopgap measure against bad software engineering practices.
>you have version 2.1.1 and you need at least 2.2.4
Stop running outdated software
>I'm running an old CentOS distribution from 2014
Stop running outdated software
>server only has Python 3.5
Stop running outdated software
>inb4 but I can't update because muh stability
Have a proper testing suite to not make updates a coin flip. Developers should stop rolling out garbage hoping people would get a hotfix next hour.

>>110321056
In addition to this, you also get the benefit of isolation so a breakage or fuckup with one of the services is usually going to be limited to its own container and you do not need to worry about it causing damage to the host system or interfering with other services.

I do agree that containers are sometimes overused, there is certainly a place for just installing some shit directly on your system.

>>110321085
retard

>>110320672
guix solves this btw

>>110321056
>its easier to deploy
a single apt-get upgrade is easier than 100 times docker compose...

>>110321117
>a breakage or fuckup with one of the services is usually going to be limited to its own container and you do not need to worry about it causing damage to the host system
If your container runs a service that connects to another containers database and it has database access... what do you gain with this?
>dear customers, we got hacked, all your data leaked and our servers are part of a botnet now
>BUT it is running in a container so the host system of the server itself isn't affected, rejoice!!!

>>110320672
> No alternatives at the time?
Pretty much. It was first on the scene to do what it did and gained traction fast. Then once enough people start using something there's a lot of inertia to switch to something else even if that something else is better.

>>110321108
your suggested tight coupling of everything is bad engineering

File: 1.png (150 KB, 480x270)

150 KB PNG

>works on my machine
>ship my machine
Simple as.

>>110321307
what did it do that vagrant didn't do before?

Podman is pretty good.
It even has docker compatible commands for the newfags. Podman is maybe nu-redhat's only useful contribution to the gnu/linux space in the past few years.

>>110321341
Docker was the full application stack, Vagrant was the entire server image which then needed some other third-party tools to install and configure your app inside once it was running. Also Docker containers spun-up in seconds while Vagrant VM's would be like booting a real physical machine and take minutes. Then there was the centralised Dock repo to make sharing images quick and easy.

>>110321359
but nu-redhat dumped podman

https://www.redhat.com/en/blog/red-hat-contribute-comprehensive-container-tools-collection-cloud-native-computing-foundation
>November 14, 2024
>Today, we’re pleased to help drive cloud-native evolution further into the next-generation of IT with our intent to contribute a comprehensive set of container tools to the Cloud Native Computing Foundation (CNCF), including bootc, Buildah, Composefs, Podman, Podman Desktop and Skopeo.

>>110321108
In theory, sure, everyone should run up-to-date software.
In practice, more than half of companies and organizations in the real world, private or public, run at least a piece of outdated software in some form or another.
It costs money and/or takes time to upgrade software and make sure everything run correctly, and people don't like to spend money or time on this when it works fine (until it doesn't), especially managers and executives who only care about short-term profit margins.

>>110321397
>It costs money and/or takes time to upgrade software
I thought AI solved this

>>110320672
I never liked docker or any kind of container distribution since they are by design not to be fucked with. I tried it briefly only to find I couldn't install my CA cert into a container without manually rebuilding the container myself.
It's just far easier to spin up a small linux instance on esxi to run that one task. 1GB of ram and one core is all it needs. On an old laptop you can fit dozens of these and have no issues. Further backups are piss easy since you just backup the whole instance and if you think you or an update might fuck it up, snapshot it first and rollback if needed.

>>110321502
Sure, for personal use that's fine. But at the Enterprise level like when you need 100s or 1000s of instances and rapid dynamic auto-scaling the benefits of containers managed by something like K8s is hard to beat.

>>110321502
>without manually rebuilding the container
That's one of the main issues for me, when I work with it. It's so stupid.

>>110321405
You underestimate how old some infrastructure can be. I vibecode with Deepseek and I'm impressed with it, but I doubt it could deal with the complex maze of scripts invoking depreciated proprietary Oracle products running on RHEL 4 I had to maintain in a past life.

>>110320672
writing systemd service files is too complicated

>>110321541
That's just a badly setup container. Thinks like keys, passwords, and certs should be passed as environment variables or pulled from a (secure) repository.

>>110320672
it's like wondering why young people started talking like niggers.

>>110321502
Adding as certificate should be as easy as
FROM base-image:latest
COPY your.cert /use/share/certificate.cert
On your dockerfile.yml, then a rebuild should just take a minute

>>110321548
That's actually the kind of shit AI is good for, especially if you have any documentation you can throw at it. I've used Claude to update a load of our legacy shit to work on modern systems.

>>110321557
>systemd service files
what black magic is this I want to know more

>>110320672
it's just chroot with extra kernel features

>>110321502
because it's meant to be readonly, so your deployment becomes reproducible.
if you modify your system, it's unclean, no?
the idea is you deploy on a clean slate

>>110321644
So this is the power of dockertards...

File: neutral-pepe-normal.png (179 KB, 720x651)

179 KB PNG

I use systemd-nspawn

>>110321502
>they are by design not to be fucked with
which is a *good* thing.

>>110321056
>durr i'm a fucking retard and i don't know how to deploy my dependencies
>save me dockerman
This shit was designed for mouthbreathers, so they can run babby's first web app on their VPS. It's crazy that no one is willing to admit this, much less do anything to improve this state of affairs.
>>110321085
Combining software deployment and sandboxing and pretending they belong together was one of Docker's biggest mistakes. Half of its sandboxing features were a necessity of its shitty packaging concept. Nevermind the fact that sandboxing properly managed software is both easier and more effective.

>>110321576
If you pass certs, passwords, keys, etc. from environment variables it's no longer reproducible across all devices. Which is their entire fucking point.

>hear me out!
>we need 1000 microservice apps!
>AND EVERY APP SHOULD HAVE IT'S OWN RIP OFF OF AN OS IN SANDBOX CONTAINER!
>GREAT IDEA, RIGHT?! RIGHT?!

>>110322163
It's designed for enterprises that have thousands of developers and hundreds of instances of software running across their servers. I remember the time when every single developer had a virtual machine they were responsible for running. And when we deployed shit either straight to the servers or to a virtual machine. And the teams running those were responsible of keeping them up to date and running.

You had hundreds of VM images floating around and when some retard inevitably nuked their VM to an unrepairable state they spent a day looking for an somewhat up to date VM image to start from and then deploy all the packages needed. Someone fucked up your test server? Have fun spending a day or two restoring it back to a usable state.

With docker? None of that fucking hassle. The only people that complain about docker are either super small teams/solo devs or people that weren't there before docker.

File: laughing-pepe.png (157 KB, 973x926)

157 KB PNG

you now remember when docker tards found out that a user with permission to use docker is indirectly able to be root

>>110322211
yep

>>110321315
he’s too low-IQ to understand.

>>110320672
Because getting shit to work on linux manually is so fucking awful that this is an actual good alternative

>>110322258
It's designed for enterprises that have thousands of mouthbreathers who don't know how to deliver software
Fixed. You don't need Docker to run more than one instance of a software on one system. You don't need to tightly couple your software to the dependencies available on the OS.

>>110321276
now use specific versions of dependencies that your distro doesn't provide

>>110322533
Just install them with the same mechanism that you used to get your custom software on the system. Is this supposed to be difficult?