systemD is coming to a port near you!

Distrowatch is not a reliable source for statistics. Nobody knows how many people are using what, where, when ....

There's no need. Just follow the instructions at Building A FreeBSD Desktop From Scratch by Trihexagonal
People can follow the guide, but do beginners prefer modifying manually than having GUI in installation? I won't say that FreeBSD GUI disk image should be on the download page, but it will save troubles if there is GUI option in installation process like openSUSE. When I first tried FreeBSD, it took 2 weeks to install GUI(because of xorg configuration), and this is not the situation that newbies want.
 
There's GhostBSD which is basically FreeBSD+MATE.

lol, looking through the recent news section of GhostBSD:
What is new in 21.09.06?
  • GhostBSD moved back to FreeBSD rc.d to start services

And more:

The switch to FreeBSD rc.d is coming

Submitted by ericbsd on Fri, 08/20/2021 - 21:25
After trying to keep all services for OpenRC up to date with FreeBSD services, I weighed the pros and cons of OpenRC. The only pro that made the decision hard to make was OpenRC's services status feature, so I turned to the community with a poll to see the consensus.
The poll was up for a week. The results are as follows:
FreeBSD RC (rc.d) 68% (217 votes)
OpenRC 32% (104 votes)
The Total of votes: 321
So I am going with the majority. I have been running GhostBSD with rc.d for over a month to ensure a smooth transition. Now I feel comfortable pushing the update to switch to rc.d. So tonight, GhostBSD will have an update that will set bsdrc to system_rc in /boot/loader.conf and add all services from OpenRC default runlevel to /etc/rc.conf. It is to be expected that the colorful boot messages will disappear.
It is to be noted that OpenRC will not be removed from our source code before next year.
For those who are disappointed with this change, put your feet in my shoes. Maintaining FreeBSD services plus FreeBSD ports services for OpenRC is too much for one person. In addition, I do not have the adequate manpower to keep up with all new services and services changes. I have people helping, but it is not enough to keep up. So instead of trying to keep up with something that already works well, GhostBSD will focus on improving the FreeBSD desktop experience.
 
Certainly! I fully agree! I didn't mean to say that it's a good thing that 3rd-party software relies on this.
No problem; I didn't read it as you thinking it was a good thing. I was just using your statement as an example of "why systemd may not be a good thing".

GhostBSD and others:
When creating a distribution or offspring of anything, if you take upstream and just add your value, it's easier for you to keep up to date. A lot of work to keep OpenRC up to date: it affects not only base but every single port that has a rc script. Port gets updated? You need to update everything for OpenRC.

Simplistically, one could create a FreeBSD-desktop distribution by "installing FreeBSD and then running a configure script to install graphics stuff". That is the approach taken by the sysutils/desktop-installer port. Not sure how up to date it is, but conceptually that is what you could do.
Basically the script does:
Detect the video hardware
Install the proper drivers (drm-kmod, nvidia-driver, etc)
Ask the user "what DE or WM do you want?" and install that.
Install standard set of ancillary programs like web browsers, email clients, etc.

The how to by Trihexagonal and the blog series by vermaden are the step by step instructions and aren't difficult to follow.
 
I was worse. But good! That process is good. It's called learning.
I agree on that. And I think this is where an important part of (Free)BSD comes in: Once you learned it you don't have to re-learn accomplishing the same thing over and over because underlying stuff changes so frequently. Have a fundamental question/problem with FreeBSD? You find some information in a mailing list archive from 2009? Great! Most likely it's still the same!
With Linux, my personal experience is that things just change all the time over and over. Sometimes even back and forth. While I most likely do have a natural tendendency to stay cautious about change I certainly know that change can be good too and I try to be as flexible as I can in most aspects of life. However, I don't want to spend time re-learning doing the same thing over and over if that thing is a tool. And to me, computers are often "just" that: A tool. I like learning and trying to master a tool. If the tool changes constantly, that can be fun, but is probably less efficient for accomplishing your actual goal when using the tool.
I can read notes I took on FreeBSD stuff from many years ago and it is still valid & holds true. My experience with a large quantity of Linux distros (and honestly Linux in itself) is that things change a lot. Just look through the various popular Q&A platforms and look for something like "How to do X in Ubuntu" and you'll find plenty of posts/comments over the years that will reflect on which versions this works and which versions it doesn't work.
Again: Not a problem in itself. Just not what I want for any production server nor for my main desktop machines. I want to enter the room, power the thing on and not having to figure out every 11 weeks on how to accomplish something that I already accomplished many times before but using different tools/techniques just because core stuff changes.

