systemD is coming to a port near you!

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!
Click to expand...
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.
 
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 said:
Remove Xorg, desktop environments, and window managers from the ports. I guarantee the drive will go away.
Click to expand...
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.
 
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.

The Ubuntu/Fedora/etc users/developers who switch to FreeBSD want it to be like the crap they just came from.
Click to expand...
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.
 
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.]
 
Last edited:
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.
Click to expand...
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 said:
100 bucks says systemdur will try to swallow up GDM-wayland, or kwin-wayland, siloing all else out.

I’m calling it now.
Click to expand...
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...
 
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.
Click to expand...
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.
Click to expand...
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.
 
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.
 
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...
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
Click to expand...
mark_j said:
Once the GUI is introduced, all bets are off.
Click to expand...
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.
 
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.
Click to expand...
"But it's a standard" until MS/Oracle get their hands on it.
 
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.
 
From the repo's readme.md:
A complex of daemons implementing various systemd APIs commonly required by desktop environments. Written in Rust, targeting FreeBSD.
Click to expand...
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! :D

Now then... back to watching the "time elapsed" counter on my poudriere instance building lang/rust... :D
 
You must log in or register to reply here.
Back
Top