# systemD is coming to a port near you!



## mark_j (Aug 13, 2021)

If spare time is available, I like to read vermaden 's valuable news. Specifically, this week's installment here.

What got my attention was the subject *InitWare (systemd fork) Runs on OpenBSD for First Time.*

A quick look at the github site gives no reasoning behind this. Further investigation yields another example here. There's probably more out there.

Of course, people are free to spend their time doing whatever they please. I am not disputing this. I am just questioning the reason/motivation for such endeavours, given what I know of systemD, it's designed to not be portable and it's inherently poor in design anyway (you know, discards the Unix principle of simplicity and minimalism [subjective]).

The best chance these have are as ports because of their licence, so again, what's the motivation?

I also wonder, once they mature,  if anyone would even use them?

I did feel like posing the question to their authors but I am not on github and don't intend to be.

Hopefully they might pass this way and reply. Either way I think it's an interesting topic (in futility, if you ask me )


----------



## Vull (Aug 13, 2021)

Maybe they want it for Wayland or KDE, or both. Who knows? Not me. I do like KDE, but it's only of peripheral interest to me, and, I hope and would certainly like to believe, to the core FreeBSD team.

It's just a port. I like the init system we already have. No need for systemd or its spawn to ever invade our base system here.


----------



## kpedersen (Aug 13, 2021)

I think a shim layer that just emulates enough systemd will help to port badly written software. Other than that it is just amusing time wasting. Like porting launchd.


----------



## Beastie7 (Aug 13, 2021)

ew, viralware. Stay away from me and my FreeBSD boxen.


----------



## Deleted member 30996 (Aug 13, 2021)

That's one of the things I addressed at DW this morning. I explained that just because it makes it into the ports tree doesn't mean it's going to make it into the Base System install. They weren't clear on the issue so I detailed it out for them. And why Xorg, DE or a WM are not included in the Base System.

That we like it that way and no matter how many people complain about "Why can't FreeBSD be more like that other OS" it's going to stay that way.


It's a dirty job but somebody has to get out there and do it. I'm already infamous. It can only add to it, take me closer to being famous for my infamy and achieving notoriety.


----------



## gpw928 (Aug 13, 2021)

mark_j said:


> If spare time is available, I like to read vermaden 's valuable news.


vermaden 's valuable news something that I also appreciate greatly.  

Viewed _*solely*_ as middleware, with the listed characteristics, namely:

InitWare  has a high level of compatibility with the core interfaces of systemd;
InitWare is highly portable;
InitWare aims to be significantly more modular; and
InitWare is of significantly smaller scope, concerning itself only with system, service, and session management, and matters ancillary to these, such as event log management.
I think it may find favour with those who want to port Linux applications *BSD platforms, and maybe even some systemd-free Linux platforms.

I say this because of the ongoing struggle I see in the Debian community -- the effort required to maintain (systemd-free) Devuan fork is approaching impossible as systemd ingratiates itself into every nook and cranny of Linux.  Getting the middleware functions, without the associated creep into the kernel, is going to make life a lot easier for some people.


----------



## Deleted member 30996 (Aug 13, 2021)

I've got a Kali 2021.2 rolling release box sitting next to this one and unless I missed something it's still based on Debian. I don't notice any difference in the way it runs from the Debian boxen I've had in the past. 

It's an Intel Core 2 Duo T7700 @ 2.4GHz with 4GB RAM at 28 days uptime. CPU usage at 2%, free memory 3449M, and apt-get works for me just like it always did.
FreeBSD 12.2 is what I use though.


----------



## bobmc (Aug 13, 2021)

The big problem for software systems these days is security. Google "security challenge" = 1,100,000,000 hits.

So when considering the merit of a software system change, one should ask "how does this improve/degrade security".


----------



## Beastie7 (Aug 13, 2021)

I don't know what apps would necessitate systemd. Doesn't the Linuxulator solve this issue for apps?


----------



## Geezer (Aug 13, 2021)

Trihexagonal said:


> I'm already infamous. It can only add to it, take me closer to being famous for my infamy and achieving notoriety.





And additionally,


----------



## sidetone (Aug 13, 2021)

I didn't understand SystemD or whatever init it was when I tried Arch Linux. It had 3 or 4 layers represented by files for starting up programs, which, I didn't know what to put first, and why one should be in the first init. Maybe if they had an init file for internet services, instead of 1. Or if they had 2 or 3 inits. 4 left me confused on how to order them. Maybe if I left the last init blank, if I didn't need it, or didn't have enough services to need its categorization for start up order.


----------



## Deleted member 30996 (Aug 13, 2021)

In my Kali home directory I have an .Xauthority, Xdefaults, .xsession-errors, .zshrc, .zshhistory, .ICEauthority (blank), .dmrc (desktop lightdm-xsession), .bashrc, .bash_logout, .bashrc_original and no sign of an .xinitrc or anything like it. I don't pay much attention to how long it takes to start, it's been up 28 days.

geezer, everyone who is famous has fame, but not everyone who has fame has infamy
When you're famous for your infamy, you're notorious.

When you pour a married woman a glass of Ocean Spray Mango Juice in Church during lunch break, go back upstairs when the Service begins again, are looking down with your eyes closed, look to your left and she's standing right beside you in the pew, her husband is on the other side of her trying to pull her back to where she'd been sitting by her hand and she is resisting, then they turn the Sermon to focus on Stealing a mans wife and you realize they're talking about you...

You're me.


----------



## Minbari (Aug 13, 2021)

Vull said:


> It's just a port. I like the init system we already have. No need for systemd or its spawn to ever invade our base system here.


I like the existing init too, yet he has its limits. Just because something exist for a long time doesn't means is good now or in the future. I think we should be more open to new ideas and changes or we will end just like Solaris & Co.
Benno Rice has a good view about systemd and why we (FreeBSD) should have a systemd like init.


----------



## Deleted member 30996 (Aug 13, 2021)

Please tell me what's wrong with the current ~/.xinitrc / `startx` paradigm. 

It's been working fine for me and I prefer it to a GUI.

What have I to gain from the change? 
(Change Bad) (Survival Good)


----------



## hardworkingnewbie (Aug 13, 2021)

Initware is LGPL, the BSDs are BSD licensed.  So no chance ever it will replace one of the BSD's default init systems.


----------



## hardworkingnewbie (Aug 13, 2021)

mark_j said:


> What got my attention was the subject *InitWare (systemd fork) Runs on OpenBSD for First Time.*
> 
> A quick look at the github site gives no reasoning behind this. Further investigation yields another example here. There's probably more out there.


Well when having a closer look then it becomes quite clear that InitWare really is an init system replacement. Probably the author thought it might be a good idea to port systemd minus some parts over to the BSDs, because then many Linux docs can be used without much change for the BSDs as well, so he did.

I mean, what were always the main selling points of systemd? Parallel startup of processes and service monitoring. The problem is what it does aside that, its creeping featurism. Also quite often usurping formerly independent projects, which have an impact for X11 and such, like elogind.

Looking at this nifty init system feature comparison table BSD's rc.d already has support for parallel startup of services, and can keep daemons alive as well. So what's the rationale then behind porting systemd is way beyond me.

Many would always argue then: bootup time is not so important as the people always tell. Truth that for both targets there are different solutions in place, which can do the same but with less luggage: OpenRC and runit. And if you think that service monitoring should not be done by the init system, there are dedicated tools for that like monit.

Complexd on the other hand is a different thing, it is a reimplementation of some systemd APIs, which might be needed by some DEs to get out the full functionality. GNOME especially had a long time a really nasty dependency on systemd stuff, meaning you could not use it properly without it.


----------



## Menelkir (Aug 13, 2021)

Minbari said:


> I like the existing init too, yet he has its limits. Just because something exist for a long time doesn't means is good now or in the future. I think we should be more open to new ideas and changes or we will end just like Solaris & Co.
> Benno Rice has a good view about systemd and why we (FreeBSD) should have a systemd like init.


Just because something is new doesn't means it should be changed for the sake of changing. Systemd doesn't bring something new, it just make things depend on it and try to incorporate everything inside it. There's not a single thing that systemd do that isn't possible with other less cumbersome init systems can do (openrc, runit, 66, s6, rc, you name it). And as hardworkingnewbie already stated, what is the main selling point of systemd? I think I can answer that: EEE.
Good that you pointed the video of Benno Rice, because he said to get what you like from systemd and try to port it yourself. My answer is: I don't need it, everything I like in systemd exists by at least 20 years as a standalone application.


----------



## mark_j (Aug 13, 2021)

Minbari said:


> I like the existing init too, yet he has its limits. Just because something exist for a long time doesn't means is good now or in the future. I think we should be more open to new ideas and changes or we will end just like Solaris & Co.
> Benno Rice has a good view about systemd and why we (FreeBSD) should have a systemd like init.


I watched that a while back and if you follow the talk through he eventually gets to the faults of systemD: the scope creep as it attempts to solve the problems its solutions have created. Just ponder that for a moment, because systemD does that.

It seems every month a new scope-creep 'feature' is offered up by the redhat boys. In that regard alone, imagine trying to port such an ever expanding piece of software written explictly to be NON-portable? Good work for a masochist.

Systemd is a solution in search of a problem; it may have some rationale to linux-based people but to freebsd it makes no sense. I mean apart from saying you have ported some of it to FreeBSD what problem does it solve?

I think you're wrong when you say we should be more open to ideas, thus implying a close-minded attitude. If your argument was with linux then you'd have a case because of their inherent NIH syndrome. However, FreeBSD has adopted linux emulation, ext file handling, dtrace, zfs, openbsm to name but a few. All of these can be said to enhance the OS or the user experience. I'm still looking for such from systemD.

But you are correct; FreeBSD can't afford to be an island; however it also can't berth the Titanic (aka systemD)


----------



## mark_j (Aug 13, 2021)

Menelkir said:


> Just because something is new doesn't means it should be changed for the sake of changing. Systemd doesn't bring something new, it just make things depend on it and try to incorporate everything inside it. There's not a single thing that systemd do that isn't possible with other less cumbersome init systems can do (openrc, runit, 66, s6, rc, you name it). And as hardworkingnewbie already stated, what is the main selling point of systemd? I think I can answer that: EEE.
> Good that you pointed the video of Benno Rice, because he said to get what you like from systemd and try to port it yourself. My answer is: I don't need it, everything I like in systemd exists by at least 20 years as a standalone application.