Simplistically, one could create a FreeBSD-desktop distribution by "installing FreeBSD and then running a configure script to install graphics stuff". That is the approach taken by the sysutils/desktop-installer port. Not sure how up to date it is, but conceptually that is what you could do.
Basically the script does:
Detect the video hardware
Install the proper drivers (drm-kmod, nvidia-driver, etc)
Ask the user "what DE or WM do you want?" and install that.
Install standard set of ancillary programs like web browsers, email clients, etc.
Unfortunately, just setting up a desktop system is half the game. For a user which wants to use FreeBSD but doesn't want to go through the installation process as it is today you'll find that they'll most likely also expect/want high-level configuration tools, GUIs for system updates/upgrades and so on.
Thinking back to my first days with FreeBSD I'd certainly have appreciated something like that but then you just handled the installation process. The user still has no clue how to use the system without all the surrounding infrastructure that your typical popular Linux distros come with.
You'll need a GUI for firewall configuration, a proper & reliable auto-mounting system, ... the list just goes on.
Again: Not judging anything. I just want to clarify that providing an Ubuntu-like installation/setup solution is not going to satisfy the demography in question.
 
As far as I can tell, the largest part of (Free)BSD people opposing systemd are not opposing the idea of a system layer or rejecting the overall concept behind systemd (these would probably be the "Unix philosophy"-huggers that you mentioned). I think the opposition arises from some (note: not all!) design decision present in systemd.
Well systemd just cares about Linux, because they are using many features where FreeBSD might have different solutions in place or no equivalents.

To quote Poettering himself:
  • Myth: systemd being Linux-only is not nice to the BSDs.
    Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.
  • Myth: systemd could be ported to other kernels if its maintainers just wanted to.
    That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces.
So this makes it crystal clear that systemd is not written with portability in mind, and also that it is not portable for a reason.

And that's also the problem with it in case a DE or other software relies and only supports its API: then these features are either not available under FreeBSD, or you've got to have something which implements these APIs without the rest. Which is probably one reason why Bruce Perens is of the opinion that systemd should be broken up in several own projects.

GNOME for example had for a while pretty much hard dependencies on systemd (this has now been changed), which really was not fun probably for GNOME maintainers under FreeBSD.
 
"When someone tells you who they are believe them"
When the "creator/designer" tells you things like "...porting to other kernel is not feasible..", one should pay attention and ask yourself "should this be ported"?.

Now if one were to take design documents for systemd, work through the requirements and then ask "should this be done", that's a whole different thing. A thing that is common in engineering. Don't simply port the implementation, look at the requirements and decide.

And that's also the problem with it in case a DE or other software relies and only supports its API: then these features are either not available under FreeBSD, or you've got to have something which implements these APIs without the rest.
Yep and by looking at that one can start to see "why do they need systemd for that?". Shim layers have been in place for a long time. linuxkpi used by drm-kmod is a popular one.
 
Any distro that a person used first is likely to use forever.
Well... I've started with Slackware 3.0 until the horrors of 4.0~7.0 then I've changed to Gentoo. Today I use FreeBSD and Artix+OpenRC. YMMV, but I can see your point, usually lazy people don't want to try different/better things, specially if one doesn't want to walk too far away from piloting a mouse.
 
No doubt in my mind this initware is driven by the desktop crowd.

Solution:
Remove Xorg, desktop environments, and window managers from the ports. I guarantee the drive will go away.

The Ubuntu/Fedora/etc users/developers who switch to FreeBSD want it to be like the crap they just came from.
And they did not realized that BSD is too easy to use, trust me I experience it everyday at my job...
 
(Free)BSD certainly doesn't have a need for it, but a lot of 3rd-party apps that one might want to run on his (Free)BSD machine does.
For example?

"When someone tells you who they are believe them"
When the "creator/designer" tells you things like "...porting to other kernel is not feasible..", one should pay attention and ask yourself "should this be ported"?
One of the earliest things Mr. Poettering said about the BSDs and systemd was that "niche kernels" would not be supported. He clearly expressed both his contempt for and ignorance of the BSDs in that simple statement.

I unfortunately cannot find this quote on the Internet any more. Master politician that he is, he scrubs and rearranges his statements every so often.
 
I unfortunately cannot find this quote on the Internet any more. Master politician that he is, he scrubs and rearranges his statements every so often.
You mean Lennart ist root on Reddit, many forums, the LKML, Ycombinator, and he edited their databases of posts to change the past?

