My container is POSIX :)
Containers Don't Solve Everything
51–60 of 99 posts
Re: Containers Don't Solve Everything
#52Follow up article: Containers don't solve anything.
6 months later, the containerless movement takes root.
2 years later, the seminal article: Perhaps containers were not such a bad idea.
Re: Containers Don't Solve Everything
#53Re: Containers Don't Solve Everything
#54Earlier quoted context omitted.
> getting devs to actually care if their software runs on platforms more than a year old. This is why we don't play games with siloing responsibilities on the tech stack. Every single developer on the team is responsible for making the entire product work on whatever machine it is intended to work on. No one gets to play "not my job", so they are encouraged to select robust solutions lest they be paged to resolve the…
So you don't support M1 Macs ?
M1s support x86 via emulation.
Re: Containers Don't Solve Everything
#55Earlier quoted context omitted.
This is well put. Containers side-stepped the deficiencies of Linux distributions, which had become so based on 'singleton' concepts; one init system, one version of that library etc. A shame because there's an inherent hierarchy; everything from the filesystem, UIDs, $LD_LIBRARY_PATH that could really allow things to co-exist without kludge of overlay filesystems. Just it was never practical to eg. install an RPM in…
This sounds like a lot of stuff that Nix solves, the multiple versions of libraries coexisting part at least
My understanding though is that nix tries to solve this globally (it manages your whole system, or your whole home directory, as opposed to docker, which has clearly demarcated separation between different images), and it doesn't reuse existing packaging (in particular the language, as in "apt install" etc.)
There's definitely advantages that way, but there's also drawbacks.
Re: Containers Don't Solve Everything
#56Earlier quoted context omitted.
Containers halfway solved some big existing problems that most people don't seem to see very well. Packaging is hard, and both debian-based and rpm-based (and really most other's I've seen) are pretty awful. (except BSDs, which I've had a lovely time with) They're slow, they're stateful, writing them involves eldritch magic and a lot of boilerplate, and they're just frequently broken. Unless you're installing an enti…
(Almost) nobody is using Arch Linux on servers, but I find its package system to be very good (not surprising since it was mostly copied from BSD ports). A few random examples (not the best you could find, just something I've used recently): - re-packaging pre-built binaries: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visua... https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nomad... - building C fr…
I was having problems building wine. So I used the arch pkgbuild and just didn't do the install phase. Made compiling pretty simple. And all the outputs are nicely defined in the aur repo locally.
Re: Containers Don't Solve Everything
#57Re: Containers Don't Solve Everything
#58It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…
> They're just the symptom of the disease that is future shock.
Yes, absolutely, and I hope you mean that in the capital-F "Future Shock", Alvin Toffler sense, because there is a lot he wrote that hasn't even been carried over and digested. Software is an endlessly disorienting sea of change, getting faster and thus worse as time progresses, and it's frankly madness at this point.
It seems absolutely no one is committed to providing a stable platform for any purpose whatsoever. Even Java, where I spent many years being ingrained with the absolute necessity of backwards compatibility with old (perhaps even dumb) classfile versions, has been making breaking changes as part of its ramp up to semi-annual major version releases. Node Long Term Support "typically guarantees that critical bugs will be fixed for a total of 30 months."[1] Pfft. It's a joke. You can't get your damn API design straight by version 12? I'll do my damnedest to avoid you forever, then. It's so unserious and frankly irresponsible to break so much stuff so often.
But change only begets more change. We're all on an endless treadmill, constantly adapting to the change for no reason. And people have to adapt to our changes, and so it goes.
Re: Containers Don't Solve Everything
#59My container is POSIX :)
What is your strategy that works for every packaging system and every version of every library you depend on?
Nothing says love like realizing that you are segfaulting due to a library version you didn't test against subtly changing its behavior.
Re: Containers Don't Solve Everything
#60It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…
> They're just the symptom of the disease that is future shock. Yes, absolutely, and I hope you mean that in the capital-F "Future Shock", Alvin Toffler sense, because there is a lot he wrote that hasn't even been carried over and digested. Software is an endlessly disorienting sea of change, getting faster and thus worse as time progresses, and it's frankly madness at this point. It seems absolutely no one is commit…
How about Golang in this case? AFAIK there haven't been any breaking changes yet.