FreeBSD vs. Illumos

It's been a long time since I've used Solaris, I was working as an intern at Sun (between my 2nd and 3rd years of university) when the Oracle takeover was announced. I got to learn Solaris 10 administration directly from their trainers as well as various kernel and hardware engineers. I was too inexperienced to really understand much at the time, but I was privileged to attend a Solaris internal training course and still have a bunch of the training material that describes how Solaris works.

When I came to FreeBSD, jail management seemed much more basic that zone administration. I think the tooling provided by ezjail/iocage/bastille/etc is similar to what Solaris provides out of the box.
Virtualised networking in Solaris felt very easy to understand and administer back in 2009ish when I used it in my dissertation.

Solaris did seem to go "all in" on concepts - everything was a zone, when you first install a system you have one zone called the "global zone", there was no inherently special root user but there was a role that was equivalent that the root user had, as could any other user...

I really liked that way SMF defines services and dependencies and the tooling to administer services, I've seen the way macOS's launchd and Linux's SystemD has iterated in the traditional init system and still think SMF was easier to understand and administer.

I know back around 2012ish the package repos for OpenSolaris were becoming outdated, it was around that time that I switched away from OpenSolaris and about four years later found myself on FreeBSD.

Solaris came across to me as a more polished Unix than FreeBSD does, although FreeBSD feels more immediately malleable to a variety of usecases (not that Solaris was capable of "interesting" usercases, IIRC the system control unit on the e15k and e25k ran Solaris 9)

The only thing that bothers me about FreeBSD is they dropped the original Solaris ZFS and adopted OpenZFS which are developed mainly by Linux developers.
This is somewhat incorrect. FreeBSD has been using OpenZFS since around 2013 when OpenZFS was created. The difference is that changes were gated by the Illumos project, and from what I understand there wasn't the engineering time to spend reviewing and adding features.
Linux folk forked the OpenZFS repo and actually added features, and Illumos did take some efforts to "keep up" with Linux - but any FreeBSD involvement was done indirectly, via Illumos.

OpenZFS was rebased on where Linux was, and the codebase is owned jointly by Linux and FreeBSD - tests must pass on both before features are released. Original members of the Sun ZFS team are still intimately involved with OpenZFS (yes, the "Linux" OpenZFS).

There are respectable people in FreeBSD and Illumos who care for ZFS and whos livelihoods depend in part on ZFS working, and they were/are in favour of the move amalgimate the Illumos OpenZFS and Linux OpenZFS into one and develop together.
 
I've looked into IllumOS Tribblix and more specifically OmniOS website and read a bit about them, BTW the mailing list over there looks slick.
In 2017, OmniTI announed the were suspending development of OmniOS. After that announcement, Andy Fiddaman, Tobias Oetiker, and Dominik Hassler took over development of OmniOS Community Edition.

Some may recognize the name of Tobias Oetiker, he is the creator of MRTG and RRDTool.
 
That's good to know FreeBSD developer was able to debug it. But still I don't have much faith in Linux developer's coding practice as majority of them like to rush things.
Please do not mix the kernel developers in with the app layer or "plumbing" writers. We know about them. That does not mean the kernel team is beyond criticism, but they usually are a lot more professional. Risking a public a** chewing from Linus (and Theo) seems to improve quality. Who do we have to do that?
 
Any evidence?
no evidence here, but one of the stories that underpin also my gut feeling (and I have been working and troubleshooting quite some docker environments from early on): https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

back on topic: I also used Solaris professionally for some time, and nowadays use FreeBSD wherever possible. However, it makes me a little sad that FreeBSD meeting the requirements for projects is becoming quite rare. Illumos is a nice community project, however, it seems it has a dead end in the longer term.
 
Please do not mix the kernel developers in with the app layer or "plumbing" writers. We know about them. That does not mean the kernel team is beyond criticism, but they usually are a lot more professional. Risking a public a** chewing from Linus (and Theo) seems to improve quality. Who do we have to do that?

Let me clarify that I'm not speaking about Linux kernel developers which I'm sure they're excellent developers. I talking about the Linux distros developing, packing and compiling apps for Linux which often breaks. In a sense it's more of a distros' fault for not doing a good job.
 
