>>109010000
what a waste of quads

>>109010000
Solves distro compatibility issues.

It has multiple use cases.

They wanted to make everything shittier and force you to use it while making you think of gay dudes putting their cocks inside other gay dudes cocks

>>109010035
Why are you gay?

>>109010000
To make deployment more predictable

>>109010075
It's not very good at that. But it works for forcing retarded junior devs who don't know anything about computers to target a somewhat viable production platform

>>109010000
Because it abstracts away the issue of having to worry about software dependencies.

>want to install stable diffusion on my linux desktop
>using arch
>SD does not work with 90% of the newer versions of dependencies I have installed
>fuck
>oh wait I could do this in docker
>write a docker file to install all the exact versions of libraries it needs into a container and mount a directory for outputs and inputs
>start it up
>it all works without having to install anything on my native system and binds local directories into the container so I can access everything I need to

This same process makes installing literally anything a breeze. Need postgres or kafka installing? Just write a docker compose file reference the version you want from docker hub, run "docker compose up" and you have an instance of postgres / kafka / whatever running without having to install any dependencies on your system at all.

So long as you're not getting docker images from untrusted sources, its literally a million times better than installing stuff natively.

>>109010104
>It's not very good at that
It's excellent at that. Predictable environments eliminate a ton of complexity.

>>109010251
...if you're retarded.

>>109010000
It's the closest thing to shipping exe files for Linux which are guaranteed to work.

>>109010000
To ruin whatever ai company also uses a whale logo

So you don't have to taint your computers by running linux on bare metal.

>>109010301
*sigh*

>>109010000
It was lighter than VMs if you want to run some application that needs specific library versions, but with the recent container escape LPEs I'd rather just run everything on its own VM.

>>109010000
Because we also have garbage like Python, Node.JS, Ruby etc.

>>109010000
makes running images with kernel namespaces easier. ive used k3s/podman/docker and theyre all fairly similar

>>109010000
To make using namespaces and chroots convenient.

>>109010000
okay since OP got quads and Docker users are ITT.
Can you spoon feed me the answer to why AI has easily gotten around docker containers, and what the simple solution is to actually keep them contained? Also any other good tips for Docker + local model would be appreciated by me.

to make bloatware portable

>>109010551
Isn't running everything on it's own VM more secure anyway? Unless you've got a rusty toaster for a host I can't imagine why you wouldn't just spin a Proxmox box and subdivide everything.

>>109010000
For computer bots to shuffle code around.

And they would’ve gotten away with it too.

>>109010000
For cross platform combability
Same docker image can run on windows, any linux distro, etc

>>109012134
If a program isn't developed to be cross-platform natively then it shouldn't be awkwardly shunted into something like Docker.

>>109010000
For privilege escalation.

>>109010000
idk ever since podman was made docker seems kinda bad in comparison

>>109010000
modern management
jeets
linus letting distros fuck with glibc

Because "developers" are incompetent subhumans who can't make static binaries

>>109010000
solving a problem is hard. wrapping it in yet another abstraction layer is easier.

>>109010000
>>109010104
Web dev is one of those things where people keep reinventing the wheel for no reason.
Like what happened to just having a collection of scripts under a LAMP stack?
You don't need docker.
You don't need Cloudflare to cache static content for your "CDN"
You don't need anything more than a standard SQL server.

>>109013352
You aren't the shot caller on what I do or do not need in my project. You aren't my project manager, and you aren't the project manager for any project on /g/ or in the wider software community. If you don't like a tool or framework, that's fine and you don't have to use it. We don't all engineer things the same way. That's fine. But you need to lose the holier than thou attitude, because it isn't making you any friends.

>>109013352
Now you need to run two different collections of scripts on your server. One of them only works on PHP8. One of them only works on PHP7.

What do you do?

>>109013392
have nginx in a location block point to the php-version-fpm binary but only for the locations where i am serving the php7 and php8, just keep them in different server blocks / location blocks

NTA btw, this is just a moronically easy solution
You could also use franken, just saying