Your email/quote from Poettering was very illuminating because that's what I've suspected all along (clearly I'm a genius ). This is why it makes sense for linux-based systems. There's a kernel developed totally separate from userland functionality. The only guiding light is Torvald's directive that nothing breaks userland. They are basically attempting to copy HP/UX, Solaris and BSD: systems designed as one.

However the severe synic and skeptic in me sees the darker side where all these distributions eventually are doomed by the ever-growing reach of systemD; they will all become the same (if that isn't already the case now?) They are in fact killing themselves off by adopting systemD. Soon there will be only one and it will be forever known as...Redhat.


----------



## Vull (Aug 13, 2021)

Minbari said:


> I like the existing init too, yet he has its limits. Just because something exist for a long time doesn't means is good now or in the future. I think we should be more open to new ideas and changes or we will end just like Solaris & Co.
> Benno Rice has a good view about systemd and why we (FreeBSD) should have a systemd like init.


Thanks for the Benno Rice link. Rice says systemd is like launchd except for the point that, whereas launchd is Apple-specific, systemd is Linux-specific. The FreeBSD init system is generic enough that any Un*x-like system can use it.

Being open to change and new ideas is a good thing, but breaking interoperability standards is not. In this case, and admittedly, without knowing all the minute granular details, I tend to view these types of interoperability barriers as anti-competitive practices. Whether this is being done deliberately or coincidentally is debatable, and in some situations, can even be prosecutable, to wit:






						Embrace, extend, and extinguish - Wikipedia
					






					en.wikipedia.org


----------



## sidetone (Aug 13, 2021)

mark_j said:


> However the severe synic and skeptic in me sees the darker side where all these distributions eventually are doomed by the ever-growing reach of systemD; they will all become the same (if that isn't already the case now?) They are in fact killing themselves off by adopting systemD. Soon there will be only one and it will be forever known as...Redhat.


Could the theoretical outcome of SystemD be anything like Vanishing on 7th Street?








						Vanishing on 7th Street (2010) - IMDb
					

Vanishing on 7th Street: Directed by Brad Anderson. With Hayden Christensen, John Leguizamo, Thandiwe Newton, Jacob Latimore. The population of Detroit has almost completely disappeared, but a few remain. As daylight disappears they realize that the Dark is coming for them.




					www.imdb.com


----------



## mark_j (Aug 13, 2021)

Vull said:


> Thanks for the Benno Rice link. Rice says systemd is like launchd except for the point that, whereas launchd is Apple-specific, systemd is Linux-specific. The FreeBSD init system is generic enough that any Un*x-like system can use it.
> 
> Being open to change and new ideas is a good thing, but breaking interoperability standards is not. In this case, and admittedly, without knowing all the minute granular details, I tend to view these types of interoperability barriers as anti-competitive practices. Whether this is being done deliberately or coincidentally is debatable, and in some situations, can even be prosecutable, to wit:
> 
> ...


If you read the link Menelkir posted, https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html, the embrace, extend, extinguish concept/philosophy is precisely what the end-goal of ibm redhat's systemd is.
You're spot on!


----------



## mark_j (Aug 13, 2021)

sidetone said:


> Could the theoretical outcome of SystemD be anything like Vanishing on 7th Street?
> 
> 
> 
> ...


If by that you mean:
"The population of Detroit [linux distributions] has almost completely disappeared, but a few remain [Redhat, ubuntu/debian]. As daylight disappears they realize that the Dark[systemD] is coming for them."? Then , yes you're movie selection is apt! 

Off-topic in an off-topic: is the movie any good?


----------



## mer (Aug 13, 2021)

mark_j said:


> I watched that a while back and if you follow the talk through he eventually gets to the faults of systemD: the scope creep as it attempts to solve the problems its solutions have created. Just ponder that for a moment, because systemD does that.


"Hi I'm from the government and I'm here to help you with the problems that the government created.  The only way I can do that is if the government gets more involved in everything".


----------



## sidetone (Aug 13, 2021)

mark_j said:


> If by that you mean:
> "The population of Detroit [linux distributions] has almost completely disappeared, but a few remain [Redhat, ubuntu/debian].


Like, "The [variety of open source is disappearing], but a few [non Redhat, non Ubuntu/Debian users and environments] remain."


mark_j said:


> As daylight disappears they realize that the Dark[systemD] is coming for them."? Then , yes you're movie selection is apt!


Comparing SystemD to a spreading void taking over what it touches.


mark_j said:


> Off-topic in an off-topic: is the movie any good?


The paranormal aspect of it is somewhat of a stretch compared to somewhat realistic in theory sci-fi's. The acting, sequences and scenery are decent. It's good if you're a fan of Leguizamo, or if this is your kind of sci-fi. It's accurate with the trailer, with a little less suspense.



mer said:


> "Hi I'm from [insert bank name here] and I'm here to help you with the problems that [we] created. The only way I can do that is if [we get] more involved in everything"


Sounds more like a bank commercial to me.


----------



## Vull (Aug 13, 2021)

mark_j said:


> If you read the link Menelkir posted, https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html, the embrace, extend, extinguish concept/philosophy is precisely what the end-goal of ibm redhat's systemd is.
> You're spot on!


Totally inspired to link the Wikipedia article by Menelkir's post, as further clarification and support for it. 

Rice also says in his diatribe that systemd uses some unique system features provided by Linux, which are not available to other Un*xes, and that right there is EEE in a nutshell, even if Rice himself doesn't recognize or acknowledge it as such in his speech. I can't speak to other people's intentions, or read their minds, but, even if launchd and systemd aren't intended as direct attacks against interoperability standards and principles, they do at least show a total disregard for them.

As a programmer in the late 90s and early naughts, I saw Microsoft do this repeatedly with HTML, Internet Explorer, and Java "extensions," drawing a little more blood every time, both directly, from the targets they "embraced" (notably Sun Microsystems), and indirectly, from contemporaneous software developers, like my employers and myself, who just happened to get caught in the bleeding of broken standards and ever-changing software requirements.
I pulled myself and employers away from RedHat at the moment when RedHat "Enterprise" split away from Fedora, and none of us ever regretted it.


----------



## a6h (Aug 13, 2021)

I think it was around 2004, when OpenBSD removed the net/ethereal (now Wireshark) from its Ports Tree. The net/wireshark exists in the OpenBSD ports tree now, but back then, the net/ethereal was a pile crap (*).

The point is that first, I think it's unlikely InitWare ends-up in the OpenBSD base. Second, although I'm not familiar with InitWare -- as I'm not with the systemd either; but if it turns out the InitWare is an abomination, then it may meet the same fate as the Ethereal, i.e. not so-ethereal!

(*) Reference:
1. cvsweb.openbsd.org:
CVS log for ports/net/ethereal/Attic/Makefile

2. wireshark.org/lists:
Ethereal-dev: Re: [Ethereal-dev] Harsh criticism from the OpenBSD folks


----------



## Brian546 (Aug 13, 2021)

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.


----------



## kpedersen (Aug 13, 2021)

Brian546 said:


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


Heh now there is an interesting idea. An open-source OS specifically targeted to the CLI. Specifically avoiding any GUI stuff.

Whether for desktop or server, a non-graphical OS would certainly shed a lot of complexity. I kinda like it.


----------



## Menelkir (Aug 13, 2021)

Brian546 said:


> 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.
> ...


Or just keep xorg (since xorg doesn't need this kind of crap to work out of the box) and remove everything that depends of those kind of things. Also, there's xenocara.


----------



## ct85711 (Aug 14, 2021)

InitWare is fighting an uphill battle, effectively chasing systemd's tail.  The issue is that systemd does not keep a stable api and intentionally makes breaking changes between versions, to make it harder to make shims for it.


----------



## sidetone (Aug 14, 2021)

Ports that are independent of graphics or the desktop are actually efficient, and they are as BSD as they can be. It needs to stay that way.

Lots of applications written for BSD are made with Bash and Linuxisms in mind, even when there are good BSD alternatives.

It's when desktop and desktop applications are added, that [more] Linuxisms creep in. There isn't a fancy alternative to gtk, except qt5.

I always want a BSD style graphical desktop. A few Linuxisms are fine, if they would be trimmed and supplemented on BSD programs, and except when there are BSD ways of doing it. When there's a capable alternative for function, corresponding Linuxisms should go. Anything that still wants upstream Linuxisms when there are enough compatibility layers should be improved or go.


OpenBSD messed up for not rejecting SystemD fork InitWare.

[Edit: moved statement, because not all applications that want Linuxisms like Bash are associated with graphics or the graphical desktop.]


----------



## kpedersen (Aug 14, 2021)

sidetone said:


> OpenBSD messed up for not rejecting SystemD fork InitWare.


To be fair, it isn't doing any harm in their ports collection. There is probably zero chance it will ever end up in base (basically for all the same reasons why systemd is a bad solution).


----------



## mark_j (Aug 15, 2021)

Trihexagonal said:


> That's one of the things I addressed at DW this morning. I explained that just because it makes it into the ports tree doesn't mean it's going to make it


Ok, I'll bite, what's DW? I'm assuming it's not Deutsche Welle TV?


----------



## mark_j (Aug 15, 2021)

sidetone said:


> Ports that are independent of graphics or the desktop are actually efficient, and they are as BSD as they can be. It needs to stay that way.
> 
> It's when desktop and desktop applications are added, that Linuxisms creep in. There isn't a fancy alternative to gtk, except qt5. Lots of applications written for BSD are made with Bash and Linuxisms in mind, even when there are good BSD alternatives.


I mean it's not absolute, but this statement is so true. Once the GUI is introduced, all bets are off.
I totally agree.


----------



## Beastie7 (Aug 15, 2021)

100 bucks says systemdur will try to swallow up GDM-wayland, or kwin-wayland, siloing all else out.

I’m calling it now.


----------



## Menelkir (Aug 15, 2021)

Beastie7 said:


> 100 bucks says systemdur will try to swallow up GDM-wayland, or kwin-wayland, siloing all else out.
> 
> I’m calling it now.


Well, wayland is pretty much developed with that in mind, so I think it's a matter of time. As far as I know, KDE people are more resistant about being systemd-only-development-model, meanwhile gnome...


----------



## sidetone (Aug 15, 2021)

Beastie7 said:


> 100 bucks says systemdur will try to swallow up GDM-wayland, or kwin-wayland, siloing all else out.
> 
> I’m calling it now.


That's obvious. It seems like it's their goal to be dominant by tying itself to nearly everything. Their goal also isn't being a better initialization system, even if they proclaim it is.



mark_j said:


> Once the GUI is introduced, all bets are off.
> I totally agree.


I didn't say this part. A few cli applications ask for Linuxisms as well. There's more of this once the desktop gets involved. I had to move a sentence to another place from where u quoted me, because that made me notice it.

I don't believe all bets are off, when it comes to the graphical desktop. It's worth pursuing, trying, or installing it as it currently is, because it's still important to lots of people.

My point is that tui applications are efficient and close to being ideal, while gui applications require a lot of cleaning up to lower the amount of additional GPL bloat, and upstream preferences for Linuxisms.

tui ports are already satisfactory as almost completely ideal. tui ports and the base are a solid foundation for graphical ports to those who desire that.

Most tui ports don't call on gui ports as dependencies. So for those who don't use a desktop, their version (in terms of what they use) of FreeBSD is already near perfect.


----------



## sidetone (Aug 15, 2021)

How about an open-source portability standard that becomes mainstream. If it requires Bash, SystemD or another Linuxism where a suitable alternative exists with the exception of GUI toolkits, it's not worth having. That it will be portable not only to BSD's will make it more formidable.

It would be an extension of Posix's function, and be modular and compatible with Posix. It would offer compatibilty when it comes to dependencies that won't require an absolute like a Potteringware.

For reference a lot of good programs aren't Posix compliant. This includes a lot of Rust programs which function under their own seeming standards.


----------



## hardworkingnewbie (Aug 15, 2021)

Menelkir said:


> Well, wayland is pretty much developed with that in mind, so I think is a matter of time. As far I know, KDE people are more resistant about being systemd-only-development-model, meanwhile gnome...


Well this number of GNOME devlopers is on Red Hat's pay roll:
GNOME developers​

Matthias Clasen - GTK, lead maintainer
Owen Taylor - GTK developer
Dan Williams - NetworkManager lead maintainer
David Zeuthen  - DeviceKit/HAL, PolicyKit lead maintainer
John Palmeri - D-Bus, lead maintainer
Ray Strode - GDM developer
Colin Walters - D-Bus developer
Richard Hughes - gnome-power-manager, PackageKit lead maintainer
Bastian Nocera - Totem, lead maintainer
Dan Winship - core GNOME developer
William Jon McCann - GDM. ConsoleKit developer
Jonathan Blandford - early GNOME developer
Debarshi Ray - GNOME Online Accounts
Dodji Seketeli - Nemiver Debugger, lead maintainer
Quite some important people there. KDE developers they got none aside Fedora package managers.


----------



## sidetone (Aug 15, 2021)

hardworkingnewbie
SystemD is a presence that tries to consume everything. With your post, I feel like there's some of this presence in ports. Perhaps not as much direct presence, as influence of the belief on the importance of excessive Gnome dependencies, which are just bloat.

Before, when I would clean up and improve an audio port related to Gnome, or Pottering, they would go right back in and reintroduce bloat.

I interpret a lot of voices as, "leave it alone, I want it to work with Gnome's way. I'm scared a Gnome non-feature will break, if sets of dependencies are fixed."


One day I'll fork ports, and it won't have Gnome, ALSA, PulseAudio or Avahi. It will have Bash and gtk, but they will be trimmed. It either won't have libcanberra, or it will be trimmed to the bare minimum. Those common voices either don't want it to be fixed, or they're scared because they don't understand it, or perhaps there's a combination of both. As of now, there's too much discouragement, and reluctance. Fork it, and this SystemD, Gnome, Redhat, Potteringware creep goes away, and they won't be able to voice, "but, but but, I absolutely need the latest Gnome/Potteringware bloat!" on it.


----------



## Deleted member 30996 (Aug 15, 2021)

mark_j said:


> Ok, I'll bite, what's DW? I'm assuming it's not Deutsche Welle TV?


DistroWatch


----------



## sidetone (Aug 15, 2021)

Brian546 said:


> 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.





kpedersen said:


> Heh now there is an interesting idea. An open-source OS specifically targeted to the CLI. Specifically avoiding any GUI stuff.
> 
> Whether for desktop or server, a non-graphical OS would certainly shed a lot of complexity. I kinda like it.





mark_j said:


> Once the GUI is introduced, all bets are off.


At first I thought, this only benefits those who don't want a desktop or gui. Then, it can actually be done in a way to make everything better, including the gui.

If there's a ports fork that is only for non-x11, or console/cli ports, this can be used across all BSD's plus Minix regardless of graphics capabilities. It would have a preference for BSD for default dependencies. A lot of attention can go into this, to make it the vanguard. It would include ImageMagick-nox11, CUPS, BSD Zeroconf implementations, sndio, portaudio, text games. It would be for both x32 and x64 architectures as well, and have packages. If a port isn't architecture specific, then let there be one package of it, only having additional packages for the architecture specific one.

Then there would be a separate fork for X11, graphical programs and GUI's specific to FreeBSD on x64 architecture which uses the nox11 ports tree fork for dependencies. When the names from each ports tree overlap, one will be suffixed with x11 or nox11. For a full graphical program that also has a nox11 flavor, let it use the nox11 version as the dependency.

It's perfect: it reduces maintenance tasks, improves quality, and it improves everything.

I would use packages from the nox11 portstree/pkg-repository fork, because they would be standardized in some of the best ways, and be treated like binaries from FreeBSD base, then I would continue with either using ports or binaries from the extended ports for graphics.


----------



## grahamperrin@ (Aug 15, 2021)

InitWare - Portable systemd(1) fork for BSDs : freebsd


----------



## mer (Aug 15, 2021)

Vull said:


> As a programmer in the late 90s and early naughts, I saw Microsoft do this repeatedly with HTML, Internet Explorer, and Java "extensions," drawing a little more blood every time, both directly, from the targets they "embraced" (notably Sun Microsystems), and indirectly, from contemporaneous software developers, like my employers and myself, who just happened to get caught in the bleeding of broken standards and ever-changing software requirements.


"But it's a standard" until MS/Oracle get their hands on it.


----------



## Jose (Aug 15, 2021)

mark_j said:


> I also wonder, once they mature,  if anyone would even use them?


Doubtful. This has been tried already. It failed.








						NextBSD - Wikipedia
					






					en.wikipedia.org


----------



## hardworkingnewbie (Sep 7, 2021)

A talk called "The Tragedy of Systemd" held at the Linux Conf Australia by Benno Rice, who is a FreeBSD developer/committer as well as core team member. 





_View: https://www.youtube.com/watch?v=o_AIw9bGogo_


----------



## mark_j (Sep 7, 2021)

He was. I think he's now working on systemd..


----------



## ralphbsz (Sep 7, 2021)

Actually, he sadly is NOT working on SystemD. After he left the "FreeBSD universe" (Isilon, iXSystems, also core team), he spent a few years working on Cloud-related stuff for a security company. Then the pandemic put the kibosh on that, and then he was looking for things to work on (ideally with a paycheck). Last I heard, he's found a job. It's interesting to hear his opinions on FreeBSD's init system progress, or lack thereof.


----------



## jbo (Sep 7, 2021)

From the repo's readme.md:


> A complex of daemons implementing various systemd APIs commonly required by desktop environments. Written in Rust, targeting FreeBSD.


To me it's rather interesting that they chose Rust for this.
Don't get me wrong, I don't want to bash Rust at all. I'm just surprised and intrigued. When thinking of writing "OS level" software specifically and only targeting FreeBSD, Rust is not the language that comes to mind - but I can certainly see the advantages of this decision too! 

Now then... back to watching the "time elapsed" counter on my poudriere instance building lang/rust...


----------



## cynwulf (Sep 7, 2021)

InitWare is forging the same path as all other systemd compatibility layer / shim projects - endorsing systemd and kneeling in front of Poettering and paying homage to his abomination...

Poettering's quoted mailing list posting is rather typical, he has made many such postings over the years regarding manipulating users and devs into adoption.

You see this "culture" right through Red Hat, certain Linux kernel devs, gnome project, Debian and Ubuntu people, Arch Linux, etc where there is this supreme arrogance and widening gulf between developers (many of whom are on the IBM/Red Hat payroll) and Linux users who are viewed in much the same way as a Microsoft Windows customer.


----------



## mark_j (Sep 8, 2021)

jbodenmann said:


> From the repo's readme.md:
> 
> To me it's rather interesting that they chose Rust for this.
> Don't get me wrong, I don't want to bash Rust at all. I'm just surprised and intrigued. When thinking of writing "OS level" software specifically and only targeting FreeBSD, Rust is not the language that comes to mind - but I can certainly see the advantages of this decision too!
> ...


Yes, strange indeed. Yet another build system and another language to include in base if this ever made it that far; which it won't of course.

But I'm not dissing rust either, as per Benno Rice's talk video where he references: blog.aurynn.com/2015/12/16-contempt-culture


----------



## mark_j (Sep 8, 2021)

ralphbsz said:


> Actually, he sadly is NOT working on SystemD. After he left the "FreeBSD universe" (Isilon, iXSystems, also core team), he spent a few years working on Cloud-related stuff for a security company. Then the pandemic put the kibosh on that, and then he was looking for things to work on (ideally with a paycheck). Last I heard, he's found a job. It's interesting to hear his opinions on FreeBSD's init system progress, or lack thereof.


It was sarcasm as he seems to be the FreeBSD poster child for wanting that crap.
I'm just glad he's no longer on FreeBSD (core or otherwise).


----------



## ct85711 (Sep 8, 2021)

If systemd wasn't so monolithic in how to pulled in various parts and hard code directly call parts of the various services; it wouldn't be so bad on porting systemd.  The part of being monolithic on single binary is completely off, in that there are several other packages that uses multiple executable files which isn't being blamed for being monolithic.  Like towards the end of the video, if they provided a specific api that everything has to use; it would solve a lot of the issues.  From what I've heard from all the various shims on systemd, is that it is a constant up hill battle; as systemd is acting hostile in that they will add breaking changes on new versions so you can't split parts off/make is shim for it.


----------



## mark_j (Sep 8, 2021)

The problem is, this is a Linux to userland issue. It always has been.

FreeBSD and indeed all BSDs solved this decades ago when they produced a kernel and a base and released them together. Linux, on the other hand, is a kernel which is pretty useless by itself. Enter all the various distros to make an O/S with their individual views on inits, services, userland libraries etc etc, and you can see the need for some single API or utilities.

Systemd is an attempt to unify, in a crude and somewhat evil way, the Linux to userland interface.


----------



## zirias@ (Sep 8, 2021)

I'm really glad the definition what FreeBSD _is_ isn't decided by some of the zealots in this thread. 

It's a general-purpose OS, and yes, this includes the ability to work as a "desktop". A good CLI is a great thing, suitable for many tasks, but there are also many things you might want to do with a computer that require a GUI to make any sense. If FreeBSD couldn't be used as a desktop, I'd have to run something else (and, for example, fight with crap like systemd as a result…). Well, no, thanks.

Now, ports are just a "distribution" of (mostly) open-source software. You have to take what you get. If many GUI-related projects drift more and more into the hell of linuxisms, sure, that's a problem, and there are several possibilities to do something about it:

Nag upstream about portability
Do a lot of patching in the port
Start alternative projects with the software design you have in mind (well, I guess lumina is/was an attempt into that direction)
It really doesn't make sense to give up the field and more or less accept the fact that OSS GUI stuff is equivalent to "Linux".


----------



## jbo (Sep 8, 2021)

Zirias I couldn't agree more.

I think the essence of the _"Tradgedy of Systemd" _talk by _Benno Rice_ is summarizing this situation pretty well.
Systemd might not be the solution for FreeBSD (although I am not qualified to judge this) but we (as in the FreeBSD community) should certainly take it serious and properly analyze it in an objective manner. There are certainly things (i.e. concepts) in there which would greatly benefit FreeBSD too. Sure, the implementation might not be suitable for FreeBSD but that doesn't mean that we should just bash it and plainly ignore the benefits such a system layer would introduce.


----------



## Deleted member 30996 (Sep 8, 2021)

cynwulf said:


> he has made many such postings over the years regarding manipulating users and devs into adoption.


Oh, you mean he has some admirable characteristics? Manipulation is an art form. I've got SystemD running on the Kali box beside this FreeBSD box. As long as it doesn't slip out when I'm not sitting here and invade my freeBSD box, I'm good with it.

Don't take ~/.xinitrc from me too...


----------



## eternal_noob (Sep 8, 2021)

Trihexagonal said:


> As long as it doesn't slip out when I'm not sitting here and invade my freeBSD box, I'm good with it.


You never know. And if it does, it's a "feature", not a bug.


----------



## zirias@ (Sep 8, 2021)

jbodenmann said:


> Systemd might not be the solution for FreeBSD (although I am not qualified to judge this) but we (as in the FreeBSD community) should certainly take it serious and properly analyze it in an objective manner. There are certainly things (i.e. concepts) in there which would greatly benefit FreeBSD too. Sure, the implementation might not be suitable for FreeBSD but that doesn't mean that we should just bash it and plainly ignore the benefits such a system layer would introduce.


Well…

It's never wrong to think about ways to improve your system and design, that's for sure 

But, regarding the init system? I'm not convinced… As already mentioned in this thread, the main "selling points" of systemd (at least with the scope "init system") are service supervision and startup performance.

About service supervision, first thing that comes to mind is: you can do that outside init. Sure, for a reliable production system, you want monitoring, you want to notify an admin when a daemon dies. Whether you want to automatically respawn it, it depends… I think more often than not, that's a bad idea. After all, there is normally a _reason_ a service dies, and it can easily happen that automatically respawning it just creates more havoc. But anyways, I don't see any reason why _init_ should do that. Just use a separate tool and let it start and manage exactly those services you _want_ supervised.

As for startup performance: Sure, you can never have the best possible performance with shell scripts. But without them, you sacrifice a _lot_ of flexibility, so, is it really worthwhile? You have to take into account that BSD's init with its mewburn-rc never was the mess sysv-init was. It supports dependency-based ordering and parallel startups, and it keeps init scripts very simple using a sophisticated framework. It's definitely ok to think about possibly better alternatives, but I don't see a pressing need.

And then, anything else systemd does, I _guess_ most people agree it's out of scope of an init system anyways…


----------



## hardworkingnewbie (Sep 8, 2021)

Just to give you a non-complete list of stuff which systemd does aside starting and supervising services: 

* own NTP client 
* own DNS resolver
* system logging in binary format 
* cron 
* automount 
* inet 
* unified configuration for many system aspects like time settings, hostname, network interfaces
* own console driver 
* D-bus integration 
* login tracking 
* Docker support 
* Device event managing daemon 
* system-homed: encrypted, portable home folders within a container file

It's basically the Emacs of init systems. Poettering himself does view his brainchild not as init system, but instead basic building block for the operating system, where the distribution creator though can turn on or off quite much stuff.


----------



## jbo (Sep 8, 2021)

Thank you for the overview. There are a few things in there I didn't know/expect to be handled by systemd.

I do suspect that it would take comparably minimal effort to have interfaces for stuff like _"own NTP client" _and _"own DNS resolver"_ to use existing infrastructure? Same for _"inet"_ (no idea why systemd would want to handle that but I guess somebody has a reason for that - easier desktop settings utilities maybe?).
I'd be curious to know the technical reasons for _"own console driver"_. The underlying OS would already provide the necessary infrastructure in a usable manner by the time systemd gets invoked/started/becomes-relevant?

Again: Not taking any position here. Just trying to understand and keeping the discussion objective/constructive


----------



## hardworkingnewbie (Sep 8, 2021)

The issue is when writing about "own client" it exactly means that - these clients are based on new code written for systemd. The official reason why was often that "normal stuff does not what we do need it to do at that point during boot time good/fast enough" mostly. Since these were new code bases they had some pretty juicy bugs in the beginning mature code bases don't have. And aside it really leads sometimes to annoying side effects. Quite often the implementation was also not complete or immature. For example systemd just might grab port 53 UDP, even if systemd-resolvd was not running "just in case."

The console driver is another area. The one in the Linux kernel - systemd does only care about Linux - is ancient, dated and has its own set of annoyances/problems to some. Some were of the opinion such a thing should be implemented mostly in user space anyway. So in 2014 systemd developers just started working on such a project, because they felt the need for a better console driver than what was being available in the Linux kernel.

Nowadays it's being called kmscon, and this is its description: *kmscon* is a system console for linux. It does not depend on any graphics-server on your system (like _X.org_), but instead provides a raw console layer that can be used independently. It can replace the linux kernel console entirely but was designed to work well side-by-side, too. Even though initially targeted at providing internationalization to the system-console, it has grown into a fully modularized console layer including features like multi-head support, internationalized font rendering, XKB-compatible keyboard handling, hardware-accelerated graphics access and more.

Here's the git commit in which it was introduced within systemd: https://cgit.freedesktop.org/systemd/systemd/commit/?id=b62a309a47dd11e11729616767421397b6ca7053

It first was introduced into systemd, then ripped out and renamed, and since then it's been rotting away.


----------



## Beastie7 (Sep 8, 2021)

hardworkingnewbie said:


> Just to give you a non-complete list of stuff which systemd does aside starting and supervising services:
> 
> * own NTP client
> * own DNS resolver
> ...



Holy…


----------



## jbo (Sep 8, 2021)

I know right? It feels like it's almost an entire OS. Wouldn't be surprised if it would come with its own dynamic memory management too!


----------



## a6h (Sep 8, 2021)

hardworkingnewbie said:


> Just to give you a non-complete list of stuff which systemd does aside starting and supervising services:
> * own NTP client
> ...


The list itself is the problem.
Why is "test" aka "/bin/[" external? To keep shell generic, and the rest of the system flexible. Do you need some new avant-garde "test"? Write a new one.
That's how I understand the UNIX psyche.


----------



## mer (Sep 8, 2021)

system logging in binary format has always been the killer for me.
System won't boot?  Oh, do you know the magic command to actually see what failed?  No?  Sucks to be you.


----------



## Menelkir (Sep 8, 2021)

mer said:


> system logging in binary format has always been the killer for me.
> System won't boot?  Oh, do you know the magic command to actually see what failed?  No?  Sucks to be you.


Can be worse, I had scenarios that the _systemd logging system _corrupts the filesystem with their changas, so the filesystem was able to heal itself (in my experience, btrfs, ext4 and xfs was able to heal without any problem) so of course you want to use the journalctl to see whats happening and guess what, you can't, because the entire log was corrupted in the process. So the only solution was to remove the entire journal chimichanga and reboot. Oh, and you'll also want to flush because eh.. they put some chimichangas in /run that should be flushed into /var/log, because reasons.
Said that, I had similar issues with freebsd and syslog-ng on linux, and situations like that just corrupt one single line in the log files, which is fine.


----------



## hardworkingnewbie (Sep 8, 2021)

In case you want to know even more stuff Systemd can do, here's a handy list over at Suckless.

Also always interesting to read this blog post features on Freebsd.org on the press releases from 2017 by Synergy Sky, named: "Why we did build our solution on top of FreeBSD?" So in a year where Systemd has already been around for quite a while, and also in their Linux distribution of choice CentOS.

Money quote: "One major issue we experienced was that Systemd managed to crash the whole dbus-systemd connection if our software took too much memory, leaving the system in unstable state, with reboot as only option (I don’t think we can blame CentOS directly for that, however pulling in such premature technology into a proclaimed stable platform, makes no sense at all!!). We had some other minor issues as well which is probably weeded out in the latest versions of CentOS (and not worth mentioning)."

Theodore T'so, creator of ext2/3/4 file systems had also problems to tinker it in a way he wanted it to behave. It was a really interesting read back then, sadly lost with the begone Google+.

And Bruce Perens, who was within Debian, was of this opinion in 2014:
"Here's another issue brought to a head by systemd. There's a conflict for anyone with a job like being on the TC for an obvious reason: Systemd achieves some powerful and important goals for Linux systems. And at the same time Systemd doesn't play well with others (especially other init systems) and is badly in need of being broken up into separate projects.

Debian was able to allow individual developers to make decisions _because it's modular_. Systemd isn't modular enough to fit the Debian paradigm, at least at present. And the way it's been pushed upon the entire community is deplorable.

It's time to put on the brakes. We need to break systemd up into separate projects, resolve the issues that cause the largest objections to it, and make sure it plays with others (again, including other init systems). Oh, and pushing back on the team that pushed it upon us is unfortunately necessary.

Until those issues are handled, Debian (and other sensible distributions) should not be based upon systemd."

And it gives you fun stuff like this now and then, crashing a whole machine by sending a specially designed dbus message to it: https://seclists.org/oss-sec/2019/q1/140

And even Linus Torvalds dislikes the systemd developer's attitude, because systemd uses some kernel stuff in a way it was not meant to be, e.g. dmesg buffter. So people are filing bugs against the kernel, not systemsd. When then the kernel developers filed these bugs against systemd, they were pretty much and fast closed. 

Interesing mail from 2017 on same patch: "
So I see many different approaches (that could be combined: I like
combining (a) and (c), for example), and absolutely none of them
involve the random "take some values from init".

And yes, a large part of this may be that I no longer feel like I can
trust "init" to do the sane thing. You all presumably know why."

Which basically is him saying that the he thinks that the most popular init thingie on his kernel sucks. And he's gruntled about when he's got to change his kernel do to the inability/unwillingness of the systemd developers to correct their mistakes.


----------



## ralphbsz (Sep 8, 2021)

jbodenmann said:


> I know right? It feels like it's almost an entire OS. Wouldn't be surprised if it would come with its own dynamic memory management too!


I really like how Benno drew a diagram of a modern OS.

In the old days of Unix, there was "kernel" and "user", and nothing else. Remember, Unix was not designed as a production operating system, but as a research tool: It allowed the Bell Labs OS research group (and later the Berkeley CSRG, where the acronym stands for Computer Systems Research Group). This is after many other OSes had more than two different kinds of code (the VAX famously has an extra ring for the shell). The job of the kernel was well defined, and includes virtualizing the hardware (provide isolation), resource management, and providing common services (like networking or file systems).

But in reality, there has always been another component, which Benno calls "system". For example, it decides which file systems gets mounted, how networks are set up and connected, and hardware attached and detached. It allows new connections to be established, for example CLI users logging in. These are all functions that have traditionally been done by init and its children (like inetd and getty). When the initial Unix versions were written (50 years ago), this area was mostly ignored and treated as an afterthought. In those early days, hardware configuration was done by editing kernel source and config files and recompiling ... I have added serial ports to machines in this way to allow more login from terminals. But this part of the overall problem has gotten much more complex than it was 50 years ago. Hardware comes and goes dynamically, configuration like networks and storage have to follow that fast movement, and the number of daemon processes that have to be managed has increased by orders of magnitude.

To me, this means that this whole area needs to be re-thought, architected, and implemented. In commercial systems, this has long happened. SystemD is one such project for the open source / free world. We can complain about some details of it. The biggest single problem with SystemD is that Lennart is an a**h*** (you can figure out what the stars in that word mean). Note that I didn't say that he doesn't understand systems research and architecture, or is a bad software engineer.

At this point, FreeBSD is already dead: it's market share has reached the point of being irrelevant, a lot of necessary development work is falling behind further and further. It has become a good base to create embedded systems (Netflix, Juniper, NetApp, Isilon), and as an alternative for hobbyists. I'm seeing more and more of that hobbyist use being driven by near-religious beliefs and paranoia, not by rational engineering tradeoffs. In the discussions here and other places, I see the biggest driver of FreeBSD adoption being irrational things like "I hate Linux" or "I hate Lennart" or "I'm old and don't like change". Obviously, people don't say these things out loud, but hide them behind lofty statements like "Unix philosophy".

If FreeBSD fails to re-build its init system simply because of "being allergic to innovation" or lack of manpower, it will become even more irrelevant. Which is sad, but it may be inevitable.


----------



## jbo (Sep 8, 2021)

I fully get your point (and I hope most others of this community do too!).

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.
I won't even bother talking about things such as personal attitude of a project maintainer or anything like that. I am not involved enough to judge any of this and frankly I also don't want to be.

Personally I would like to see more efforts to design/suggest/provide/implement solutions to some of the problems rather than just bitching about it and missing out on a lot of good capabilities. As Benno put it: We don't have to use systemd if we don't want to - but we need something similar/equivalent pretty soon.

Of course, I can be very wrong with all of this.


----------



## Jose (Sep 8, 2021)

ralphbsz said:


> ..and as an alternative for hobbyists.


You say that like it's a bad thing.


ralphbsz said:


> I'm seeing more and more of that hobbyist use being driven by near-religious beliefs and paranoia, not by rational engineering tradeoffs.


_Ad hominen_ much?


ralphbsz said:


> In the discussions here and other places, I see the biggest driver of FreeBSD adoption being irrational things like "I hate Linux" or "I hate Lennart" or "I'm old and don't like change". Obviously, people don't say these things out loud, but hide them behind lofty statements like "Unix philosophy".


You manage to pack 3-4 fallacies in those two short sentences. See items 3, 5, 11, and maybe 9 here:








						Systemd: The Biggest Fallacies by Jude C. Nelson
					

We are reproducing here a very good article we found on without-systemd.org which is on the dreaded blogspot.  It took allowing three different sites to flash scripts so the simple text html docume…




					sysdfree.wordpress.com
				





ralphbsz said:


> If FreeBSD fails to re-build its init system simply because of "being allergic to innovation" or lack of manpower, it will become even more irrelevant. Which is sad, but it may be inevitable.


And I say embrace the long tail! The Internet has made it possible to be small and yet remain relevant. This is a Good Thing.


----------



## hardworkingnewbie (Sep 8, 2021)

ralphbsz said:


> At this point, FreeBSD is already dead: it's market share has reached the point of being irrelevant, a lot of necessary development work is falling behind further and further.


Yeah, I've been hearing that for at least two decades now. Still waiting for it to come true in my life time!


----------



## fel1x (Sep 8, 2021)

What a great news! I remember when I first tried FreeBSD, there was no systemd, and it was so surprising. However, now I'm familiar with rc. Maybe I will try it if it comes out.


----------



## mer (Sep 8, 2021)

So FreeBSD is a real life example of Monty Python "I'm not quite dead yet!  I'm feeling better!  I think I'd like to go for a walk!"

Relevant.  What is relevant?  What is not?  
Does financial/commercial support connotate relevancy?
Does User Base?
Does "most blingiest window manager ever"?

Based on those 3 Windows is the only thing relevant today.

Systemd:  the "emacs of init systems" is the best analogy I've seen.  But sometimes emacs is what you want.
My main issue with Systemd is "It's like Sendmail".  One big huge monolithic bit of software that is doing a bazillion things.  
From a pure security aspect, < insert your favorite puking emoji here > because it's too big to properly vet.
Why does it need to be NTP client?  "Because NTP doesn't start fast enough"  Really?  Then you have your ordering wrong or you are not properly waiting for NTP ready state.  It's the old "thundering herd" vs "orderly bring up".  Thundering herd can work but everything needs to properly wait for it's dependencies.  It usually winds up "hurry up and wait".  Orderly can be slower but more repeatable and testable.

Security should be one of the primary concerns for anyone writing software today.  If you can't draw the boxes and arrows and explain the interrelationships on one sheet of A4 paper, you need to decompose further.

My opinions, agree, disagree, all the same to me.


----------



## fel1x (Sep 8, 2021)

I quite agree. FreeBSD became an alternative of linux for companies who don't want to reveal their source code. Even raspberry pi 4 is not fully supported(wifi, sound) and I quite agree that the proportion of community engagement of FreeBSD is obviously lower than Linux. I think it should increase the number of individual users who can discuss on the community and it will help increasing users if essential programs such as Gnome, firefox, KDE etc offcially support FreeBSD.

The reason that more people use Linux is 
a. FreeBSD is not proper for newbies who just started unix-like os. They will likely use user-friendly and automated os like ubuntu. When I first tried unix-like, I chose Ubuntu because its installer was much friendly for newbies. It looks similar to Windows which is the first os for most people. 
b. Lack of software. Even Linux has poor software support than Windows. (Even though there is Wine, it's not perfect, and most people prefer native Windows.) Individual users(I mean who just surf the internet, playing games, watching youtube) wants a number of games, browsers, and other programs. But in FreeBSD the supported browser amongst Firefox, Edge, Chrome is only Firefox, and games that runs on Linux sometimes do not work on FreeBSD. Vulkan does not support FreeBSD(Wikipedia), and it is very sad thing for gamers like me.

Yet, the only cheerful news is that the market share of FreeBSD has risen recently according to Distrowatch. (but it is not that credible)

Summary: It is true that FreeBSD is dying, but there is still hope to increase the users.


----------



## fel1x (Sep 8, 2021)

ralphbsz said:


> "I'm old and don't like change"


not always. FreeBSD adopted ZFS as the first filesystem in 13. I quite agree that it does not change much, but it can be important for users who want high compatibility. See what happened to macOS. They adopt metal and threw away opengl just in one update, and that bothered developers very much.


----------



## kpedersen (Sep 8, 2021)

ralphbsz said:


> If FreeBSD fails to re-build its init system simply because of "being allergic to innovation" or lack of manpower, it will become even more irrelevant. Which is sad, but it may be inevitable.


I would honestly rather be running an irrelevant operating system than one that is unusable.

I am certainly not saying that Linux is *unusable* but it is certainly getting further and further away from what I came to UNIX-like for in the first place.

Plus oddly enough for things that are "old" or "obsolete" or "inefficient" on FreeBSD, I can't really see a market for the effort required to seriously do a good job on and improve. Because... well, why don't they just use Linux?

*[Unsubstantiated musing ahead]*
I almost fear that one day these "improvements" to FreeBSD will entirely come from rejects that couldn't hack it in the Linux world or make a celebrity name for themselves, so they come to FreeBSD instead where it is less crowded with less competition and try to needlessly change it whilst pushing their agenda making a worse Linux than Linux (but with *their* name on it).



fel1x said:


> Yet, the only cheerful news is that the market share of FreeBSD has risen recently according to Distrowatch. (but it is not that credible)


I honestly feel FreeBSD is getting more popular. Though I believe it is not because FreeBSD has gotten particularly better, it is just that Linux has gotten worse. Systemd is probably the best thing that has happened to FreeBSD's user-count.

Its a race to the bottom guys! Soon we will be begging for MS-DOS!


----------



## hardworkingnewbie (Sep 8, 2021)

The thing is FreeBSD is in much stuff you don't see as such. It runs e.g. Netflix and Whatsapp, also quite a lot of the top 500 web sites when looking over at netcraft.com. Furthermore many NAS solutions.

And on top of it's driving the Nintendo Switch, Sony Playstation 4 and 5 (if this info is correct).


----------



## Tieks (Sep 8, 2021)

ralphbsz said:


> "I'm old and don't like change"


That could be me. But how many companies like change? To companies, an OS is merely a tool. If it comes to their tools, they may be better served with evolution than revolution.


----------



## mer (Sep 8, 2021)

fel1x said:


> FreeBSD adopted ZFS as the first filesystem in 13


What do you mean "first filesystem"?  ZFS has been in FreeBSD since at least FreeBSD-9.  FreeBSD-13 switched to OpenZFS-2.0 (ZoL).  Before that is was basically "CDDL release from Solaris plus updates"


----------



## fel1x (Sep 8, 2021)

mer said:


> What do you mean "first filesystem"?  ZFS has been in FreeBSD since at least FreeBSD-9.  FreeBSD-13 switched to OpenZFS-2.0 (ZoL).  Before that is was basically "CDDL release from Solaris plus updates"


Sorry. I meant that the first filesystem on the list when we install freebsd. In FreeBSD 12, the UFS was on the top, but in 13, ZFS is on the top.


----------



## fel1x (Sep 8, 2021)

Moreover, due to FreeBSD licence, things that came from FreeBSD(Netflix, playstation, Nintendo switch etc) do not always help FreeBSD. They sometimes contribute to FreeBSD source, but compared to Linux, the situation that big comapanies such as Red hat and SUSE apply their code to linux does not much happen in FreeBSD.


----------



## dd_ff_bb (Sep 8, 2021)

ralphbsz said:


> At this point, FreeBSD is already dead: it's market share has reached the point of being irrelevant,



No, Its not



ralphbsz said:


> If FreeBSD fails to re-build its init system simply because of



Systemd is not a init system, its a almost complete new OS



ralphbsz said:


> the biggest single problem with SystemD is that Lennart is an a**h***



No, its not.

Biggest single problem; Systemd is almost another OS on top of Linux based OS which means it doesn't matter if you were using a Linux distribution for the last 10-20 years because now you have to learn how to use Systemd OS.

You want to change your resolv.conf nope you can not, you have to do it through systemd and add some packages to do that.
Change hostname? nope you have to ask systemd to do it for you etc.....

Meaning whatever you think you knew about your OS is not working as you might expect. You simply CAN NOT do that. You can not make batshit crazy changes to 30 years old operating system (same applies for programming languages)

I was using Red Hat Linux 6.2 (not red hat enterprise) but today if i sit in front of a Red Hat Enterprise Linux i cant do anything except cat and grep.

Does Systemd OS has advantages? possibly but i want to run FreeBSD OS not Systemd OS.

And let me tell you this Systemd would not stop until it completely infects Linux and takes over its host(its almost done). So bringing Systemd into "how ideal init system should be" argument is non sense.


----------



## mark_j (Sep 8, 2021)

fel1x said:


> I quite agree. FreeBSD became an alternative of linux for companies who don't want to reveal their source code. Even raspberry pi 4 is not fully



That's because raspberry pi foundation chose to use a linux-based os. Why? Because linux kernel had a lot of the drivers for the hardware they wanted, broadcom was already using linux and the developers of the Pi were familiar with linux.
Henceforth, it has always been a struggle for other OS to work with it.
I've read of developers of the Pi saying it's no big deal, just read the Linux code and there's the driver information. Well sure, but they forget about the licencing system which prevents this. 
So, your argument is not with FreeBSD it's with the raspberry pi developers.



fel1x said:


> The reason that more people use Linux is
> a. FreeBSD is not proper for newbies who just started unix-like os. They will likely use user-friendly and automated os like ubuntu. When I first tried unix-like, I chose Ubuntu because its installer was much friendly for newbies. It looks similar to Windows which is the first os for most people.



This is quite true, as I see it also. I rank skill and knowledge of computing (in general terms) required to use an operating system as such.
1. Apple OS.
2. Microsoft OS.
3. Linux
4. FreeBSD
5. Solaris, other esoteric OS.

Of course, it's only based on those 5 and because they can be used by home users. 1 is easy, 5 is harder.


fel1x said:


> b. Lack of software. Even Linux has poor software support than Windows. (Even though there is Wine, it's not perfect, and most people prefer native Windows.) Individual users(I mean who just surf the internet, playing games, watching youtube) wants a number of games, browsers, and other programs. But in FreeBSD the supported browser amongst Firefox, Edge, Chrome is only Firefox, and games that runs on Linux sometimes do not work on FreeBSD. Vulkan does not support FreeBSD(Wikipedia), and it is very sad thing for gamers like me.


This is just a general statement, not particularly aimed at you, but you do raise a good point.

I do not understand this constant push for FreeBSD to have everything gnu/linux has. It seems to me, if you need those things, why not run linux?
Ok, sure, you might prefer FreeBSD, and yes, it might be great if those things ran on FreeBSD, but they don't. Sometimes you have to lower your expectations. If you can't live with that, then change to another OS (hopefully without systemD ).

Surely everyone only needs X11, a lightweight WM, xterm, xeyes and ctrl-alt-backspace?  Ok, I admit, xneko is probably mandatory as well.



fel1x said:


> Yet, the only cheerful news is that the market share of FreeBSD has risen recently according to Distrowatch. (but it is not that credible)
> 
> Summary: It is true that FreeBSD is dying, but there is still hope to increase the users.



FreeBSD is dying? Seriously? FreeBSD will die when developers stop wanting to develop for it. What their motivation is, I do not know, but I would guess it isn't user-base expansion. An OS like NetBSD has flourished with a minuscule amount of money, developers and users; look at all the code pulled in from NetBSD (drivers, init system etc).

More users would help potentially bring more money to the project and this would be a good thing.


----------



## mark_j (Sep 8, 2021)

jbodenmann said:


> Zirias I couldn't agree more.
> 
> I think the essence of the _"Tradgedy of Systemd" _talk by _Benno Rice_ is summarizing this situation pretty well.
> Systemd might not be the solution for FreeBSD (although I am not qualified to judge this) but we (as in the FreeBSD community) should certainly take it serious and properly analyze it in an objective manner. There are certainly things (i.e. concepts) in there which would greatly benefit FreeBSD too. Sure, the implementation might not be suitable for FreeBSD but that doesn't mean that we should just bash it and plainly ignore the benefits such a system layer would introduce.


You are correct, of course. That's why people are developing this initware software.

That's what is good about FreeBSD, you have choice. You can change your init system from rc. It's not trivial but it's fairly easy to do.
SystemD, on the other hand, is attempting to make it OBLIGATORY to use it on linux-based OS.

Not only that, as Rice says, the incessant scope creep of systemd is inevitable.
The developers find some process that does not conform to their latest set of changes and so they need to re-write a perfectly good utility. See hardworkingnewbie's post for a not-so-exhaustive list (who forgot systemD handles coredumps as well ).

SystemD might have started at  linux with its foot in the door via init, but it's now inside trying to sell you carpet cleaner for your wooden floor and you can't get it to leave. Calling the cops won't help, they own the cops.


----------



## Menelkir (Sep 9, 2021)

ralphbsz said:


> At this point, FreeBSD is already dead


Glad you said that so I can use this website:

https://isbsddeadyet.com/


----------



## ayleid96 (Sep 9, 2021)

I would not worry about it, systemd will never happen in BSD world. BSD doesn't have any need for it.

EDIT:
Reminder that systemd has over 1.2 million lines of code, BSD world could develop something with drastically less code to suit its use.


----------



## ayleid96 (Sep 9, 2021)

kpedersen said:


> ...
> I honestly feel FreeBSD is getting more popular. Though I believe it is not because FreeBSD has gotten particularly better, it is just that Linux has gotten worse. Systemd is probably the best thing that has happened to FreeBSD's user-count.
> 
> Its a race to the bottom guys! Soon we will be begging for MS-DOS!


That is the case really. I started using FreeBSD because of mess that linux became.

EDIT:
Luke Smith from youtube started to experiment with OpenBSD after a video about how linux is getting worse for average computer user. Its interesting stuff, check it out.


----------



## Beastie7 (Sep 9, 2021)

ayleid96 said:


> EDIT:
> Reminder that systemd has over 1.2 million lines of code, BSD world could develop something with drastically less code to suit its use.



That's actually bigger than ZFS itself. I can only imagine how bad the stench of that code base is. Jesus.


----------



## a6h (Sep 9, 2021)

About two years ago, a random fella came to the OpenBSD mailing-list and proposed the stupid idea of replacing Perl with Lua in the OpenBSD base.
He got mocked and told go fork your OpenLuaBSD.

In some projects -- OpenBSD for example, there is always someone to shut trends down.
In the FreeBSD, it's the Core job to CRUD new features.

New ideas and trends come and go, and some will stay. Consequently, they will divide a project in two fractions:
One group is cheering, the other keep whining, and that's normal. If you think it's not normal, then you are abnormal.

Some examples: ZFS, Forth/Lua, CVS/SVN/Git, X/Wayland, init/systemd, GitHub, c∅c, etc.

If you believe FreeBSD is heading in the wrong direction -- due to bad judgment, being under peer-pressure; or some fellas have difficult time to say "NO", ... 
then you have to change the Core. There is no other way around. We can whine forever, but this is how you can do it:

1. Roll up your sleeves, buy some time by not watching Netflix.
2. Use the extra time to report bugs, port new programs, ... be active in the mailing lists.
3. Aim at getting Commit bits.
4. Build a circle of like-minded Beasties, of course with Commit bits.
5. Vote them into the Core, in a biennial basis.
6. By taking control of the Core => if something works, Keep it in stasis.


----------



## sidetone (Sep 9, 2021)

vigole said:


> About two years ago, a random fella came to the OpenBSD mailing-list and proposed the stupid idea of replacing Perl with Lua in the OpenBSD base.
> He got mocked and told go fork your OpenLuaBSD.


It's not a bad idea, but it forces everything to change, and makes it something else. That something else would also be good. It would be a lot of work, just to change a language, whether it were forked or hypothetically adopted. It sounds like they're scared it might work well.

I would laugh if the person had the capability to fork it or fund that kind of project, and it turned out to be a success. It's unlikely that the person would actually do it, but the theory of undertaking it is possible. A mathematical scripting language makes a lot of sense in itself. I can't make sense of the syntax though, but I know barely enough to make use of very few scripting languages.

If such a thing happened, it would likely mostly come out of Brazil, maybe in large part from a university in that country. That's a country where Lua is popular, and Lua came out from a university from there.


----------



## Deleted member 30996 (Sep 9, 2021)

vigole said:


> We can whine forever, but this is how you can do it:


I've got a Kali box sitting next to this FreeBSD box. I like FreeBSD the way it is. 

If FreeBSD changes more than I like and want to run a SystemD box, I already know how to do it and have a USB stick readymade to get on it.


----------



## a6h (Sep 9, 2021)

sidetone said:


> I would laugh if the person had the capability to fork it or fund that kind of project, and it turned out to be a success. It's unlikely that the person would actually do it


A diff-less proposal is not a proposal.


----------



## Vull (Sep 9, 2021)

FreeBSD may not be for everyone. If you just want an easy-to-use desktop, you might be better off using Debian, or even Linux Mint, or even some other non-Debian derivative. Many of my friends are only happy with Windows or MacOS. To each their own. Some crazy people like me might be more interested in server software. Some slightly more sane people might even be interested in deploying server software in order to make a living, or for other such mundane purposes.

But that's not me anymore. I'm retired now. In my dotage, operating systems are just a hobby to me (just a hobby! Ya hear?) where I sometimes occupy my addled brain by maintaining some old web application software of my own warped design, and keeping it up to date.

FreeBSD is my top choice for web server deployment because it significantly outperforms the few Debian-derived Linux systems against which I've tested it. This chart compares times for my two favorite testing benchmarks, an interactive, browser-based, encrypted SQL backup program, and it's counterpart decrypting restore program. These time tests were run on one of my multi-boot systems, where I can compare how these systems run, using the exact same hardware, and using the exact same encrypted SQL backup file, to restore and prepare matching databases using commonplace FOSS on both the server side (PHP, PostgreSQL, and Apache) and the client side (Firefox, ECMAScript, and XMLHttpRequest) to implement both the backup and restore interactively.


----------



## jbo (Sep 9, 2021)

ayleid96 said:


> I would not worry about it, systemd will never happen in BSD world. BSD doesn't have any need for it.


I think in here lies the core of the problem? (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. This will result in less software being usable/runnable under (Free)BSD which can eventually reduce the user base. BSD might not need it, but it needs an active community, which means it needs users, which means users need to be able to use somewhat modern tools (both hard- & software!) - one way or another.
Again: I am not advocating here.



mark_j said:


> See _*[FONT=monospace]hardworkingnewbie[/FONT]*_'s post for a not-so-exhaustive list (who forgot systemD handles coredumps as well ).


How does that even work on a technical level??


----------



## mer (Sep 9, 2021)

jbodenmann said:


> I think in here lies the core of the problem? (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.


That right there is the problem, at least to me.
Let's just look at the list way back in post 61.
NTP Client, DNS resolver, system logging, cron, automount, inet:  an application can get those without systemd.
Own console driver:  why in the world would an application need to depend on this from systemd?
Unified configuration for many system aspects....:  Seems like every single Desktop environment Settings or Preferences menu item.  If one must have "one place to go for configuration", that's an application on top of existing utilities like date, host, ifconfig.
D-bus integration:  If dbus is present why do messages need to go through systemd or does this mean "systemd responds to dbus messages"?
login tracking:  that already happens without systemd.
Docker support:  meaning what?  systemd can start docker containers if docker is installed?
Device Event Managing Daemon:  gee the OS layers of device drivers and devfs/devd/devmatch already do this, so now systemd has to manage them too?  This is a concrete example of "systemd is an OS".
system-homed:  an application should never be depending on a users "home folder" format.

I've never anything provided by systemd that an application should be depending on coming from systemd.  It's a lazy approach to programming, it's pushing security and best practices into a chunk of software too big to actually understand and vet.


----------



## fel1x (Sep 9, 2021)

In my opinion, the Linux distro that mostly resembles FreeBSD is arch linux(no gui, port, administrator should manage the system manually, less automated parts than other distros) According to Distrowatch, the number of users of FreeBSD is 2/3 of Arch Linux. It is astonishing and we can say FreeBSD is doing its best now even though it cannot run linux binaries(there is linuxulator, but there are problems with some programs like Chrome). 

The documentation and active community are the advantages for newbies. (I've never seen a Linux distro that documentation is more detailed than FreeBSD.) However, most people think that FreeBSD is kind of old because its UI does not look like Windows(which they primarily use). Linux distros that are recommended for beginners have GUI from the installation process, whereas in FreeBSD, you should install gnome and xorg, modify xorg, add some line to rc.conf.

Any distro that a person used first is likely to use forever. (example: my first linux distro is Fedora, and that is my primary distro until now) Changing distro may not be a good thing for most people because they have to move their data for installation and should be get used to the new one. 

I think, at least, if FreeBSD releases a disk image with GUI on their website, there will be a significant increase for both hardcore uses and newbies.


----------



## jbo (Sep 9, 2021)

mer said:


> That right there is the problem, at least to me.
> [...]
> I've never anything provided by systemd that an application should be depending on coming from systemd. It's a lazy approach to programming, it's pushing security and best practices into a chunk of software too big to actually understand and vet.


Certainly! I fully agree! I didn't mean to say that it's a good thing that 3rd-party software relies on this.



fel1x said:


> In my opinion, the Linux distro that mostly resembles FreeBSD is arch linux(no gui, port, administrator should manage the system manually, less automated parts than other distros) According to Distrowatch, the number of users of FreeBSD is 2/3 of Arch Linux. It is astonishing and we can say FreeBSD is doing its best now even though it cannot run linux binaries(there is linuxulator, but there are problems with some programs like Chrome).


Arch Linux was my main distro before I switched to FreeBSD. I guess I'm not alone there 
Not that this matters (in this discussion or at all), but I did never really became buddies with `pacman`.



fel1x said:


> I think, at least, if FreeBSD releases a disk image with GUI on their website, there will be a significant increase for both hardcore uses and newbies.


There are ongoing efforts: https://www.freebsd.org/status/report-2021-04-2021-06/#_experimental_installer
Sure, one might now complain about this being a web interface... but one might also complain about pretty much anything else if so desired.


----------



## a6h (Sep 9, 2021)

fel1x said:


> According to Distrowatch,


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


fel1x said:


> I think, at least, if FreeBSD releases a disk image with GUI on their website


There's no need. Just follow the instructions at Building A FreeBSD Desktop From Scratch by Trihexagonal


----------



## fel1x (Sep 9, 2021)

vigole said:


> 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.


----------



## jbo (Sep 9, 2021)

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)
> ...


----------



## a6h (Sep 9, 2021)

fel1x said:


> When I first tried FreeBSD, it took 2 weeks to install GUI


I was worse. But good! That process is good. It's called learning.


----------



## mer (Sep 9, 2021)

jbodenmann said:


> 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.


----------



## jbo (Sep 9, 2021)

vigole said:


> 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)
> ...


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.


----------



## hardworkingnewbie (Sep 9, 2021)

jbodenmann said:


> 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.


----------



## mer (Sep 9, 2021)

"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.



hardworkingnewbie said:


> 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.


----------



## Menelkir (Sep 9, 2021)

fel1x said:


> 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.


----------



## a6h (Sep 9, 2021)

jbodenmann said:


> And I think this is where an important part of (Free)BSD comes in:
> .
> .
> .


I've partially quoted your comment, but the entire comment is very well articulated.

P.S. When I installed FreeBSD for the first time, I hadn't had MODEM. I had one, but it was a fake-MODEM, aka WinMODEM. Now you can imagine!
Necessity is the mother of RTFM.


----------



## l2f (Sep 9, 2021)

Please keep away the SystemD or any fork/imitation from FreeBSD: Unix Way Only.


----------



## l2f (Sep 9, 2021)

Brian546 said:


> 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.
> ...


And they did not realized that BSD is too easy to use, trust me I experience it everyday at my job...


----------



## Jose (Sep 9, 2021)

jbodenmann said:


> (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?



mer said:


> "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.


----------



## ralphbsz (Sep 9, 2021)

Jose said:


> 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!


----------



## eternal_noob (Sep 9, 2021)

Lennart is also the author of audio/pulseaudio and net/avahi-zeroconf. So if you use them, you are doomed also.


----------



## hardworkingnewbie (Sep 9, 2021)

eternal_noob said:


> 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.


----------



## kpedersen (Sep 9, 2021)

hardworkingnewbie said:


> 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.


----------



## hardworkingnewbie (Sep 9, 2021)

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.


----------



## mer (Sep 9, 2021)

hardworkingnewbie said:


> 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.


This is a huge "Why would you do that" for me.


----------



## Unixnut (Sep 9, 2021)

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.


----------



## hardworkingnewbie (Sep 9, 2021)

Unixnut said:


> 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.


----------



## Unixnut (Sep 9, 2021)

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")


----------



## sidetone (Sep 9, 2021)

Jose said:


> 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.




eternal_noob said:


> 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.


----------



## hardworkingnewbie (Sep 9, 2021)

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.


----------



## Unixnut (Sep 9, 2021)

hardworkingnewbie said:


> 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.


----------



## mer (Sep 9, 2021)

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)


----------



## hardworkingnewbie (Sep 9, 2021)

Well the Linux kernel guys usually dislike kernel drivers which are not GPL licensed, OpenZFS is CDDL. CDDL is compatible with FreeBSD, but not GPL. Many believe that this was done back then on purpose by Sun, because the Solaris release 10 which introduced ZFS in 2006 also had some other groundbreaking innovations like Dtrace in it, and Solaris back then was open source. What Sun didn't want to see is ZFS and Dtrace popping up in Linux instantly, therefore the CDDL. Dtrace was re-licensed under the GPLv2 in 2019 by Oracle, so some still do hope this might happen with ZFS soon as well.

Their Linux kernel developers mantra is: yes user, you can do that, but then don't pester us with bug reports. Your kernel is tainted.

Also this means that they don't really care about providing the interfaces which ZFS might need, or not. In their eyes it's an external thing, and that's all about it. So the developers have always to play the catchup game when a new Linux kernel version comes out.


----------



## Beastie7 (Sep 9, 2021)

Even if those innovations were permissively licensed, they would still manage to find a way to fsck things up with a bunch of layer violations. The community has an unhealthy habit of reinventing the wheel poorly also. Btrfs, systemd, pulseaudio, systemtap, epoll, etc. are all examples of that. Meanwhile, ZFS and DTrace became first class citizens on FreeBSD.. with no wasted effort no reinventing crap.


----------



## fel1x (Sep 9, 2021)

I advocate porting systemd to FreeBSD but won't use it. There are still people who prefer systemd, and this port will promote influx of those kind of users. It should not be applied to the base system, but there is no drawbacks in just porting them.


----------



## eternal_noob (Sep 9, 2021)

fel1x said:


> but there is no drawbacks in just porting them.


If you pull in *systemd*[1] into FreeBSD, you would have to deal with one of the worst maintainers ever existed.



> And finally, the *lamest vendor response* award went to Systemd supremo Lennart Poettering for his controversial, and perhaps questionable, handling of the following bugs in everyone's favorite init replacement: 5998, 6225, 6214, 5144, and 6237 that we covered here.








						Systemd wins top gong for 'lamest vendor' in Pwnie security awards
					

Epic fails and l33t pops celebrated by hackers




					www.theregister.com
				




Let alone the technical issues, i find it much more important that the person behind the software is reliable, which is not the case here.

[1] https://www.freedesktop.org/wiki/Software/systemd/


> Yes, it is written *systemd*, not *system D* or *System D*, or even *SystemD*. And it isn't *system d* either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case *d*. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) *System Five Hundred* since *D* is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with *systemd*. On high holidays you may also spell it _sÿstëmd_. But then again, _Système D_ is not an acceptable spelling and something completely different (though kinda fitting).


----------



## hardworkingnewbie (Sep 9, 2021)

eternal_noob said:


> If you pull in *systemd*[1] into FreeBSD, you would have to deal with one of the worst maintainers ever existed.


I am pretty sure the FreeBSD developers would reject systemd alone due to its LGPL license.

Aside that making it runnable on FreeBSD would require heavily work, it would be really more of a fork rewriting large stuff in it. And therefore require a dedicated FreeBSD maintainer, who is not Poettering, who is able to deal with Poettering and willing to play the eternal catchup game then with him.


----------



## kpedersen (Sep 9, 2021)

fel1x said:


> I advocate porting systemd to FreeBSD but won't use it. There are still people who prefer systemd, and this port will promote influx of those kind of users.


Would FreeBSD really benefit from having those kinds of users?

A user that will only use FreeBSD because it resembles Linux somewhat is likely to be more effort than they are worth.


----------



## Deleted member 30996 (Sep 9, 2021)

cynwulf said:


> Poettering's quoted mailing list posting is rather typical, he has made many such postings over the years regarding manipulating users and devs into adoption.


Let's call manipulation Social Engineering from now on. Social Engineering is a cool buzzword for the same thing, as described on Page 1 of "The Art of Deception: Controlling the Human Element in Security" by Kevin Mitnick. He's a hero to some people, I have his book in pdf format.


cynwulf said:


> You see this "culture" right through Red Hat, certain Linux kernel devs, gnome project, Debian and Ubuntu people, Arch Linux, etc where there is this supreme arrogance and widening gulf between developers (many of whom are on the IBM/Red Hat payroll) and Linux users who are viewed in much the same way as a Microsoft Windows customer.


I saw the same thing happen to PC-BSD when X-systems came into the picture. Their own arrogance was what I used against them, called PC-BSD the Win98 of the UNIX World, left and never let them live it down.

Which, once again cynwulf, brings us back to the culture of GroupThink. Which uses manipulation in their tactics of out-grouping. But their cause is just so getting down and dirty is justified. Yeah, that's the ticket, and an example of how the mind can use rationalization as a means of self-defense.



ralphbsz said:


> The biggest single problem with SystemD is that Lennart is an a**h*** (you can figure out what the stars in that word mean). Note that I didn't say that he doesn't understand systems research and architecture, or is a bad software engineer.


No, when you couldn't refute his credentials you sunk to a personal attack on his character. It's a standard tactic. One you're above, disparage the use of and tells me something you can't see.



ralphbsz said:


> It has become a good base to create embedded systems (Netflix, Juniper, NetApp, Isilon), and as an alternative for hobbyists.


I'm considered to be a hobbyist but don't see the connection to Netflix, Juniper, NetApp or Isilon using FreeBSD. I don't use any of those services and don't even have a PS4.



ralphbsz said:


> I'm seeing more and more of that hobbyist use being driven by near-religious beliefs and paranoia, not by rational engineering tradeoffs. In the discussions here and other places, I see the biggest driver of FreeBSD adoption being irrational things like "I hate Linux" or "I hate Lennart" or "I'm old and don't like change".


You are the most knowledgeable person when it comes to UNIX I have ever met, have such a rich background in close association to the early days of UNIX development and are a wealth of knowledge in the area of your expertise I feel we are lucky to have in our midst.

But your area of expertise is not Psychology or Behaviorism, it's mine. A Professional in my field, qualified as such by experience, with 46 years experience my current level of expertise.

Within the space of one paragraph you raised yourself above the gutter in voicing your opinion of him as an a**h***  to lofty heights, casting aspersion on hobbyist driven by "near-religious beliefs and paranoia", not by "rational engineering" based argument. Statements such as "I hate Linux" or "I hate Lennart" or "I'm old and don't like change" being "irrational things".



ralphbsz said:


> Obviously, people don't say these things out loud, but hide them behind lofty statements like "Unix philosophy".



That you couldn't see it in yourself and were oblivious to exhibiting the same behavior you decry, as obvious to me as my ways might seem irrational to a hobbyist in my field.

You once said that if someone you considered to be of questionable character walked into the room while you were eating dinner you'd get up and walk out. Look within, Ralphbzs.


----------



## Jose (Sep 10, 2021)

kpedersen said:


> 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.


It shows his Linux-centric view of the world. Every OS is a kernel + GNUish userland. He didn't (and maybe still doesn't) know that the BSDs are more than a kernel.


----------



## mark_j (Sep 10, 2021)

eternal_noob said:


> [1] https://www.freedesktop.org/wiki/Software/systemd/
> 
> Yes, it is written *systemd*, not *system D* or *System D*, or even *SystemD*. And it isn't *system d* either. Why? Because it's a system daemon, and under *Unix/Linux* those are in lower case, and get suffixed with a lower case *d*. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!


Yes well Linux ain't unix, so it's wrong assuming we should use unix naming conventions for a mess like systemD.


----------



## eternal_noob (Sep 10, 2021)

I don't care how we call that mess, i just posted that quote from Poettering to emphasize what type of guy he is.


----------



## hardworkingnewbie (Sep 10, 2021)

Wear your love for it! (A design which Poettering featured on Twitter.) This bug report is just hilarious btw: https://github.com/systemd/systemd/issues/437


----------



## Deleted member 30996 (Sep 10, 2021)

vigole said:


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


Jessie, the owner of DistroWatch, caught people voting multiple times when he had the thread about whether or not to include or segregate Operating Systems that had a Religious or Political stance.


----------



## Deleted member 30996 (Sep 10, 2021)

fel1x said:


> People can follow the guide, but do beginners prefer modifying manually than having GUI in installation?


It's not the installation process that gives people who use my tiutorial or new people in general the most problems, and I've watched closely since mine went up,

It's tinkering around tweaking this file and that before they have the knowledge gained through experience to fix the problems that can and do arise from that practice. Then they become needlessly frustrated, and it can't be their fault (it worked this way on Linux),  so they blame FreeBSD and trudge back to Tux Town, tail dragging, 8oz wings flapping.

I've said many times "If it's not broken don't fix it." But nobody listens.


----------



## mer (Sep 10, 2021)

Trihexagonal your second paragraph is key to me.  We were all newbies once, I remember when one had to really know your monitor and card specs to get it all working.

Is it easier if a single tool could properly detect all the hardware and install everything the user wants?  Easier, yes.  Better?  Not to me because then I am constrained by what the tool-creator thinks is "Best".
A good script or tutorial that gets someone 85-90% "there" is more useful in the long run.  Regardless of the OS, a user may need to get out of their comfort zone to fix things (Windows, bad update, regedit are my personal examples);  if the needed tweaking can be minimized and "how to do it" is clearly documented (even to the point of absurdity), with maybe clearly "go to here and ask for help", then maybe the frustration turns into a learning experience.


----------



## Deleted member 30996 (Sep 10, 2021)

mer said:


> f the needed tweaking can be minimized and "how to do it" is clearly documented (even to the point of absurdity), with maybe clearly "go to here and ask for help", then maybe the frustration turns into a learning experience.


I broke it down into exculpating detail for people who were just like me when I was a noob using PC-BSD in 2005 so hopefully they wouldn't have to struggle as much as I did teaching myself. I still hadn't built a desktop from scratch tilI got here and used a tutorial written by someone else to do it.

I'd already taught myself to use ports but was still using their product to get to the desktop. If I'd have continued to hang out there and let them do the hard work for me, I wouldn't be the person I am today. Or what's left that make up the person I am today.


----------



## mer (Sep 10, 2021)

Teach a man to fish, give a man a fish, complain that the fish isn't caviar.

circling back to SyStEmDee, some of the links that someone posted with Potterings quotes/myths, I went and read.  The funniest was "systemd is not monolithic because it has 67 separate binaries".
So, ok, technically, he has a point, but if "all 67 binaries are used to usurp major parts of the OS and only work with and for each other" isn't that monolithic in practical terms?


----------



## Vull (Sep 10, 2021)

I can't speak to all of what motivates the FreeBSD core team, nor do I make a study of it, however,_* not*_ having such things as a pre-configured desktop environment with extensive prepackaged graphics capabilities, in the kernel and elsewhere, makes base system FreeBSD very compact, and the ideal choice for headless servers and embedded systems which have *no* eye-candy or graphics requirements.

Furthermore, it does so in such a way as to not inhibit other end-users who might wish to add such things after the initial install. I tend to label this as *flexibility*. Anyone is free to configure FreeBSD in whichever way one chooses.

Anyone who wants a desktop installer is free to write one of their own, and FreeBSD provides everything one might need in order to do so.

If one *also* wants automatic graphics hardware detection and configuration, it might turn out to be a pretty rough ride, and require a lot of frequent, ongoing maintenance and OEM-specific customization, since hardware manufacturers are many in number, and continually adding new graphics processors, each with its own increasingly complicated set of OEM-specific requirements.

Adding such capabilities and overhead for graphics hardware requirements, which are constantly changing, and most of which will go unused in any single specific hardware system, might very reasonably be characterized as unnecessary, inefficient, and inelegant *bloatware*.


----------



## Deleted member 30996 (Sep 10, 2021)

Vull said:


> however,_* not*_ having such things as a pre-configured desktop environment with extensive prepackaged graphics capabilities, in the kernel and elsewhere, makes base system FreeBSD very compact, and the ideal choice for headless servers and embedded systems which have *no* eye-candy or graphics requirements.
> 
> Furthermore, it does so in such a way as to not inhibit other end-users who might wish to add such things after the initial install. I tend to label this as *flexibility*.


That's the way we like it and the people who actually use FreeBSD want it to stay.



Vull said:


> Anyone is free to configure FreeBSD in whichever way one chooses.


And no two desktops look the same. You don't have to like mine and yours doesn't have to look like mine.

Unlike a wallpaper show/screenshot thread of Linux desktops that all look the same except for the wallpaper.

I'm working on making FreeBSD more a viable option to the Linux community, and for some BSD as a stated alternative to SysD.

The New World Order Top Secret Illuminati issued code name for the new OS once it assimilates SysV and World Domination put in place as Priestly peyote prophesy preordained previously in the past, probably. 
Resistance is futile.


----------



## Deleted member 30996 (Sep 21, 2021)

I saw this related article in this weeks DistroWatch News. On my Kali box with SystemD running, which I'm using now while ports compile on two other FreeBSD machina:

"People who are interested in porting software between open source platforms such as Linux and the members of the BSD family just gained a new tool: a cgroup filesystem for the BSDs."





__





						DistroWatch.com: Put the fun back into computing. Use Linux, BSD.
					

News and feature lists of Linux and BSD distributions.




					distrowatch.com
				




It includes a quote from the InitWare/CGrpFS Github page:

"CGrpFS is a tiny implementation of the GNU/Linux CGroup filesystem for BSD platforms. It takes the form of a FUSE filesystem and implements robust tracking of processes. Resource control, however, is not present; the different BSD platforms each provide different mechanisms for this, none of which are easily adapted to CGroups semantics. The process tracking alone is sufficient for the main user of CGrpFS, InitWare, a service manager derived from systemd.


CGrpFS is available under the Modified BSD Licence. It is not as-yet very well tested, but seems to work fine for InitWare's purposes."









						GitHub - InitWare/CGrpFS: Tiny implementation of the GNU/Linux CGroupFS (sans resource controllers) as a PUFFS or FUSE filesystem for BSD platforms
					

Tiny implementation of the GNU/Linux CGroupFS (sans resource controllers) as a PUFFS or FUSE filesystem for BSD platforms - GitHub - InitWare/CGrpFS: Tiny implementation of the GNU/Linux CGroupFS (...




					github.com


----------



## Beastie7 (Sep 22, 2021)

Trihexagonal said:


> porting software between open source platforms



Or they just can just make their software portable.. (_or use the Linuxulator)_. I'm sure the committers wouldn't bother much with this.


----------



## zirias@ (Oct 9, 2021)

For those who think FreeBSD needs to change anything: You're wrong.

I just wrote my first init-script, for a software I wrote myself and need myself. I made it "comfortable", so it translates some rc.conf(5) variables into command line options automatically. The script looks like this: https://github.com/Zirias/zfbsd-ports/blob/local/net/remusock/files/remusock.in

So, apart from this one shell function providing the configuration comfort, it's all declarative and automated by the awesome mewburn rc framework, see rc.subr(8). Plus I need to set correct permissions on the directory where the pid file will be created – damn easy to do in a _shell script_.

I assume this _could_ be solved with systemd as well. Do you really want to know/learn how? I don't.


----------



## mrbeastie0x19 (Oct 9, 2021)

I don't know exactly _which_ problems it solves that are not addressed by other init systems. What I do know is since it was rolled out boot hangs and slow start-up times are very common, which could be forgiven if the rest of it were intuitive and stable while booted. Not so in my experience at all.

Also looking at the responses by the maintainer above about CVEs is very alarming, they do not appear to take security very seriously, which is not good when it is a huge monolithic daemon...


----------



## zirias@ (Oct 9, 2021)

mrbeastie0x19 said:


> I don't know exactly _which_ problems it solves


And that's the point.


----------



## eternal_noob (Oct 9, 2021)

mrbeastie0x19 said:


> I don't know exactly _which_ problems it solves


It solves Redhat's ambitions to take over Linux.


----------



## Jose (Oct 9, 2021)

Zirias said:


> Plus I need to set correct permissions on the directory where the pid file will be created – damn easy to do in a _shell script_.
> 
> I assume this _could_ be solved with systemd as well. Do you really want to know/learn how? I don't.


You are so not into modern programming. Systemd defines a whole language for creating pid files and setting the right permissions on them. You really should get with the times. It's make you so much more agile and functional.

Yes, that's sarcasm.


----------



## zirias@ (Oct 9, 2021)

Jose I guess what I want to say is: DON'T GET THE FUCK IN MY WAY with your STUPID DSL. Your DSL (talking to "systemd" here) is, well, "domain specific". That means anything the designer of that DSL didn't have in mind, WON'T WORK. (Let alone having to learn yet another language, which is a PITA in itself)

Yep, I assumed setting permissions on a dir, so a daemon can store its pidfile there, _is_ something that was considered. I'm pretty sure some other edge cases weren't. There are countless! 

Bourne shell, OTOH, is a general-purpose (turing-complete) programming language. Writing init-scripts in bourne shell has its challenges. But given an awesome framework like *mewburn rc* (which IIRC was developed for NetBSD, but is used in FreeBSD) makes it a piece of cake. Of course, assuming you know shell scripting. But hey, who doesn't?


----------



## Jose (Oct 9, 2021)

C'mon now, DSLs are the future! Why are you stuck in the past?


----------



## macondo (Oct 9, 2021)

bobo@foo:~ $ sudo pkg delete pulseaudio
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 3 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
    alsa-plugins: 1.2.2_1
    alsa-utils: 1.2.2
    pulseaudio: 14.2

Number of packages to be removed: 3

The operation will free 9 MiB.

Proceed with deinstalling packages? [y/N]: 


I'm an alsa user, whatever Pottering is selling I don't want it: pulseaudio, systemd, whatever...


----------



## zirias@ (Oct 9, 2021)

Jose said:


> C'mon now, DSLs are the future! Why are you stuck in the past?


I know this is more sarcasm , still I'll give a serious reply:

I'm not against DSLs in general. _If_ your domain is well-understood and complete, they make sense. I just doubt "system startup" is such a domain with clear-cut boundaries. IMHO, you _need_ a general-purpose language for that.

And again, a good framework can offer most of the advantages of a DSL, without imposing restrictions.


----------



## Jose (Oct 9, 2021)

Yes, that was sarcasm. I love to dig up fossilized hype from bygone days. Back in 2005 Ruby on Rails was the answer to every question. Its build tool, Rake, was a wonder of this new DSL programming approach. It was the future, you know. I wonder how many people are still struggling to migrate away from flaky and slow monolithic Rails apps that are killing their business.

One of the ironies of Systemd is how late it is to the party. They're trying to dominate the desktop in a time when the desktop doesn't matter. They're even resurrecting the hype from the good old days of the desktop.


----------



## grahamperrin@ (Oct 9, 2021)

hardworkingnewbie said:


> stuff which systemd does … system-homed



▼








						Linux systemd-homed
					

TechRepublic has an overview of the functions provided by systemd-homed which facilitates portable home directories in systemd 245.  Apparently homed does not yet work with ssh logins (home directories are encrypted until you have logged in so the private keys in ~/.ssh are inaccessible during...




					forums.freebsd.org


----------



## zirias@ (Oct 9, 2021)

Jose said:


> One of the ironies of Systemd is how late it is to the party. They're trying to dominate the desktop in a time when the desktop doesn't matter. They're even resurrecting the hype from the good old days of the desktop.


Hm yeah, that's a way to look at it . I'm still a user of a "classic" desktop, and I know one area where they're still very relevant: offices. Not only, but also for software developers. OTOH, almost any office will use Windows as their Desktop OS, so, still pointless. The "killer app" is MS Excel.


----------



## a6h (Oct 9, 2021)

Jose said:


> C'mon now, DSLs are the future! Why are you stuck in the past?


The keyword, "The Future", ... always a red-flag. A word of wisdom from the past.


----------



## bsduck (Oct 9, 2021)

macondo said:


> I'm an alsa user


Well, on Linux everyone is an ALSA user (except if you install OSS on Linux, which is possible), PulseAudio is just an additional layer between the sound framework and applications.


----------



## gpw928 (Oct 23, 2021)

Returning to the original subject line, it's not universally inevitable:





						Devuan GNU+Linux Free Operating System
					

Free GNU+Linux base OS. Devuan is a fork of Debian without systemd. Devuan Bewoulf provides a safe upgrade path from Debian, to ensure the right to Init Freedom and avoid entanglement.




					www.devuan.org


----------



## mrbeastie0x19 (Oct 24, 2021)

gpw928 said:


> Returning to the original subject line, it's not universally inevitable:
> 
> 
> 
> ...


Debian now has an option to install sysvinit via netinstall, it removes systemd


----------



## jbo (Oct 24, 2021)

I wonder whether I will tell my grand kids about this thread.


----------



## mark_j (Oct 24, 2021)

Only if they're dependent on systemd...


----------



## Jose (Nov 8, 2021)

Actual message at work this morning "Systemd fails to start (needed logging process) 1% of the time..." If you think 1% is low, multiply times several hundred instances and imagine what happens if they produce no logs at all.


----------



## cynwulf (Nov 16, 2021)

Jose said:


> You manage to pack 3-4 fallacies in those two short sentences. See items 3, 5, 11, and maybe 9 here:
> [REMOVED]


This is the original: https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html?view=mosaic&m=1

Avoids having to visit that agenda driven, activist site.


----------



## Jose (Nov 16, 2021)

cynwulf said:


> This is the original: https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html?view=mosaic&m=1
> 
> Avoids having to visit that agenda driven, activist site.


Looking for a problem with








						systemd-free linux community
					

we follow the development of linux away from systemd




					sysdfree.wordpress.com
				




And I really can't find one. No problems here








						About sysDfree
					

This is just a short excerpt for the about page.




					sysdfree.wordpress.com
				




Or here








						We are a systemd free linux community
					

This is the post excerpt.




					sysdfree.wordpress.com
				




So I really don't see the problem with








						Systemd: The Biggest Fallacies by Jude C. Nelson
					

We are reproducing here a very good article we found on without-systemd.org which is on the dreaded blogspot.  It took allowing three different sites to flash scripts so the simple text html docume…




					sysdfree.wordpress.com
				




But don't let me get in your way if you really would rather support Google and a platform that's hostile to its content creators.


----------



## cynwulf (Nov 17, 2021)

I don't support the platform - you'd need to take that up with the blog author - they chose it.  It happens to be the original source.  He's an agreeable enough type and might consider moving it, if you could point to alternatives?

Regarding the activist site - do some more reading if you have any desire to investigate further.  I won't comment on that.


----------



## hardworkingnewbie (Nov 22, 2021)

Canonical, the makers of Ubuntu, are right now working on including it to its WSL images, because many software didn't startup really well without it and Microsoft so far used an own, small stub INIT system. Also many users are relying on documentation with systemd userland tools as well.









						Systemd may be coming to Windows Subsystem for Linux
					

Stop the rock, can't stop the rock, we can't stop the rock




					www.theregister.com


----------



## baaz (Dec 12, 2021)

jbodenmann said:


> I know right? It feels like it's almost an entire OS. Wouldn't be surprised if it would come with its own dynamic memory management too!


at this point I wouldn't be surprised if it made its own kernel


----------



## baaz (Dec 12, 2021)

ayleid96 said:


> I would not worry about it, systemd will never happen in BSD world. BSD doesn't have any need for it.
> 
> EDIT:
> Reminder that systemd has over 1.2 million lines of code, BSD world could develop something with drastically less code to suit its use.


if needed I think BSDs don't need to develop anything runit with at most 1000 lines of code exists! (with bsd license :‌D)


----------



## zoujiaqing (Nov 2, 2022)

_InitKit is the standard Unix init system. It is designed for flexibility in accordance with a special operationalisation of the principles of the Unix Way._


----------



## Crivens (Nov 2, 2022)

For completeness : http://www.fefe.de/minit/


----------

