FreeBSD Making Progress On Wayland Support, The Basics Are Working

[Duve]

Well for one none of the mainstream BSDs use sysvinit. There's no /etc/inittab, no runlevels etc. You have /etc/rc.d for system init scripts, /usr/local/etc/rc.d for installed init scripts, /etc/rc.conf to enable/disable services and configure services/kernel on startup, and /etc/ttys to manage display managers like xdm and the ttys. It's a BSD init system and while it's far from feature-rich it has far less of the issues that sysvinit has - namely bsd init has a simpler start up, more intuitive configuration and it's far more reliable. Is it great? Hell to the no.

I'd personally say OpenRC is not worth it. I've used it, it's fine - but it is a Gentoo project. Runit is good. System XVI was promising, jobd is okay I guess. Ultimately I'd probably like a system that works similarly to SMF, keeps the current rc.conf syntax and avoids the pitfalls that launchd (which is designed around macOS and XNU, it is unsuitable for freebsd) and systemd (whose design makes dangerous assumptions).

I've educated myself on systemd's architecture, and I have three main complaints:

Over-reliance on dbus/kdbus. We already have sockets, shared memory, and on System V and BSD, STREAMS. Linux could have adopted STREAMS and that would have ended this crap long ago.

The PID 1 (Process manager and init) design makes unsafe assumptions: That all code running on the system is trusted. That any untrusted attacks will be caught by SELinux, namespaces, or privilege separation systems. That race conditions affecting the process manager are unlikely. The latter is troubling because in the event I exploit a race condition that allows me access to a process running with root privileges, I am in control. I can steal any data, bring down the system, destroy all of the data, or bring the server/desktop into a botnet.

Tight integration of all these system services leaves you with a monolithic, if modular architecture. It doesn't matter if I can compile it without what I need - the fact is most Linux distributions don't have ports trees, don't have some system you can use to customize software before it's installed - which means you have to build it out of the package manager. And that kind of defeats the purpose of having something like a package manager. At least, as of the systemd that got merged into Arch back in 2013 you couldn't specify what to install directly from pacman. That may have changed. But as long as I've had X, all the way back to the Xfree86 days, I remember that even then I could opt out of installing any part of the X package.

https://youtube.com/watch?v=Mri66Uz6-8Y

[TeamBlackFox]

Uhm, wait, what? Then why the fuck does it offer its own compartimentalization, access restriction, and so on features (basically exposing kernel features, btw)? Sure you can decide to not use them, but that's your (server admin or distro mantainer) responsibility.

The process manager running at PID1 has the minimum functionality necessary for its function, all other stuff like say logind and friends are run as daemons with other PID and non-root privileges.

Actually it's possible to separate PID1 into two (or three) distinct binaries:

1. Init
2. Process manager (root)
3. Process manager (unprivileged)

I would prefer this setup - or even another setup utilizing some way to separate privileges further.

Also, don't take what I say out of context. What I mean is simple: PID1 runs as root. Because the process manager is running as the root process you have the following issue - any exploits or problems with the process manager extend to all of PID1. That's what I mean - runit and OpenRC both separate the process manager into a different process altogether.

You claim it's running under least privilege but it isn't. I don't care that logind and friends is a different binary from PID1, that is irrelevant to what I am talking about. The only benefit to having everything under the systemd umbrella is a unified communication architecture being used by all these secondary processes (dbus) which isn't in and of itself a bad thing.

Afaik the script-based init systems have far more issues about random shit happening (not just race conditions, just about anything can happen in a script) and giving root access to everyone doing a simple exploit to a fucking database that was supposed to have no outside access (but is accessed by a website, of course).
True story, btw.

I wasn't defending script based init. The BSD init system may be reliable but it is far from perfect. Nobody ever said that it was perfect, either. Though, systemd's service files aren't perfect either - they don't show what's going on behind the scenes so if one of them gets corrupt then the operator of the server will have to check either against a known good service file or the relevant man page to repair/rebuild the service file. I wasn't complaining necessarily about the systemd service files. There's a lot to admire in systemd's goals. I just disagree with how it's been built.

This is a distro issue, only binaries that are actually fused together are the init and the logger, everything else is a separate binary. If your distro decides to ship them as a package, complain with your distro's mantainers.

