Docker is dead

[a6h]

I find it quite entertaining. It's fun to watch them all scramble to one thing then abandoning it a few years later for the next "best thing since sliced bread".

What's the solution to Linux package mess: Choose the best one (pacman, apt-get, or whatever it is) across all distros, not to build a new one! The latter leads to more mess.
It's very simple. Isn't it?

 

[Alain De Vos]

But why couldn't they create sustainable business ?

 

[kpedersen]

What's the solution to Linux package mess: Choose the best one (pacman, apt-get, or whatever it is) across all distros, not to build a new one! The latter leads to more mess.
It's very simple. Isn't it?

The LSB did specify that rpm had to be present in conforming implementations. It would have been somewhat cool if no matter what package system a distro went for, they always had an rpm plugin to make it integrate consistently with the "standard".

Of course that didn't happen.

I think at this point AIX (which does provide rpm) is probably closer to LSB conformance than 99% of Linux distros.

 

[mark_j]

What's the solution to Linux package mess: Choose the best one (pacman, apt-get, or whatever it is) across all distros, not to build a new one! The latter leads to more mess.
It's very simple. Isn't it?

I believe systemd-packageD is in the works. Stand by!

 

[Jose]

The LSB did specify that rpm had to be present in conforming implementations. It would have been somewhat cool if no matter what package system a distro went for, they always had an rpm plugin to make it integrate consistently with the "standard".

Of course that didn't happen.

I think at this point AIX (which does provide rpm) is probably closer to LSB conformance than 99% of Linux distros.

Rpm is so two package managers ago. All the cool kids are using dnf nowadays. It's clear whomever named that tool never participated in a race.

 

[mark_j]

Rpm is so two package managers ago. All the cool kids are using dnf nowadays. It's clear whomever named that tool never participated in a race.

Does this not point to something? I'm generalising here, but, something common to a lot of linux zealots and developers, that change is great just because they can?

While Torvalds might have a mantra of don't break userland, their userland has a mantra of break it at all costs. I don't know why he bothers.

Their psyche seems to be, if it's more than 3 years old, has zero bugs and is not getting fresh additions then it's time to scrap it and build something else. Then the cycle repeats. SirDice hinted at this in #195.

Don't get me wrong, change is ok, to a point, but adding something like linux-containers to FreeBSD when we already have a very mature alternative, just makes no sense. It makes even less sense if we have developers' scarce resources used in pursuit of such a goal where the only perceived benefit is FreeBSD is more linux-like.

 

[Jose]

No one ever made a name fixing bugs in Rpm or ifconfig. Being the person who wrote the new Linux IP tools looks a lot more impressive on a resume.

 

[Alain De Vos]

You have to mount the linproc filesystem.
Or you have to mount the proc filesystem.
Or you have to use pulse-audio because sndio is not supported or does not work well ..

 

[drhowarddrfine]

something common to a lot of linux zealots and developers, that change is great just because they can?

I love it when I see postings where people complain about something that's been around a long time and used by everybody but want it replaced because it's old. I'll usually ask them if that thing does what they want it to do and the usual reply is yes. So then I ask for a technical reason why it should be replaced and, if they reply at all, they usually want a graphical interface cause using the terminal is for neckbeards only.

Any replies that use the term neckbeards always tells me the level of person I'm talking to.

 

[mark_j]

Yes drhowarddrfine , I think Jose said it quite eloquently: "No one ever made a name fixing bugs". I think this is possibly these developers' sole motivation. You correctly say, there is no technical reason for a lot of this stuff to be replaced or even added; à la containers.

No one would have heard of Poettering if he was just fixing bugs and making enhancements to sysVinit.

 

[Deleted member 30996]

No one would have heard of Poettering if he was just fixing bugs and making enhancements to sysVinit.

Everyone who is famous has fame, but not everyone famous has infamy.

When you're notorious you're famous for your infamy. Which is best of all IMO.

 

[scottro]

drhowarddrfine said

I love it when I see postings where people complain about something that's been around a long time and used by everybody but want it replaced because it's old.

Sounds as if he's been listening to my wife complain to me. :-(

 

[patrickjp93]

Rpm is so two package managers ago. All the cool kids are using dnf nowadays. It's clear whomever named that tool never participated in a race.

*Laughs in zypper*

 

[patrickjp93]

Does this not point to something? I'm generalising here, but, something common to a lot of linux zealots and developers, that change is great just because they can?