Matter-of-fact, I think SirDice and Crivens will be very surprised to find that Lennart has his own admin account on this forum. Actually, I just found the explanation: They are all the same person! Here's proof: Have you ever seen them together in a room? No!
 
Lennart is also the author of audio/pulseaudio and net/avahi-zeroconf. So if you use them, you are doomed also.
He is the creator of them, but stepped down as maintainer and project lead from both years ago. Some nasty (?) people say that since then Pulseaudio became drastically better compared to the state it was in before. Avahi though still many consider to be quite the mess.

That's the difference to systemd: he's still busy maintaining and leading it.

The "niche kernels" make sense, since Poettering's employer is RedHat. RedHat for sure does not care about FreeBSD at all.
 
The "niche kernels" make sense, since Poettering's employer is RedHat. RedHat for sure does not care about FreeBSD at all.
What other kernels does systemd support anyway?

Someone less weird would surely have just said "non-Linux kernels".

Microsoft's init system also works on every kernel apart from the "niche ones"... So just NT then. Very odd wording. Can't decide if he was being crafty or if he is just out of his depth in terms of wider knowledge.
 
Turns out that systemd does not even support most of the Linux kernels. It's a fast moving target, with feature creep in full motion, so getting new features every release. So the number of kernels the most recent versions do support is quite limited.

This also affects udev, which is nowadays part of systemd and the Linux device manager handling all events on adding or removing devices. One of these things which was standalone before, and then absorbed by systemd.

When this happened few years ago the folks over at Gentoo started to fork udev, and managed their own replacement for it called eudev, because they were of the opinion such a basic and important tool should not only support this limited range of kernels by Poettering's choice.

...and since maintaining this fork became over the time too work intensive and troublesome, it will be removed at 1st of January 2022. So they will then just use systemd-udev instead of it.
 
I freely admit that I moved to FreeBSD because of systemD, having been a Linux user since the late 90's/early 00's. systemD walked away from the Unix philosophy, and in my mind started making the same mistakes Microsoft did with Windows.

I felt that in many ways Linux was trying to emulate Windows, specifically:

- systemd: One big binary blob of questionable code quality, general scope creep, root (or higher) system privileges, linked into the kernel, and the source of some serious vulnerabilities and bugs, is the direct analogue of "taskmgr.exe" in Windows, which is the same in conception (And indeed ran in its own "system" user, which was above the administrator user).

- d-bus based "central configuration", which is so similar to the system registry in Windows. I remember one time when debugging a systemD machine, looking at a binary forest of trees, all with UUIDs, binary blobs, random snippets of text/config/code bundled together. It felt like I might as well have typed "regedit" into the console (indeed I ended up aliasing "regedit" to point to the config editor on these machines, as a form of dark humour more than anything else)

- Binary logs - Yep, exactly the same as Windows event logging, with pretty much the same problems

- Arcane instructions poorly documented to debug, and generally a system designed to make it hard to debug/fix. Yep, Windows had this for ages, I suspect to ensure a steady supply of work for "MCSEs", and with it a steady supply of people paying for MCSE courses. I suspect the same idea is used by RedHat/IBM here to create a steady demand for "RHCE" courses and jobs.

In some ways, I think Linux has fallen to the curse of "May your strongest desires come true". Throughout the 90s and 00s a decent component of Linux users clamoured for "Linux on the desktop", and "to dethrone Windows".

As it happens, on this quest Linux started to turn into what it was fighting. To me it feels that as Linux became more mainstream, a lot of Windows programmers starting writing code for it, and unfortunately brought all their habits and philosophies with them. People who never understood the "Unix Philosophy", or even "the KISS Principle" started writing code for Linux, with the expected consequences really.

The result is Linux is becoming more like Windows, while ironically, Windows is becoming more like Unix (with a "core" modular design, stability, ability to run headless and a proper shell that can be used for scripting and automation, even over SSH).

I started my sysadmin career virtualising unstable Windows boxes on stable Linux systems, and now I have seen a full reversal. We virtualise unstable Linux boxes on stable Windows HyperV servers.

Indeed, systemD systems break in such arcane and nonsensical ways that it is usually quicker to do a quick "turn it on and off again", and if that doesn't work, to wipe and reinstall (Which is exactly what we used to do with Windows machines). It just feels like a black box really.

