Docker became popular over FreeBSD jails the same way MySQL became popular over PostgreSQL in the 2005-ish. Not based on technical merit but because of ease of use. In case of MySQL it was a Windows installer which made for a low barrier of entry. However MySQL didn't do ACID transactions, views, etc. at that time, all things PostgreSQL had.

Similarly Docker was easy to use with images but security was a mess. The first couple of years Docker stance was actually that their container wasn't to be considered a security boundary and being able to access the host system "wasn't a bug". This in total contrast to FreeBSD jails which were always regarded as a hard boundary.

Docker in FreeBSD is not as simple as you might think. FreeBSD has a Linux ABI compatibility layer in order to be able to run Linux binaties (just like WINE is a Windows ABI compatibility layer). Docker itself, the CLI application, the API, etc. is probably the easiest part.

In 201709 I tried to install FreeBSD, and could not find any reasonably practical way to verify the CD image PGP seal, nor clear pertinent documentation.

On the official IRC chat some people tried to help, however this patently is not a common issue. How weird. Who wants to install an OS without being able to verify the image seal? Downloading through HTTPS may be MITM'ed, or the image replaced on the server.

I reported the problem. Somebody also reported it more than a year afterwards.

More than 2 years after my initial report... the ticket remains open. At best the BTS seems neglected.

The FreeBSD maintainers probably agree upon the relative importance of those seals, because they publish them at https://www.freebsd.org/releases/12.1R/signatures.html , however this is neglected in documentation ( https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/b... ). BTW I just noticed that the signing key isn't in the strongset ( https://pgp.cs.uu.nl/mk_path.cgi?FROM=8D12403C2E6CAB086CF64D... )

Everyone involved probably thinks there are more important things to do. I don't complain, as nobody "has to" do anything upon this matter.

My point is that such a way to handle this may reveal that most FreeBSD "hacktivists" just aren't willing to do such menial but necessary onboarding-facilitating job, which would IMHO be useful.

It may be part of the reasons why FreeBSD has way less users than it could and should. In a way it is related to "ease of use", however this "image sealing" is more fundamental than bells, whistles and porcelain.

The ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222044

> It may be part of the reasons why FreeBSD has way less users than it could and should.

I would like to gain understanding as to why the BSD maintainers + developers invest the time they do into their projects. They are awesome projects, but... who are they for? The 0.1% of people who lie to themselves saying "FreeBSD makes a great desktop/laptop?" Mac OS X makes a great laptop, that's why it is in every coffee shop around the world. Linux must beat BSD server usage 10:1, if not 100:1. I'm sure somebody below will prove me wrong but I strongly feel it's just the echo chamber effect of reddit/Hacker News. I can't think of any good reasons somebody would use *BSD over Linux and "their man pages are great + the clib is written in the same repo as the kernel + userland utilities" isn't good enough of a response for me.

> I can't think of any good reasons somebody would use *BSD over Linux

Well one reason could be that you are a commercial company and you make a proprietary appliance. FreeBSD's license (3 clause BSD) is way easier in that case then the GPLv2, let alone GPLv3 (which a lot of userland is licensed in most Linux distro's). Examples of some high profile appliances running FreeBSD: Sony's Playstation 4 and Juniper's Junos OS which runs on their firewalls and routers.

Ubiquiti is getting a lot of flak for not being GPL compliant and the only thing I can think of when I hear this is: "Why did they use Linux if they wanted to make a proprietary product? They wouldn't be in this mess if they had used FreeBSD.".

Another reason could be FreeBSD ships ZFS out of the box because combining the CDDL + BSD licenses is not a problem. However GPLv2 (Linux kernel) + CDDL is a problem.

> Well one reason could be that you are a commercial company and you make a proprietary appliance

Any other use cases other than licensing that would make somebody want to use *BSD instead of Linux/Mac?

Yeah, it runs better.

I've used FreeBSD on my production systems instead of Linux since I started this whole bit 15 years ago. Linux surprises me. FreeBSD, for example, does not. I do not walk away from production FreeBSD systems and have them fall over for reasons other than hardware failure. Full stop.

And this shows in lots of places, from gaming (Linux is nowhere, meanwhile the most popular console runs FreeBSD) to enterprise routers (Juniper) or NAS (NetApp).

> How weird. Who wants to install an OS without being able to verify the image seal? Downloading through HTTPS may be MITM'ed, or the image replaced on the server.

While it should be fixed I think your overstating the importance here.

