How is FreeBSD coping with a systemd future?

Status
Not open for further replies.
fonz said:
LukeWolf said:
I am again more than willing to put my money where my mouth is and work on code, but I lack experience with C and systems level programming
Click to expand...
I suggest you start by evaluating exactly what the impact of systemd would be: which components of either ports or the base system does it replace? Which does it interact with? Which will be requiring it? Once there's a clear picture of the scope of the "project", it can be determined whether it's feasible and, if so, what would be needed.
Click to expand...
Well I do have a reasonably clear high level idea of what needs to be done, the primary concern at this point in time is logind, however it is looking like OpenBSD will take care of that through their GSoC although when it's done it will still need to be ported to FreeBSD. Of secondary concern are all of the other various D-Bus services that systemd provides, those can basically sit in the ports tree. There's no point reimplementing the init system or any of the replacement programs that it provides as far as I can tell, however future concerns are being able to consume systemd service files and launching managed user sessions, which I need to do some more research into the capabilities of FreeBSD for. As far as I can tell though the best bet for the last two are doable through launchd. Translating service files to scripts just seems like it'd be too much of a hack vs mapping it into launchd.
 
I think I see the problem we are having here in the thread.

  • Your concerns are valid
  • Our concerns are valid
  • We see your point, but do not seem to care
  • Both sides have different ways to deal with such problems

That the spread of systemd will be a problem for desktop usage is clear. BUT - many here do not use desktop environments, and thus don't care. Effort to gain ratio says you should go play with the kids instead. Most users here have an engineering background and, that is important, some experience in the field. They see systemd as one of the many many "oh look, shiny" projects out there. While Linux went from MAKEDEV to HAL to udev (now part of systemd), *BSD went to devd and was done with it. All these *Kit packages (I think of BeOS when I hear these mentioned) are also being replaced. And the same will be done with their replacement.

Standard engineering practice is to first check if a problem has to be solved. We do not have enough resources to hand this out to someone, there are more important things to do. That is the way engineers think, when they can think for themselves.

  • Can this be solved?
  • Can I solve it?
  • Why should I?
  • What would the benefits/contras be?

So before you think nobody understands what you want and run off - we do understand. We simply have a different mind set. We have some priorities, and we have some experience. I tried to point that out when I said that it might not be in the best interest of the desktop environment people to utilize systemd in any substantial way. It might save work now (short term gain) but is likely to cost them dear in the future when the makers of systemd do things to break stuff (been there, seen it).

You are welcome to work on the task, we will help you. But we will not gather around some banner for this. At least, I won't. Nothing personal, that's experience.

:beer
 
LukeWolf said:
And your preference would be to continue using a deprecated and unmaintained project (Consolekit) that desktop developers are looking to drop support for?
Click to expand...
No, no, no. Many people NEVER use that thing, not even on the desktop. There's more to life than KDE or GNOME, you know.
 
I've been thinking a lot about the increasing tendencies of major projects to target Linux only. Linux is really moving toward being its own entirely unique OS, without even a pretense of being a *nix-like system. Lots of engineering challenges: ALSA, PulseAudio, *kit, Dbus, udev, systemd, Wayland, etc. Even the desktop environments are being dumbed down into shiny toys now. Obviously, we'll keep writing shims around these technologies. But let's say hypothetically that eventually fails, the shims get too complex, and we can't wrap them anymore.

So when I think about it all... I have a nice system running Xfce 4.10, and 95% coverage with GTK+ 2. My desktop is designed for a keyboard and mouse, rather than for a tablet. If it's all deprecated, so what? It still works fine on my system, and I'll keep it there as long as I can. If ports start being killed due to breakage+abandonment (e.g. gFTP), or transformed into hideous tablet applications, then I'll write my own replacements. I already have a few, such as a hex editor.

If things get so incredibly bad that we lose all of X.Org, all of Wayland, all of our accelerated video drivers, all of GTK+, and all of Qt, the absolute doomsday scenario, then I will help rewrite it all. One ioctl and one mmap, and you've got a hi-res pixel buffer that's good enough for anything but playing 3D games. I am certain I won't be the only one interested in a true, portable *nix-style desktop that uses tried and true paradigms instead of constantly redesigning everything. Especially if the BSDs end up with no alternatives. We'll recreate it all from scratch if we have to: first a display server, then a window manager, then a toolkit, then userland applications. One by one.