That's why I prefer using ...
I mostly agree with you. There is a good English saying: "Choose your poison". Very suitable. We have the package/unstable ABI problem with open source and unwanted changes driven by corporation. Of course everybody may try whatever suites him. I personally liked what RedHat did when they provided a stable base for about 10 years. I used it from 2013 till 2022 with self backported packages. It's a hustle. Pulseaudio was a pain. I can't migrate to the next release because of systemd. Now FreeBSD provides me with poudriere and 5 years of stable ABI during major release. So I've built software as I like and I don't mess with it now, even if official packages are migrating to another version of QT and got troubles. So far so good. Well, 5 years is smaller then 10, but at least I will migrate to F14 without systemd changing everything. :) Well, yes, I would have to rebuild all my software... But nobody forces me and I will have ZFS snapshots to roll back just in case. I also have my Window Manager from the beginning of 200x and no corporation had forced me to change it. So that's my way.

Solaris would be perfect in this scenario... But it didn't happen to be. Firefox just can't handle (in the past for sure) so much Tabs as I usually like to keep open.

> The only thing that bothers me about FreeBSD is they dropped the original Solaris ZFS and adopted OpenZFS which are developed mainly by Linux developers.

Yes, me too. But the good news are, they would probably step on a bug first.)
 
I am a Solaris user, so my opinion may be slightly biased.

To create a zone, you need:
- open zonecfg tool,
- set path to the zone (it's one-liner),
- few one-liners to add and configure net (address, gateway etc.),
- another few one-liners to mount external directory to the zone,
- commit & exit,
- run zoneadm install and wait, let's say, 30 seconds (for sparse-root zones).

If you know zonecfg and zoneadm, you can have sparse-root zone ready in less than a minute.

Regarding FreeBSD, forgive me if I made something incorrect or my knowledge is outdated. But when I was testing jails some time ago, I was forced to:
- install sources of everything,
- create a jail by compiling entire FreeBSD system onto it,
- wait, eat lunch, still wait.

I found jails management tools counterintuitive and difficult to learn. I am sure that after some time, one can be as good with managing jails as with zones. However, jails have key disadvantages compared to zones:

1) To create a jail, you need to compile from sources. I don't understand why compile it, if all files are already on disk?

2) I haven't been able to find anything like a "sparse-root jail". A jail is complete FreeBSD system, which is what makes deployment process so slow. In contrast, sparse-root Solaris zone, inherits most of files from global zone ("mounts" live system directories from the real OS) and only takes up about 150 MB of disk space. This makes deployment of multiple zones quick and pleasant. And no compilation!

Sparse-root zones were removed in Solaris 11, but I can't find similar information for illumos, so I expect they're available there.

ps.: Very interesting topic. I know that future of Solaris user is illumos or FreeBSD. Certainly not Linux!
Someone lied to you...
You don't need anything special other than knowledge to create and administer/run jails.
No compilation, no installation.
All you need is a proper running system and the knowhow and you're good to go.
I taught myself in under 30 minutes!!
 
It has been a lot said about advantages of Solaris. Even Solaris ZFS implementation avoids double buffering as in FreeBSD, but the eco-system is limited too much. When migrated from Linux (Jan 2022) I've made a check list to choose between the two. And if we speak about workstation, there is no port of Google Chrome for Solaris and that's a deal breaker. Also it's package manager sucks. Also you can run FreeBSD both on hosting and at home. So FreeBSD is a compromise between Linux that develops chaotically so much, that it doesn't make sense for me as a user. FreeBSD is kinda a patchwork of different techs (3 firewalls?! are you kidding me?!), but with that it manages to be the same i used to use for the last 20 years. And I miss an old closed source gtk2 software like Nero burner and Adobe reader. I like when things just work as before for a long time.
FreeBSD doesn't make sense to you, you miss closed sources...
Why are you still using it? ??‍♂️
 
Someone lied to you...
I struggled with FreeBSD myself, learning it in virtual machine. Maybe I followed wrong guidelines, or my installation was broken? Never mind, I'll test it again later.

there is also LX Branded Zone which is LX Linux container

I use it when I'm missing a desired tool in Solaris, e.g. Rar archiver. Booted up Linux-branded zone takes 20 MB of RAM. It behaves much like regular non-global zone, the obvious difference is that you can run Linux applications in it. They work with native performance, regardless of whether hardware supports virtualization or not. You can even load a GNU dekstop, that will integrate with the real one. The result is two taskbars on Solaris desktop: the native one at the bottom of the screen, and the GNU taskbar above it. You can run Solaris and GNU/Linux graphical apps side by side. Oracle abandoned this interesting technology, but apparently it has been revived in illumos.
 
