FreeBSD is a tremendous project. I've used it since the 4.x days, first for work (web/mail/database hosting, at the time) and then for personal projects.
I have a 2000-era desktop PC as a personal server that I had left collect dust until very recently after switching to Macs for daily work long ago. It was running 6.1 and I hadn't booted it in a few months shy of ten years. I booted it right up, and in an afternoon proceeded to, in small stages, update it to the latest 12.1 release, which I am running with great stability now, including live repartitioning and better use of the available disk space after going into single-user admin mode. "Recent" improvements that I've been appreciating have been a smaller/more dense console font, easier wireless configuration (it has an Atheros-based PCI wifi card), and easier and more clear package and ports management. AND it still runs fast.
I've done the same thing with in-place Fedora upgrades over a similar time-frame. It is impressive, but not unrivaled in the Linux world. (I'm not playing favorites with Linux here: I'm a FreeBSD developer.)
There's also a famous video on youtube where some guy installs every versions of windows (maybe not 1 and 2) back to back and it kinda works (passing custom configuration most of the time too)
FreeBSD 10.0 and newer include etcupdate (and it has been available as port even longer) which improves a lot upon mergemaster through the use of 3way instead of 2way merges. Recent releases also added ways to keep most of your config in your own files (often included from /usr/local/etc) to avoid merge conflicts. Simple systems can often upgrade without any merge conflicts at all.
I will just use this oportunity to thank FreeBSD team (from kernel to ports maintainers) for their work on project and give my thanks in advance for anyone who joins it.
It was magnificent server for last 10+ years and I have never trembled before doing a major upgrade.
If you dont hear this enough: please keep on working your great work, maybe you are not the most used OS, but you have all my love <3 <3 <3
it's comments like this that make we want to take the dive. thanks for not only supporting the freebsd team but encouraging potential future users.
though with that said, i will say that k8s is taking over the world and bsds are going to be left in the dust for my use-case, non-(appliance, embedded, IoT) applications.
We've been hearing FreeBSD is dying since before it's been the year of linux on the desktop.
Is FreeBSD ever going to be hip and trendy? Probably not, it's not 1994 anymore. But, I don't need a hip amd trendy OS, I need an OS that provides a stable base for me to work upon and supports enough hardware that I can chose decent parts. As a bonus, I've found it easy enough to muck with the internals when it has benefited me or my employer.
I'm surprised the meme is still understood. Do young geeks even know what Netcraft was...?
It reminds me that in my hometown, opening a communal door of a condo from your flat is called "pulling", because people used to pull a cord to do it when electricity "didn't exist". Nobody has had to pull a cord to open a door in probably 80 years, but everyone there still says "I'll pull it".
I'm not questioning whether FreeBSD is hip or trendy. Not sure why you're bringing that up.
I'd pick up FreeBSD in a heartbeat if I knew that the investment in learning the platform would help me be productive in production. But like you said, it's not 1994 anymore and modern deployment and maintenance of an application stack is docker and k8s. A trend where the OS is abstracted away as much as possible. So why invest in FreeBSD? Okay, so maybe it's a nice OS for appliances; though so is Linux and I can continue to leverage my knowledge.
At home I run an appliance and thought I'd deploy FreeBSD on it to run my storage server. I was really excited to deploy ZFS, the BSD killer app. The justification for this getting more difficult to make since ZFS on Linux is production ready.
I want to use FreeBSD. I don't care that it's not mainstream. The unfortunate issue is that it's falling behind in my use-case, by a lot and that's a bummer.
FreeBSD has had fully integrated, working ZFS for over 10 years. You were so excited to deploy the BSD killer app, you forgot to do so for ten years.
I can only tell you, whatever scary differences you expect between Linux and FreeBSD are probably no more than between any two Linux distros with different packaging systems.
Ten years ago, fresh out of a failed stint at university, I applied for a junior position at a Linux shop. Would nowadays probably be called junior system engineer or so. The night before the interview, I read around a bit in Stevens' TCP/IP Illustrated as well as Design and Implementation of BSD (to calm my nerves). I told them honestly, I had maybe 15 lifetime minutes on a Linux shell. But I started with FreeBSD4.4 and had by then already 8'ish years of experience on general *nix administration.
I'm still there. Pivoted around and upward a couple of times internally. But I still run FreeBSD on my workstation to get things done. And we're still fundamentally a Linux shop.
But the root cause of my career is a friend at university handing me a FreeBSD 4.4 CD. It is a tremendous system if you want to learn about the services a kernel offers to its userland. If you care to make the dive, it not only tells you the what and how, but the why and all the compromises that had to be made along the way. And that understanding is universal.
FreeBSD may be well known as a solid production platform. It's true strength is as the foundation for not only a lifetime of learning, but a lifetime of understanding.
Good for you! FreeBSD taught you Unix which applies perfectly well at least at that time, to Linux as well. That was a good bet! Somewhat the same as learning Slackware at the time would teach you Unix, while chosing another distro would be more limited.
I have submitted multiple bugs for ZoL, from prohibiting boot of zfs as root (for the sake of boot beeing faster (?) they are not doing zpool import -a(f) but rather rely on cache file which is... crazy). Also the .zfs/snapshot still doesnt work. Both are vital issues and still not beeing fixed.
Boot on Linux laptop now looks like:
- power on
- wait for recovery shell
- `zpool import -a`
- `exit`
In all my years I have never observed this on FreeBSD and... as I have said, I expect from FreeBSD to be rock solid and it never dissapointed.
ZoL? I wouldn't be running it on my linux servers for a while. The basic mistakes that they are doing are not something that apriciate from file system that is meant to be as reliable as possible.
The actual problem you are having is that there isn't a setup option on virtually any distro that will set this up for you but you are clearly setup incorrectly. I was using Funtoo with a zfs root for years until the machines CPU died.
The process of booting up looked like hit power button wait for desktop to show up. The "basic mistakes they are doing" are completely a function of your distro not having a way to easily set this up and you not knowing how to use it correctly. As far as I know the only distro that supports zfs on root via its installer is at
Stop spreading FUD. ".zfs/snapshot" has been working on Linux for years now. I don't know when you last used ZFS on Linux, but just because you haven't used ZoL for a while doesn't mean that the developers stopeed working on it.
Also, me and hundreds of other people have been booting off of ZFS on Linux for years. Your issue is most likely in your distro's initramfs setup or you must have botched the initramfs config yourself. If you're just used to FreeBSD, just stick to commenting about FreeBSD without maligning other operating systems.
Again, if it doesn't work, then it doesn't work; to users it doesn't matter _why_ - whether it's a problem with ZoL code itself, or with distro-provided initramfs. It's the end result that counts.
That's an initramfs bug; the initramfs scripts are not actually supplied by the ZoL project. You should file a bug report against your distro's initramfs package.
That's part of the problem. From the user point of view it doesn't matter if the bug is due to initramfs, or the kernel, or ZoL, or whatever else. What matters is it doesn't work. With FreeBSD development model it's easier to get it to work, since it doesn't need to go through so many separate groups of people.
I am on fedora with added zol repository and fedora 30 doesn't supply any zfs modules or initramfs scripts. I had to do my scripts to verify that the modules are included and don't break my boot process. And it worked like a charm... for a while.
I have ZFS images that I can't send from my freebsd server to my 16.04 server with the ZoL repo enabled. Given that it's my personal data I can't really submit until I narrow down to a minimal reproducing case, but yeah, there are bugs.
zfs has a feature where you can `cd` to hidden .zfs folder (you wont see it by `ls`, imagine it like /procfs but hidden) on root of zfs filesystem (if you have tank/whatever mounted to /whatever this would be /whatever/.zfs) with some interesting content: within .zfs/snapshot you will get a list of snapshots for that filesystem with materialized state (!!!) of fs when the snapshot was taken. Imagine (instead of rollback the snapshot), just copying the original file(s) from there, with content from the time when snapshot was created.
This is imho, the killer feature of zfs, maybe matching only by VMS or DragonflyBSD hammer filesystems. They were/are both better at it (`undo`!) but zfs comes closely.
I just tried going in my .zfs/snapshot on my CentOS 7 system running kernel 3.10 and ZoL 0.8.3 and it's working. I can list snapshots and cat file off a snapshot.
tag name v3.10 (bc1b510b8979ecc322f8d930dde56658967b7355)
tag date 2013-06-30 15:13:42 -0700
Even with stable fixes and CentOS distro sugar on top, running 3.10.x in 2020 feels batshit crazy. I always thought such reptilian kernels are only found on shitty embedded devices...
RHEL kernels are like that. They backport a ton of stuff and the major version number is of little relevance, but it doesn't change because they maintain a stable kABI.
By now the CentOS 7 kernel is probably closer to mainline 4.x and 5.x than the original 3.10
Just for any case, I would really love to solve this, I accept the fact that it is connected with upgrading the modules but this just is no reason for breaking backward compatibility.
But nevermind, this is something that was working since zfs as root was brought into FreeBSD (and we are talking about FreeBSD not ZoL), never had issues about it.
FWIW, I think you have a good point here. I really like that FreeBSD has a focus on quality, that the base is one whole coherent system and that the documentation is very good. But as you point out, it does seem like they have a hard time keeping up with the world outside.
I see it as a huge issue that the whole world has point on marketing which is horrible wrong. The last two projects I was working on, both are doing mission critical task (for obvious reasons I can't name them or what they are doing):
one is really piece of s*, full of beginner mistakes, lasigna/spaghetti/ravioli mixed in horrible way, done in java, wasting resources like olympic games. But with polished webui, full of colors, nice icons etc.
Second one, c++, with kernel module for linux, driver for windows, really nice and clean code (I was surprised). Not really nice webui but it did do the job well. Passed the benchmarks with flying colors, almost once faster than the first project.
At the end: the first one was a bestseller. There is no technical reason to be better selling, they both were doing the same task, from technical perspective, the second one was far better. Benchmarks, way of doing its work. Just far better. But the worse product with better "colors" won.
Marketing, marketing, marketing. The pestilence of our time and probably the Dark Ages of technology. I doubt I will see the Renaissance.
Yes that works for 'end user software' but in the long run NOT for Operating-systems/Database/Filesystem/Network/Hardware...they need to be rock-solid, everything on top is your problem.
Both of those are doing quite complex tasks for sysadmins (probably it should be guessable what they are doing) that NEED to work. There is no excuse for them to fail. They need to be rock solid, "Operating-systems/Database/Filesystem/Network/Hardware" can fail, those should not (words like "criminal liability" comes to mind).
I agree with wanting an stable OS and FreeBSD definitely is, and having read some Linux and FreeBSD code few years ago, FreeBSD was lot cleaner.
Having said that, we use OS to run things. I feel FreeBSD is lacking there, and despite being incredible, that incredibility seems less attractive. Its hard enough to write things that work correctly in different Linux environments, I'm not sure how much more work would it be in FreeBSD land (hardware drivers, software outside Portage repo, and support) -- specially considering a lot of software is written with Linux (or Win/macOS depending what we are talking about) support first in mind, and anything else is more or less a "checklist" thing.
So from a user perspective, it comes down to -- do I want to spend time tackling software/configuration issues that I'm very likely have if I run this on FreeBSD vs. should I run in a slightly less cleaner OS that just works 99.99% of the time.
To each its own, while FreeBSD might be a nice server or game console OS, sadly it isn't what I need in desktop computing.
And for server deployments, cloud and language runtimes make the underlying OS kind of meaningless, other than for those doing low level performance optimizations.
I am missing an updated version of "The Design and Implementation of the FreeBSD Operating System", though.
But for mission critical tasks I will choose FreeBSD. I have seen too many times linux distributions (Linus is sane - distributions decisions on the other hand are making me scratch my head just too often) pulling "Crazy Ivan" and I really dislike it.
For FreeBSD I know I wont encounter any nasty suprises and I consider it paramount. And once you encounter some jewels like setfib (https://www.unix.com/man-page/freebsd/1/SETFIB/) you just fall in love <3
If anyone else is wondering like me who Bruce Evans is:
> Bruce Evans <bde@FreeBSD.org>
> Bruce is the Style Police-Meister. When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various standards applicable to FreeBSD.
Seems he had an approach to reviews worthy of emulation:
"Code reviews from Bruce came in three flavours, "mild", "brucified" and "brucifiction", but they were never personal: It was always only about the code, the mistakes, the sloppy thinking, the missing historical context, the ambiguous standards - and the style(9) transgressions."
I wouldn't suggest emulating it. His approach to review was to exhaustively detail every perceived bug in any particular file when someone touched that file. Preexisting issues unrelated to the change. Style warts unrelated to the change. Subjective opinions unrelated to the change. In his emails, every one of these was a "bug."
There is some value in suggesting adjacent areas for future work, if authors have time and interest, but BDE went well beyond that.
I think Bruce should be admired for his demonstrated desire to improve FreeBSD, and for his great attention to detail. But I would not like anyone to emulate his code review emails.
If you're reviewing a block of code, you need to review the whole final version (not just the diff) or you risk missing context and interactions. If you're doing that, it's simpler to just review the whole thing and not filter out some parts just because you later notice that it predates the current patch. Although I would tend to hope that he doesn't treat pre-existing issues as blockers, I can certainly see why a person would take that approach if the goal is code quality.
Bruce's reviews were singularly masterful. He consistently condensed valuable layers of meaning into terse prose in a way that I have never experienced otherwise. As I would uncover these layers during repeated readings, I would develop the unshakable feeling that even as brilliant as Bruce was, he must have put great care and effort into his writing.
I think the idea of having a long term support release for 5 years was great [1].
FreeBSD 11 has been around for some years now, getting an update to which 11.3-RELEASE can be upgraded with minimal hassle is a major plus for FreeBSD.
I too used FreeBSD for many things between 4x and 10.x, but have made the switch to Ubuntu in the past couple of years.
Things I miss:
1) Jails without having to have a hypervisor system, Linux doesn't really have anything comparably as easy to use particularly with the iocage project managing the jails.
2) ZFS out of the box supported at at lower level than modules and user tools. ZoL has come a ways but Linux's political opposition to it is always going to be a weight around its neck.
FWIW I am using a ZFS pool that has never been wiped/recreated since FreeBSD 8. It was created on that OS and has been migrated between Linux/BSD twice over a span of 11 to 12 years.
Things I don't miss:
1) The lack of file/directory monitoring libs and third party applications because, honestly, kqueue sucks.
2) While simple SysV init was simple 15 years ago systemd has come a long way. I hate to admit it, but systemd is the better way at this point because I like having my daemons restart themselves without third party monitors.
3) Brain drain is real, it seems the last time I used FreeBSD that port maintainers are running thin and I don't have a suggestion for how to attract more of them. For many years FreeBSD's package/port system was the best in the world (yes, better than the Linux alternatives like apt and rpm too). I think pkgng's rollout was bungled, though, and while it may be better now it seems to have a lingering cost in port maintainers.
It's highly misleading to state that one will not miss "simple System V init" from FreeBSD, because it is a falsehood by implication.
One of the things that characterizes the BSDs is that they never had AT&T System 5 init, nor the van Smoorenburg clone thereof for Minix+Linux. It's one of the things that the BSD side of the universe resisted from the AT&T side of the universe back in the 1980s. FreeBSD has BSD init, a rather different beast to AT&T init, and Mewburn rc, which is very different to van Smoorenburg rc (although the post-2014 revisions on Debian make van Smoorenburg rc come closer) on Linux.
And it's equally misleading to talk about liking your dæmons restarting themselves, because that's untrue too. systemd is the very third party monitor, externally monitoring and restarting the dæmon programs so that they do not have to restart themselves, that you claim to want to do without.
The difference between inittab and the scripts controlling the startup routines are minimal. A person in 2005 could grasp the difference between BSD and Linux init scripts in about an hour.
As for hating systemd, that battle is lost, my friend. There's really no point in even engaging any discussion about it beyond this paragraph. No one is looking to write shell scripts for init in 2020 when there are systemd service files that are simple configs. It's provided by the distro, that's why it's adoptable. No one in the right mind trusts open source project devs to maintain compatibility in even minor version variations, that's why there's a booming container business. Tools that the distro provides work, tools from third parties are on borrowed time until they break, so yes systemd is the only viable up-monitoring solution.
Nothing there follows from what I wrote, or even from what you yourself wrote earlier, for that matter; and the idea that the difference between inittab and rc is "minimal", when the quite marked difference between init and rc has been a fundamental Unix thing since First Edition, is laughable and gives away the entire lack of foundation here. One never has "written shell scripts for init", moreover. You really do not have any sort of grasp of what you are talking about, and the "hating systemd" strawman that you just introduced out of thin air to then argue against is indicative of at best a lack of technical points to make.
Many people have rejected the systemd cult of bloat and scripts are easy to read, write, understand, and maintain. Most consist of generic boilerplate anyway.
Nobody wants to replace a simple init system with something with 1.5 million lines of code like systemd. For crying out loud, it’s 2020.
First, there's the error of the false dichotomy that the only two options that exist are van Smoorenburg rc and systemd. That's certainly not true for FreeBSD, which is the headlined topic, and not true on Linux operating systems, either. The Uselessd Guy famously called this false dichotomy out years ago. Moreover, in the Debian Hoo-Hah the choice was primarily amongst OpenRC, Upstart, and systemd; van Smoorenburc rc was acknowledged by all as not even in the running in practical terms, even though it formally was.
Second, FreeBSD has Mewburn rc, and one really cannot apply the same critique to it as to the van Smoorenburg rc for Minix+Linux, in discussions pro or discusssions con. The scripts are vastly different in structure. (Ironically, it is little known that Debian people have local modifications to van Smoorenburg rc, from 2014 back in the time of the Hoo-Hah, that make huge changes to van Smoorenburg rc scripts on Debian, making them structured much more along the lines of how Mewburn rc and OpenRC structure rc scripts.) In Mewburn rc, scripts actually do not mostly consist of generic boilerplate. The generic parts are not in the scripts in the first place, but in a common shell script function library.
I didn't think there was any political opposition to ZoL other than the fact that its licence is incompatible with the GPL, and outside of a complete clean room rewrite, there's really nothing anyone can do about it. It's not like you're going to convince Oracle to relicence it.
> I didn't think there was any political opposition to ZoL other than the fact that its licence is incompatible with the GPL, and outside of a complete clean room rewrite, there's really nothing anyone can do about it.
I suppose it depends on how you mean that, but I probably disagree; when Greg KH can say, "My tolerance for ZFS is pretty non-existant" [0], and Torvalds says, "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel... [the] benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it any more..." [1], we've gone well beyond "they just can't merge it because of licensing" and into "[political] opposition".
> It's not like you're going to convince Oracle to relicence it.
I've always wondered at this, actually; why doesn't Oracle relicense it? BTRFS, AFAIK, was started at Oracle but basically flopped; why on earth do they not simply bring over the far-superior ZFS codebase to replace it? They can't possibly be trying to protect Solaris the way Sun did; they've killed off >90% of the Solaris team [2] and AFAIK have made exactly zero effort to sell Solaris for years now. Why wouldn't they get ZFS upstreamed into Linux and make it a core feature of OEL (or whatever they were using BTRFS for)?
I admit to not being as familiar with Jails as I'd like, but systemd-nspawn seems to cover much of this use-case on the Linux side. I've used it in a few different scenarios and found it very easy and intuitive to set up. Easier and simpler than VZ for kernel-based VMs for sure.
kevent() is indeed the MsgWaitForMultipleObjects() of the Unix world, a very useful mechanism, and indeed the very file directory monitoring library function that RNCTX wrongly claims to be lacking.
But from experience of using it extensively in my softwares I can report that it has some warts on FreeBSD. A very quick précis:
* It has problems if one wants to combine NOTE_TRACK, NOTE_FORK, and NOTE_EXIT in EVFILT_PROC, because it returns one event for both a forked child and an exited child, which both try to store different things in the single "data" field of the event.
* Quite a few of the pollable device drivers in FreeBSD are not kevent() enabled. So it mysteriously fails to work with a whole bunch of I/O devices, where (confusingly for diagnosis) polling does. kevent() is not universally usable.
* One might think, from reading the various operating system's manual pages, that only NetBSD and MacOS have EVFILT_FS. In fact, FreeBSD kevent() also has EVFILT_FS. It's just entirely undocumented.
FreeBSD is a delight to run, I use an old AMD build to host Plex, PiHole and some other services in bhyve VMs. Keep a copy of Absolute FreeBSD around for physical reference just like the 90s.
During quarantine I decided to set up some networking equipment with FreeBSD whereas historically I’d have used Linux. Wow! What an improvement! Everything is so much cleaner, easier, faster to set up. I don’t have to screw around as much to make it boot and install on headless hardware. I can boot off a ZFS root volume. Networking is simple and clear to configure. Documentation is great. I don’t think I’ll use Linux again in the future when setting up a server, if I can avoid it.
What kind of networking equipment? I'm thinking of ditching pfsense and going bare freebsd or pfsense for my home router box and a few more anecdotes of similar projects would be nice to hear.
Happy FreeBSD user here. I personally use a Protectli FW1 with FreeBSD 12.1 and PF (Kernel recompiled with ALTQ support for QoS) and it works very well! I tried to move to OpenBSD to get the latest PF features/syntax but unfortunately the interfaces are dropping packets and no one on the OpenBSD mailing list have been able to help me. Unfortunately for me I'm not a programmer so I'm not able to contribute/fix it myself but I have to rely on the community/devs. I have reverted back to FreeBSD 12.1 and still being super happy with it!
"FreeBSD 11.4-RELEASE Announcement
[...]
Some of the highlights:
The clang, llvm, lld, lldb, and compiler-rt utilities as
well as libc++ have been updated to upstream version
10.0.0.
[...]"
I found this interesting. Seems like FreeBSD is more pragmatic than OpenBSD. They are using the latest and greatest llvm/clang series.
For license related reasons OpenBSD is stuck on an older version of gcc. I understand that OpenBSD has now _also_ become stuck on an older clang/llvm due to license changes there too.
In the long run, not upgrading the compiler is going to hurt OpenBSD a lot, I think. A lot of mitigations are now built in the compiler and languages (e.g. C++) are accumulating features at quite a fast pace.
I was wondering if users of OpenBSD have thoughts on the above. Do you think its a bit deal? What is the solution? How does OpenBSD not get left behind as a platform?
Or is this older clang/llvm issue only relevant for the core system and pkgs would have latest clang/llvm?
I think that that sticking to some principles is great. Not dropping them at the first difficulty is what proves that your are indeed sticking to it. OpenBSD is not dying, and even grab the interest of notable figures such as Carmack recently.
Not everybody is running after the last shiny feature. I don't mean that in a condescending way: there is room for all approaches.
I’m aware they maintain forks and patches for many packages. However development resources are always precious! Now openbsd needs to devote them to backporting from rapidly evolving llvm. Effort that could have been spent elsewhere.
Also note that backporting may be unfeasible in some cases I’m guessing because changes to latest llvm/clang may be under the new unacceptable license. Openbsd might need to make their own modifications.
I’m not making a value judgement whether it was good or not to not accept new llvm license. Just making an observation that this is going to be a drag on the project.
This seems like a good place to ask. I saw this comment[1] few weeks back
> This is one of the superior aspects of FreeBSD: no parsing of human-readable strings to get back machine-readable information about the process table. It's available directly in machine-readable form via sysctl().
And started wondering how deep does that go in (Free)BSD? Is all info available in neat strucured format programmatically, or are there other places where you'd need to do Linux-like parsing of special files? Is there some good reading material of this aspect of the system?
I hope this isn't too inflammatory Linux vs BSD question, I did not intend value judgement on either approach.
> And started wondering how deep does that go in (Free)BSD? Is all info available in neat strucured format programmatically,
In short: not exactly, but it's somewhat better than Linux. Sysctls are a commonly used, structured tree of mostly integers. The thing Linux does where procfs/sysfs are a bunch of unstructured text files? FreeBSD mostly doesn't do that.
Here are some sort of off-hand exceptions or oddball things that might be less desirable:
1. To get the disk/partition topology, there is a sysctl that spits out an XML graph: kern.geom.confxml. So that's sort of text parsing, but it's got a well-defined grammar that many libraries exist to parse already.
2. Some sysctls just dump opaque kernel ABI binary structures. These are machine parseable by C programs as long as they were compiled with the same headers as the kernel; parsing in non-C or across ABIs is less good. If these interfaces need to be portable, they are usually exported in a more portable way by libc or another base system C library.
> or are there other places where you'd need to do Linux-like parsing of special files?
The only special filesystem you need in FreeBSD is devfs (/dev), and it is populated by devices (or directories containing devices, symlinks to other devices, etc). So if a device exposes an interface that is arbitrary text, sure, you could have something like the Linux situation. But that is atypical. You absolutely do not need /proc or /sys; I don't have either on my desktop FreeBSD workstation.
The common convention is to use ioctls instead. Ioctls are a pretty lax type system, but the FreeBSD ones do embed the size of the structure in the identity of the ioctl, so you have at least a slight guarantee of noticing ABI changes and being able to provide backwards compatibility.
> Is there some good reading material of this aspect of the system?
The canonical book here is FreeBSD: Design and Implementation, 2nd Edition. It's not super recent, but many of the underlying design principles are accurate. Many of the subsystems described function in basically the same way today. I would also plug Joe Kong's FreeBSD Device Drivers if you're interested in writing device drivers specifically (full disclosure: he is a friend).
I think this comes from the different development model. Passing machine-readable stuff instead of parsing strings is convenient, but requires cooperation between parties, usually the kernel and the userspace. In FreeBSD it's trivial: I can change the kernel, userspace, and documentation all in a single commit. In Linux it's much more involved - you never know which userspace version is going to interface with whatever you've tinkered with; people who put together distributions are separate from actual developers of various parts etc.
As a long time user, this feels like something that's true but not. The userland tools to dump kernel information (ps, ifconfig, etc) get back binary data from the kernel, not human readable strings, so it's true, but other programs that might need that information would often be expected to call the same tools and then parse the human readable forms until the recent inclusion of libxo can provide machine readable outputs. libxo was added in FreeBSD 11.0, and I'm not sure how far it's been implemented; when I was still managing a large fleet of FreeBSD machines, we had a bunch of 10.x, so it didn't makes sense to update our scripts to use libxo.
viraptor was talking about C programs having to parse human-readble strings from /proc in Linux to get machine-readable data. That the output of the `ps` command is only human-readable is a complete red herring. That's not what a C program would use, and not the C API that viraptor was talking about.
There's an enormous amount of stuff available via sysctl(). It is essentially a huge, hierarchically extensible, system call API that passes (usually, but not always) machine-readable data to programs. The sysctl(3) manual page has a lot of stuff, but it doesn't cover anywhere near everything.
All of the transmit/receive statistics for the second Ethernet interface on one of my machines are various numeric values under dev.bge.1.stats , for example.
The machine-readable process table record structure is given as a C language structure, struct kinfo_proc, in the <sys/user.h> header.
I was porting a diagnostic command the other day, which displayed SMT status for the IBM power processor - written by a programmer at IBM. It was essentially a directory walk strncmp loop over /proc. The overwhelming sadness compelled me to spend a day of trying to figure out how far back I could trace direct evidence proving the existence of _SC_NPROCESSORS_CONF. Unfortunately I couldn't find the source code for SVR4.0MP, only references in interface manuals.
Again, though, viraptor was talking about the APIs used in C programming, not what one has in shell script programming.
When it comes to shell script programming, the obvious mechanism has already existed in FreeBSD for quite a while now. It's vis (vis(1), unvis(1), vis(3)). I have an alternative to ps that vis-encodes the fields in its output, and from experience most and possibly all of the well-known and widely-documented (by Greg Wooledge and others) pitfalls that are warned about do indeed go away with simple application of vis encoding.
It does the same on Linux-based operating systems, too, although one has to go and get an unvis tool from somewhere. Yes, the code to read the process table on Linux in the first place does indeed involve decoding human-readable strings from stat files into machine form. (-:
After a year of trying Ubuntu as my at home dev machine, I'm going back to FreeBSD. FreeBSD is much more of a pain during initial setup, but then it just works. Where as my laptop with Ubuntu has the most finicky Wifi and freezes way too often, and I didnt have these problems with FreeBSD on the same hardware.
I love FreeBSD. Been using it in a server context for going on 20 years now.
Trying to use it on a desktop takes me back to, well, trying to use Linux on the desktop 20 years ago.
Recently started shopping different distros because I’m not comfortable with the direction Ubuntu is going and rather than upgrade my 18.04 when it’s EOL’d, I’m looking at just hopping to something else for my work laptop.
Took hours to get X working with my laptop’s graphics card (though most resources I found online said it wouldn’t work at all, so that was a nice bonus). Not “get accelerated graphics working” just “get X to start”.
Spent another couple hours screwing around trying to get the trackpad working. And not just “get it working to my liking” but get it working at all. Turns out it’s entirely not supported as a lot of modern laptops uses a I2C connection rather than USB/PS2/etc, and there’s just no driver support for that. Never did get that resolved.
A lot of desktop apps that I use are either unavailable or require a lot of dicking around to use at all. There is no Slack desktop client. You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.
You’ll pry my FreeBSD servers from my cold dead hands, but it’s certainly not my go-to for a desktop OS.
I agree that the DRM/i915/amdgpu experience leaves something to be desired. (?)Ironically, the nvidia drivers are rock solid and just get out of the way, which has also been my experience on Linux. The only real fault I have with nvidia on FreeBSD is that they don't ship CUDA/NVENC/NVDEC.
With a stable GPU, the desktop experience is more or less identical to Linux, IMO. (I've been using Linux desktop since the mid 2000s and FreeBSD desktop since mid 2010s.)
I don't know what century you've tried freebsd, but trackpad works nearly otb and otb in new xorg. Accelerated graphics works fine with intel (YMMV depending on the chip), nvidia (if you install driver from nvidia and not opensource one), amd.
> There is no Slack desktop client.
There is no Slack desktop client for any platform. It's just a web browser. You can make "desktop client" yourself.
> You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.
Actually, this setup works MUCH better than Docker on Mac. Which is good enough for developer. Looking at 3 laptops right now: mac, windows and freebsd. Docker user experience goes linux (non-rhel based) > linux (rhel based ) > windows > freebsd > mac.
That being said, FreeBSD isn't "Oh, I will try running freebsd on this machine", FreeBSD is "I'm buying this specific machine because it runs FreeBSD". I use it both on my desktop and laptop.
I've had some success with running Linux binaries with the Linux emulation layer, that could possibly work for the Slack client? It tends to fall down with things that are native binaries mixed with shell scripts though, like I recently tried to run Steam and gave up, because I hit my (very low) limit of munging other people's shell scripts; they were calling a program and FreeBSD has the program, but the output is different, and the arguments are different, and I wasn't sure that I'd be able to run the thing I wanted to anyway, so I cut my losses early. It turns out, the thing I wanted to do doesn't (easily?) work on Linux Steam anyway, so I made a good choice. :)
If you decide you need Linux due to drivers or whatever, I'd recommend giving Arch a try. Arch has a reputation of having a learning curve, but it's no worse than the FreeBSD and like the BSDs it has excellent documentation. In my experience, Arch has been very stable with few surprises, especially if you avoid unnecessarily complicated software like GNOME. I can't say the same for Ubuntu or Fedora.
If you're able to get your drivers and all working with FreeBSD then good for you! FreeBSD is awesome and I'm always happy to come across it.
I personally feel sad when people state (indirectly) that Linux is NOK because their Ubuntu didn't work well :(
Ubuntu is probably the only Linux distro which I hate => I admit that it's a bit a mixed situation (Ubuntu seems to be a kind of "lighthouse" for the Linux world), but in the end I personally think that it's a pity that it acts as representative of the Linux distros.
I'm currently using Gentoo & Mint & Arch (depends on the usage), and in the past I liked as well at least Fedora and CentOS (not using them since a long time), but I never liked Ubuntu.
I hear ya, but as a counterpoint to my above post I've yet to have a issue with Linux in a server context, although I tend to use FreeBSD on servers where ever possible. The only time I've had issues with either FreeBSD or Linux is using it as a desktop/dev machine. They are both awesome operating systems, I just prefer FreeBSD.
Do you actually get working wifi, suspend/resume and acceptable battery life under BSD?
Last time I tried (open)BSD, none of those things worked acceptably. The recommended way to connect to wifi was to manually edit wpa_supplicant.conf and battery life was a solid hour less than under linux.
I feel like BSD is a great "laptop OS" if you're the kind of user that leaves their thinkpad plugged in all the time, essentially using it as a small-form factor desktop.
Sorry, but OpenBSD and FreeBSD are very different operating systems, it's not just "different distros" like in the Linux world
Whatever you tried in OpenBSD has most likely no relation to FreeBSD
Speaking of the things you mentioned, I personally would expect suspend/resume to just work out of the box in the latest OpenBSD, but not necessary in FreeBSD (it was never a priority for the developers).
You also don't need wpa_supplicant in OpenBSD (unlike FreeBSD), ifconfig should be enough in most cases.
For the battery life, you certainly gonna need some tuning, as it's not a config priority by default, but generally (on mainstream hardware) you should be able to reach at least 80%-sh battery life comparing to Linux in OpenBSD, and comparable to Linux in FreeBSD
Suspend/resume is definitely a priority for everyone who uses FreeBSD on their laptop, which is - judging by various FreeBSD conferences - increasingly popular.
Editing wpa_supplicant.conf is rather user-unfriendly, but it's literally a four line copy/paste followed by adjusting two lines of config file; I suppose nobody could be bothered.
I'm not sure; I edit wpa_supplicant.conf, because I want the change to be persistant across reboots. Nothing like doing kernel development directly on your laptop; keeps you focused ;-)
>For the battery life, you certainly gonna need some tuning, as it's not a config priority by default, but generally (on mainstream hardware) you should be able to reach at least 80%-sh battery life comparing to Linux in OpenBSD, and comparable to Linux in FreeBSD
Yeah, see, that's unacceptable to me in a laptop.
I have a small pcengines apu2 running openbsd but I don't enjoy tinkering with it. I find it cumbersome and unwieldy. The documentation seems to be mostly "complete" but it's definitely geared at someone who already has an in-depth understanding of openbsd, and lots of fundamentals are left unsaid, which makes it difficult to learn what the "proper" way to do something is. I end up with a patchwork of hacks and it's very unsatisfying.
It took me quite a long time to figure out how to get wireguard working on that box, for instance, whereas on linux and mac it "just works" pretty much out of the box.
You said above you were using OpenBSD not FreeBSD, they are completely different operating systems. Also getting the battery to last long on FreeBSD was a super simple config change, that took less than a minute to do.
Suspend and Resume was the hard one, battery life is solid, although I haven't done a direct comparison with Linux. Wifi was easy but not as easy as Linux to setup. On Linux wifi worked out of the box but I would lose wifi a couple times a day. While on FreeBSD I had to edit a few config files to get wifi working but I dont lose wifi every day. To get the Suspend and Resume to work I had to use the drm-next-kmod port.
BSD isn’t like Linux where it’s the roughly the same kernel and user land but a different distribution of packages. OpenBSD and FreeBSD are entirely different operating systems albeit with a shared lineage.
WiFI is working, but not `802.11n/ac`, so you're limited to `802.11g` which sucks, but I use it with ucb-c dongle, so not much of an issue for me. I don't use any GUIs for WiFi because I use the same 3 networks.
> suspend/resume
Yeah, just like linux it doesn't support fancy states that windows does, but suspend to ram works. Works perfect with laptop lid, but you do need to change a sysctl thingy.
> Battery life
I can go entire work day on a single charge for my x1 carbon (gen 6). I know that because I forgot to plug it in multiple times.
I've never heard of MonadBSD, but installing a previous version of a package is straight forward on FreeBSD. Just specify the version when you use pkg or use portdowngrade.
Any docs to this effect? I'm curious to check them out because I've had flawless wifi under GNOME across various work laptops since at least 2010. Maybe it's Ubuntu+GNOME specific, haven't run Ubuntu, but it certainly doesn't seem to be GNOME.
Ah, on re-read of the OP comment, it's "wifi issues and freezing", two different problems they had. Have never seen either from GNOME though.
Wifi in Linux distros is not handled by the DE. It's usually systemd-networkd and wpa_supplicant.
GNOME is very slow. The UI and animations are implemented in JavaScript. KDE Plasma isn't much better though. You should try using a tiling window manager.
Or just a sane floating one like Fluxbox. Taskbar, systray, window merging by title, Zukitre themes to match the GTK ones and dead simple to setup, with no XML such as the "other one".
My confusion stems from the fact that when you say "implementing" animations, I think of shuffling pixels around. By your logic, every HTML marquee tag "implements" an animation.
I've been mulling over a decision to add a dedicated server for my postgres usage in my home server cluster. Ideally I'd like something rock solid stability and that doesn't require a lot of maintenance, and FreeBSD is definitely a candidate. Low resource usage, fast networking, and native ZFS are great benefits.
Does anybody here run postgres on FreeBSD? Any gotchas to look out for? Is performance comparable to linux? Anything to look out for when using NVMe flash drives?
KDE releases numbers can be 4 part. The first 3 are for scheduled releases and the 4th one is for unscheduled one. E.h. 5.18.4 was released without having the version number in the source code updated, so 5.18.4.1 was released right after with that fixed. Otherwise FreeBSD has both the Plasma and the Application version number in their meta package. 5.18.4.1 is Plasma and 19.12.3 are applications.
The last three parts are probably a date in yy.m.d format.
Package names only get longer as you add more layers of maintainers. (For example, package-XubuntuY or package+YYYYmmdd-n was common on Ubuntu, who needed their versions to fit "between" given Debian versions.)
It's a shame the popular VPS providers, like Linode and DigitalOcean, don't support easy installations of FreeBSD (and other BSDs). Does anyone know of trustworthy hosting solutions that make things easy?
I'm missing something here. We have lists of AMIs in every release announcement, and FreeBSD is also in the AWS Marketplace. (Also, for the automation nerds, there's an SNS notification which goes out every time we publish new AMIs.)
I wasn't very clear: the way the AWS Marketplace wants me to 'buy' the AMI for $0 is an annoying extra step. You're doing the right thing on your side, publishing the AMI IDs plainly, the way Ubuntu do. [0] The AMI IDs work fine in EC2 even without 'buying', if you already know them, so it makes little sense for Amazon to artificially introduce this $0 payment step, in the name of it being a 'marketplace'.
While we're here: As I implied, I recently got FreeBSD up and running from one of your AMIs. (I was just playing around, not doing anything serious, and I don't know FreeBSD well at all, my experience is with Linux.) Thanks for your work here. I encountered two issues though:
1. It took a long time for the instance to boot up and for port 22 to open. Roughly 14 minutes. This is with a t3a.small instance.
2. I was unable to confirm the SSH public key of the instance. The EC2 custom is for it to be written to the system log, which is viewable from within the EC2 web dashboard, but FreeBSD didn't appear to do this. (This can take a few minutes on Ubuntu and Amazon Linux 2, for whatever reason, but it works eventually.)
Also, and perhaps it's just me that trips over this, but I'd find it helpful if it were made more explicit that the correct username is 'ec2-user'.
I haven't tried out the ARM64 AMIs but it's great you're providing AMIs for both architectures. Amazon seem pretty serious about their ARM instance-types.
Yeah, this... though it'd be awesome if they updated their setup for working ZFS boot environments OOTB. Last I checked they were setting vfs.root.mountfrom explicitly in /boot/loader.conf.local, which is not stellar. =-(
I changed the OS of my NAS a few weeks ago (from "Gentoo Linux" to "Linux Mint") to FreeBSD (mainly to have a "better ZFS" - I read only later that apparently both Linux & BSD ZFS are being merged?) and the installation and configuration has been very smooth (currently up and stable with e.g. Xfce, gkrellm => just a simple NAS).
I miss only the "nmon" utility but apparently it's possible to "port" almost any Linux program automatically to FreeBSD Linux apps => I might have a look at that.
Recently, a certain unmentionable trend in Linux system software makes me really want to try FreeBSD again.
What’s the state of the art for unprivileged containers? I’m very keen on containers that look very similar to the host OS as they make excellent environments for teaching pupils about the OS, especially if the container host can fake them into being “root” in their container.
Part of the security premise of FreeBSD Jails is that jailed root cannot escape. So, jails are a lighter-weight container which satisfies that need. They can (and often do) look very similar to the host OS.
I think the gold standard here is hypervisors, and if you want to go that route, Bhyve is satisfactory for many workloads. But jails should be somewhat lighter overhead.
BSD threads are similar to PHP threads. Most comments are speaking judgementally about the overall quality of the product rather than the post itself, though in the case of BSD the judgment is overwhelmingly positive rather than negative.
Looks like a nice release. I'd be curious to hear from people who are using FreeBSD on the server, their stories of how it works out especially vis-a-vis working with newer developers who may lack depth in their Unix background.
There's a tendency to try to pigeonhole NetBSD, FreeBSD, and OpenBSD (and sometimes DragonFly BSD and MirOS BSD) into neat little categories. Usually it is along the lines of "the portable one", "the secure one", and "the PC one", but which desktop they notionally support is a similar attempt at classification.
Avoid this. It's as superficial and wrong as classifying people into blondes, brunettes, and redheads. It's not how the BSDs differentiate.
FreeBSD supports KDE, Gnome, i3 and and and.... OpenBSD or FreeBSD don't have a preferred DE, next time check for your self and don't believe in 'explanation's' from some douche-bag.
I tried to install KDE onto OpenBSD and was greeted with a wildly out of date install; while they might not have a DE specifically sponsored on their website, it’s self evident which DE is preferred by the people that maintain and use the OS.
Gnome is updated to 3.36.3.1, while KDE is on the stale 3.5.10 in OpenBSD
In FreeBSD Gnome is updated to 3.28.2, while KDE is on 5.19.0.20.04.2
The Gnome on FreeBSD is 2 years stale, and KDE on OpenBSD is about 12.
I have a 2000-era desktop PC as a personal server that I had left collect dust until very recently after switching to Macs for daily work long ago. It was running 6.1 and I hadn't booted it in a few months shy of ten years. I booted it right up, and in an afternoon proceeded to, in small stages, update it to the latest 12.1 release, which I am running with great stability now, including live repartitioning and better use of the available disk space after going into single-user admin mode. "Recent" improvements that I've been appreciating have been a smaller/more dense console font, easier wireless configuration (it has an Atheros-based PCI wifi card), and easier and more clear package and ports management. AND it still runs fast.