As for me, I gave systemD a try originally, but watching it crash, break, corrupt and general trash every single Linux box we installed it on, I decided to call it a day. Most egregious was one where systemd found a way to corrupt the EFI BIOS, which actually rendered the systems unbootable until the BIOS was re-flashed.

As someone else mentioned in the thread, almost all the Unix skills for debugging did not apply on systemd. I actually found it easier to transition from Linux to FreeBSD then to transition to systemD. I now run only FreeBSD on servers, and Devuan for GUI desktops.
 
I started my sysadmin career virtualising unstable Windows boxes on stable Linux systems, and now I have seen a full reversal. We virtualise unstable Linux boxes on stable Windows HyperV servers.
Stable Windows HyperV servers? Hold my beer, because Microsoft has different opinion on this, just look at that Linux patch coming from them: https://lore.kernel.org/lkml/20200914112802.80611-1-wei.liu@kernel.org/T/

Hi all

Here we propose this patch series to make Linux run as the root partition [0]
on Microsoft Hypervisor [1].

Microsoft wants to create a complete virtualization stack with Linux and
Microsoft Hypervisor. There will be a subsequent patch series to provide a
device node (/dev/mshv) such that userspace programs can create and run virtual
machines. We've also ported Cloud Hypervisor [3] over and have been able to
boot a Linux guest with Virtio devices since late July.


So Microsoft wants to replace Windows in favor for Linux as host operating system for their own HyperV Hypervisor. I'm sure they've got pretty enough reasons for this in that Azure cloud. So sounds like Linux HyperV servers are the future they are working on, well at least in their own data centers.
 
Well, I admit my evidence is anecdotal. However I can't deny from experience that the Windows servers have fewer problems than the Linux servers. Not so much because Windows got that much better, but Linux got that much worse.

Microsoft may have their reasons, but they may not be technical reasons. They may well do it just because clients want it, or they want to be cross platform to better compete with their rivals (e.g. VMWare/VirtualBox). The patch allows Linux to be the root partition, but does not diminish windows as the root partition. It just gives you a choice.

Saying that, the solution most of the time is pretty much the same now for both Linux and Windows: "Turn it off and on again", followed by a wipe and reinstall. I admit automation tools like Ansible have made rebuilding so much easier, that sometimes it is more cost effective to rebuild then to spend a day debugging.

Alas the company would not even consider FreeBSD, not even for ZFS (they tried ZFS on Linux instead, and the best way to describe that implementation is "not yet production ready")
 
I unfortunately cannot find this quote on the Internet any more. Master politician that he is, he scrubs and rearranges his statements every so often.
Perhaps he does, but things we knew before are difficult to find again on the Internet anyway. Sometimes, information was there, but whatever occurred afterwards is all that's found. and it's like whatever happened before that can't be found. The search engines seemed to work better a few years ago. Either that, or there's so much on the Internet, compared to before.

There are some clowns who actually scrub and rearrange indefensible actions on purpose.


Lennart is also the author of audio/pulseaudio and net/avahi-zeroconf. So if you use them, you are doomed also.
Those don't belong in the ports tree, but then I only get told, to use Poudriere. That's no solution. The problem is embedded, and without getting rid of it completely, we're just chasing our tails for a minimal effect.
 
ZFS on Linux is now the same as in FreeBSD 13, namely OpenZFS. The times when FreeBSD used a different implementation of ZFS are over. Reason for that if I remember correctly is to catch up with the new features OpenZFS has, but FreeBSD had not. It's been a change not everybody is glad about it.
 
ZFS on Linux is now the same as in FreeBSD 13, namely OpenZFS. The times when FreeBSD used a different implementation of ZFS are over. Reason for that if I remember correctly is to catch up with the new features OpenZFS has, but FreeBSD had not.
Indeed, but its interaction with RHEL/CentOS was less then stellar, and the company will not consider other distro's. I do believe if you want ZFS on Linux, Ubuntu is the go-to distro at the moment. I can't comment on the actual OpenZFS code itself, but I have not heard anything concerning about it so far.
 
If one searches ZFS on LKML you find a whole lot of "impolite phrases about the parentage of ZFS" and given the licensing, ZFS will likely never become "a filesystem supported by the kernel".
So, at least to me, implies OpenZFS can progress without being tied to Linux Kernel which means everyone benefits.
FreeBSD-13 is basically a "rebase of FreeBSD ZFS to OpenZFS 2.0" I don't know if IllumOS or others have done the same or if they are still using the FreeBSD-12 ZFS code (OpenZFS 1.0)
 
Back
Top