While Torvalds might have a mantra of don't break userland, their userland has a mantra of break it at all costs. I don't know why he bothers.

Their psyche seems to be, if it's more than 3 years old, has zero bugs and is not getting fresh additions then it's time to scrap it and build something else. Then the cycle repeats. SirDice hinted at this in #195.

Don't get me wrong, change is ok, to a point, but adding something like linux-containers to FreeBSD when we already have a very mature alternative, just makes no sense. It makes even less sense if we have developers' scarce resources used in pursuit of such a goal where the only perceived benefit is FreeBSD is more linux-like.

Making it drastically easier to port a lot of software to FreeBSD and improve cloud hosting capability is a pretty sweet benefit.

Or do you think Joyent doing EXACTLY that with Triton and being wildly successful with it is just a fluke?

And once again, they are not "Linux Containers." They are application containers. You can implement them with jails or however you like.

Being able to say "give me an app environment with my provided application files in a specified directory path, some support applications (like nginx or Apache) from your native implementation repo, a set of port mappings I provide, a set of DNS resolutions to external resources I provide, and you secure it/lock it down however you like" all with one yaml file and an environment variables list is enormously beneficial to a lot of developers. Gone are the Ansible playbooks and galaxies, gone are the Virtual Box and VMWare cruft, gone are all of the network admin upkeep tasks like renewing loadbalancer and Apache SSL certs (new deployment = new cert) gone are the differences between local and remote software deployment...

As I have tried to make crystal clear, it's supporting OCI, NOT Docker and NOT Linux. Make it native. And don't use straw man args about Linux to shoot down an idea that isn't even tied to Linux.

 

[patrickjp93]

Here's the truth about Docker: It's a Linux-centric solution for a Linux problem: distro fragmentation. GNU/Linux distros regardless of use case have been incompatible in the most minor ways, making lives hard for application developers. Trying to standardize minor details on Linux has been hard and with little success, while *BSD, Windows, and macOS have avoided these issues for the longest time.

Docker on the server and Snap/Flatpak on the desktop is a way to hide Linux fragmentation, containing it via OS-level virtualization. In this case, a developer only has to worry about a so-called "single platform". It doesn't solve it at all, just hides it.

If everyone using Linux servers instead used FreeBSD (or about anything else), Docker as it exists today wouldn't even exist. Why? FreeBSD/*BSD variants and Windows don't have distro-level fragmentation to the extent GNU/Linux has. However, if Docker is cool developers will use it even if this means apps from GitHub don't work on *BSD.

A particular BSD variant is more or less similar across versions, userland, packaging manager, etc. Derivatives like pfSense or FreeNAS still maintain compatibility with their source for the most part. However, some incompatibility is still tolerated between versions or within "derivatives" like pfSense versus stock FreeBSD, as long as they don't go far enough to become a separate variant.

On Windows, you explicitly have a single source (Microsoft), and on top of that, backwards compatibility is literally a make-it-or-break-it, to the extent that legacy Windows 95/NT 3.1 apps can run unmodified on the latest Windows 10 Insider build.

I don't know much about Solaris/Illumos so I won't comment on that.

If the world ran FreeBSD instead of Linux, Docker would be more of a Ansible rolled in to a Jail manager. If it were a Windows world, I'm not sure, I've only been using Windows more in the past few months thanks to a day job (see disclaimer) and "Windows Containers" are still new when compared to their Unix equivalents.

Disclaimer: I work at Microsoft, not on Windows or Azure (at the time of writing). I still develop at work using the Windows/.NET/Azure stack as opposed to a FOSS stack.

And believe me, I'd love to be in such a BSD-rich world.

And yes, "Docker/Kubernetes compose" from a local development standpoint would essentially be something that consumed a Jailfile, a Beehive file, and a .env file before proceeding to building an image with the jail spec, the application artifacts, hooks for mounted volumes at runtime, and a short list of DNS resolutions and port mappings.

Runtime orchestration/management of the "cluster of jails" is a whole separate kettle of fish (mostly the virtual network nesting being the biggest Gordian Knot), but certainly much of that can be outright copy/pasted out of the Kubernetes codebase and the "only" major changes would be the interface between "BSD_K8s" and the Jails.

 

[patrickjp93]

This to me is a bug and not a feature. I've run into too many "engineers" that had no idea how things they had written and deployed worked. It's all fun and games until you run into a problem you can't fix. That is when all the technical debt you incurred by doing things the fast and easy way comes due.