The appeal of docker is for developers who want to ship everything in one redist that is known good. I really feel like podman or kuberenetes offer more when it comes to an actual production deployment

>>109013363
I know, I'm just some kid shitposting my opinion. But this is one of the only sites where I can express it, be listened to and get good feedback if I'm wrong.
>>109013392
I would need to know more about the situation. In some cases it might be worth it to update the PHP 7 scripts. I'd pull an all-nighter if it means my job is easier in the long run. Otherwise I might look into something like >>109013397, those features exist to be used. I might also look into alternatives if what we're using doesn't play nice with the rest of the stack.

>>109010000
We get to a point where OS are flawed to get work done and we come up with all these abstractions that should've been POSIX since day 1, like docker, Ansible and many other.

I'm guessing you've never had to spend a week debugging and extremely non-googleable obscure error that ended up being due to a bug 3 dependencies deep that was fixed in a patch version of a distro-wide library.
meaning, I'm guessing you've never had a job

>>109010014
this.

>>109010035
>>109010104
>>109013352
ITT: script kiddies that have never deployed software.

>>109013352
why should people be forced to use LAMP, you imbecile? docker is agnostic.
holy shit are docker haters brainless.

>>109010017
>we solved the distro compatibility issue by installing a second distro
Statements dreamed up by the truly deranged.

>>109014348
also your fucking scripts depend on the OS they're running on.
docker decouples your code from the OS.
you can deploy to a different OS and it will still just work.

>>109013392
>Linux can't have two different PHP versions installed

Switch to a better OS

>>109014348
Not an argument. I accept your concession.
>>109014366
Ah yes, "deploying" (installing and configuring) on different server OS such as "Enterprise Linux distro", who knows we might want to use FreeBSD.
I bet you use Cloudflare to cache static content too.

>>109010000
to sell AWS subscriptions

>>109014403
>having the freedom to use any tech stack on any OS without a change in configuration is not an argument
ok retard

>>109010000
A lot of software today is just a GUI wrapper around something that a bunch of nerds created. In case with docker it's a bit different though. Although it clearly does that thing, but since we are talking about Linux, one has to mention the fact that Linux simply has Docker because such features were present in UNIX, but that famous burglar and thief known as Linus Torvalds failed to produce a full clone of UNIX, it took literally decades to port most of the basic and very old UNIX features to Linux.
But you know, they are getting there. Maybe two more decades and they will completely rewrite UNIX and have all of it's features. Docker is one of them essentially.

>>109014331
Whoa whoa whoa, we've got a PodWoman expert in the thread. Listen and learn when trans pioneers speak!

Yet another garbage thread of
>Don't understand how something works
>Make up garbage argument against it that makes no sense and shows you have no working knowledge
>Insult your opponent if you get called out with name calling
>pretend to win

>>109013352
>he thinks it's about "web dev"
>he still uses terms like "LAMP stack"
it's very hard to take any of your points seriously when you come out with shit like this, anon

>>109014443
you hit the nail on the head, anon

Dockerfags are truly the lowest of the goyim. It's like being excited about a 10x improvement over baseline when the optimal solution would be a 1000000x improvement.

>>109014513
>gays fags jews buzzword bigga numba bettah
Ah, a fellow employed member of society, I see.

>>109010000
dev containers are comfy

>>109010000
because namespaces and cgroups were completely bungled and overly complicated, so there was a desire by sysadmins for a tool that made dealing with them infinitely less retarded.

plan 9 doesn't have this problem btw.

>>109010601
youre asking the wrong question
the problem was the user then

you want tips heres the only one
podman rootless

Imagine you spend 30 days ricing your shitty Linux desktop

If you want your NPC friend to do the same, he would have to repeat everything step by step, takes ages

You can make a Docker image, he runs it, and gets your config. No more "Works on my machine tho lol" issues

Of course you'll have to maintain the image and it doesn't run natively, so it's not meant for the scenario described, but that's the basic idea afaik