Crivens said:
While Linux went from MAKEDEV to HAL to udev (now part of systemd), *BSD went to devd and was done with it.
Click to expand...

Same for OSS -> ALSA -> PulseAudio. Instead of just forking OSSv3 when the author saw dollar signs in licensing, and then sensibly multiplexing /dev/dsp like FreeBSD, they created the most complicated, poorly documented audio API I have ever worked with. And I've worked with nearly a dozen.

I basically bailed over systemd. Poettering's last project, PulseAudio, was such a trainwreck that for the first year it was shoved down my throat, I had to actually install the OSSv4 commercial binaries and rebuild all twenty sound wrappers to use it instead of ALSA (SDL, libao, OpenAL, the sound servers, etc.). Even when Pulse worked then, the latencies were horrendously bad, upwards of 150 ms. But hey, it solved a problem I will never have: streaming audio over a network connection. It seems to work well and good now on Linux, but only after years of other people cleaning up his mess. And that arrogant attitude... no, I'm not going through that again.
 
We Slackware guys are still holding on to the legacy approach which is more admin friendly IMO, you know, simple text configuration files. However whatever Pat will decide on inclusion of systemd, will decide the future of the project and most of the userbase will comply with that as far as I see.

Regards.
 
byuu said:
If things get so incredibly bad that we lose all of Xorg, all of Wayland, all of our accelerated video drivers, all of GTK+, and all of Qt ... the absolute doomsday scenario, then I will help rewrite it all. One ioctl and one mmap, and you've got a hires pixel buffer that's good enough for anything but playing 3D games. I am certain I won't be the only one interested in a true, portable *nix-style desktop that uses tried and true paradigms instead of constantly redesigning everyting. Especially if the BSDs end up with no alternatives. We'll recreate it all from scratch if we have to: first a display server, then a window manager, then a toolkit, then userland applications. One by one.
Click to expand...

I'm in :)
 
kpa said:
ralphbsz said:
What does systemd do for headless machines (those without X)?

If the answer is "nothing", then why make it the default? For servers, the existing SysV init is plenty.
Click to expand...

This is incorrect. It offers a complete replacement for service management (service(8) under FreeBSD) including services that have nothing to do with X11 or graphical UIs and startup scripts that are traditionally handled by rc(8) on FreeBSD and usually by sysvinit under Linux.
Click to expand...
systemd is irrelevant for BSDs and should be ignored as every bad idea whether it is coming from BSD, Linux, Solaris or God knows which ecosystem.
 
Oko said:
systemd is irrelevant for BSDs and should be ignored as every bad idea wheather it is comeing from BSD, Linux, Solaris or God knows which ecosystem.
Click to expand...
I'm with you so far. But this morning I read a pice about X.Org getting rid of their log files (xorg.0.log) in favor of systemd as a log back end. This is the tentacle creep I meant, which will make a lot of software unusable without this abomination around. While I would like to shame the developers of X.Org, they might even have valid reasons for this decision. But if they do it, I wish them good luck and also that systemd suddenly turns closed source and commercial.
 
Crivens said:
Oko said:
systemd is irrelevant for BSDs and should be ignored as every bad idea wheather it is comeing from BSD, Linux, Solaris or God knows which ecosystem.
Click to expand...
I'm with you so far. But this morning I read a pice about xorg getting rid of their log files (xorg.0.log) in favor of systemd as a log back end. This is the tentacle creep I meant, which will make a lot of software unusable without this abomination around. While I would like to shame the developers of xorg, they might even have valid reasons for this decision. But if they do it, I wish them good luck and also that systemd suddenly turnes closed source and commercial.
Click to expand...

I am with you guys too. I also don't care if someone wants to make a systemd emulator, but it does not belong in base.
 
Crivens said:
Oko said:
systemd is irrelevant for BSDs and should be ignored as every bad idea wheather it is comeing from BSD, Linux, Solaris or God knows which ecosystem.
Click to expand...
I'm with you so far. But this morning I read a pice about X.Org getting rid of their log files (xorg.0.log) in favor of systemd as a log back end. This is the tentacle creep I meant, which will make a lot of software unusable without this abomination around. While I would like to shame the developers of X.Org, they might even have valid reasons for this decision. But if they do it, I wish them good luck and also that systemd suddenly turns closed source and commercial.
Click to expand...
The dirty secret of X.Org has been for a while that only Linux matters. I am afraid that people will have to fork or find alternatives to X.Org if they want a GUI on other UNIXes.
 