Well I was wrong there, I admitted I may be wrong indeed. Seems I was.

I don't know if you really get that systemd isn't perfect or not. But Linux is far from the end-all be all of OSes. Beyond Linux, BSD, UNIX etc. There's a lot more OSes out there and some of them that I've used do a fair amount better than UNIX ever could. For instance, half of the midsize (formerly 'minicomputer') operating systems I've used such as VMS have some form of system error recovery built in. So do the few mainframe OSes I've touched, including DEC's ITS and TOPS-20. Now you may be saying to yourself, "But those are apples and oranges from general purpose OSes" And you're right, except that the idea of things like error recovery without panics or crashes is nothing new to the desktop world. And if I were a better designer, I'd probably build a OS right now that could put all of UNIX, Linux, and BSD to shame. But I'm not. So in lieu of that, I say that we deserve better. I only use BSD because of the following reasons:

I disagree with the Marxist GNU philosophy of 'free software', including the GPL's viral and reciprocity clauses. I cannot completely eradicate GPL, but I can not use Linux.
Linux has featuritis and has made a laundry list of design choices I disagree with. My grievances with the BSDs is far shorter.
HP-UX, IRIX, AIX and Solaris are behind BSD in features - not to mention vendor locked-in to their hardware except for Solaris.
Windows I am stuck on 7 because I refuse to adopt 8 or 10 on the principle of un-removable NSA backdoors - and 7 is far from the most effective for software development or other applications outside of games.
MacOS is locked into overpriced, underpowered and bad quality hardware and Mach/XNU is a shitty kernel to base an OS on. Screw MacOS
UnixWare, SCO OpenServer etc. are dead.
Android is fine as a mobile OS but not practical for other things.

Thus I use BSD. You may consider my reasons invalid, but as a prerequisite for discussing this with me you have to respect my choice without insulting me over my choice.

https://youtube.com/watch?v=Mri66Uz6-8Y

Jordan Hubbard is ONE former contributor to FreeBSD. He now works for iXSystems. His opinions are not the FreeBSD project's at large and it isn't his decision whatsoever.

[Luke_Wolf]

It's going to be different to some degree since there is a urge in FreeBSD to build their own system from the ground up, but both systemd and launchd have been named as inspirations to such. I would expect some similarities to them when the solution does appear. It's not like they have anything else to work with...

OpenRC is more or less a non-starter due to the lack of documentation.

We'll see what the TrueOS guys do with it, I thought it an odd choice myself due to that reason.

All efforts to simply port launchd have ended in failure to some degree, mostly on the issue of licensing and binding.

Not strictly speaking true. FreeNAS is now successfully using it, however they grafted a Mach compatibility layer on in order to do so. So for that reason... I wouldn't imagine it making it upstream.

That said, there is a feeling that they need something to replace old SysV init since there are ways to do it better. I would expect something similar at this point since most of the research has headed in the direction of systemd, with it being one of the few things that they can openly look at in it's entirety. That said, assuming that it would be like OpenBSD's systembsd effort would be rather naive at this point, since copying systemd wholesale isn't really a good idea.

As things currently stand, I get the feeling it's going to be jobd. http://mheily.github.io/jobd/ https://github.com/mheily/jobd as it's heading in the direction FreeBSD seems to want to go and isn't calling for huge changes in the kernel or anything.

[TeamBlackFox]

We'll see what the TrueOS guys do with it, I thought it an odd choice myself due to that reason.
Not strictly speaking true. FreeNAS is now successfully using it, however they grafted a Mach compatibility layer on in order to do so. So for that reason... I wouldn't imagine it making it upstream.
As things currently stand, I get the feeling it's going to be jobd. http://mheily.github.io/jobd/ https://github.com/mheily/jobd as it's heading in the direction FreeBSD seems to want to go and isn't calling for huge changes in the kernel or anything.

Yeah I have a name for the Apple dingleberries we seem to have in the FreeBSD community: Apple-fags. I don't mean to sound homophobic or anything, but they have a huge hard on for Mach and other Apple crap and take Steve Jobs to be their white Jesus. I doubt FreeNAS and TrueOS's efforts will ever go upstream, ditto for NeXTBSD.

jobd I have some doubts about, namely I dislike the name, but hey, if it works, it works!