Will FreeBSD ever use the Linux systemd management framework?

Status
Not open for further replies.

Maelstorm

Well-Known Member

Thanks: 130
Messages: 326

#1
Not sure if this should go here or in the off-topic forum.

I've been doing some research into systemd and the controversy behind it. Here's the background as I understand it...

From what I can ascertain, two developers from Red Hat (who shall remain nameless) started this project to replace init, to make system startup faster and more efficient. The project consists of multiple programs which are tightly coupled together and use specialized Linux system calls to the kernel.

Some pros to using systemd:
  • Faster startup.
  • Daemons start in parallel and not serial like in init.
  • Active monitoring of daemons. Will attempt to restart a daemon that exits.
  • Single config file in one location instead of multiple obscure files in different places (supposedly).
  • Not as fragile as init is (also supposedly).
Some cons as I see them:
  • It's taking over more and more functions that was previously served by other tools.
  • It is violating the Unix philosophy of having one tool to do one job very well.
  • Overly complex (looks like svchost.exe from Windows).
  • Popular software now has hard dependencies (Gnome 3.8 and later).
  • The attitude of the developers (Linus Torvalds banned one of them).
  • Sponsored by Red Hat, who is forcing down the Linux community's throat.
In looking at the pros, embedded applications would benefit greatly from systemd. But for workstations and big iron, not so much. A number of the big distros have switched to systemd because of software dependencies. RHEL, Fedora, SUSe, Gentoo, Unbuntu, Arch, and others.

This leads to a few questions....

I looked in ports, and I see that Gnome 3.18 is available. Since systemd is a Linux only monster, and that Gnome 3.8 and later has systemd marked as a hard dependency, how does Gnome run on FreeBSD?

Will FreeBSD ever have a systemd equivalent? The current init system seems to work just fine. At least from what I have seen. I haven't had any problems with it.
 

Snurg

Aspiring Daemon

Thanks: 326
Messages: 794

#2
OMG! :eek:
I hope this monster will never get hold of BSD.:mad:

Regarding Gnome, I guess then some shim will need to be made for BSD users, for those who love that DE.o_O
 

sidetone

Aspiring Daemon

Thanks: 323
Messages: 944

#3
Never fear, based on most public reactions of FreeBSD users, they object to that tangling of components.
We should allow a GNU fork of the ports tree to do whatever it is, they want to do. And, more importantly make functional rules for ports here, based on KISS (Keep it Simple ...)
Typical FreeBSD users need to move on to smaller window managers, instead of Gnome, KDE, XFCE.
It kind of defeats the purpose to have Gnome on top of FreeBSD.
(I think this is more of off-topic)
 
OP
OP
Maelstorm

Maelstorm

Well-Known Member

Thanks: 130
Messages: 326

#5
I interact with my system via CLI only. pdksh is my shell of choice, although I do have bash installed. I have a 3dfx card installed in the machine, so it shouldn't be that hard to install X on it. As for window managers, I always prefered olwm from Solaris.
 

vermaden

Son of Beastie

Thanks: 1,057
Messages: 2,700

#6
From what I can ascertain, two developers from Red Hat (who shall remain nameless) started this project to replace init, to make system startup faster and more efficient.
Lennart Poettering is responsible for writing this shit, same with Avahi and PulseAudio.

The project consists of multiple programs which are tightly coupled together and use specialized Linux system calls to the kernel.
Do You really believe that systemd is engineered or is it just like that:


Look at FreeBSD boot and check how much time is taken by LOADER, then by KERNEL and then by RC init. RC only takes about 1/4 of that time and I havent seen that it is aignifically faster then systemd on Centos 7.4 for example.

Daemons start in parallel and not serial like in init.
Yes, they run everything in parallel withtout chaecking ANY dependencies, fail most services, then restart them again at again at the boot process to eventually finally have everything started. This seem to be intelligent approach? not much. Also with RC, or OpenRC or RUNIT the boot process is DETERMINISTIC which is VERY important in operating systems. With systemd its random and You can not even reproduce its bugs sometimes because boot process is different every fscking time ...

Active monitoring of daemons. Will attempt to restart a daemon that exits.
This can be achieved with daemontools but I agree that having that in RC would be good.

Single config file in one location instead of multiple obscure files in different places (supposedly).
FreeBSD RC also has one config file in one location - /etc/rc.conf