>>109014593
Ah yes, the employment cope. With no doubt, an employed individual is highly likely to spend multiple hours per day autistically raging on imageboards about his favorite way of deploying software: a miniscule incremental improvement over what came before. He will also, despite his fixation, have no clue that much better tech has existed for years beforehand, and will repeatedly try to self-assure that anyone trying to dethrone his favorite mediocre software must be stuck with the inferior ways.

>>109015392
>miniscule
lmao retard

>>109014331
Deploying software is my job. Docker is good but most docker shills and especially people who can't think outside docker-compose are always shitting up deployment pipelines with garbage that I have to fix because you made some wrong dumbass assumption
>The zoomerlib dependency I'm using in my code needs this scary app called postgresql to work, so I will shove a pgsql container to my build and put the configuration in docker-compose what could possibly go wrong

>>109015941
>Kettle? This is pot. You're a nigger.
The idea of Docker is:
>deploying lots of software on a system following the FHS is hard, so we'll just make multiple isolated FHS hierarchies and only install a little bit of software on each one
That's almost a canonical solution. The thing you should have learned is that the FHS is shit, and a much better way to fix deployments is to stop using the FHS. Get rid of the problem instead of working around it. Not that a dockerbrain could imagine what that would look like.

>>109017361
>FHS
That's not the problem at all. That docker winds up with everyone throwing shit into their own containerized /etc is just a side effect of lazy people using docker in the first place. Same goes for shit like port mapping. Somehow people are too lazy to learn how to bind a different port on their software so they just use docker to map the default ports. Retarded problem.

The most important and fundamental issues that docker addresses are binary compatibility and dependency management.
Operations wants Distro A for hardware support.
Developers want Distro B for the userland stack.

Docker lets you (to some extent) give both sides what they want.

>>109017853
>Operations wants Distro A for hardware support.
>Developers want Distro B for the userland stack.
FHS is in fact the fundamental problem here. Developers don't want Distro B, they want the libraries and tools included with Distro B. But why can't they just install those libraries and tools on Distro A? Because of the design of the FHS. In particular, the FHS involves lots of global search spaces. These allow conflicts to exist. Non-FHS systems don't need to care about that, they can eliminate the concept of global search paths, and then there's nothing left to cause conflicts.

because linux is a shitshow

>>109018469
If two different distros link against different versions of a library with an incompatible ABI, it doesn't matter whether they're in the same path or not not. You'll get a symbol not found error or some similar link-related problem. FHS has absolutely nothing to do with this.

>>109018475
It's not a shitshow on the whole.
But there is no stable ABI.

>>109010000
It was invented before AI—it's antique garbage now.

>>109019107
>If two different distros link against different versions of a library with an incompatible ABI, it doesn't matter whether they're in the same path or not not.
It very clearly does matter. Being in a different path and not looking at the other path when looking for libraries is exactly what enables this to work in the first place. Either version of the library is stored at a different path because it is a different library (where "version" can also just mean an ABI difference) . Binaries linked against version A will only look in path A, while binaries linked against version B will only look in path B. FHS has everything to do with this because it expects you to only have one path for all libraries, but you actually need one path for each version of a library.

>>109019111
The stable ABI of Linux is the kernel system call layer. This is what no one seems to understand about Linux. You cannot expect Linux to have any particular set of libraries, or a particular libc. You can't even expect it to have a libc at all. The ONLY thing you can expect is to have the basic set of syscalls provided by the kernel. You MUST bring everything else yourself.

>>109010000
Because some people have decided that
>installing programs directly in your OS = bad
so they developed a method to turn simple installations into complex, isolated sandboxes where programs are only allowed to interact with the system and each other in explicitly defined ways.

File: Podman-logo-orig.png (31 KB, 500x166)

31 KB PNG

HELLO?!
>He loves to use the botnet instead of the free version that literally does every motherfucking thing better

>>109019222
>The stable ABI of Linux is the kernel system call layer.
Well yeah, the linux ABI itself is stable.
It's not that I don't understand that, it's just not especially relevant to the discussion about Docker
>You cannot expect Linux to have any particular set of libraries, or a particular libc.
This is the root cause of Docker's popularity (shared with Flatpak and AppImage). You can't just compile a binary with any significant dependencies on linux and ship it to another linux distro and expect it to run, unless you build your entire stack from libc on up. And yes this is done sometimes, but for the average person docker is a much more convenient alternative.