Oko said:
The dirty secret of XOrg has been for a while that only LINUX matters. I am afraid that people will have to fork or find alternatives to XOrg if they want GUI on other UNIXes.
Click to expand...
You are leaving part of the story out here. Some X.Org developers have reached out to our development community before and received little or no response. Is anyone from our community working upstream? Why is OpenBSD coping better? Maybe if we ate as much dog food, we'd be better off.

@LukeWolf, have you tried your questions on the FreeBSD mailing lists (x11@ or hackers@) and/or the PC-BSD forums?
 
Last edited by a moderator:
To be clear, I really want a new display server+toolkit+desktop environment to be an absolute last resort. After we no longer have the manpower to keep supporting more and more Linux-only technologies. But if we do get to that point...

The wonderful thing is that it's very easy to get started, and to get something quite usable. Even back in the '90s, having only been programming for 2-3 years, I put together a DOS+VESA "desktop environment" with most of your standard widgets. It was kind of interesting how much more complex a simple text box is than you would think. Sure, it had intense limitations: no acceleration, no compositing, no Unicode, no vector-based fonts, no real applications. But it was perfectly usable as the development IDE I wanted it for, even on that P166.

Nowadays I'm sure I could put together something much nicer. It would just be about spending a few months prototyping how to create the modularity so that it could expand without having to be scrapped. You want to allow for hardware-accelerated drivers. You want a way for OpenGL to fit into the equation. You want to plan for Vsync and adaptive sync, and for KMS and UEFI/GOP. You want the window manager to be its own layer so that others can be written. You want the toolkit to be fully themeable, and you may as well plan for 200+ dpi screens right from the start.

Do all of that, and we can have a basic, modern functional desktop in under six months' time. We don't have to do all of the hardest work, either. Vector font rendering is a hard problem, so we would use the cross-platform Freetype library for that. HTML rendering is an insanely, impossibly complex problem. So we would use the cross-platform WebKit engine for that. Figuring out undocumented instant messaging protocols is challenging, so we would use libpidgin for that.

Eventually, we could reach a point where we port over Intel, AMD and nVidia/nouveau driver code. We could make an interface between our display server and OpenGL. We could create backends for GTK+ and Qt to run the truly cross-platform applications (the ones you see on Windows, OS X and Haiku) like GIMP, Transmission, Pidgin, Firefox, etc. At some point, I really believe minimalist Linux distributions, those like Slackware and Gentoo, would start to seriously consider a Linux+GNU userland+BSD display server system.

But right now, the only problem all of this Linux technology is causing me is that I have to enable D-Bus+hald, I have to use a ConsoleKit shim to log out of Xfce, and can't use Thunar's volume manager to auto-mount drives. The rest of my desktop works just fine. Not nearly dire enough to warrant this extreme solution, yet.

jrm said:
Some Xorg developers have reached out to our development community before and received little or no response.
Click to expand...

Because it's disingenuous. "Hey, we want to use this elaborately complex init system that's over 550,000 lines of code already and that depends on dozens of Linux-only kernel features and interfaces. Can you guys pretty please support it full stop?"

The answer is no. BSD != Linux. We don't need cgroups, we have jails. They're not exactly the same, because they are different operating systems. They have very different philosophies. One example I love, is /dev/random and /dev/urandom. Linux uses the former for "true" entropy (recording key strokes, mouse movements, interrupt counts, etc.), and the latter for PRNGs. The former will exhaust itself after a few KB of data, and then lock on reads. But "true" entropy is mysticism. There's no guarantee it's truly random, no evidence that it's more secure, and the entropy can actually be significantly worse. Dilbert sums this up nicely. FreeBSD instead relies on cryptographically secure PRNGs only, because those at least have a scientific basis for their strength. Being a man of reason over faith, I much prefer FreeBSD's approach.

I'm no fanboy. There are some designs where I think Linux does things better. But most of the time, I prefer the approach of the *BSDs. I don't want FreeBSD to turn into Linux just so it can run GNOME 3 for Tablets.