And this is why Service Oriented Architecture and Microservices came to be. Have clear boundaries around spheres of functionality and responsibility so you can effectively reason about a large system. I may package my primary million-line Java app as a monolith, but there are only 4-5 code files that break 500 lines, and it was at least architected with clear separation of concerns baked in. When we're given an assignment to make a change to the code, it's not all that daunting.

Hell the dependency upgrades are the most dreaded tasks by far. And re-packaging the app into Docker/Kubernetes has been a long, arduous journey too, but the ethos remains.

In a BSD-native implementation of Docker/K8s, as long as you, the developer, know it all boils down to installing your app and supporting components into a Jail and registering that Jail with a "cluster" manager once it's up and running, you can recovery from "Docker" breaking.

I don't think anyone here believes we shouldn't know how to go back to brass tacks, but we get paid to be productive, and we get paid to make things reproducible and discard-able. When we succeed at making ourselves redundant, we have achieved excellence in our craft.

ZFS is one such example. It's so good at what it does and is so well-made it practically never needs a patch. It IS the last word on file systems. Eventually it'll need to support exa-scale storage natively, but that probably isn't "hard."

 

[Jose]

And this is why Service Oriented Architecture and Microservices came to be...(snip more buzzword engineering)

Go peddle your silver bullets elsewhere. Your Jedi mind trick won't work on me. I have too much real-world experience.

 

[patrickjp93]

No they can't run. You are mistaken. Pointing to documentation for a feature that relies on Windows Subsystem for Linux shows you don't quite understand the limitations of containers and what a Windows binary is. The fact that Microsoft runs Ubuntu in a Hyper-V based VM doesn't make Docker portable!

Can you point out to me an exact document that shows that Docker can run macOS binaries? Apple would not let it exist for one.

• Target Win32, Compile for Win32, Use Win32 natively
• Target macOS, Compile for macOS, Use macOS natively
• Target BSD, Compile for BSD, Use BSD natively

None of these can you do with Docker. You can only work with Linux binaries. Sure, some platforms can run Linux as VMs or compat layers. But that is nothing more than babysitting unportable Linux code.

Wrong, wrong, and wrong. WSL no longer loads a full VM and has not done so for the best part of a year. All it is now is the Linux System Call Table, the package manager of the distro, and the GNU tools in the flavor of the distro. The Hyper V VM is GONE.

And yes, you can do all of that on Docker/Kubernetes. You can build Win32 binaries and run Win32 binaries in a container on either Windows or Linux.

I make no apologies or defenses for Apple's douchebaggery. You've got me there.

 

[patrickjp93]

Go peddle your silver bullet elsewhere. Your Jedi mind trick won't work on me. I have too much real-world experience.

Oh for Pete's sake. No one is saying to blindly use automation tools without understanding what's under the hood. And experience is nothing but bias ingrained. Good engineers are good engineers, and experience has very little to do with it.

 

[shkhln]

Wrong, wrong, and wrong. WSL no longer loads a full VM and has not done so for the best part of a year.

Proof?

All it is now is the Linux System Call Table, the package manager of the distro, and the GNU tools in the flavor of the distro.

And the whole Linux kernel.

The Hyper V VM is GONE.

While it's technically possible to patch the (Linux) kernel coLinux-style, that doesn't really bring any advantages over using a hypervisor.

 

[patrickjp93]

Proof?


And the whole Linux kernel.


While it's technically possible to patch the (Linux) kernel coLinux-style, that doesn't really bring any advantages over using a hypervisor.

RTFM

Nope, not the whole kernel. Exact same lightweight emulation of ONLY the system call table as you enjoy in FreeBSD.

 

[shkhln]

RTFM

O RLY?

 

[patrickjp93]

O RLY?

Specifically for GPU acceleration which even BSD's Linux emulation needs.

Feature parity. Cry more.

 

[shkhln]

You aren't even trying now. Behave in a civil way or you are going to be garbage collected. (This is probably not your first account, right? This all seems too familiar.)

 

[patrickjp93]

You aren't even trying now. Behave in a civil way or you are going to be garbage collected. (This is probably not your first account, right? This all seems too familiar.)

First account. I'm right. For 99% of WSL use cases, zero reliance on Hyper V or any hardware virtualization. You want to use GPU acceleration (thanks entirely to NVidia), you end up needing it (equal stain on BSD space, and everyone here knows it).

You're the one being uncivil. RTFM. Your seniority does not trump your abject and reproducible lack of knowledge in this moment in time. Cry more.