>>109010000
Modern projects have too much dependencies, and on such scale conflicts happen with syst libraries more often. On top of that devs don't know how to build applications with bundled libraries, so they put it in a magic box and install the dependencies as if it was global install.

op is unemployed and a faggot

>>109010000
because i need something to just fucking work out of the box without having to invest an unnecessary amount of time trying to get it to.

As a development tool it's a testing environment, I've always assumed.

But I use it primarily to stand up servers easily, since people prepackage server packs that run in Docker and it's awesome.

>>109021764
java solved it, you just build a fat jar
and for server applications - wars, ears should be self-contained
but you can always put shared libraries into lib dir and set a classpath for any java application

the equivalent in C, C++ would be compiling with runpath pointing to relative directory

>>109019203
Path issues can trivially be solved by setting LD_LIBRARY_PATH and PATH before running the program. It's not a fucking issue, you fucking absolute moron.

In fact there's a real-world tool for managing environment variables when you have multiple build stacks where the main issue is locating the library in the filesystem (https://lmod.readthedocs.io/en/latest/). It's used by people who build their entire software stacks from source (sometimes even compiling the same software with different compilers for different optimizations). The Red Hat Software Collections Library uses something similar to configure PATH and LD_LIBRARY_PATH for the shit it installs into /opt/rh. Again, no containers, no docker, just '. /opt/rh/theapp/enable ; theapp' . Because it's all compiled for Red Hat, they link against Red Hat glibc and openssl and all the other lower level dependencies so there's no need for any additional compatibility layer.

But most people don't want to build everything from source. Even if you don't mind working through the build process, it can take hours to compile everything you need compared to a minute to install precompiled binaries from public distro repositories.

For a lot of languages/stacks, they used to be more firmly coupled to their environments and hard to lift and shift, deploy onto new servers or Linux servers. This solved that issue. At the same time, everyone made a big push to make their tech stack OS agnostic. So now most things are built to deploy easily and be OS agnostic natively, and Docker almost feels redundant.

>>109019107
>FHS has absolutely nothing to do with this.
yes it does. two libraries with different ABIs would be different .so's with different shasums and thus not possible to accidentally link.
investigate nixos and ostree.

>>109019111
>But there is no stable ABI.
the only reason docker works at all is because Linux has stable ABIs.
Windows containers require you shipping the entire userland specific to the host's kernel.
I believe starting with Win Server 2022 and up, they now have a stable NT syscall numbering and ABI so they can compete, but I think it only gives you backwards compat, not forward compat, like you get on Linux (assuming not using new meme features).

>>109021829
But then you're constrained to the JVM, which is its own compatibility layer.

>>109013392
>>109014331
>>109014348
>>109014483
those are the people who make large businesses somehow go bankrupt due to maintenance costs, and keep switching companies and keep leaving big piles of shit behind for other developers or engineers to clean, and keep thinking they're competent because they keep using whatever new hyped shit they see on the internet

>>109013352
>You don't need anything more than a standard SQL server.
kek, yes I do. "standard SQL" is shit and many engines usually maliciously comply with standards to the point that correctness can be a problem.

>>109022087
> two libraries with different ABIs would be different .so's with different shasums and thus not possible to accidentally link.
(a) You have presumed the two appropriate libraries are installed and available to begin with. How did that happen? There are many ways to do it, docker is a popular one.
(b) FHS or no FHS it's always possible to accidentally link unless you are specifically building your software with static linking or building it to use a custom linker that doesn't search the filesystem and doesn't respect LD_LIBRARY_PATH at all.
>investigate nixos
Ah, and now we see where the obsessive fixation on the evils of FHS comes from. Snowflake fanatic behavior at its finest. "If only everyone always did it MY way." Nix is just one of many possible solutions to the library dependencies problem, and it's one that most people don't like because it requires a substantial commitment (in time and mental energy) to a very niche ecosystem with few measurable rewards.

