FreeBSD 12.1(freebsd.org)
freebsd.org
FreeBSD 12.1
https://www.freebsd.org/releases/12.1R/relnotes.html
55 comments
This release is dedicated to the memory of Kurt Lidl, a long time BSD developer, who died on October 10th from metastatic kidney cancer: https://www.freebsdfoundation.org/blog/in-memory-of-kurt-lid...
I was sad to see that in the release notes, I had not heard. I remember Kurt from the Old Days, when I went to some open houses at UUNET and attended Usenix conferences.
It was very sudden -- it seems like it was just a few weeks from "Kurt has cancer" to "Kurt is in a hospice" to "Kurt died". :-/
FreeBSD is amazing, and a major reason for that is how well it is managed. I would find it very hard to name three other open-source projects of comparable size that are so well-organized and have consistently delivered for this long. Here's a warm shoutout to the FreeBSD Foundation, as well as your reminder to donate: https://www.freebsdfoundation.org/donate/
Been running Linux servers for years. FreeBSD is what gave me back the passion to run servers.
It's such a well structured operating system. The documentation is just great and Jails are a really nice way to get lightly isolated environments to run different web services.
Thanks to all the people who make FreeBSD possible!
It's such a well structured operating system. The documentation is just great and Jails are a really nice way to get lightly isolated environments to run different web services.
Thanks to all the people who make FreeBSD possible!
I hear you. TBH, most popular Linux distros feels very bloated nowadays. The other day I created a VM and there I installed FreeBSD for the first time. The process was really quick. It felt like a breath of fresh air. Much much simpler than what I had imagined. Everything felt very logical. I have thought about this before but since I already knew Linux I was hesitant to take the time to learn another Unix-like OS. But now I feel that I want to carve out some more free time to get more acquainted with FreeBSD. I’m quite sure it will pay off in the end.
> The trim(8) utility has been added, which deletes content for blocks on flash-based storage devices that use wear-leveling algorithms. [r344688]
Is this replacing an older utility or is FreeBSD way behind on supporting SSDs?
Is this replacing an older utility or is FreeBSD way behind on supporting SSDs?
TRIM has been available in FreeBSD for mounted ZFS filesystems for quite a while, since ~Sep 2012 in 10-CURRENT[1]. I believe this is just a user space command for manually TRIM'ing in cases where it doesn't have explicit filesystem support.
[1]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/all-ab...
[1]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/all-ab...
FreeBSD is issuing TRIM in ZFS and UFS2 for quite a while.
When I was researching the topic, I learned that how TRIM is implemented on the drives, issuing it in bulk is more efficient than individually, so perhaps that's why the tool was added? Although looking at ZFS at least it looked like it also collects blocks that supposed to be TRIMmed and issues it periodically.
When I was researching the topic, I learned that how TRIM is implemented on the drives, issuing it in bulk is more efficient than individually, so perhaps that's why the tool was added? Although looking at ZFS at least it looked like it also collects blocks that supposed to be TRIMmed and issues it periodically.
This is to erase an entire device. Filesystem support for trim has been present for many years.
Support for TRIM in ZFS, UFS (kernel), or fsck (userspace) has been in place for years, but there was no easy way to tell “TRIM all this whole device now”.
Trim support has been built in to ZFS since FreeBSD 10.
Presumably, this utility is useful for disks that are not ZFS formatted.
Presumably, this utility is useful for disks that are not ZFS formatted.
> BearSSL has been imported to the base system. [r343281]
Exciting. Is it being used for anything yet?
Exciting. Is it being used for anything yet?
I believe it was imported so that it could be used by code-verification bits in the boot loader and exec calls. I'm pretty sure those aren't turned on by default yet, but my understanding is that Juniper uses them.
Is there a 300-page or less book that can teach practical usage of FreeBSD? Like the C book or the UNIX programming environment book. I have it installed on one of my laptops but never got around to use it.
Yes, "Absolute FreeBSD" by Michael W. Lucas:
https://nostarch.com/absfreebsd3
Currently part of a Humble Bundle: https://www.humblebundle.com/books/linux-bsd-bookshelf-2019-...
Thanks, I'll probably get it.
Oh thank you very much!
There’s the FreeBSD handbook. Iirc it and the forums help the most. And the usual google.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
Thanks. I'm aware of that handbook but somehow I find web-based books lack the charm of a real book but eventually once I know my way around it, I'm sure I'll come to it.
There’s a two part book available on Amazon from the FreeBSD documentation project titled FreeBSD Handbook. Meant for going from 0 knowledge and up.
My train of thought went "hmm, I wonder if FreeBSD would be good to use in production for running some Docker containers" and I stumbled across this https://wiki.freebsd.org/Docker
> Docker's currently broken.
that leads to this: https://reviews.freebsd.org/D21570
> Docker's currently broken.
that leads to this: https://reviews.freebsd.org/D21570
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.
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
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 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. 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.
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).
> 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?
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.
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.
> 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
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.
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
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.
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?
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.
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.
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?
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.
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.