But even when it comes to shims, I think they're underestimating just how small the FreeBSD desktop userbase is. Windows is to Linux as Linux is to FreeBSD on the desktop. (On the server, it's more even. But servers don't need tablet GUI environments.) There just aren't enough developers to keep up with >550K SLOC init systems, when we already have a perfectly functional one.
 
jrm said:
Oko said:
The dirty secret of XOrg has been for a while that only LINUX matters. I am afraid that people will have to fork or find alternatives to XOrg if they want GUI on other UNIXes.
Click to expand...
You are leaving part of the story out here. Some X.Org developers have reached out to our development community before and received little or no response. Is anyone from our community working upstream? Why is OpenBSD coping better? Maybe if we ate as much dog food, we'd be better off.

@LukeWolf, have you tried your questions on the FreeBSD mailing lists (x11@ or hackers@) and/or the PC-BSD forums?
Click to expand...

That was one of the reasons besides Hiroki Sato's ten-year effort to port TeXLive to FreeBSD that made me switch camps and become an OpenBSD guy. I find it despicable to even talk about FreeBSD on the desktop when so many developers are using OS X and run FreeBSD only in the virtual machine. OpenBSD in general is a far simpler OS with a different focus. I would like to see FreeBSD being the OpenBSD of file systems, multi core computing and scientific computing.
 
Last edited by a moderator:
Currently, Wayland does not seem to need D-Bus and thus has no dependency on things discussed here. I will have a closer look into that, maybe it is more feasible to get Wayland up to speed and then keep it out of the quagmire that happens when politics get in. And yes, I think all this systemd/dbus-to-the-kernel/WTF/... stuff is mostly politics and blinds for the eyes.
 
There is some interesting reading here regarding the topic, and one very nice suggestion in the thread.
 
The question to this thread is wrong. It should be "How is Linux coping with a systemd future?". It's not so rosy but we're not to discuss other operating systems here.
 
drhowarddrfine said:
The question to this thread is wrong. It should be "How is Linux coping with a systemd future?". It's not so rosy but we're not to discuss other operating systems here.
Click to expand...
Partly yes, partly no. As far as Linux as an OS is concerned, they can do whatever they want with their kernel and user land. But when it comes to applications, that is a different keg of beer alltogether.

The problem is not that Linux is doing what they do, the problem is that a lot of upstream gets sucked in on this. And this is where other parties (that includes FreeBSD), should be concerned. Systemd is force fed to the Linux user base, and the upstream of a lot of projects gets affected, and it then comes down to us. So I think this should concern us, even when it is out of our direct influence to act on it. Maybe we should simply extend a hand to projects which are willing to do something about this and offer them a new /home?
 
Hmmm... within the last twelve hours, three or more threads have appeared [1] on the arch linux forum about problems with systemd. Not going to click on those! I can envision if systemd ever arrives here, the same happening, and numerous forum visitors deciding, Not going to install that!
[1] and/or have new posts within them.
 
http://www.infoworld.com/d/data-center/ ... pse-248436 is one negative take on it.

Since it's gotten into RHEL7, and therefore, CentOS 7, there's been various and sundry threads on both mailing list and forums as well, more or less echoing what goes on with the other Linux distributions. I think that @Crivens hit the nail on the head. As it affects more and more of upstream, it will affect various programs that currently are easily ported from Linux.
 
Last edited by a moderator:
Speaking of the desk/lap/palm top for the masses (including my good self), the only Linuces that matter are the Google's flavors: Android and ChromeOS and those don't really need systemd.

That being said, I am more interested by cgroups and their use in system–level virtualization and application containers. I will be curious to see how Docker will be ported to FreeBSD.
 
When you are interested in system level virtualization and containers, I would suggest to check out jails in combination with memory disk images - should need be. There should not be any need to port Docker to FreeBSD, that functionality is here and has been for some time. Or is there something missing of which I am not aware of?
 
Crivens said:
When you are interested in system level virtualization and containers, I would suggest to check out jails in combination with memory disk images - should need be. There should not be any need to port Docker to FreeBSD, that functionality is here and has been for some time. Or is there something missing of which I am not aware of?
Click to expand...

I have already been using jails for years now.

I have been playing with Docker and the approach seems to me different.

Correct me if I am wrong but I think Docker is more is more about embedding applications while Jails are more about running systems within a system.

I like the idea of embedded virtual systems.
 
Status
Not open for further replies.
Back
Top