FreeBSD Celebrates 25th Anniversary
freebsdfoundation.org
freebsdfoundation.org
There are lots of different ways to configure jails, which unfortunately means there are lots of places to get stuck.
I typically deploy to x1.* instances, which have NVMe drives. I create a zpool of all the NVMe drives, and then mount a zfs filesystem on the zpool at /mnt/jails. I run all my services in jails. Each jail gets its own IP address on the host, and services are made available to the outside world using pf rdr rules. Services in jails are allowed to access the outside network using pf nat rules. pf makes it easy to monitor and restrict network activity for each service.
Once you’ve configured a jail, you can snapshot it with zfs, compress the snapshot, archive it and rsync it to other FreeBSD hosts. Once copied to other hosts, starting the jail simply requires registering it in /etc/jail.conf and running `service jail start $JailName`.
I’ve started documenting this and have been thinking hard about how to provide a more generic container interface on top of this implementation. If you’re interested in the shell scripts, I’ve started posting them here:
Given that BSD doesn't require you to go through such hoops for a POSIX API, it's a mystery to me why the BSDs aren't more used in the enterprise/SaaS space.
There needs to be a name for the fallacy that the technically best solution will always win.
BSDs aren't more popular in commercial spaces because it's too difficult to find engineers with BSD experience, and no pre-existing supporting ecosystem. There needs to be a compelling reason for companies to ignore the conventional unpopularity, which means that using a BSD must solve a specific pain point that's visible and understandable enough to executives to get approval for going outside the mold. I hate to break it to you, but your boss (probably) doesn't appreciate why a POSIX API is even a thing in the first place, let alone how it applies to a business case.
Nine times out of ten, the servers at your first job or university were centos or ubuntu, and your desktop tower was rhel, fedora, or again, ubuntu. If you're an enthusiast maybe you had an arch, debian, or gentoo install. (shrugs slackware predates me).
Without some degree of exposure or evangelism you'll choose what you've seen work over something you suspect might not. And that rationale applies to a lesser agree to docker vs rkt.
Nothing profound. It just has popular mindshare so it's the default. You'll have to beat the pants off something to overcome that.
* http://jdebp.info./Softwares/nosh/guide/jailing-services.htm...
* http://jdebp.info./Softwares/nosh/guide/converting-jails.htm...
This is something that annoys me too, do you have any recommandations? Should I learn to setup jails from scratch? Or settle on a single tool like ezjails?
ezjails and some of the others really do seem like the definition of leaky abstractions if you expect a nice layer on top. They're more like handy reusable shell functions.
If you learn from scratch (which again, isn't far removed from those helper packages), you'll have a better understanding for when you get stuck.
https://www.skyforge.at/posts/an-introduction-to-jails-and-j...
https://git.cse.bth.se/system/bertha/tree/master/usr/sj
My target use-case is deploying backend servers into minimal jails. The servers are single binaries written in golang and the goal is to minimize the attack-surface as far as possible in case I’ve left something exploitable in the server code.
It saved me from wasting so much money. I was in the process of giving up on the Amiga and had just bought a top spec dual boot NT/95 machine (2x Pentium II, Adaptec SCSI, SCSI cd writer, Seagate Cheetahs, something very expensive for graphics and sound). It was a pile of shite that was objectively slower and worse than the 040 Amiga at every task I tried. Burn a CD sir? Sure, just don't do anything else at the same time, you must disable screensavers or receive a coaster. Move the mouse? Gosh that's brave sir.
FreeBSD gave something that wasn't brain dead, and actually worked, from that horribly expensive failure. Made a useful home file and printer server. Gave a similar desktop to the Suns at work. I took out a sub with CDROM.com that I kept running until they died. I've had a BSD box as some variation of home NAS/media server ever since.
The Amiga would surprisingly live 5 more years as daily driver (with one of the 10k Cheetahs). Windows 2000 was actually reliable enough to use. When retired that first BSD box had an uptime in years. Oh those simple times before constant security updates! I'd love to have used FreeBSD as the daily driver but software and laptop support was lacking in comparison to Windows (I did try a time or two), and OSX that I leapt to as daily machine when it was released. Thankfully today FreeBSD hardware support is much better.
So from chance discovery to the most reliable platform I'm ever likely to get my hands on. Especially with jails, ZFS etc. I just wish it was a little better known compared to Linux.
Yes, it takes more time to create your desktop then just install Elementary OS or Ubuntu where someone else made that for You, but once You have your configuration files, its similar experience.
On a new box You just install it, add needed packages and put your configs in the ${HOME} directory, same for FreeBSD, same for Ubuntu.
You will also 'lose' less time later since You will have bulletproof upgrades with ZFS Boot Environments (sysutils/beadm) and a lot more stable environment - no rush changes - no systemd - no ifconfig/ip problem - no netstat/ss problem - etc.
Even though there are proprietary NVIDIA drivers, CUDA is not supported, which excludes most modern machine learning.
[edit: removed some criticism, not nice on a birthday :)]
I really like FreeBSD as a clean, understandable UNIX system, it wish it had more momentum (and thus more hardware support, testing, etc.).
This was true until drm-next-kmod and drm-stable-kmod ports appeared. Now you have very similar Linux and FreeBSD graphics experience.
> This also means relatively limited support for Wayland, so you have to use X11, which is insecure.
Wayland is enabled by default since recently.
As we talk about security...
* Linux - Vulnerabilities (2103) - https://www.cvedetails.com/vendor/33/Linux.html * FreeBSD - Vulnerabilities (368) - https://www.cvedetails.com/vendor/6/Freebsd.html
About 7 times more on the Linux side, do not mix X11 into that :)
FreeBSD as every system has its limitations, that is for sure, but as I track its developments of the span of 15 years its just getting better and better, in all aspects - including desktop.
Of course there are 'environments' where its all or nothing like 'mobile', Linux has most of the market here with Android while FreeBSD has nothing.
Which are, respectively, based on 4.9 and 4.11 in ports. The AMD has made large strides since then. In those kernels, the amdgpu driver barely supported Southern/Sea Islands. These work extremely well with recent kernels (much smoother than the old radeon driver). Vega cards only support graphical output since 4.15.
Wayland is enabled by default since recently.
The FreeBSD website states that Wayland is not ready for general use. Wayland has been 'enabled' in many Linux distributions for years, but it took a long time to remove all the wrinkles.
I wonder: did you actually run a full GNOME desktop on Wayland on FreeBSD for a couple of months?
Linux - Vulnerabilities (2103) - FreeBSD - Vulnerabilities (368)
Linux is far more popular and most likely audited more as a result of that. So, it is not surprising that it has more CVEs. Also, the Linux kernel is a fair bit larger, supports more architecture, and more hardware, which means more surface.
About 7 times more on the Linux side, do not mix X11 into that :)
X11 is a permanent security vulnerability. Every application can read each other application's mouse events, key strokes, and do screen grabs.
Yes, its currently little older, but they catching up ;)
> The FreeBSD website states that Wayland is not ready for general use. Wayland has been 'enabled' in many Linux distributions for years, but it took a long time to remove all the wrinkles.
I haven't used it, so I do not know how mature it is.
> I wonder: did you actually run a full GNOME desktop on Wayland on FreeBSD for a couple of months?
I run 'light' with openbox/tint/dzen and do not prefer Desktop Environments, besides, for me it does not matter if it runs on X11 or on Wayland as the end result is the same, but as I did not used Wayland I will stop with conclusions here.
> Linux is far more popular and most likely audited more as a result of that. So, it is not surprising that it has more CVEs. Also, the Linux kernel is a fair bit larger, supports more architecture, and more hardware, which means more surface.
Microsoft Windows is magnitudes more popular then Linux, yet it has less holes, so its not only popularity.
https://www.cvedetails.com/product/17153/Microsoft-Windows-7...
Since the source is not generally available, it is probably inspected less. Also, a lot of device drivers are provided by third parties, whereas they are included in the Linux kernel.
For example, I've never liked IPT and I believe the way you set up pf(.conf) makes a lot more sense and is easier to understand. You can work somewhat around that (and vice versa as well via pfctl) but I prefer PF. YMMV.
Things like ifconfig and ip differ per *NIX which is bloody annoying. The macOS ifconfig and route differ a lot from the Linux one, for example adding a default gateway in Linux and FreeBSD with the route command requires different syntax/argument and just typing route on macOS doesn't yield the current routes (cause logic). As much as there is a learning curve involved, iproute2 is a great solution to simplify. There's even iproute2mac for if you're accustomed to iproute2 on Linux. It is a wrapper for ifconfig/route/etc though advanced arguments don't work.
Systemd has the same problem iproute2 has: a learning curve of an integral part of the OS.
As for snapshots, Windows, macOS, and Nix have that as well.
Personally, I love the macOS desktop (and Mac in general with UNIX under the hood) but something like i3wm would also do the job. And I bet it'd run just as great on FreeBSD.
It does. I use i3 everywhere, and once you've logged in, there's absolutely no difference across any Linux distro or BSD I've tried. Debian, FreeBSD, OpenBSD, Alpine linux... short of actually running `uname`, it's not really possible to tell what the underlying system is.
As everything in our lives, some prefer Linux, some prefer FreeBSD, some OpenBSD, some macOS, etc.
> Systemd has the same problem iproute2 has: a learning curve of an integral part of the OS.
Its not the learning, its just broken and I will not waste my or your time to discuss this again. ;)
> As for snapshots, Windows, macOS, and Nix have that as well.
Can you boot from them and preserve fully working UNMODIFIED system after upgrade? Nope. That is the difference in ZFS Boot Environments.
I also used Mac OS X (it was called that way before it became macOS) and I also liked it, but I feel on FreeBSD more 'at home'.
Regards, vermaden
You can do that with btrfs. You can make a snapshot of the whole filesystem and set a subvolume to boot.
Another approach is taken in Team Silverblue (formerly Fedora Atomic Workstation) [1], which uses OSTree snapshots with package layering. It stores the system as a git-like content-addressed object store. So not only can you boot into any version, you can guarantee that two systems are identical by checking out the same OSTree commits.
I also used Mac OS X (it was called that way before it became macOS) and I also liked it, but I feel on FreeBSD more 'at home'.
And the FreeBSD project actually cares about its UNIX user land. I am not sure if I can say that for Apple anymore. Outdated utilities, missing man pages, dtrace unusable by default due to SIP, etc.
Apart from Dtrace (which you can of course run in VM) it is just a matter of installing and using Homebrew.
Besides that, Homebrew does not solve the fact that for a lot of Apple-specific utilities, subsystems, and daemons there are no man pages.
(I do agree that Homebrew is a great project, have been using it pretty much since its inception.)
That's typical for *BSD. Examples include gcc vs cc, gmake vs make, and many others.
After checking out macOS for the first time in late 2016, it took me until only recently to realise macOS mostly only supports info pages - not man (but to confuse matters, some man pages for certain things like "man ls" do work). Even something as recent as git only offers info pages in Darwin - I'd love to understand why that is.
I've had to run through the "info info" tutorial a few times because the keyboard shortcuts seem neither compatible with emacs nor Readline and they still feel clunky compared to man pages, but I sort of know my way around them now to not have to frequently Cmd-tab back to Safari and figure out which desktop/workspace I've ended up at and how to get back (fwiw, I favour i3).
As for the outdated utilities, I do think it's a little absurd that brew and brew cask are essential add-ons to fetch what should already be present and "just work" (e.g., coreutils).
Or ip? Or netstat?
Honestly though, systemd is actually a good thing. We write a single .service that works everywhere and takes care of ulimit, private tmp, cgroups/slices, etc, etc.
The systemd implementation is just bad - http://without-systemd.org/wiki/index.php/Arguments_against_...
What about ip/ifconfig or netstat/ss?
Deprecating good old tools by rewriting them over and over again with new bugs and not covering full features of the original instead of improving the well tested tools.
* https://invisible-island.net/ncurses/ncurses.faq.html#vt100_...
There is irony in your "off by default" statement when it comes to GNU toolsets. ECMA48 colour and italics support is on by default in GNU troff, which should not come as a surprise as GNU troff was begun over a decade after ECMA48 was first published and the idea of multiple colours was fairly normalized and widespread at that point. Linux distributors and FreeBSD people later went to significant lengths to turn it off, with extra flags and macros.
But here's another FreeBSD's advantage: it gives you the choice. Just do "pkg install coreutils", change your $PATH and voila: GNU tools.
I see your point, but quite frankly I like the fact that in some cases I need something outside the usual use case and most times gnu grep (and other gnu utilities) have me covered and I don't have to go crazy fiddling with stuff.
It's just preferences, I guess?
The AT&T lawsuit may have been a factor, but I think a more plausible explanation is that the Linux ecosystem just moved faster by having short incremental release cycles, where FreeBSD only branched from -CURRENT every few years. So, you in FreeBSD-land you basically had to choose between something that is unstable or something that is old.
Another factor (I think) is that the Linux ecosystem marketed itself better. FreeBSD was a non-profit project (even though Walnut Creek supported them), Linux had a lot of commercial vendors (Red Hat, SUSE, Caldera) that were actively pushing boxes to book stores, etc.
Alas, this word "truth" doesn't have the meaning you believe it has.
It was more complex than most people realize and it was unclear for some time where it left the open source BSDs: Were we covered or not ?
One way or the other, we got sent back to "Start" (Do not collect...), and had to spend a number of months to get from Net/2 (once it were ready) to a working system.
And it didn't really help either that the 386BSD people felt we stole their thunder, that caused some low-level frictioon and copyright uncertainties.
But I think the biggest reason FreeBSD "did not become Linux" is that we didn't want it to.
We were all UNIX veterans, we wanted something stable, reliable and fast - hence the tagline "FreeBSD - The power to serve"
Linux back then, less so now, was a paradise for hackers and experimenters, people wrote 60% of a device driver for all sorts of crappy hardware and had endless fun with it.
I used a car comparison a lot in those days: Linux is an open GTI, FreeBSD is a 18-wheeler truck. The GTI is no good for haulin' - the truck is no fun for cruzin'
Amongst other differences, that gave Linux a much bigger mindshare in universities and dorm rooms, but then, as now, people get to a certain age and just want things to work.
That window was a very small one from the late 1980's to the very early 1990's Id say 1993 max. SCO Xenix occupied that commodity UNIX on i386, but Minix386 started to fill that void, even though it was basically forbidden. Linux changed all of that as there was no insane licensing once version 0.12 was introduced ( https://web.archive.org/web/20070819045030/http://www.kernel... ), with TCP/IP being added shortly afterwards in 1992. Linux was not obscure at the time at all, when new versions were released getting the latest kernel source from prep.ai.mit.edu was an insane waiting in line task..
Just as in the same time period we saw the rise & fall of OS/2, and the emergence of Windows NT. The hacker free market was open for grabs, but Minix's licensing failed, BSD was caught up in a lawsuit, and NT was anything but free. Solaris was going to stay a SYSV secret, and Mach needed 32v + BSD + SYSV licensing so no joe kid on the street could get access.
Why settle for Unix v6 photocopied Lions notes on the PDP-11 when you could spend a few days downloading SLS onto disks and boot into Linux?
1994 was far far too late. Even for AT&T's UnixWare to make a dent. SCO just ended up blowing their brains out partnering with IBM on that project Monterrey to bring SYSV to 64bits, just as Apple wasted their company way with fantasies of IBM & Pink/Taligent. Even IBM did it to themselves porting OS/2 to L4, thinking that OS/2 on a Microkernel was going to compete with Microsoft's implementation of a microkernel.
So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status.
Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS or towards code review and bugs fixing).
Until supermarkets accept Git PR, devs need to get something else.
If they rely on FreeBSD so much, why are Netflix and Facebook and Sony not paying FreeBSD enough to make it financially independent?
Why should I donate, if these giant billion dollar corporations are going to just leech off my donation?
If Netflix doesn't pay FreeBSD enough to keep the lights on, I guess you should start spamming them every few months.
Facebook steals my data and sells it, but I also need to subsidize the development of their instant messenger?
Maybe with a better license that didn't enable such freeloading on the part of these gargantuan corporations, FreeBSD wouldn't need to go begging for donations from private citizens.
I'd be interested to know if this type of advertising works on anyone - it just doesn't seem like an effective strategy at all.
This was about 15 or 16 years ago, I think. That was back when hardware support, both in Linux and in FreeBSD (and in most other free operating systems) was very flaky, and FreeBSD was the only one that I could get my network card and RAID controller to reliably work on. I ran Linux for a while, but unreliably and with out-of-tree drivers running over strange Frankenkernels. One sleepless, outrageously hot summer night, I tried FreeBSD (4.1, I think? Or 5.0?) and it remained on my hard drive for a pretty long time.
I learned to properly use Emacs on it, after outgrowing NEdit and SciTE. I learned how to write portable (hah...) Unix code, learned about SSH and kqueue and ACPI and firewalls. I learned to use patch and wrote my first open source program from scratch, whose source code has been thankfully buried forever but for a summer or so, I wrote the worst Windows desktop clone you have ever seen (that was back when Qt 3 could deliver us from STL and everyone wrote their own window manager for fun and it had real artwork, not boring, flat themes).
I also learned ksh, having learned that bash is not the only shell in this world. I learned about OSS and could not quite stomach Alsa ever since.
I learned about the ports system and that was a whole new world for me and I'd spend days tinkering with programs I didn't really need, just for the fun of it.
I mostly lurked on the mailing lists. I was thankfully past my script kiddie period and was comfortable admitting I didn't know much about programming and system administration, so I was a little intimidated; I joined discussions rarely, and under a pseudonym, but I read the public mailing lists religiously, and learned a lot from them.
Unfortunately, using FreeBSD on a desktop today is a little harder for me, now that portability is considered more of a stone-age concept for old farts who haven't yet installed Arch Linux on their laptops. It's certainly possible (I toyed with 11.1 a little and it's great) but it requires a little more tinkering than I have time for. Admittedly, that's mostly my fault; I chose a career path (embedded systems) that involves weird FPGAs and microcontrollers and the Linux bandwagon, so the little free time I have is spent getting up to date with stuff like Wayland. Sometimes I tell to myself I'm going to get a long vacation and work on something useful for OpenBSD or FreeBSD and maybe work my way into a job (or a consulting gig, and then another, and then another...) where I can use one of them, but then real life kicks in and I'm back to the Land of Useless Manpages.
I've long lost touch with FreeBSD development and don't know too much about what's happened lately. I've heard that the project has made a number of questionable choices in terms of development, and something about the security team being slow, but I really don't know too much on the subject, so it didn't get a chance to change my opiniong of this project. Granted, I don't know if this is true anymore -- but back then, I thought FreeBSD's pragmatism and clean approach to engineering was something to strive for, and I'm pretty disappointed that it hasn't become more popular in the open source world.
Happy birthday, FreeBSD! Here's for another 25 years of quality software.
Same here. I was a student working as a part-time employee in a IT-department and whenever machines were deemed too expensive to fix, I would harvest the parts which still seemed to be good... which I eventually managed to assembly into a full working server. And on a student-economy, a free server like that was a big deal.
There was only one catch: I couldn't get it to boot. Neither Linux nor Windows.
So the department Unix-guru asked me why I didn't try FreeBSD, something he was somewhat fond of. "It's like Linux, but different" he said.
I was a bit confused, but thought it was worth a shot, and what do you know? FreeBSD not only booted the machine, but kept it running nicely for over half a decade.
In effect, FreeBSD gave me a free server when I could afford hardware the least. That's not something you forget :)
I later learned that the mainboard had a serious chipset-failure (which was probably caused Linux and Windows to fail), but FreeBSD seemingly managed to work around that and just kept on running. As far as I can recall, this most has been the most stable server I've ever run.
These days I have a hard time letting go of the impression that FreeBSD is made of better stuff than other OSes, and has been engineered from the core and up to be more reliable.
Despite that I almost exclusively use Linux now (because it's more plug'n'play but IMO more flaky). I still have fond feelings for FreeBSD in my heart though.
I wish I had time to setup a working FreeBSD laptop, but with small 2 kids and a wife... Those times seems long gone.
Anyhow: Hopefully FreeBSD will still be around when I have time for that. Here's to another 25 years!
It is impressive how Linux changed from being yet another UNIX clone to being UNIX in most people minds, to the point many say Linux when they actually mean UNIX.
How power corrupts ..
See this thread from 2 years ago: https://news.ycombinator.com/item?id=11318508 (and others: https://news.ycombinator.com/from?site=mrsk.me)
(FWIW, that's why I actually run OpenBSD on the few non-Linux machines that I use :-) )
However, it seems to me like this is one of those cases where there's more than one way to skin a cat. FreeBSD is missing a lot of useful hardening features, such as ASLR (yay, it's 2003 again!), and has made a couple of "interesting" security choices, but judging by the number and scale of FreeBSD deployments, it seems like there are convincing ways to work around these problems in practice. That document suggests there's a lot of work involved in working around them reliably; again, the number and scale of deployments would suggest that the trade-off is considered reasonable by a lot of people.
There's also NetBSD which is ported on a lot of architectures. Though Linux is also strong in that field, traditionally NetBSD was. Its the project OpenBSD derived from (Theo got kicked out of NetBSD).