Not as fragile as init is (also supposedly).
Excuse me? Are we talking about same piece of shit 'software' systemd here? RC init is rock stable while systemd breaks everything and itself ... it has been also nominated and rewarded (multiple times) as being worst piece of software and also with biggest and most dangerous security holes.


Sponsored by Red Hat, who is forcing down the Linux community's throat.
Systemd situation in the Linux ecosystem is quite like gang rape. Statistically most participants of a gang rape are happy :ASD


In looking at the pros, embedded applications would benefit greatly from systemd.
In what way?


But for workstations and big iron, not so much. A number of the big distros have switched to systemd because of software dependencies. RHEL, Fedora, SUSe, Gentoo, Unbuntu, Arch, and others.
RHEL CREATED systemd, so its 'ironic' saying that is *SWITCHED* to systemd ... same thing with Fedora which is also Red Hat 'playground'.
SUSE is just for the money, they do what Red Hat do and vice versa.

Gentoo has MANY init systems, systemd is just one of them and its NOT the default.

Ubuntu just goes with the upstream, its 'cheaper' for them to not maintain their own 'upstart'.

Arch is just bleeding edge, no matter the consequences ...

Look at Debian and Devuan (fork), the Debian community has been cut to two halves ...

There is little to none hope in Linux ecosystem because of systemd, but Alpine Linux and Gentoo/Devuan are the last ones that are SENSIBLE choices.


I looked in ports, and I see that Gnome 3.18 is available. Since systemd is a Linux only monster, and that Gnome 3.8 and later has systemd marked as a hard dependency, how does Gnome run on FreeBSD?
Good, that systemd sh!t is definitely not needed, OpenBSD created 'dummy' systemd replacements which 'emulate' this sh!t behavior just to MEET thos sick dependencies, this is the best way as OpenBSD CONTROL this code.


Will FreeBSD ever have a systemd equivalent? The current init system seems to work just fine. At least from what I have seen. I haven't had any problems with it.
Maybe, definitely not systemd. Rather not launchd from Darwin/MacOSX/macOS.

An incremental update with 'daemontools' monitoring would be useful.

Regards.
 

sidetone

Aspiring Daemon

Thanks: 323
Messages: 944

#7
Maelstorm just created a &@#!storm in here. vermaden just let it out. Anyone familiar with these forums would know the reaction to this topic.

FreeBSD RC also has one config file in one location - /etc/rc.conf
Sort of. For customized configurations, there's also /etc/rc.conf.local or /usr/local/etc/rc.conf. There's also the defaults to be overridden at /etc/defaults/rc.conf. Still, this is very simple.
 
OP
OP
Maelstorm

Maelstorm

Well-Known Member

Thanks: 130
Messages: 326

#10
Thanks for the education. No, really. I did read that it was replacing some of the old tried and true functionality that was covered by other services (cron, inetd, etc...), but I had no clue it was that bad. I'm glad that it won't be finding its way into the *BSDs for some time to come. The big thing that I saw was the attitude of the systemd developers. Linus Torvalds himself banned one of them because of their bad attitudes to the community. So it looks like it's a project that is propped up by inflated egos.

I was reading about PulseAudio... "Since we are using more functions of the drivers that haven't been used before, we expose more bugs in the drivers. Nope, not our fault. If you think it's our fault, then you fix our code..." I wasn't aware that the developers behind systemd was also behind PulseAudio. Now it makes sense.

This actually reflects a trend that I see in software development as of late. It seems that the new generation of coders want to change things for the sake of change, whether good or bad. This is one of the main reasons why I avoid Linux. Sometimes, one needs a few years to understand the wisdom behind the adage "If it ain't broke, don't fix it" which I think applies here.
 

MarcoB

Well-Known Member

Thanks: 92
Messages: 335

#12
Don't think it will ever be on FreeBSD, but porting DE's like Gnome will eventually be impossible. I'm afraid that big applications like Firefox or Chromium will depend on systemd too.
 

vermaden

Son of Beastie

Thanks: 1,057
Messages: 2,700

#13
This actually reflects a trend that I see in software development as of late. It seems that the new generation of coders want to change things for the sake of change, whether good or bad. This is one of the main reasons why I avoid Linux. Sometimes, one needs a few years to understand the wisdom behind the adage "If it ain't broke, don't fix it" which I think applies here.
It is a 'rule' in Linux world for quite some time, ifconfig is deprecated, us ip, netstat is deprecated, use ss, route is deprecated, use ip, arp is deprecated, use ip, yum is deprecated, use dnf (but still uses RPM under the hood :ASD), iwconfig is deprecated, use iw ... its endless. Linux 'ecosystem' LOVES to rewrite everything introducing the same (or different) bugs over and over again in the pretext of 'improvement'. Its quite the opposite what is happening in the BSD where tools are IMPROVED. Take a look at OpenBSD's ifconfig which is now also used instead of wpa_supplicant ... just one example of many.