99.999% of the world doesn't care about that; No one who installed Windows verified the image. No one who installed macOS verified the image. No one who gets a notebook from a store verifies the install. Let alone everyone who runs stuff in the cloud on a VM, those people have no way at all to verify the OS they are actually running.

> It may be part of the reasons why FreeBSD has way less users than it could and should.

Linux became popular over BSD mostly due to the unix wars [1].

[1] https://en.wikipedia.org/wiki/Unix_wars

> could not find any reasonably practical way to verify the CD image PGP seal

There is no easy or obvious solution here. You can not verify anything PGP unless you can directly (!) obtain the public key from the person in question. So-called Web of Trust is a theoretical construct.

> Who wants to install an OS without being able to verify the image seal?

Well, for example, Ubuntu downloads (and checksums) were available exclusively over plain http until 2018 or so. Flavors are still http.

Is there a Docker equivalent for FreeBSD? Jails are only part of the equation. I can orchestrate networking/volumes all while accessing a breadth of remote images through Docker/docker-compose

I suspect there is but I dont know about it (I use SmartOS / Triton). There is a small list of jail management tools [1]. If it doesnt exist it should be really easy to make since FreeBSD jails (usually) sit on ZFS you can easily use "ZFS send" to create a image of the ZFS dataset. All that one would need to add is some (minor) tooling.

On the more "heavy side" I know that for example Project Fifo has experimental FreeBSD support [2] in case you want to host multiple FreeBSD machines with jails on them.

[1] https://mwl.io/archives/2291 [2] https://docs.project-fifo.net/docs/freebsd

I can guarantee none of these tools come even remotely close to the features of Dockerfiles, docker-compsoe.yml, docker-machine, etc.

Maybe combining jails with something like Ansible for building images and automating configuration would be close to good enough? Though more boilerplate? I wonder

Back then I chose MySQL because of php-myAdmin. That and the fact there were so many more tutorials for it were the main drivers of the decisions. Proper foreign keys and transactions were nice, but who knows if this app would go anywhere anyways (it didn't).

to be fair, freebsd had something like docker for decades. Jails have existed for a long time and are easy to use.

Jails are “similar” to Docker but they aren’t quite the same: https://blog.jessfraz.com/post/containers-zones-jails-vms/

Clear as mud. I know the author is a known person, but that style of writing is pretty bad for this topic.

That link has near zero substance.

Jails and Docker are different, but they are both used for process isolation.

This is a great point. I know https://wiki.freebsd.org/bhyve is massively popular/successful too.

Really? I used bvyhe on FreeNAS and it was awful comparing to KVM or ESXi.

Docker is mainly a Linux LXC thing. Why would you want to run that on FreeBSD?

I don't follow. Docker and LXC do similar things but they don't share a code base and aren't even compatible with each other.

I think the parent is just a little behind on the news. Docker used LXC internally at one point. Easy to miss!

Because I can develop my stuff on a mac, then run it on my FBSD fleet?

FreeBSD has incompatible executable files with Mac.

He/she is talking about being able to deploy a `Dockerfile` or use `docker-compose` / `docker-machine` on FreeBSD.

It's very common in backend development to run a Dockerized version of Redis/Postgres for local testing/development. A lot of developers develop Go/Python/Rust/node.js/etc. on a Mac, then deploy it to nix. They would need to deploy the same Docker containers built locally (or in CI/CD) to BSD, which seems unsupported given the comments.

I see, but I thought the selling point of docker was reproducibility, which was thanks to the image. The Dockerfile is not truly reproducible, and the image once created it is typically created with linux binary.

I think docker is a glorified zip file, but if that would help popularize FreeBSD more I wouldn't mind that feature. I guess linux compatibility layer could help here as well.

> The Dockerfile is not truly reproducible

What makes you say that?

Tons of examples where it works on developer's computer, but doesn't in production or someone's elses computer.

Dockerfile is not ensuring that build is fully reproducible, it's just list of steps to build the image. There are many issues with it, but biggest offender is due network access, if you're updating your package repo or downloading a file, there's a high chance that the resulting image is different every time. Dockerfile is as reproducible as a bash script. The only thing that's reproducible is the resulting image, but at that point so is a zip file.

Try this experiment. Build an image from a non-trivial Dockerfile today. Then make another image from the same Dockerfile in another couple of months and see if it is identical to today's image.

And? Mac and Linus systems have the same issues, yet my laptop is a mac and most of my docker hosts are linux.