Docker is dead

No, because Jails are not portable even between between OS versions, let alone other platforms (you want people to migrate to BSD, right?)
As SirDice mentioned, versions aren't a problem.

As for other platforms, do please have a think about this question: Can you run a Windows or macOS binary in a Docker container?

No. So what you are saying is "Target Linux. Compile for Linux. Use Linux". Obviously that isn't going to be a popular suggestion in this community.
For a long time Docker ran on a VM on Windows and macOS so that it could run Linux binaries. Effectively you can do that with FreeBSD. We can run Linux just fine in VirtualBox and Bhyve. So FreeBSD effectively already supports Docker.

Do we really want people to migrate to BSD? The OpenBSD stance is a definate NO! FreeBSD is a little more easy going but we still only want correctly thinking people. Otherwise the project will turn into an eclectic experiment like most Linux distributions.

Having OCI compatibility (not Docker compatibility) makes BSD much more palatable to developer communities and system admins who would love to be able to use it but for the fact BSD is a walled garden that chains the organization to private datacenters.
And until OCI compatibility extends to other operating systems rather than just Linux, it is surely a little embarrasing to recommend it to an operating system that exactly isn't Linux. Perhaps Linux should support Jails?

Any organisation that chains itself to OCI is basically yet another "Linux house". Nothing new or special there.
 
Yes, they are. It's perfectly fine to run a 12.2 jail on a 13.0 host for example. That's a supported way of running it.
The reverse has to also be true for you to have feature parity with OCI. You don't have it.

While the Dockerfile (System Image Spec) and docker-compose.yml (System Image Composition Spec) feature sets may expand over time, when an actual image is made using today's 3.8-compliant spec files, it's portable all the way back to Docker 1.0, on ANY OS Docker 1.0 runs on. Same thing goes for an image built way back when on 1.0. You can run it on Docker 3.8, Kubernetes, OpenShift, or Triton.

You can't take a BSD 12.x jail spec to a BSD 10 machine without manually rewriting it. And even if you could, that alone is not enough.

What Focker is doing is only half your battle. It provides you a version-agnostic jail composer. Now unify that capability with the OCI container spec to use Jails as the underlying implementation for your execution environment, and you have "Docker" (OCI) on BSD.
 
This is your daily reminder that BSD is a license. (Unless you are talking about the FreeBSD's ancestor OS, in which case we don't have jail compatibility with that.)
 
  • Thanks
Reactions: a6h
As SirDice mentioned, versions aren't a problem.

As for other platforms, do please have a think about this question: Can you run a Windows or macOS binary in a Docker container?
Yes you can. https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

Windows jumped on the OCI train so Windows binaries could run on Linux and Mac several years ago.

So what you are saying is "Target Linux. Compile for Linux. Use Linux". Obviously that isn't going to be a popular suggestion in this community.
No I am not. Please tell me English is your second or third language.

Target BSD, Compile for BSD, Use BSD natively. Just give me a toolchain that I can use to transfer what I was being forced to run on Mac and Linux over to BSD without having to rewrite the wheel that is all the configuration hackery to support a full-blown CentOS VM on a Mac host (like building a Vagrant to host everything in the FreeBSD way since lord knows the hacks we set up to get Vagrant to behave on Mac OS Big Sur the way we needed it to were stomach-churning).

BSD has native Postgres, Java, Cassandra, unix shell tools, file systems, etc.. I'm more than happy to use them. I'd LOVE to use them.

Let me hand you a spec file that says "set up some directories, create DNS resolvers for a whitelist of external resources (that only this "container" can see), download a native Java dist., download a native Postgres dist., download my application from my Nexus, set up env vars, set up pre-defined secrets, and expose a port for the world to reach my app. You're free to handle the details of the networking and resource allocation."

You can use Jails and ZFS and whatever else you like to implement the secure sandbox for it to run in.
 
Why would you do that? That's a nonsense argument. 10 ended 4 years ago.
I guess that's because you can do such things with Docker … you can even run a Linux container on a Windows host. But of course, under the hood, this will use full virtualization, so IMHO it's just "hiding a problem". One key advantage of using "containers" (jails) is that it's light-weight…
 