Take a look at this 'mess' mapping:
https://teknixx.com/new-linux-networking-commands/
 

ShelLuser

Son of Beastie

Thanks: 1,497
Messages: 3,283

#17
Personally I think the current rc system works quite well. If they would want to have some replacement or 'improvement' then I think the manifest boot process from Solaris 10 (I don't remember the official name anymore) would be a much better alternative. Of course that won't really work because of the different boot process (rc.conf vs. init.d), but at least it could be less intrusive. Assuming that you could somehow apply it to the rc process of course.

But I'm quite confident that a monstrosity such as systemd will never get its tentacles into FreeBSD.
 

vermaden

Son of Beastie

Thanks: 1,057
Messages: 2,700

#18
I quite like sysutils/fsc as it integrates really well with the existing FreeBSD boot scripts. I'd like to see something like that integrated in the base.
Thanks for sharing this fsc I love such simple tools that provide that much simple yet useful features with that small amount of work and code.

Any idea how to change the timeout for the service restart?
 

vermaden

Son of Beastie

Thanks: 1,057
Messages: 2,700

#19
Personally I think the current rc system works quite well. If they would want to have some replacement or 'improvement' then I think the manifest boot process from Solaris 10 (I don't remember the official name anymore) would be a much better alternative.
Its SMF and svcs/svcadm as commands. As tool its great, but configuration in XML is not that like'able. I would like to see a RC / SMFmerge with some usable config format, at least JSON ...
 

vermaden

Son of Beastie

Thanks: 1,057
Messages: 2,700

#20
That's for laptops. Nobody else needs it.
This idiot (Lennart) literally wrote systemd for his laptop which he claims in one of the interviews, along with claiming that he has ZERO knowledge about maintaining servers ... and this guy wrotes init system for the most widely used system (Linux) for servers on Earth ... and Red Hat thinks this is 'innovation' ...

Interview:
 
OP
OP
Maelstorm

Maelstorm

Well-Known Member

Thanks: 130
Messages: 326

#23
That's for laptops. Nobody else needs it.

Well there is actually one other use case. That is where your computer is hooked up to the light in the bathroom and keeps restarting.
Oh, that could get messy... ;)

But seriously, I was thinking more along the lines of embedded applications such as a CCTV recorder or a set-top box where a fast reboot would be advantageous. Here's a case in point:

A Comcast home gateway for Triple-Play (Phone, Television, Internet) takes 70-90 minutes to fully recover from a reboot. During that time, things do not work. The same applies to the set-top boxes as well. They have to download their software from Comcast's servers.

A home gateway from AT&T for U-verse is about 5 minutes... Same thing with the set-top boxes: 5 minutes.
 
Thanks: OJ

xtremae

Member

Thanks: 6
Messages: 25

#24
Oh, that could get messy... ;)

But seriously, I was thinking more along the lines of embedded applications such as a CCTV recorder or a set-top box where a fast reboot would be advantageous. Here's a case in point:

A Comcast home gateway for Triple-Play (Phone, Television, Internet) takes 70-90 minutes to fully recover from a reboot. During that time, things do not work. The same applies to the set-top boxes as well. They have to download their software from Comcast's servers.

A home gateway from AT&T for U-verse is about 5 minutes... Same thing with the set-top boxes: 5 minutes.
I seriously doubt systemd is relevant to the above example in any way, because (it) isn't really about boot times and (it) isn't really an init. I mean, it can be viewed as an fast booting init, but that's missing the point. Regarding the benefits from fast booting embedded devices, there are equally fast (if not faster) init systems like runit and OpenRC so... why not just use one of those? In fact, both runit and OpenRC are compatible with a multitude of libc implementations, especially the ones that target embedded systems (musl-libc, uclibc, etc), while systemd only targets glibc which - in the embedded world - is avoided like the plague. Based on this presentation [06:50], systemd devs probably don't even accept patches that extend systemd's compatibility with other libcs.

With all the above, there're now trends to avoid the systemd + glibc monoculture in the linux world, with systems like Alpine, Void, Devuan, Gentoo, etc.
 
Status
Not open for further replies.
Top