Linux very very explicitly separates itself from userspace. How does the FreeBSD kernel and userspace break this rule, and how does it help FreeBSD? reddit / freebsd ---------------------------------------------------------------------- DESTRUCTOCORN · 2022-07-06 01:10 Pure curiosity here - I think it would be a cool discussion too ---------------------------------------------------------------------- [deleted] · 2022-07-06 01:46 [deleted] ---------------------------------------------------------------------- edthesmokebeard · 2022-07-06 01:58 Because Linux is a kernel and FreeBSD is an OS. ---------------------------------------------------------------------- celestrion · 2022-07-06 02:50 > rule If you were to look at all the other Unix-family operating systems, you'd find very few where the kernel is developed independently, and most of those are of the sort where the "unixness" of the system is a pluggable feature (ex: The Windows POSIX Subsystem). > how does it help FreeBSD? FreeBSD's relatively linear development makes adding features easy. Let's say that someone pitches to the FreeBSD folks the idea of a really "deep" feature that needs some userland support, some kernel "middle-ware," changes to a driver, and additional tooling in a userland too. I'm thinking of [FFS Snapshots](https://www.usenix.org/ legacy/events/bsdcon/mckusick/mckusick_html/), which enabled backgrounding the filesystem check. This needed: 1. The work in the FFS/UFS filesystem driver to implement snapshots and the garbage-collection for when a snapshot goes away. 2. The work in the VFS layer of the kernel to "pivot" between a snapshot and the live filesystem. 3. Work to `fsck` to support this new background mode. 4. New tools (`mksnap_ffs`, `snapinfo`, etc.) to support handling snapshots. 5. Intelligence in the `rc` scripts and initialization system to cope with a backgrounded `fsck`. With everything under one project, you can see how the work gets divided. If the kernel were maintained by a separate team, you'd get points 1 and 2 done, and...then what? Not only do all the teams dealing with these tiny tools have to add feature support, but the tools have to check at runtime that they're running on a new-enough kernel to deal with the features. In this modern world of single-board computers that don't always get mainline support, dealing with a mainstream distribution running atop a kernel artificially held back gets messy very quickly. ---------------------------------------------------------------------- kraileth · 2022-07-06 03:05 It's a well-known fact that Torvalds takes "we don't break userspace!" religiously. I wouldn't say that this is creed is a strong side of Linux but rather shows one huge weakness: The kernel developers have zero control over the applications that run on Linux. There's downsides of this. For example if they mess up, they basically cannot ever come clean and get rid of a flawed design. All they can do is give it another try (and make the most bloated kernel even more bloated). Torvalds even stated that once any application starts depending on something that is clearly *a bug*, that bug turns into a feature and will not be fixed! If you're interested in sound design and clean programming this is very bad. With FreeBSD neither userland dictates how the kernel may or may not evolve nor does the kernel force userland development into one direction or the other. The developers consider both parts to be an integrated whole to take into consideration when evolving the OS. This also gives them the power to correct things that went wrong. Which is not a theoretical option, BTW! One example of this would be `kse(2)` N to N threading which got implemented in FreeBSD 5.x as it looked very promising but later turned out to be highly problematic. Since FreeBSD can directly make changes to its userland, the project was able to drop it for 8.x instead of having to live with it on and on. For some more context: Compared to Linux FreeBSD is not "the other extreme" as some people might think. That would be OpenBSD. They frequently break ABIs between the versions and do so with good reason (according to their goals): Never ignore any chance to make things better than before and aggressively purge old stuff that could be problematic! FreeBSD is a middle ground between those two, providing a fairly stable base (not changing things without a very good reason + consider POLA, the *policy of least astonishment*) but not being unable to make changes where they clearly make a lot of sense. The FreeBSD approach is a rather practical one while the other two stem from different goals / situations. ---------------------------------------------------------------------- DESTRUCTOCORN · 2022-07-06 04:17 This is a great explanation with a great example. Thank you!! ---------------------------------------------------------------------- DESTRUCTOCORN · 2022-07-06 04:22 Precisely why I asked the question homie :) One part of the design paradigms of FreeBSD that really brought me to this community. I'm learning a whole bunch of what this actually means ---------------------------------------------------------------------- DESTRUCTOCORN · 2022-07-06 04:23 I apologize if it seems backwards. I'm just now diving headfirst into the FreeBSD world ---------------------------------------------------------------------- DESTRUCTOCORN · 2022-07-06 04:27 This is is fantastic. With all parts of the operating system and the people developing it working together, like some sort of gestalt entity, this brings a great deal of empowerment. Thank you for responding! ---------------------------------------------------------------------- grahamperrin · 2022-07-06 05:53 > OpenBSD /u/DESTRUCTOCORN additional context: * [Why computers suck and how learning from OpenBSD can make them marginally less horrible – Telegraph](https://arccompute.com/blog/why- computers-suck-and-how-openbsd-makes-them-marginally-better/) (2019-12-05) – [discussion](https://old.reddit.com/r/openbsd/comments/khfc1n/-/) ---------------------------------------------------------------------- TorMazila · 2022-07-06 14:52 So far there were not so many cases when FreeBSD has broken compatibility with previous versions: Threaded applications got broken when there were "tensions" between libthr/libpthread around 7.x, though binaries not using them were working ok. 64bit FreeBSD broke a.out compatibility (ELF got introduced in 3.0 instead of a.out), though there is an unofficial patch for that - I've never tried it. Basically, it was important if you had 10+years old legacy binaries w/o any source code. Also, there may be issues related to GPU/X Window aspects and other driver-related issues that I am not aware of. ---------------------------------------------------------------------- FUZxxl · 2022-07-06 15:00 > 64bit FreeBSD broke a.out compatibility (ELF got introduced in 3.0 instead of a.out), though there is an unofficial patch for that - I've never tried it. Basically, it was important if you had 10+years old legacy binaries w/o any source code. a.out is still supported, just for i386 only. It was never supported for any other architecture. Note that kernel support must be compiled in for this to work. ---------------------------------------------------------------------- hertzbug · 2022-07-06 18:26 By actively maintaining a stable ABI they allow / encourage downstreams (distros, Android, etc) to upgrade to new kernels without worrying about userspace falling apart. This is a highly valuable property that allows linux to be used in enterprise deployments where long term stability and compatibility are paramount. It also has other benefits of varying importance where e.g a user can run (binary) rolling release distributions upgrading kernels on regular intervals without worrying about breakage. ---------------------------------------------------------------------- setwindowtext · 2022-07-06 19:28 Just don’t forget that smartwatches, microwaves, cars and supercomputers all run Linux kernel, too. Do you expect Linux developers to maintain Android’s userland, or should they stick to the desktop one, which is completely different? Or should they work on both? Mind you, Android is the most widely used OS in the world, so the question may not be as strange as it looks like. What about containers? It’s very common to see BusyBox and musl userland there — again very different from the desktop’s GNU / libc — should kernel or “Linux” developers also maintain this lot? It quickly becomes state of the art in the cloud, can’t be ignored. ---------------------------------------------------------------------- Nyanraltotlapun · 2022-07-07 09:05 Yet they breaking userspace when corporations ask them to do so. I don't understand from where this opinion about Linux not breaking userspace comes. ---------------------------------------------------------------------- Middlewarian · 2022-07-07 14:58 I left FreeBSD after 7+ years and went back to Linux mainly due to io- uring. To the best of my knowledge FreeBSD doesn't have a good alternative to that. I disagree with some of the sentiment about C++, but otherwise am finding Linux to be a good option. ---------------------------------------------------------------------- TorMazila · 2022-07-16 20:05 Thing is you can run ELF from 3.0 on modern 64-bit OS. Using i386 arch for OS is semi-dead as in real life you loose more than you gain - you loose all those new registers and instructions (=speed), access to 4GB+ RAM w/o hoops&loops, and gain only lower memory footprint. As you can run 32bit ELF on 64bit OS and almost any new hardware can run 64bit OS - i386 version makes no sense. But as I said - sometimes you have legacy binaries and it makes not much sense to do lots of work to replace them on one hand and running a whole separate OS (either on real hw or in VM) is a bit expensive on the other. ---------------------------------------------------------------------- FUZxxl · 2022-07-16 20:12 > instructions (=speed) I'm actually not aware of any instruction set extensions that don't also work in 32 bit mode. Even AVX-512 does (though you only get to use 8 registers). > i386 version makes no sense. I was perhaps unclear; you can also run a.out binaries on amd64 FreeBSD, but only for i386 binaries. ---------------------------------------------------------------------- mpgazaza · 2022-07-23 16:40 Thats what they are saying, the problem is that linux is the kernel not the os. That is why freebsds userland and kernel can be developed in harmony without forcing the kernel to keep buggy or old features since the userland can also be easily changed. ---------------------------------------------------------------------- setwindowtext · 2022-07-23 21:38 So at what level does FreeBSD maintain compatibility then? ---------------------------------------------------------------------- grahamperrin · 2022-07-24 00:46 > at what level does FreeBSD maintain compatibility ABI and KBI are mentioned at . There should be something closer to a plain English explanation, I can't find it at the moment. ### Postscript See [That Word Does Not Mean What You Think It Means](http://www.wonki ty.com/~wblock/docs/html/stable.html#_that_word_does_not_mean_what_you _think_it_means) in **Upgrading FreeBSD To -STABLE** by Warren Block. Related: * FreeBSD bug [263571 – FAQ: CURRENT, STABLE RELEASE: corrections, updates and enhancement](https://bugs.freebsd.org/bugzilla/show_bug.cg i?id=263571), [comment 6](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263571#c6). Also, worth noting: * [Changes to the FreeBSD Support Model](https://lists.freebsd.org/pipermail/freebsd- announce/2015-February/001624.html) (2015-02-03).