Why would you do that? That's a nonsense argument. 10 ended 4 years ago.
So did CentOS 6. Sometimes old servers have to live a long damn time because corporate makes a priority decision that is ITSELF nonsense.

Don't forget that if you work for an organization that already broadly uses FreeBSD (or any of the BSD server OSes), you probably lack a fair amount of nonsense that the rest of the world commonly has to deal with from "management." I can take my Java application stack back to our CentOS 6 servers if some mission-critical security flaw is found in the v8 boxes and they need to be taken down, because CentOS 6 has a JVM compatible with our code, and the rest is networking + directory paths. By the same token, I can take that app to Windows Server or FreeBSD, because they all have JVMs.

But say you have a larger organization that has multiple datacenters, all in different states of being "up-to-date." Say you have an in-house software that is to be rolled out to all datacenters, and it needs to run regardless of OS version. If you wrote it in Python or Java, there's a pretty solid chance it will. If you wrote it against the very latest jail spec that isn't directly transferrable to the N-1 version in another DC, you're going to have to custom-roll another Jail spec and deployment for that DC. An automation of this is Focker.

No one WANTS to go back in time. Disaster Recovery plans sometimes necessitate it, especially in the context where your datacenter provider isn't very timely on spinning up new environments for you and updating OSes on existing machines is another ball of wax unto itself. Decisions being made above engineers' heads sometimes necessitate that in the ecosphere outside this immediate community. Try to not take that for granted too much.
 
I guess that's because you can do such things with Docker … you can even run a Linux container on a Windows host. But of course, under the hood, this will use full virtualization, so IMHO it's just "hiding a problem". One key advantage of using "containers" (jails) is that it's light-weight…
Where is this myth still coming from? The VM hosting requirement is only true on Mac OS anymore. Windows Linux Subsystem is now a lightweight OS virtualization just like BSD's Linux compatibility layer. It's a call table emulator and not much more, has been that way for a little over a year now. The hardware virtualization is gone.
 
Yes you can. https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

Windows jumped on the OCI train so Windows binaries could run on Linux and Mac several years ago.


No I am not. Please tell me English is your second or third language.

Target BSD, Compile for BSD, Use BSD natively. Just give me a toolchain that I can use to transfer what I was being forced to run on Mac and Linux over to BSD without having to rewrite the wheel that is all the configuration hackery to support a full-blown CentOS VM on a Mac host (like building a Vagrant to host everything in the FreeBSD way since lord knows the hacks we set up to get Vagrant to behave on Mac OS Big Sur the way we needed it to were stomach-churning).

BSD has native Postgres, Java, Cassandra, unix shell tools, file systems, etc.. I'm more than happy to use them. I'd LOVE to use them.

These are also available on linux.

I admire your passion but most of your arguments read like over-hyped advertising spiel. The linux foundation is free to fund oci on freebsd; nothing's stopping them.

Freebsd (and this is a broken record retort) has limited developers, funding and overall resources compared to linux. That's the crux of it.
 
Yes you can. https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

Windows jumped on the OCI train so Windows binaries could run on Linux and Mac several years ago.
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.
 
Windows Linux Subsystem is now a lightweight OS virtualization just like BSD's Linux compatibility layer. It's a call table emulator and not much more, has been that way for a little over a year now. The hardware virtualization is gone.
[citation needed]

Microsoft getting rid of a syscall-level emulation layer was precisely the point of WSL 2. Are you claiming there is WSL 3 already?
 
If SYSTEM is not a Type-1/Type-2 VMM, and SYSTEM wants to run Windows PE (EXE/DLL),
SYSTEM has to implement at least these bunch of things (TTBOMK) -- either in kernel or user-space, e.g. WineHQ.

* ntoskrnl.exe (syscall)
* KERNEL32.DLL (win32 API)
* GDI32/USER32 (userland libs)

AFAIK, N/A to the Docker.
 
SYSTEM has to implement at least these bunch of things -- either in kernel of user-space (like WineHQ)

* ntoskrnl.exe (syscall)
Nitpick: Not sure wine is doing this, but it's not strictly necessary. The kernel API on windows is by definition "private" and no userspace program should attempt to access it. They should use a subsystem instead (normally: win32).