>>109022424
content based addressing is beyond nix. I already told you ostree is a similar concept that tries to fit the FHS cope model.

>>109022114
>the only reason docker works at all is because Linux has stable ABIs.
Already addressed this confusion here: >>109019317
When it comes to developers developing software that they want to deploy to end-users or to a server running business services, they primarily target userspace APIs not kernel APIs. They write for libc, libm, libcrypt, libstdc++ and so on. And those libraries do not have stable ABIs. You cannot build postgres on Ubuntu, rsync the install files directory to Fedora, and expect it to run. It might if you are lucky, but it probably won't.

>>109022504
You haven't addressed the point that FHS is not the root cause of docker usage and ABI incompatibility.

>>109010000
>Vmmem randomly starts using 100% of your CPU for no apparent reason

>>109010000
because you can't just ship a binary on Linux. and Linux fanboys will cope non-stop about how that's not an issue and refuse to do anything about it.

>>109022424
>"If only everyone always did it MY way."
Literally yes? Nearly every distro does it the FHS way, which is obviously wrong. There's this one alternative way, which is a clear improvement and works on every existing distro already. What's the problem?
>just don't aim the gun at your foot bro
>stupid non-foot-shooter, why invest all this time and energy in aiming away from my foot when I could just wear steel-toe boots instead?

>>109022424
>You have presumed the two appropriate libraries are installed and available to begin with. How did that happen?
the library was brought onto the system alongside the application that required it. developers already do this when shipping programs for windows.
>FHS or no FHS it's always possible to accidentally link
it's always possible to do stupid shit, but that has nothing to do with this discussion. just don't use a linker that does stupid shit. it doesn't need to be a custom one. setting LD_LIBRARY_PATH is similarly just an easily avoidable thing you shouldn't do. it's like going into a windows program's installation directory, deliberately deleting random files to the point where it doesn't work anymore, and proudly proclaiming "see? it's always possible to accidentally break software."

>>109014443
Welcome to /g/.

>>109024272
> There's this one alternative way, which is a clear improvement and works on every existing distro already.
You just refuted yourself, retard.
That Nix works on every FHS distro already proves that FHS is not obstructing anything. FHS not the problem at all. Neither is Nix's convoluted system actually what is desired here, which is the ability to easily ship a pre-compiled binary or a simple installer that runs on any Linux system. Nix is just another convoluted way to work around the unstable ABI.

NixOS is the autistic extreme for people who need to lock down and control every detail of a system, even the method incurs significant up-front costs and maintenance overhead vs relying on mutable distros and hacks like docker.

Mutable distros use FHS because they need to expose a consistent, intuitive and usable system to users and administrators to make modifications (managed to whatever extent they choose to, using whatever tools they choose, whether that's OSTree, Ansible, Puppet, Docker, or ad hoc scripts)

>>109024744
>That Nix works on every FHS distro already proves that FHS is not obstructing anything.
Ah yes, FHS is not the problem because the best way of doing software deployment involves avoiding FHS as much as possible. Sound logic.
>Neither is Nix's convoluted system actually what is desired here, which is the ability to easily ship a pre-compiled binary or a simple installer that runs on any Linux system.
Nix literally solves this. You copy a directory of pre-compiled binaries to the target system and it will work.
>Nix is just another convoluted way to work around the unstable ABI.
The correct way to handle the unstable ABI is to not rely on it. That's not a workaround, that's directly addressing and solving the problem. It's not convoluted either, it's about as simple as it could be. Just put each package into its own directory bro.
>Mutable distros use FHS because they need to expose a
>consistent,
So consistent that you can't even rely on /lib64/libc.so.6 being the same thing everywhere.
>intuitive
Using a special sandbox layer to deploy software instead of just copying the binary with its dependencies and running it however you want is extremely intuitive.
>and usable
You never really know what's going on on your system and you need to use hacks to run software not specifically compiled for it, very usable.
>make modifications (managed to whatever extent they choose to, using whatever tools they choose, whether that's OSTree, Ansible, Puppet, Docker, or ad hoc scripts)
How does a non-FHS deployment system stop you from using any of those?