Hello,
What are the advantages and disadvantages of FreeBSD compared to Illumos?

Thank you.
FreeBSD kernel and userland are built together as one system by the same people. Most iterations of Illumos have Ubuntu or Debian as the userland and what used to be the OpenSolaris kernel. I'm sure its kernel has been modified since, but it has a much smaller user base and zero corporate adoption vs FreeBSD. So if you run into problems there will probably be a lot less places to find online documentation or help. It will also be much harder to find a job with Illumos. It would be better to just learn FreeBSD, Solaris and Linux and put those on your resume. If you just want to tinker, I'm sure its a great place for it. I used to used the defunct kFreeBSD when it was active. While it had most of the same problems I mentioned here for Illumos, it was fun to tinker around with and I miss that.
 
Solaris Zone management doesn't need additional software to create zones, similar to FreeBSD jails. However, Solaris zones offer better containment and security because they don't share system resources with other zones. In contrast, FreeBSD jails, while improved with VNET, may face challenges when running two web servers on the same port in separate jails.
Why would that be?

Long ago there was an issue with multiple postgres databases, because they might use the same sysv-ipc. It seems this has been fixed, because mine are running well together for many years already.
The last troublesome issue in my knowledge was that trafficshaper/dummynet was not separated. It is now in Rel.13.
Now what remains difficult is mostly the error messages from kernel modules, which cannot be easily sorted out back into individual jails.

It seems to me in our modern social media times there is a lot of hearsay circling around, and rather few people really touching the matter and reading the source.
 
it has a much smaller user base and zero corporate adoption vs FreeBSD. So if you run into problems there will probably be a lot less places to find online documentation or help. It will also be much harder to find a job with Illumos. It would be better to just learn FreeBSD
Joyent which is owned by Samsung has SmartOS which is illumos.
MNX is cloud-based object storage which uses illumos.
Lucera provides financial infrastructure services and uses illumos.
Delphix provides database virtualization and uses illumos.
Nexenta provides storage and uses illumos.
EveryCity provides managed cloud services and uses illumos via OmniOS Community Edition.

There's just a few.

As for finding a job, are there seriously more jobs for FreeBSD development than illumos? Not likely. If someone is able to do kernel development on illumos would they still be hirable by company X? Likely, because they know how to do kernel development, not just because it was illumos or FreeBSD.

illumos uses illumos userland. They use gnu coreutils and gcc to compile, but that doesn't give them a Debian userland. OpenIndiana uses oi-userland. OmniOS uses omnios-userland.
 
Joyent which is owned by Samsung has SmartOS which is illumos.
MNX is cloud-based object storage which uses illumos.
Lucera provides financial infrastructure services and uses illumos.
Delphix provides database virtualization and uses illumos.
Nexenta provides storage and uses illumos.
EveryCity provides managed cloud services and uses illumos via OmniOS Community Edition.

There's just a few.

As for finding a job, are there seriously more jobs for FreeBSD development than illumos? Not likely. If someone is able to do kernel development on illumos would they still be hirable by company X? Likely, because they know how to do kernel development, not just because it was illumos or FreeBSD.

It was news to me that those or any company used illumos. So thank you for that. This wiki sites DilOS as having dpkg and apt. I know Dyson is another version of illumos that uses those too. Maybe they just have those tools on top of an illumos userland, but I wouldn't see the point in using both. I thought I remembered OpenIndiana having Ubuntu for the userland, but I see now that is not correct. My bad.
 
I struggled with FreeBSD myself, learning it in virtual machine. Maybe I followed wrong guidelines, or my installation was broken? Never mind, I'll test it again later.
I think the thing that got me coming to FreeBSD Jails was that all the instructions I found started by fetching the compiled base tarball and unarchiving it (or using one of the many tools to do so). The ZFS guides of several years ago almost got you to do this, then clone the dataset for each new jail.
Compare that to my experience on Solaris where the recommended way of setting up Zones was (as you previously mentioned) to share a bunch of directories from the non-global zone - as a result your Zones were effectively upgraded along with the host. I can't remember where, (maybe on these forums, or maybe on IRC) I was recommended to not do this on FreeBSD "because it could break things"...