Of course, you'll probably find some programs ignoring that, so – as I said, a nitpick ;)
 
So did CentOS 6. Sometimes old servers have to live a long damn time because corporate makes a priority decision that is ITSELF nonsense.
Servers are not Operating systems. One can have long lived hardware and modern OS. Running an old OS version and using this as an argument for why jails are not as good as linux containers is a spurious argument.

Don't forget that if you work for an organization that already broadly uses FreeBSD (or any of the BSD server OSes), you probably lack a fair amount of nonsense that the rest of the world commonly has to deal with from "management." I can take my Java application stack back to our CentOS 6 servers if some mission-critical

I have no idea what centos 6 is, old or new, but I still don't see the correlation or relevance to freebsd. Freebsd is an OS, linux is a kernel. People add various junk to it to make it into an OS. Having stuff like OCI to make a 'standard' seems a reasonable thing for an operating system pulled together differently depending on the distribution. It probably makes sense for 'linux'.

So redeploying some software from one freebsd server to another is child's play. Freebsd is freebsd. Centos is, however, not redhat or ubuntu or gentoo. Your arguments premise on the linux world and presumes their same hotch-potch of OS building applies to freebsd; this simply isn't the case.
security flaw is found in the v8 boxes and they need to be taken down, because CentOS 6 has a JVM compatible with our code, and the rest is networking + directory paths. By the same token, I can take that app to Windows Server or FreeBSD, because they all have JVMs.

But say you have a larger organization that has multiple datacenters, all in different states of being "up-to-date." Say you have an in-house software that is to be rolled out to all datacenters, and it needs to run regardless of OS version. If you wrote it in Python or Java, there's a pretty solid chance it will. If you wrote it against the very

We only ever maintain one version of the freebsd (and netbsd) Os across our datacentres, both regional and state. Problem solved. We're not running ubuntu on one, redhat on another and archlinux on yet another and expecting it all to run like clockwork. Nope, we're on FreeBSD 12.2p5, with a internal package repository and we like to measure uptime in years.

As I've alluded to, I really don't see the need for freebsd to push itself into an area already occupied by linux. It has a potential best case rate of return of zero. It makes no sense in any way.
 
Having stuff like OCI to make a 'standard' seems a reasonable thing for an operating system pulled together differently depending on the distribution. It probably makes sense for 'linux'.
They were meant to have LSB (Linux Standard Base) but they simply can't seem to keep their sh*t together.

Now the popular thing is to bundle up an entire userland and distribute that ala Flatpak, Snap, Docker, etc. It is getting a little painful to watch.
 
Now the popular thing is to bundle up an entire userland and distribute that ala Flatpak, Snap, Docker, etc. It is getting a little painful to watch.
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". It just sucks I have to support all that mess at work because managers fall for the same traps every time.
 
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". It just sucks I have to support all that mess at work because managers fall for the same traps every time.
Very, true. Watching from the sidelines it quite good fun. Though as you mentioned they can't wait to drag us into their self-inflicted mess one way or another.

There was actually a good book here, though originally relating to programming it summarizes the "cool guy" that waltzes into a company with the newest toys. Does their best to get them stuck into the current projects and then disappears after the work becomes too hard for them to handle. Leaving us to maintain the shite when we originally were the ones against using it.

The worst part is that it undermines us. We ironically get seen as the guy who flitters around with different "nerdy" technologies because management conveniently forgets that they originally forced us to because they listened to the "cool guy"! It means that for future tech discussion meetings we get heard even less and you end up being called a luddite and a tech experimentalist in the same damn meeting XD
 
They were meant to have LSB (Linux Standard Base) but they simply can't seem to keep their sh*t together.

Now the popular thing is to bundle up an entire userland and distribute that ala Flatpak, Snap, Docker, etc. It is getting a little painful to watch.

Band aids on-top of band aids on top of band aids, then they have the nerve to call corporate trends like "OCI" et al., a standard.

You can't make this s**t up people.
 
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". It just sucks I have to support all that mess at work because managers fall for the same traps every time.
And sadly, the better things are mostly forgotten or overshadowed by crappy other things. For example, appimage is way better than the counterparts, but guess what...
 
Back
Top