systemD is coming to a port near you!

Vull

Aspiring Daemon

Reaction score: 517
Messages: 822

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.
 

vigole

Daemon

Reaction score: 1,562
Messages: 1,395

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

Member

Reaction score: 6
Messages: 31

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

Son of Beastie

Reaction score: 2,167
Messages: 3,006

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

Well-Known Member

Reaction score: 365
Messages: 320

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

Member

Reaction score: 63
Messages: 93

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

Daemon

Reaction score: 922
Messages: 1,885

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:

kpedersen

Son of Beastie

Reaction score: 2,167
Messages: 3,006

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

mark_j

Daemon

Reaction score: 744
Messages: 1,284

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?
 
OP
M

mark_j

Daemon

Reaction score: 744
Messages: 1,284

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

Aspiring Daemon

Reaction score: 616
Messages: 727

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

I’m calling it now.
 

Menelkir

Well-Known Member

Reaction score: 365
Messages: 320

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

Daemon

Reaction score: 922
Messages: 1,885

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.

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

Daemon

Reaction score: 922
Messages: 1,885

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

Active Member

Reaction score: 238
Messages: 242

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

Daemon

Reaction score: 922
Messages: 1,885

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.
 

sidetone

Daemon

Reaction score: 922
Messages: 1,885

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

mer

Aspiring Daemon

Reaction score: 400
Messages: 631

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.
 

ralphbsz

Son of Beastie

Reaction score: 2,407
Messages: 3,283

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.
 

jbodenmann

Well-Known Member

Reaction score: 236
Messages: 453

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

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