I use it when I'm missing a desired tool in Solaris, e.g. Rar archiver. Booted up Linux-branded zone takes 20 MB of RAM. It behaves much like regular non-global zone, the obvious difference is that you can run Linux applications in it. They work with native performance, regardless of whether hardware supports virtualization or not. You can even load a GNU dekstop, that will integrate with the real one. The result is two taskbars on Solaris desktop: the native one at the bottom of the screen, and the GNU taskbar above it. You can run Solaris and GNU/Linux graphical apps side by side. Oracle abandoned this interesting technology, but apparently it has been revived in illumos.
This sounds basically the same as using the Linux compatibility layer in FreeBSD to create Linux Jails - not sure on how easy/possible it would be to share desktop components (not something I've done on either system). While I have run a few Linux Jails on FreeBSD, I never had cause to use branded zones on Solaris.
 
I think the thing that got me coming to FreeBSD Jails was that all the instructions I found started by fetching the compiled base tarball and unarchiving it (or using one of the many tools to do so). The ZFS guides of several years ago almost got you to do this, then clone the dataset for each new jail.
Compare that to my experience on Solaris where the recommended way of setting up Zones was (as you previously mentioned) to share a bunch of directories from the non-global zone - as a result your Zones were effectively upgraded along with the host. I can't remember where, (maybe on these forums, or maybe on IRC) I was recommended to not do this on FreeBSD "because it could break things"...
This is an interesting point.
In the old times, when there were X-terminals, these would nfs-mount their entire disk from a common server. Back then there was a clear understanding which filesystems a machine would write to, and which it would only read. And even, which filesystem it would read in an architecture dependent way, and which could be shared among architectures.

The layout of the unix filesystem is not due to "some POSIX standard", it is due to these kinds of technical requirements.

In this century, however, we have seen that nobody gives a damn about these things (speak: we are 'modern' and we don't need it any more), and in fact Berkeley might be the last bastion where the tradition is slightly kept alive.

But, good enigneering does not really become old-fashioned, and if you remember that old style of disk partitioning, then you already have the missing piece for your coupled upgrade: because it only "could break things" if you share the wrong parts.

So much for systems management by tapping tiles and listening to hearsay...
 
This is an interesting point.
In the old times, when there were X-terminals, these would nfs-mount their entire disk from a common server. Back then there was a clear understanding which filesystems a machine would write to, and which it would only read. And even, which filesystem it would read in an architecture dependent way, and which could be shared among architectures.

The layout of the unix filesystem is not due to "some POSIX standard", it is due to these kinds of technical requirements.

In this century, however, we have seen that nobody gives a damn about these things (speak: we are 'modern' and we don't need it any more), and in fact Berkeley might be the last bastion where the tradition is slightly kept alive.

But, good enigneering does not really become old-fashioned, and if you remember that old style of disk partitioning, then you already have the missing piece for your coupled upgrade: because it only "could break things" if you share the wrong parts.

So much for systems management by tapping tiles and listening to hearsay...

Not just diskless X terminals, entire workstations booted disklessly. This was a big thing with SunOS 4 on SPARCstations.

To save disk space it was well supported to only have individual filesystems per workstation for the root filesystem with etc, var and the like. And have a /usr that was readonly mounted and shared between all workstations. I actually ran FreeBSD like that for a while, but it is too much headache for patching.

Of course now you don't need it anymore if you have ZFS with dedup on.
 
  1. Initially, eyes lit up at the possibility of finding and reinvigorating a defunct KDE-on-FreeBSD distro
  2. heart sank, briefly, when seeking kFreeBSD led to Debian/kFreeBSD, whats the point?
  3. hilarity, at stumbling across a ninth Reddit ID for someone :)

The actual count may be somewhat higher. Terms and conditions apply, et cetera and so forth.

When kFreeBSD was well maintained in 2015, it was good for me. FreeBSD was foreign to me then, but kFreeBSD let me experiment with pf, jails and ports, but have the security of knowing I could use a Debian package if I got stuck and needed to. After that I just wanted more BSD and moved on to using FreeBSD and other BSDs instead.

I must say though, I usually respect why lot of people make fun of kFreeBSD until you mentioned KDE with adoration. I can't imagine becoming well versed in FreeBSD only to use one of the most bloated and resource heavy DEs available. I must say, I loved KDE in 2004, but today I would say if you still use KDE or Gnome you might as well use Ubuntu Linux like a farmer.

I guess we all have our older software that makes us nostalgic.
 
Back
Top