# How is FreeBSD coping with a systemd future?



## LukeWolf (May 30, 2014)

I'm not interested in a debate over whether systemd is good or evil, I'm interested in the question of how is FreeBSD working to respond to the changes that systemd is creating in the open source software ecosystem, and what needs to be done.

Obviously *BSD has its own init system so SysV init going away doesn't effect that. FreeBSD just has to continue the work of supporting init scripts.

My understanding is that FreeBSD has a udev replacement in devd, however PC-BSD appears to be relying upon hald.  Obviously hald has been long since abandoned by Linux, so does KDE SC for example have a solid backend for devd? What needs to be done to shift away from hald?

Logind is probably the biggest issue for the immediate future. Consolekit was deprecated by it's maintainer and as far as I know, nobody has stepped up to the plate to maintain it, nor has anybody implemented the DBUS API that logind presents. Meanwhile GNOME intends on using logind's DBUS API exclusively for wayland and long term I expect the various Consolekit backends are going to bitrot and break. What does FreeBSD intend on doing about this?

Session management is something I've seen discussed on both the KDE and GNOME side of things where systemd would manage the user session, while I expect such a thing to stay optional with KDE, what I've read of GNOME blogs indicate that they want to use it to eventually deprecate gnome-session, does FreeBSD provide some equivalent functionality or what is the plan?

Sorry if any of the above is a stupid question, but I'm a Linux user who recently decided to look into FreeBSD and was impressed by the exceptional documentation, ports system and what appears to be a generally better engineered approach to things (for example OSSv4 vs ALSA). I'm thinking about migrating at least one of my systems over, however I need to wait on Radeon to pick up dynamic power management for use outside of a VM, and I'm concerned by the lack of obvious movement towards actually doing something about the systemd future as opposed to just complaining about it. If it's not too difficult, I'd be willing to work on code myself however I'm a decent but rather inexperienced C++/Qt and C# programmer, and so would need a mentor to help me.


----------



## Derydlus (May 30, 2014)

I'm not sure if FreeBSD is doing anything, but this intends to provide systemd replacements for ports that require it. More details here. Seems like there's little need to duplicate effort, although I'm sure help would be appreciated. I'm not sure about the logistics of helping out current GSoC projects. You may need to wait to contribute patches.


----------



## ralphbsz (Jun 1, 2014)

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.


----------



## kpa (Jun 1, 2014)

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.



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.


----------



## drhowarddrfine (Jun 1, 2014)

Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distributions don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?


----------



## zspider (Jun 1, 2014)

drhowarddrfine said:
			
		

> Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distros don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?



There are those who will stop at nothing to foist _that thing_ onto this project too. They don't care about the UNIX philosophy, just that they get their way, at any cost. They may succeed eventually, so it would not be bad to have alternatives lined up.


----------



## Crivens (Jun 1, 2014)

I would like to reprase the question a bit: How will the Linux world deal with what systemd will become in the future? And while we are at it - udev is a remake of devd.

So we would likely need to patch around the places where someone thought a hard dependency on systemd would be a good idea, and most likely will ignore anything that refuses to be changed in such a way. We are used to not getting it all on a silver platter, so why should we care too much?

Time will tell, and time and tide wait for no man.


----------



## obsigna (Jun 1, 2014)

kpa said:
			
		

> ralphbsz said:
> 
> 
> 
> ...



@@kpa, your answer is of course correct if we take the question "What does systemd do?" as being about the functionality of systemd. However, we could understand the question also like: "What are the benefits of systemd for headless machines (those without X)?" And in this case, your response is still lacking the answer.

systemd is mainly advertised because of giving performance gains when starting-up, isn't it? I raise my hand here, because I am particularly interested in the expected starting-up time savings. My low-end Atom Dual Core 1,67 GHz server (DNS/web/mail/file, ...) needs exactly 60 s. May I expect that systemd brings this down to 30 s? It is hard for me to believe this. On the other hand, a time saving of 3 s would for me mean almost the same as "nothing".


----------



## kpa (Jun 1, 2014)

obsigna said:
			
		

> kpa said:
> 
> 
> 
> ...



The benefits are not in the area of performance. System start up times are irrelevant anyway because unless you suffer from ADHD you won't be restarting your machine ten times a day as a regular user. Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery. This is an area where in my opinion FreeBSD and other open source OSes are still severly lacking because of shortcomings of tools that are used to implement the service framework, namely the Bourne shell.

I dislike MS Windows for many reasons but even I have to admit that they did something really right when they implemented their service framework. Other OSes are only now catching up.


----------



## obsigna (Jun 1, 2014)

kpa said:
			
		

> ... The benefits are not in the area of performance. ...



How then shall I understand this:


			
				http://en.wikipedia.org/wiki/Systemd said:
			
		

> ...
> Lennart Poettering and Kay Sievers, the software engineers who initially developed systemd, sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies; to allow more processing to be done concurrently or in parallel during system booting; and to reduce the computational overhead of the shell. ...





			
				kpa said:
			
		

> System start up times are irrelevant anyway because unless you suffer from ADHD you won't be restarting your machine ten times a day as a regular user.


Well, this statement throws the main goals of Lennart and Kay for systemd into the trash can.



			
				kpa said:
			
		

> Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery.




The number of occasions my servers may be in need for this, are much much less than the weekly restart after the scheduled system update. I even cannot remember any of the many services were crashing in the middle of the operation.
I hate automatic crash recovery, because a crash means that something ran seriously bad, and I prefer that the crashed service stays offline, until I've had a chance to analyze what happened.
What reliability improvements are you talking about? 99.95 % to 99.97 %? That's even less benefit than an improvement in the starting-up time from 60 to 57 s.


----------



## jb_fvwm2 (Jun 1, 2014)

I recall, IIRC, seeing several  [arch]forum topics weekly about systemd wrecking stuff (and/or at the ArchLinux Reddit subforum), but I know little or nothing about systemd other than reading a few threads a while back.


----------



## Crivens (Jun 1, 2014)

For what it's worth, I was told that one of the driving forces behind systemd and the obsession with boot times is the automotive industry. Fast restarting of failed services or components is very important to them, also your "entertainment system" needs to be operational when you sit down in the driver seat. Boot starts when you click your key remote, and has to be almost over 3-5 seconds later. So go figure if debugging of custom tuned setups is on the agenda for these driving forces.


----------



## owemeacent (Jun 2, 2014)

> Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distributions don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?



Linux is, as far as anyone's concerned, still a unix-like system, it mostly adheres to the POSIX specification, it uses mostly GNU userland, which is as close to Unix as Richard Stallman wanted it to be (and he wants it A LOT), and a lot of Linux distributions still don't use systemd: Debian doesn't (but it will), Gentoo is strictly against it, RedHat doesn't, and neither does Slackware, and many others don't use it either. It's just an init system, you could change it if you want, you don't have to fuss about it.


----------



## scottro (Jun 2, 2014)

RedHat will be using it in its next iteration, RHEL7.  One of the reasons systemd is becoming so ubiquitous is, IMO, because RedHat throws its not inconsiderable weight behind it. Slackware and possibly Gentoo are the relatively exceptional holdouts.   With Debian and the *buntus going over to it, this means that the vast majority of Linux users will be using it.  

Unfortunately, (again, IMO) it seems that various programs may have ties to systemd, and that means that porting these over to FreeBSD will possibly involve additional work.  However, the previous sentence is based upon vague recollection, i.e. read it on the Internet somewhere, I think, so may be completely wrong.  I can't name such a program (that is, a general userland program that in Linux will be tied to systemd).


----------



## SirDice (Jun 2, 2014)

owemeacent said:
			
		

> Linux is, as far as anyone's concerned, still a unix-like system, it mostly adheres to the POSIX specification,


POSIX != UNIX. Even Windows was at one point POSIX compliant. http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem


----------



## drhowarddrfine (Jun 2, 2014)

And GNU userland isn't Unix either.


			
				owemeacent said:
			
		

> and a lot of Linux distributions still don't use systemd: Debian doesn't (but it will), Gentoo is strictly against it, RedHat doesn't, and neither does Slackware, and many others don't use it either.


That's my point. Why should FreeBSD be concerned about the Linux proprietary systemd when large swaths of themselves don't use it?


> It's just an init system, you could change it if you want, you don't have to fuss about it.


Then why bring up the question?


----------



## LukeWolf (Jun 2, 2014)

You know... I specifically said I wasn't interested in the complaining and fighting. Yet after the first reply, which was actually helpful, you guys dove right into doing that.

For those who think that "Oh the Linux ecosystem hasn't adopted it, why should we care?", guess what? You're wrong. All of the distributions except for Gentoo and Slackware either are or will be using it, and even in their camps a segment of the userbase is using it. This is not something you can just ignore.

Why should FreeBSD care about the systemd umbrella project? Well it's really quite simple, if you intend to use FreeBSD for desktop/workstation or mobile roles you better be paying attention to it. For example Consolekit is deprecated and unmaintained, and logind is its replacement, either you need to move to support OpenBSD in writing and maintaining a drop-in replacement for logind or give up on the desktop and mobile front because Consolekit support will be dropped by the desktop environments, and nobody will be writing new mobile environments on top of deprecated and unmaintained software, particularly now that a drop in replacement is being written. The other big two issues are going to be service files and session management. KDE is planning on swapping out the startkde script for a set of service files (although it will for the time being remain as a fallback option), and GNOME has spoken of  using systemd to manage the user session as opposed to gnome-session. The launchd porting effort could solve this, and then it would just be a matter of providing all of the little dbus services that systemd provides so that the FreeBSD experience is not degraded versus the Linux experience.

The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem. 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


----------



## obsigna (Jun 2, 2014)

LukeWolf said:
			
		

> ...
> Why should FreeBSD care about the systemd umbrella project? Well it's really quite simple, if you intend to use FreeBSD for desktop/workstation or mobile roles you better be paying attention to it. ...



Perhaps you have more success with your systemd missionary on the PC-BSD forum. There, the server guys won't interfere by asking: "Why do I need systemd only to start Apache?"


----------



## drhowarddrfine (Jun 2, 2014)

LukeWolf said:
			
		

> You know... I specifically said I wasn't interested in the complaining and fighting. Yet after the first reply, which was actually helpful, you guys dove right into doing that.


Speaking for myself, I find the question insulting. That we need to follow Linux' lead.

For that matter, let's all start a thread on a Linux forum asking how Linux is going to cope with the fact that they are no longer compatible with Unix.



> For those who think that "Oh the Linux ecosystem hasn't adopted it, why should we care?", guess what? You're wrong. All of the distributions except


 So all of them haven't. Someone else mentioned RedHat won't and one other big one.



> The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem.


And that truly is a problem for those who want to run FreeBSD as a desktop, which I also do. That some desktop environments may abandon all others in pursuit of Linux proprietary systemd is a problem with those people who make those desktop systems. I don't know that someone won't come up with a workaround to still make FreeBSD compatible with that, like it does now and, according to some, even faster and better than Linux does.


----------



## ralphbsz (Jun 2, 2014)

kpa said:
			
		

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



I don't use service(8), and AFAIK there is no need to use it.  Editing /etc/rc.conf is perfectly sufficient.  So, let me re-ask my question: For a headless system (no X login, no X server), for which  /etc/rc.conf is sufficient, what improvements does systemd offer?



			
				obsigna said:
			
		

> systemd is mainly advertised because of giving performance gains when starting-up, isn't it?



If your system is starting up a lot, then it is not a production system, but a toy (namely something that people play with).  I'm interested in a stable, reliable, simple to manage production system.
Want performance gains on starting up?  Many things come to mind.  Get a UPS, so a small power outage turns into a clean shutdown (without fsck) rather than a crash.  Use file systems that don't have to wait for fsck, or where fsck runs.  Remove unnecessary services and daemons from startup.  And put the root file system on an SSD.
On my system (a dual-core Atom, with a cheap SSD for root) the startup time is dominated by the BIOS, and it having to spin up and query five disks.  The actual time from the kernel loading and init(8) starting to all services running and a login prompt on the console is probably 10 or 20 seconds.  For a system that typically has an uptime of several months, that is not relevant.



			
				kpa said:
			
		

> Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery. This is an area where in my opinion FreeBSD and other open source OSes are still severly lacking because of shortcomings of tools that are used to implement the service framework, namely the Bourne shell.



If services crash, the problem is much bigger than the need to restart them.  It means that a service that the machine is SUPPOSED to provide is not working.  Restarting a broken service is not the correct answer; hardening the service so it becomes reliable is the correct answer.

On the Linux religious war question: I have nothing against Linux.  I use it, on probably two dozen machines at work, and a few at home.  I even understand why some people select a *nix operating system for a graphical desktop (although I chose not to).  However, I need an operating system for a server-class machine, which needs to be reliable and functional, with minimal effort.  Replacing the functioning startup system we have today with something more complex is a step in the wrong direction, for my use pattern.

And to be clear: I have nothing at all against someone porting systemd to FreeBSD, and integrating it with KDE, GNOME, or whatever other software they want to integrate it with.  But I have a serious problem with making it the default or only mechanism for starting services, unless someone can come up with a good argument for it.  My main argument against it is: don't mess with a running system.  The current rc setup functions well, and has a great balance between simplicity and easy of use, and functionality for its intended purpose.

EDIT: The spell-checker keeps changing "systemd" to "systems", and I have to keep going back to fix it.  Sorry about that.


----------



## SirDice (Jun 3, 2014)

ralphbsz said:
			
		

> If services crash, the problem is much bigger than the need to restart them.  It means that a service that the machine is SUPPOSED to provide is not working.  Restarting a broken service is not the correct answer; hardening the service so it becomes reliable is the correct answer.


I fully agree. And in case you actually need something like this there's always sysutils/daemontools. There are also projects like sysutils/fsc.


----------



## Crivens (Jun 3, 2014)

LukeWolf said:
			
		

> The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem. 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


Maybe it is only me, but putting "engineering" into the context of systemd does not sound right. The purpose of systemd seems not to be a solution to a problem but an attempt to be a problem as well, defying solution. Walled garden from inside, so to speak. Maybe it is neccesary to deal with systemd somewhere and somehow - by porting, emulating, or patching it out of any component depending on it. 

If it gets completely impossible to work with any system but Linux due to the tentacles systemd spreads out, it will be time for me to set up virtual machines and use some other means of GUI and keep a headless FreeBSD to use.

Adapting systemd into any application or desktop environment will tie that code into Linux and leave it at the mercy of any decision which may come up in the developers there. That is what any author of such components needs to keep in mind. And this is something I, for one, would resist. So maybe we do not need to deal with it at that level but simply need to remind those authors that this might not be the best decision to make. But you never know.


----------



## drhowarddrfine (Jun 3, 2014)

That is exactly my point.


----------



## fonz (Jun 3, 2014)

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


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.


----------



## LukeWolf (Jun 4, 2014)

drhowarddrfine said:
			
		

> 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? The fact is you don't even need to follow Linux (and in fact even can't because systemd is specific to the Linux kernel).  What needs to occur for FreeBSD to continue to support the desktop environments of the future is to support a set of DBUS interfaces, which you can choose to handle however you want. It's not Linux that will be being followed but the desktop developers with their declared needs.



			
				drhowarddrfine said:
			
		

> For that matter, let's all start a thread on a Linux forum asking how Linux is going to cope with the fact that they are no longer compatible with Unix.
> 
> 
> 
> ...


systemd will be coming into RHEL7, RHEL6 only isn't using it because systemd wasn't around when it came out. Debian will be using it in their next major version, Ubuntu will be using it.  Fedora, openSUSE, Maegia, and Arch already use it, and derivatives use what their parents use.  This means that the only holdouts are Gentoo, and Slackware. Gentoo has systemd as a first-class (though not default) option, and there's a significant part of their community that uses it, and some members of the Slackware community have made it so that it works there too. Neither Gentoo or Slackware are significant enough to halt the adoption of the interfaces systemd provides, and so will also have to either work around them or shift to systemd.



			
				drhowarddrfine said:
			
		

> > The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem.
> 
> 
> And that truly is a problem for those who want to run FreeBSD as a desktop, which I also do. That some desktop environments may abandon all others in pursuit of Linux proprietary systemd is a problem with those people who make those desktop systems. I don't know that someone won't come up with a workaround to still make FreeBSD compatible with that, like it does now and, according to some, even faster and better than Linux does.


And just what did you think I was calling for? Bringing systemd to FreeBSD is impossible, however supporting the dbus interfaces it provides, and providing equivocal functionality when we're talking desktop configurations (in other words what you termed as workarounds) is completely possible and in fact required if FreeBSD desires to continue supporting the major desktop environments in the future. However the entire reason I started this thread is that until that OpenBSD GSOC project nobody was moving forward on said workarounds and Desktop Developers are already moving forward on shifting away from Consolekit (As far as I know Gnome is now shipping in degraded mode for systems not supporting the logind dbus interface) and distribution specific code towards systemd's interfaces.


----------



## LukeWolf (Jun 4, 2014)

fonz said:
			
		

> LukeWolf said:
> 
> 
> 
> ...


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.


----------



## Crivens (Jun 4, 2014)

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


----------



## fonz (Jun 4, 2014)

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?


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.


----------



## byuu (Jun 4, 2014)

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.



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.


----------



## CurlyTheStooge (Jun 4, 2014)

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.


----------



## Crivens (Jun 4, 2014)

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.



I'm in


----------



## Oko (Jun 5, 2014)

kpa said:
			
		

> ralphbsz said:
> 
> 
> 
> ...


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.


----------



## Crivens (Jun 5, 2014)

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.


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.


----------



## zspider (Jun 5, 2014)

Crivens said:
			
		

> Oko said:
> 
> 
> 
> ...



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.


----------



## Oko (Jun 5, 2014)

Crivens said:
			
		

> Oko said:
> 
> 
> 
> ...


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.


----------



## jrm@ (Jun 5, 2014)

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.


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?


----------



## byuu (Jun 5, 2014)

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.



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.


----------



## tankist02 (Jun 5, 2014)

PC BSD started Lumina: http://blog.pcbsd.org/2014/04/quick-lumina-desktop-faq/. Maybe this will help?


----------



## Oko (Jun 6, 2014)

jrm said:
			
		

> Oko said:
> 
> 
> 
> ...



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.


----------



## Crivens (Jun 6, 2014)

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.


----------



## Crivens (Aug 22, 2014)

There is some interesting reading here regarding the topic, and one very nice suggestion in the thread.


----------



## drhowarddrfine (Aug 22, 2014)

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.


----------



## Crivens (Aug 23, 2014)

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.


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?


----------



## jb_fvwm2 (Aug 23, 2014)

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.


----------



## scottro (Aug 23, 2014)

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.


----------



## ctaranotte (Aug 24, 2014)

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.


----------



## Crivens (Aug 24, 2014)

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?


----------



## ctaranotte (Aug 25, 2014)

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?



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.


----------



## ctaranotte (Aug 25, 2014)

That being said, cgroups and namespace are two great functionalities that FreeBSD might need at some point in time.


----------



## vermaden (Aug 25, 2014)

ctaranotte said:
			
		

> That being said, cgroups and namespace are two great functionalities that FreeBSD might need at some point in time.



In what way cgroups are better then FreeBSD's Hierarchical Resource Limits?
https://wiki.freebsd.org/Hierarchical_Resource_Limits


----------



## BSDBernd (Aug 25, 2014)

tankist02 said:
			
		

> PC BSD started Lumina: http://blog.pcbsd.org/2014/04/quick-lumina-desktop-faq/. Maybe this will help?



What I like about that FAQ is the answer to the question of why creating lumina:



> Why create a new desktop environment? Whats wrong with KDE/GNOME/XFCE/<other>?
> Answer: There are many reasons for needing a new desktop environment instead of using the existing ones, mainly because all the major existing DE’s are developed on/for Linux, not BSD. This causes all sorts of problems on BSD, and I am going to try and list a few of the big ones here:
> 
> (4-a) Porting time
> ...


----------



## sulman (Aug 25, 2014)

Crivens said:
			
		

> I think I see the problem we are having here in the thread.
> 
> 
> Your concerns are valid
> ...



systemd May turn out to be the best thing that happened to FreeBSD in a long while.


----------



## ctaranotte (Aug 25, 2014)

vermaden said:
			
		

> ctaranotte said:
> 
> 
> 
> ...



RCTL enforces specific limits on resources while cgroup enforces shares.

EDIT: a modern OS needs both.


----------



## sulman (Aug 25, 2014)

This is a good, brisk read (they're slides) for anyone who likes to feel a bit odd about what exactly FLOS is. http://0pointer.de/public/gnomeasia2014.pdf


----------



## AzaShog (Aug 25, 2014)

I'm sorry, but obligatory XKCD is obligatory: http://xkcd.com/927/.

Unfortunately politics have taken over and forced systemd to almost all major Linux-based distributions, virtually overnight. Time will show that systemd is technically impossible in the land of open source where tiniest ego clashes result with forks and fragmentation and one-system-to-rule-them-all is impossible per those same open source thermo-ego-dynamics. I am actually surprised that so many distros got on board, but I think that's because of marketing and propaganda from Red Hat. I somehow think they all thought they were just voting on a new init system but got backdoored with so many replaced components. And now nobody dares to speak first.... But it'll blow. Soon, the egos will start to clash and decisions will start to get reverted, forks will be thrown around.

I declare 2015 the Year of the Linux Forks. Mark my words.

Oh, we were talking about FreeBSD... Well... *shrug*? It will continue to be FreeBSD, as awesome as ever. I think, I hope, I'm sure.  :beergrin


----------



## CurlyTheStooge (Aug 26, 2014)

One good guy in linuxquestionsdotorg once mentioned, systemd is a result of brilliant C programmer with no idea of the UNIX system administration happens, which I completely agree with. 
I'm not sure if the various Linux distro maintainers didn't know that systemd is not going to be just an init system, Lennart had mentioned it clearly in the beginning that this is going to be a system management tool. We (Slackware guys) haven't still jumped the systemd bandwagon but I have been reading about the systemd architecture and I think that it*'*s a great piece of coding and how the layers of system management has been designed around the core but the problem is, the tools it is replacing were not broken to start with.

Regards.


----------



## Crivens (Aug 27, 2014)

sulman said:
			
		

> systemd May turn out to be the best thing that happened to FreeBSD in a long while.


Only if it stays outside.

systemd has the potential to break Linux apart in a truely epic way, I will not call 2015 the year of the forks (the prophecy is noted, @AzaShog, but IMHO the stars are aligning up even more perfect for Linux as you may think). 

I predict that this movement they pin out in their slides will turn Linux into something of the Titanburg? Hindenic? You get the idea. I will try to get into the position they want it to be, the glue code to connect everything to all the rest - and then they have highjacked all the ecosystem. There will be fights, forks and arguments which will not help FOS or Linux in any way but which will be watched with glee (and some champagne) in Redmond and elsewhere. That is what I totally agree with @AzaShog, but I think that these problems will be stirred and fed quietly and efficiently by interested parties, if not now then soon. It will not stop at forks and arguments. And within one year or two, not only Linux on the desktop will be in shreds but all unix-like systems because all the applications will be in a complete state of fubar. Anyone fancy a three-year rollback to get out of that hole?

Right now I put the possibility of the above around 60%.


----------



## AzaShog (Aug 27, 2014)

Crivens said:
			
		

> I will try to get into the position they want it to be, the glue code to connect everything to all the rest - and then they have highjacked all the ecosystem.



But that's the problem. systemd is not only hijacking, but providing its own versions of important system tools. It's not just a glue. If it were, then I'd have no problem with it. If it used, or patched ntpd for extra data instead of reinventing systemd-timesyncd, it would be a glue. If it did the same to mDNS responding functions, DNS resolving functions, DHCP daemons, ..., by patching for a central "hub" instead of reinventing and rewriting its own versions, I might not have a problem with it. But it goes into the hilarious part of the circus. I read it also implements a light httpd server and now implements its own terminal, vt and will act as a virtualization container/manager as well, I don't know, maybe by consuming or better yet, reinventing docker.

That's really far from being brilliant and good coding, as @CurlyTheStooge mentioned. It would be if it cleverly patched and coordinated existing tools thus leaving room for someone to truly use it as "building blocks", as the PDF linked few posts above wants us to believe, to patch in whatever daemon replacement they needed or wanted.

But, I have the freedom of choice and I've left the GNU/Linux world completely in favor of FreeBSD, both for servers some time ago and now even desktop, primarily for other reasons but systemd is good part of that. I'd have a problem with upstream limiting or removing that choice for me by hard depending on systemd in the future, and that's my only concern about systemd at the moment. Personally I don't think that will ever happen. GNOME is an exception, if it really does end up depending on it more than it's currently hinting at.


----------



## mayak (Aug 27, 2014)

AzaShog said:
			
		

> But, I have the freedom of choice and I've left the GNU/Linux world completely in favor of FreeBSD, both for servers some time ago and now even desktop, primarily for other reasons but systemd is good part of that.



I am also in the process of migrating to FreeBSD. When the Debian initsystem debate began I completely moved to Gentoo. Now I am trying to get into FreeBSD to be prepared. Currently I am rewriting all my Ansible roles to support both Gentoo and FreeBSD. Unfortunately I don't have a choice at work where RHEL/CentOS is dominating...

To the FreeBSD folks: thank you for the clean base system, extensive documentation and good man-pages.

PS. I am also looking forward for the coming pkgng/ports (update-) improvements.


----------



## drhowarddrfine (Aug 27, 2014)

Just to ditto what @AzaShog and @Crivens have said. For the past year or more I've been saying Linux is no longer a Unix-like system and will become just "Linux" and incompatible with everything else to its own detriment.


----------



## nakal (Aug 27, 2014)

You will rather see that Linux won't be incompatible, but FreeBSD will be considered incompatible with Linux and not worth support (see also how nVidia drivers are developed for us). At the end FreeBSD will lack applications. I am on FreeBSD because I like the applications and how they are managed for me (big thanks to all in the FreeBSD ports team). But when applications go away, I will be forced to use Linux. There is no point in having a pretty system that is truly great (and undeniably better than Linux with their userland) , but on which you cannot do your basic work.

At the moment I am not dependent on KDE or Gnome, so this things can disappear without biting me (maybe not all of you agree here), but I still care that there is choice to have FreeBSD under the hood instead of Linux. For the developers of KDE/Gnome freedom of choice does not matter that much. Portable programming using well-know standards is not important, especially for developers who write on desktop software. I doubt that many reasonable developers who create daemons (services) are going to drop support for FreeBSD, but the future of desktop on FreeBSD is unsure at the moment.


----------



## CurlyTheStooge (Aug 27, 2014)

nakal said:
			
		

> You will rather see that Linux won't be incompatible, but FreeBSD will be considered incompatible with Linux and not worth support (see also how nVidia drivers are developed for us). At the end FreeBSD will lack applications. I am on FreeBSD because I like the applications and how they are managed for me (big thanks to all in the FreeBSD ports team). But when applications go away, I will be forced to use Linux. There is no point in having a pretty system that is truly great (and undeniably better than Linux with their userland) , but on which you cannot do your basic work.



^This.

People who are foreseeing a forfeiture/detriment of Linux (as a kernel) are obviously oblivious to the ground reality. A couple of Linux distros might lose some following or a small user base however that certainly will not going to be 'demise' of Linux and sudden rise of FreeBSD. How harsh it is, that seems to be the truth. If FreeBSD didn't gain momentum until now that's for a reason and it will never; it will always be a niche OS as it is. FreeBSD has already been declared incompatible by the Linux guys/hardware vendors on some parts (not in the literate terms). It's the community which is keeping its motors running, which is great.

I'm not the slightest of supporter of systemd as a system management tool, I like my text files as logs but that's not going to change the fact that the managements running the big data centers don't give that much freedom to system architects and administrators and will keep using what comes with a support contract. They don't care if the admins have to learn new things to manage the same system.

Regards.


----------



## AzaShog (Aug 27, 2014)

Doesn't being dependent on systemd mean dropping support for Windows and Mac OSX too? I'm sure a lot of common software might not want that except maybe major desktop environments that are run only on Linux or the "irrelevant" BSDs. For example, I don't see the LAMP stack and its variants going systemd only, beyond using it as init (eg. having a unit file, and maybe dropping daemonization but that's easily patched for FreeBSD). Good portion of developers of LAMP based software are primarily Windows users. I also don't see programming languages dropping portability. Or libreoffice and that class of desktop apps. Graphics applications (gimp, inkscape, ...) are present on Windows as well. Browsers? Aren't the major ones developed on/for Windows primarily? But those are all daemon-less apps that I don't see affected by systemd anyway.

Unless someone upstream makes (g)libc integrated with systemd... which I seriously doubt will ever happen. Or if it does, I seriously doubt that'll make (g)libc-using applications unusable with FreeBSD's libc.

So really, what class of userland applications will benefit by and not lose by, becoming dependent of systemd? Major desktops environments?


----------



## Crivens (Aug 27, 2014)

AzaShog said:
			
		

> Graphics applications (gimp, inkscape, ...) are present on Windows as well. Browsers? Aren't the major ones developed on/for Windows primarily? But those are all daemon-less apps that I don't see affected by systemd anyway.
> ...
> So really, what class of userland applications will benefit by and not lose by, becoming dependent of systemd? Major desktops environments?


The browsers may find themselves in the position that they need to access systemd-networkd for network connections. They might decide that they need to hog your network settings like they do with cgroups, thus sitting in the position to only grant network access to those they like.

You never know. The developers of the browsers will not care, so this would make things interesting for Linux. The benefit of all this would be outside of Linux. Who would benefit from this balkanization of applications? Any ideas? Because it would not be Linux, in the end, and most other free operating systems before that.


----------



## AzaShog (Aug 27, 2014)

Uh, no. systemd-networkd does not work that way, it's just a NetworkManager replacement on steroids (e.g. managing networking dependent devices and targets, if I'm not mistaken). I know you gave just an example, but that's exactly my point. I don't see any reason for applications to integrate with systemd, other than for desktop environments to achieve some kind of deeper integration (e.g. logind requirements). Programs might drop certain functions because systemd provides them instead (e.g. daemonization and/or process management, or virtualization container management), but I think that's easily replaceable under FreeBSD.

I think systemd is such a NIH replacement-o-rama, except of course the init functions and process control, that it can be easily shimmed and that's what OpenBSD's GSoC project is about.

As for hardware vendors dropping FreeBSD compatibility, that's an entirely another story. But that's kernel stuff unless Linus makes systemd a significant part of the kernel. I think hell will freeze over twice before that happens.


----------



## drhowarddrfine (Aug 27, 2014)

nakal said:
			
		

> You will rather see that Linux won't be incompatible, but FreeBSD will be considered incompatible with Linux and not worth support


What I'm seeing now is what was brought up earlier, the fighting and fragmentation and complaining and splintering, etc. That is how I see as being detrimental to Linux. Already we have seen a number of Linux users talking of how they're tired of it all, here and many other forums, and switching to BSD where things seem more stable and level headed. Which leads me to another point. 

The "Windows-fication" of Linux. Part of their issue is the influx of Windows users who want Linux to be a free version Windows. This has led to many of the fights between those looking for technical excellence versus "candy". 

But I don't want to get off on that.


----------



## radish (Aug 28, 2014)

Even with Systemd I will probably move back to Linux if all of the basic productivity tools on FreeBSD vanish. Though that has not happened yet, and might not ever. The quality of the project was enough to convince me to switch to it. Granted I am not a normal use case, I switched because I like SCHED_ULE(4) and find it superior to cfs/bfs from Linux.


----------



## dpejesh (Aug 28, 2014)

systemd is irrelevant to FreeBSD as far as I'm concerned. If you've been paying attention you'll have noticed systemd isn't about just improving init. It's about absorbing everything it possibly can and turning itself into a monolithic userspace kernel (MUK?  Pokemon anyone?) which controls everything on the system. You will no longer have utilities which communicate with the kernel, you'll have systemd specific tools which talk dbus to systemd to do those same tasks.

The goal is clear, the systemd developers want it to be the gatekeeper of userspace. The problem with it is that it's nothing more than an undocumented, standardless, hackjob with the backing of one of the biggest players in the Linux world (RedHat) which will only benefit them, with the added long-term goal of creating vendor lock-in. How long until they decide it's going to handle package management and require RPM? How long until they start signing services and packages and locking you out from using your own unless it's signed by them? How long until they start implementing ways of preventing Oracle from basing their Linux distribution off it, and everybody else for that matter? How long until the Linux kernel itself becomes so hardwired to it that the two will be indistinguishable and we'll just have RedHat systemd/Linux and that's it, for which the motto will be "you can have any Linux you want as long as it's systemd." The possibilities they now have is scary to think about and what they'll end up doing with it, especially once more and more distributions give up trying to fight it, effectively giving RedHat even more control.

It might sound far fetched, especially 10 years ago when there was so many Linux distros and so many different people maintaining their own projects independently to provide the various pieces of userspace which systemd has now hijacked, that trying any of that would have been suicide. Now that they've gained so much influence and control over the entire ecosystem is it worth trusting them; especially after you read the lies, misinformation, and straight up bullshit on the systemd mailing lists from the lead developers? Sure it's GPL and you have the source to do what you want with, but when every piece of it is intertwined and a confusing mess of shit code with a nefarious motive the barrier to rip out the pieces you don't want, or use only the small pieces you do want elsewhere, or manage your own fork will negate the time and money to do so. I'd love to see how Stallman tries to make a GPLv4 to counter it once he realizes what's happening, but at the end of the day they're playing by the GPL rules.

Should any of the BSDs care? Nope. Let them destroy the foundation which made Linux great and turn it into a product owned and controlled by one company with the sole purpose of making a profit, and the BSDs will continue happily down their own path cherry picking the few things systemd does right, if there are any.


----------



## Crivens (Aug 28, 2014)

We should not hope for the demise of Linux, for a simple fact. Should that happen, a lot of contributors will look for new playgrounds. And whoever watched the mailing lists and forums associated with *buntu, for example, should consider the consequences of these coming here.

In the short run, Redhat will profit from this. But I think they will suffer in the long run. As will we.


----------



## zspider (Aug 29, 2014)

Crivens said:
			
		

> We should not hope for the demise of Linux, for a simple fact. Should that happen, a lot of contributors will look for new playgrounds. And whoever watched the mailing lists and forums associated with *buntu, for example, should consider the consequences of these coming here.
> 
> In the short run, Redhat will profit from this. But I think they will suffer in the long run. As will we.



Indeed, that would not be good. At the very least the quality of the project would probably drop like a rock, that would be a deal breaker for me and I imagine many others.


----------



## sulman (Sep 5, 2014)

AzaShog said:
			
		

> But that's the problem. systemd is not only hijacking, but providing its own versions of important system tools. It's not just a glue. If it were, then I'd have no problem with it. If it used, or patched ntpd for extra data instead of reinventing systemd-timesyncd, it would be a glue. If it did the same to mDNS responding functions, DNS resolving functions, DHCP daemons, ..., by patching for a central "hub" instead of reinventing and rewriting its own versions, I might not have a problem with it. But it goes into the hilarious part of the circus. I read it also implements a light httpd server and now implements its own terminal, vt and will act as a virtualization container/manager as well, I don't know, maybe by consuming or better yet, reinventing docker.





			
				dpejesh said:
			
		

> How long until they decide it's going to handle package management and require RPM? How long until they start signing services and packages and locking you out from using your own unless it's signed by them? How long until they start implementing ways of preventing Oracle from basing their Linux distribution off it, and everybody else for that matter? .



Think bigger. Much bigger. They want to containerise the whole caboodle.

The future? Read it and weep.

They want to eliminate the distro ecosystem in all but name. What is the point of all this otherwise? It's technically very impressive, but I cannot understand what problem it is solving.


----------



## bthomson (Sep 6, 2014)

I for one am very grateful to systemd. It convinced me to finally migrate my desktop to FreeBSD, which turned out to be a great decision.

I'm sure I'm not the only "systemd refugee" here.


----------



## drhowarddrfine (Sep 7, 2014)

bthomson said:
			
		

> I for one am very grateful to systemd. It convinced me to finally migrate my desktop to FreeBSD, which turned out to be a great decision.
> 
> I'm sure I'm not the only "systemd refugee" here.


You're not. There are tons as I noted earlier.


----------



## pkubaj (Sep 7, 2014)

Tons if you count how many FreeBSD users there were before the rise of systemd, but if you look at it globally, FreeBSD isn't even noted in Netmarketshare's statistics of desktop operating systems market share. Last I browsed http://www.netmarketshare.com/operating ... pcustomd=0, FreeBSD was at 0.01%, now it's not even in statistics. And Linux has actually risen, it was like 1% before. See e.g. here http://www.netmarketshare.com/operating ... imeframe=Y. Not only is FreeBSD in there, but also Solaris. Now they're gone.
EDIT: Now that I think about it, I've also seen more BSD topics at https://boards.4chan.org/g/, but it's hardly a measure.


----------



## drhowarddrfine (Sep 7, 2014)

@pkubaj, you are confusing market share with "number of people who have moved to FreeBSD". There are tons of ex-Windows users who want a free ride and have jumped on the Linux band wagon now that there are easier to install distros. Let Linux have 'em. That takes nothing away from the scores of people I see every day coming to FreeBSD boards/forums/subreddits who say, "I'm coming from Linux cause I'm sick of [insert systemd, fragmenting, etc.]"; something I had rarely seen until the past year or so which is the point I made earlier. These are generally not people who are just looking for a Windows replacement.

There are also a ton of ex-Windows users who have found that the web world has gone mobile and Microsoft does not exist in that arena so it's far more natural to switch to a Unix-like system. All their friends are on Linux so that's where they go without technical consideration. I'll pat myself on the back for giving that some thought 10 years ago when my brother-in-law, a manager of a large Microsoft shop, told me to use Linux for my business. Instead, I gave it some thought and went for what I considered to be the better technical choice and signed up for FreeBSD. 

I have never regretted that choice.


----------



## pkubaj (Sep 7, 2014)

drhowarddrfine said:
			
		

> @pkubaj, you are confusing market share with "number of people who have moved to FreeBSD". There are tons of ex-Windows users who want a free ride and have jumped on the Linux band wagon now that there are easier to install distros. Let Linux have 'em. That takes nothing away from the scores of people I see every day coming to FreeBSD boards/forums/subreddits who say, "I'm coming from Linux cause I'm sick of [insert systemd, fragmenting, etc.]"; something I had rarely seen until the past year or so which is the point I made earlier. These are generally not people who are just looking for a Windows replacement.
> 
> There are also a ton of ex-Windows users who have found that the web world has gone mobile and Microsoft does not exist in that arena so it's far more natural to switch to a Unix-like system. All their friends are on Linux so that's where they go without technical consideration. I'll pat myself on the back for giving that some thought 10 years ago when my brother-in-law, a manager of a large Microsoft shop, told me to use Linux for my business. Instead, I gave it some thought and went for what I considered to be the better technical choice and signed up for FreeBSD.
> 
> I have never regreted that choice.


FreeBSD's market share alone isn't a measure of a number of people who have moved to FreeBSD, but its difference with FreeBSD's market share from a year before is. And the fact is that in 2009 0.01% of desktop users used FreeBSD, and now, since FreeBSD doesn't appear in statistics, there are less. There's a catch though, because it's not a number of people but percentage, so the number of users is probably larger than in 2009, but, since new users are less than 0.01% of all new computer users, the overall percentage is smaller.
I think FreeBSD will survive anyway, OpenBSD has much smaller market share but it's still here. I can see FreeBSD's development is speeding up, since at 9.0 it was much more behind Linux in many areas (not only desktop but also virtualization etc.).


----------



## drhowarddrfine (Sep 8, 2014)

What you are talking about still has nothing to do with what I said, and the rest of your post is wrong, but I will leave you with that and won't comment further.

btw, mods, shouldn't this be in the off-topic area? systemd has nothing to do with FreeBSD.


----------



## CurlyTheStooge (Sep 8, 2014)

By the way, taking FreeBSD or any other BSD for a spin and studying it doesn't mean suddenly system administrators are leaving Linux kernel behind and becoming refugee. There are way many options in the Linux world *still*. Slackware with their sysvinit and CentOS 6.x are not going anywhere for next *couple* of years and a regular system admin will weigh everything down before jumping the ship. Sure, I like my logs files in text format but we'll see.

Dear drhowarddrfine made a claim in some another thread of *huge number of* gamers coming to FreeBSD looking for an alternate, I'm still not sure what does that even mean and where's the data to back that claim? How does that even matter for a gamer if its systemd or BSD style rc scripts in the background, if his/her games are available and working fine? (Please spare me the PS4 having some sort of customized FreeBSD argument, that's not desktop gaming)

Regards.


----------



## pkubaj (Sep 8, 2014)

CurlyTheStooge said:
			
		

> By the way, taking FreeBSD or any other BSD for a spin and studying it doesn't mean suddenly system administrators are leaving Linux kernel behind and becoming refugee. There are way many options in the Linux world *still*. Slackware with their sysvinit and CentOS 6.x are not going anywhere for next *couple* of years and a regular system admin will weigh everything down before jumping the ship. Sure, I like my logs files in text format but we'll see.
> 
> Dear drhowarddrfine made a claim in some another thread of *huge number of* gamers coming to FreeBSD looking for an alternate, I'm still not sure what does that even mean and where's the data to back that claim? How does that even matter for a gamer if its systemd or BSD style rc scripts in the background, if his/her games are available and working fine? (Please spare me the PS4 having some sort of customized FreeBSD argument, that's not desktop gaming)
> 
> Regards.


There are still some distros that use traditional init, and it's not only Slackware are CentOS 6. There's also CRUX and Gentoo doesn't use systemd by default and even when it's default, like in Debian 8, there are options to switch to something else (https://wiki.debian.org/OpenRC).


----------



## CurlyTheStooge (Sep 8, 2014)

pkubaj said:
			
		

> There are still some distros that use traditional init, and it's not only Slackware are CentOS 6. There's also CRUX and Gentoo doesn't use systemd by default and even when it's default, like in Debian 8, there are options to switch to something else (https://wiki.debian.org/OpenRC).



That's exactly my point. I quoted the distors which I use on daily basis and will keep using in foreseeable future. I'm not following Gentoo at this moment but I know their developers are working on a replacement of Udev, eudev or that's extracted udev.

Regards.


----------



## kpa (Sep 8, 2014)

Gamers are not going to care whether the system uses systemd or not, if it works they will use it to play games. If it doesn't, it's going to the trash bin. Simple as that. You wonder why OS X has recently become a very viable gaming platform? Make a guess (and no the answer is not launchd alone).


----------



## obsigna (Sep 8, 2014)

kpa said:
			
		

> ... (and no the answer is not launchd alone).



Comparing launchd with systemd is like comparing apples with penguins.

launchd restricts itself to the mere task of launching processes and maintaining these running, and the processes do not need any interface to launchd, and continue to not need to know by whom they were launched.

systemd wants to be the super-controller of everything what's running while running, and it expects "well behaved" processes communicating their status with it.

launchd is slim, systemd is bloated and carcinogen.


----------



## kpa (Sep 8, 2014)

obsigna said:
			
		

> kpa said:
> 
> 
> 
> ...



I was predicting someone would make that comparison (or rush to tell everybody how wrong it is) if I start talking about OS X, hence my remark. Hook line and sinker  :OO


----------



## drhowarddrfine (Sep 8, 2014)

CurlyTheStooge said:
			
		

> Dear drhowarddrfine made a claim in some another thread of *huge number of* gamers coming to FreeBSD looking for an alternate, I'm still not sure what does that even mean and where's the data to back that claim?


*I made no such claim.*  I said gamers and Windows users were moving to Linux. I also said Linux users were *moving to FreeBSD*, not just "taking it for a spin". viewtopic.php?f=3&t=46667&p=267702#p266926 and others


----------



## CurlyTheStooge (Sep 8, 2014)

drhowarddrfine said:
			
		

> CurlyTheStooge said:
> 
> 
> 
> ...



I meant this thread and this post :-
viewtopic.php?f=15&t=47858#p267518

I resisted my self from commenting off topic there for some reason. I don't understand why would a Linux gamer be looking for and what in BSD world considering they are Linux gamers and are aware of all the ground realities of open source gaming?

Regards.


----------



## drhowarddrfine (Sep 8, 2014)

Even in that post I said most were sysadmins and that, yes, unfortunately some gamers were taking FreeBSD "for a test spin", as you said, but my point is there are a lot of people moving to FreeBSD from Linux over the systemd thing.


----------



## uzsolt (Sep 9, 2014)

http://www.openbsdfoundation.org/gsoc2014.html#systemd
https://www.google-melange.com/gsoc/pro ... 4879778816


----------



## Crivens (Sep 9, 2014)

uzsolt said:
			
		

> http://www.openbsdfoundation.org/gsoc2014.html#systemd
> https://www.google-melange.com/gsoc/pro ... 4879778816


On the one side it is good that it seems to be possible to have some shims to come around this. But on the other hand - that does not make it OK! Simply being able to work around it is not the solution for this. Good to know that, if needed, it can be done. But it will always be a race after the next thing that is cooked up "over there".


----------



## ctaranotte (Oct 2, 2014)

userlessd (see http://uselessd.darknedgy.net/) is a fork of systemd without some of the controversial features.



> What version of systemd is uselessd based on?
> 
> systemd-208-stable. We chose this, because it predates kdbus integration into PID1, the sd-bus API, networkd and a whole host of other cruft that has been growing quite profusely since then. Most baffling has been the recent inclusion of prerequisites for moving in kmscon, as well as the addition of a graphics card device access layer.



And 



> What is this about FreeBSD you say?
> 
> uselessd is planned to work as a primitive stage 2 init (process manager) on FreeBSD. Stage 1 is inherently unportable requires a total overhaul in regards to low-level system logic (with systemd assuming lots of mount points and virtual file systems that aren’t present, is designed with an initramfs in mind and many other things). Stage 3 can always be achieved by having a sloppy shim around the standard tools like shutdown, halt, poweroff, etc.



That's better than nothing I guess :OOO


----------



## vermaden (Oct 2, 2014)

ctaranotte said:
			
		

> userlessd (see http://uselessd.darknedgy.net/) is a fork of systemd without some of the controversial features.



Fork of sh!t is still sh!t


----------



## Crivens (Oct 2, 2014)

ctaranotte said:
			
		

> userlessd (see http://uselessd.darknedgy.net/) is a fork of systemd without some of the controversial features.
> 
> 
> 
> ...



(Emphasis mine)  Holy FSCK. In about 2 years from now, systemd will be a quite usable operating system. It will only lack a decent init system. Maybe the emacs folks could provide these chaps with a nice init.elc file? Seriously, that thing will collapse into a /dev/blackhole soon.

And I have to agree to @vermaden, no matter where you fork this - it is still wrong. You may end up fixing some of the dependencies, but sooner than later some dependencies will come around which need the latest "cool thing" from systemd. And then all this starts again. I was "impressed" when I checked what bash did on my system and who thinks that depending on a shell as a run-time dependency was a good idea.

My vote in this matter would be, when we look at the original question : avoid it, lobby upstream to avoid dependencies, provide solutions to the rest of the open source landscape. Should there be a GSOC project porting devd to Linux? Why not? It could be interesting. But fight it, in the name of sane software design.


----------



## jrm@ (Oct 2, 2014)

Crivens said:
			
		

> Maybe the emacs folks could provide these chaps with a nice init.elc file?


I grasp that this is tongue-in-cheek, but why state your disdain for apples when we're talking about oranges?  In the case of Emacs, no one is forcing anything down our throats. There are no forced dependencies on CUPS, D-BUS, HAL or PulseAudio and when it's released there is no major porting process because it just works on FreeBSD.

Edit: Minor updates without changing meaning


----------



## Crivens (Oct 2, 2014)

jrm said:
			
		

> Crivens said:
> 
> 
> 
> ...


The point with emacs was the old joke about /vmunix.elc, pointing at the excessive feature set of emacs. The only bad thing about emacs I can now remember is the dropping of ctrl-alt-backspace as X11 killswitch due to being pressed by emacs users by accident. I do not use emacs myself as I think it will need a lot of efford to get it tuned to my taste. But I tip my hat to those who use emacs on a regular base and who have invested the time to learn it. Also, I do not think that the design of emacs suffered with the growing feature set - and that is something that might be a problem to come for systemd and Linux.


----------



## scottro (Oct 2, 2014)

Actually, I thought the joke was aimed at the old statement


> Emacs is a great operating system.  If only it had a decent  text editor



And while not relevant here, the other one that used to make me laugh 


> I tried to learn emacs but then decided to learn a simpler operating system


----------



## drhowarddrfine (Oct 3, 2014)

scottro said:
			
		

> And while not relevant here


I don't see any elephants either but I don't know what elephants have to do with anything. Maybe I'm misunderstanding something.


----------



## ctaranotte (Oct 3, 2014)

vermaden said:
			
		

> ctaranotte said:
> 
> 
> 
> ...



I agree the execution has been crap so far but there are some good ideas on virtualization in systemd. 

Just read the statement of the devs behind usslessd.


----------



## vermaden (Oct 3, 2014)

ctaranotte said:
			
		

> there are some good ideas on virtualization in systemd.
> 
> Just read the statement of the devs behind usslessd.



Which part?


----------



## Oko (Oct 5, 2014)

vermaden said:
			
		

> ctaranotte said:
> 
> 
> 
> ...


+1 P  I extensively tested Red Hat 7 and my final verdict is that if vendor support for FreeBSD get just little bit better you will see massive exodus of enterprise users from Linux to FreeBSD. Porting HAMMER and getting bhyve production ready will nail it for FreeBSD. Now tell us little bit about Dockers aka Jails which FreeBSD has circa 2000 and non functional OpenLMI and PCP crap.


----------



## AzaShog (Oct 5, 2014)

Oko said:
			
		

> Now tell us little bit about Dockers aka Jails which FreeBSD has circa 2000 and non functional OpenLMI and PCP crap.



No, Docker is not a.k.a jails. Jails are comparable to LXC. Docker is "comparable" to ezjails. And if we do want to attract the enterprise users, some terms and comparisons then have to be used properly. Because then you'll see that Docker is far more advanced than anything FreeBSD has got right now.  :beergrin


----------



## Oko (Oct 5, 2014)

AzaShog said:
			
		

> Oko said:
> 
> 
> 
> ...


Ok Docker is not a Jail it is a Linux version of Warden which was introduced 5 years ago in PC-BSD and now has matured in CLI tool for TrueOS. That doesn't change the fact that Linux is getting LXC 20 years after Solaris had zones and 14 years after BSD had Jails. Which technology you think I am going to trust   :q


----------



## AzaShog (Oct 5, 2014)

Oko said:
			
		

> Which technology you think I am going to trust   :q



That might work for you very well. But age is hardly the only, or *a* factor at all for enterprises currently using the Linux ecosystem and *seeing* FreeBSD as irrelevant because there is nothing their current setups cannot do that FreeBSD can, and time & money required for the switch are absolutely not paying off eventual benefits gained. There's another factor that is, unfortunately, winning, and that's the fact that there are orders of magnitude more people using, fixing and coding new features for the Linux virtualization subsystems, Docker included. There will hardly be any mass exodus over systemd, between Linux distros let alone toward the BSDs. The group against systemd in the Linux ecosystem is very vocal, but unfortunately in significant minority.


----------



## jb_fvwm2 (Oct 5, 2014)

I would not be so certain... I can imagine that paragraph posted in a Linux forum resulting in several users and maybe even some datacenter managers proceeding to google "this vs that" -- and as a result moving their machines over to FreeBSD... the only thing stopping that now being the idea of an alternative, as in "FreeBSD?  it has a forum even? "


----------



## AzaShog (Oct 5, 2014)

jb_fvwm2 said:
			
		

> I can imagine that paragraph posted in a Linux forum resulting in several users and maybe even some datacenter managers proceeding to google "this vs that" -- and as a result moving their machines over to FreeBSD... the only thing stopping that now being the idea of an alternative, as in "FreeBSD?  it has a forum even? "



I'm assuming you're referring to my paragraph. But perhaps you are not familiar how enterprises work. I'm pretty sure nobody is going to "move over their machines to FreeBSD" just because they read something in a forum, or blog post, unless their business does not depend on a stable and well understood environment. They might "fire up FreeBSD alongside their existing ecosystem" to see what is it all about. That's what we're doing.

We are a small company, delivering some SaaS solutions and managed hosting, few dozen servers, nothing big. We are running FreeBSD for a year now alongside existing Debian, Ubuntu, CentOS and Gentoo installations because we're testing and trying it out. We are certainly not going to base any decision without extensive testing and strategic planning. It's not just installing and using the system. We have tools, configuration templates and systems, monitoring, failover and redundancy, all tailored for the systems we use, all requiring change of some kind in order to "switch". I can imagine much bigger companies having even more resistance, testing requirements and above all paperwork, to change.

Above all, our testing for our use cases is telling us we can't switch.

Linux is faster for us because of PostgreSQL regression on FreeBSD 10. We're a PostgreSQL shop. Linux is more secure for us because we run well documented and understood SELinux and AppArmor, and the Linux kernel has had for years some security features (like ASLR) that are yet to come in FreeBSD (10.1), and MAC/RBAC on FreeBSD is completely unknown to us and pretty much undocumented. Linux as a distro with supported non-base software is more stable for us because it is stabilized by many, many people before release and there is much less work for us to test and deploy updates as opposed to FreeBSD ports which are moving as fast as a rolling Linux distro would, which requires far more testing, more manpower, build servers, staging/testing servers, etc... We're a Python shop and our software is grown on Debian 7 with Python 2.7.3, while on FreeBSD the 2.x branch is 2.7.8. Now, believe it or not, we can't switch without changing the code because some bugs were fixed and some features introduced between those two versions that is breaking our code on FreeBSD. That, of course, is *absolutely not* FreeBSD's fault, I'm just trying to show that there are many unforeseen problems and "switching over" is not just a matter of firing up a new VPS... Which in itself would also be a problem because our hosting company is not supporting FreeBSD. And if you've been in the web hosting industry as a consumer of hosting services as long as we have, you'd know that once you settle with a hosting company that works for you, finding another (that might support FreeBSD) is a nightmare that also requires many months of testing under various circumstances to see how they fare.

We can use Debian 7, Ubuntu 14.04 LTS, CentOS 6.x for years to come without having to violate our systems with systemd, and I'm pretty sure our clients would like us NOT to change anything in that department without significant amount of objective reason. We will continue to use FreeBSD in parallel and test it, perhaps there are use cases and scenarios which we haven't yet encountered that would significantly swing the opinion over for the switch.

Don't get the above as something against FreeBSD. Quite the contrary, despite all that, we continue to use FreeBSD in testing. I'm just trying to paint the picture how "switching over to FreeBSD" is far easier said than done. I'm sure the bigger the enterprise, the bigger the inertia toward any kind of change. So no, I don't see any mass exodus happening over systemd to anything - another Linux or BSDs.


----------



## Oko (Oct 5, 2014)

AzaShog said:
			
		

> I'm assuming you're referring to my paragraph. But perhaps you are not familiar how enterprises work. I'm pretty sure nobody is going to "move over their machines to FreeBSD" just because they read something in a forum, or blog post, unless their business does not depend on a stable and well understood environment. They might "fire up FreeBSD alongside their existing ecosystem" to see what is it all about. That's what we're doing.


I concur!



			
				AzaShog said:
			
		

> We are a small company, delivering some SaaS solutions and managed hosting, few dozen servers, nothing big. We are running FreeBSD for a year now alongside existing Debian, Ubuntu, CentOS and Gentoo installations because we're testing and trying it out. We are certainly not going to base any decision without extensive testing and strategic planning. It's not just installing and using the system. We have tools, configuration templates and systems, monitoring, failover and redundancy, all tailored for the systems we use, all requiring change of some kind in order to "switch". I can imagine much bigger companies having even more resistance, testing requirements and above all paperwork, to change.


The same here. A small academic lab couple of dozen physical servers, two dozen virtual, and abut 2-3 dozen of desktop machines. It took me a year to rebuilt it after taking over the infrastructure which was falling apart. Even though I had complete freedom to do anything I want it was difficult working around whatever existed because people had to continue doing their work. They were also got used to some things and taking those things away was as difficult as taking a candy from a my own kids.



			
				AzaShog said:
			
		

> Above all, our testing for our use cases is telling us we can't switch.


+1 Being an ardent OpenBSD users it was easy to switch entire existing network infrastructure (Firewalls, DNSs, LDAPs, monitoring, shell gateways, and few other things to OpenBSD). Linux has nothing worth looking in that domain. Then I start thinking about switching storage space to either FreeBSD/FreeNAS or DragonFlyBSD. I did lots of testing in-spite of the fact that DragonFlyBSD is very dear to my heart and I used to work with FreeBSD a lot in the past. One of the hardest thing to admit was that DragonFlyBSD is not usable in production even in a small shop. One great (arguably the best) file system is not enough reason to compensate for the lack of basic infrastructure elements (LDAP client not working), lack of basic monitoring tools and a friendly, knowledgable but tiny community which lacks critical mass. FreeNAS and FreeBSD on another hand prove to be worthy adversary to Linux as a data storage OS and I switch all but one well configured file servers from Red Hat to FreeNAS. There was just no incentive to spend 2-3 days messing with it as Red Hat was working well enough on the hardware RAID. Then I start looking at the virtual hosts and due to the fact that our primary guest OS is Linux (due to heavy use of Java in our proprietary product) two days of testing VBox and half a day of reading about the state of Bhyve was enough to realize that we are KVM do or die shop. Computing nodes, desktops and similar was an easy decision. I need MATLAB to work. MathWorks doesn't support MATLAB for FreeBSD. That was it.    



			
				AzaShog said:
			
		

> Linux is faster for us because of PostgreSQL regression on FreeBSD 10. We're a PostgreSQL shop. Linux is more secure for us because we run well documented and understood SELinux and AppArmor, and the Linux kernel has had for years some security features (like ASLR) that are yet to come in FreeBSD (10.1), and MAC/RBAC on FreeBSD is completely unknown to us and pretty much undocumented.


Coming with the OpenBSD background I have a very low opinion of MAC as a general idea and even lower opinion as a practical idea but I will take your word it. On my key network infrastructure points I am happy to settle with the OS which has a code base smaller of order 20-30 times than Linux. Somehow makes me feel there are  fewer bugs in the 30 times smaller code base  



			
				AzaShog said:
			
		

> Linux as a distro with supported non-base software is more stable for us because it is stabilized by many, many people before release and there is much less work for us to test and deploy updates as opposed to FreeBSD ports which are moving as fast as a rolling Linux distro would, which requires far more testing, more manpower, build servers, staging/testing servers, etc...


You are not serious about this one  §e ? Red Hat 7.0 formally came in June. There are still no EPEL RPMs released for it. QA is pitta comparing to OpenBSD. While I concur that FreeBSD 10.0 feels little bit like a ride on the wild side at least it has 24000 ports comparing to 0 RPMs for Red Hat 7.0. 9.3 is definitely very stable just like the Red Hat 6.5 which we use.



			
				AzaShog said:
			
		

> We're a Python shop and our software is grown on Debian 7 with Python 2.7.3, while on FreeBSD the 2.x branch is 2.7.8. Now, believe it or not, we can't switch without changing the code because some bugs were fixed and some features introduced between those two versions that is breaking our code on FreeBSD. That, of course, is *absolutely not* FreeBSD's fault, I'm just trying to show that there are many unforeseen problems and "switching over" is not just a matter of firing up a new VPS... Which in itself would also be a problem because our hosting company is not supporting FreeBSD.


 We are Python shop as well. I can't believe what you just said. If you proprietary code brakes from 2.7.3 to 2.7.8 you have much bigger problem than picking an OS for your shop. Red Hat 7.0 ships with 2.7.5 and I am sure by the first "usable" 7.1 or 7.2 release it will updated to 2.7.8. My main grudge with Red Hat 7.0 is systemd. It is not so much that breaks my services and chkconfig routine (finally I am relative new comer to Linux using True64, Solaris and  BSDs circa 1990)
but the crappy systemd code and 0 absolute 0 quality assurance for such  a monumental and profound change how the system works is frightening. We will certainly not switch to 7 branch until the end of life of Red Hat 6 branch and if FreeBSD gets Java (somebody told me that foundation signed the contract with Oracle and possibly MATLAB) we will most definitely switch to FreeBSD. I would really, really like to see HAMMER ported to FreeBSD too. I still hope that Red Hat gets to its senses and just remove systemd. 



			
				AzaShog said:
			
		

> And if you've been in the web hosting industry as a consumer of hosting services as long as we have, you'd know that once you settle with a hosting company that works for you, finding another (that might support FreeBSD) is a nightmare that also requires many months of testing under various circumstances to see how they fare.
> 
> We can use Debian 7, Ubuntu 14.04 LTS, CentOS 6.x for years to come without having to violate our systems with systemd, and I'm pretty sure our clients would like us NOT to change anything in that department without significant amount of objective reason. We will continue to use FreeBSD in parallel and test it, perhaps there are use cases and scenarios which we haven't yet encountered that would significantly swing the opinion over for the switch.


Couple hard core UNIX users could definitely sway opinion in your company. I find an average Linux system admin completely ignorant of UNIXes (Solaris, AIX, HP, BSDs). Customers are another story and I find them very prone to PR propaganda. I put monumental fight to keep away Ubuntu and Debian away from our shop and typical line of attack against Red Hat was always "it has older kernel" and "packages are outdated". Nothing of course can be further from the truth as Red Hat heavily back ports their kernels and people who know little bit about RPMs run the same versions of software on RedHat as on Ubuntu or Debian. 



			
				AzaShog said:
			
		

> Don't get the above as something against FreeBSD. Quite the contrary, despite all that, we continue to use FreeBSD in testing. I'm just trying to paint the picture how "switching over to FreeBSD" is far easier said than done. I'm sure the bigger the enterprise, the bigger the inertia toward any kind of change. So no, I don't see any mass exodus happening over systemd to anything - another Linux or BSDs.



I wish I could say the same for DragonFlyBSD. I will wait to see what comes out of HAMMER2 but speaking of HAMMER my only hope for production use is that it gets ported over to FreeBSD. That dma and Sasha's work on kernels in the userland will be nice too


----------



## AzaShog (Oct 5, 2014)

Oko said:
			
		

> You are not serious about this one  §e ? Red Hat 7.0 formally came in June.



Having run several distros, and now with FreeBSD, in parallel for years, yes, I'm dead serious. RHEL 7 might have been just released, but we don't use RHEL, and CentOS 6 that we do (because clients require it) is several years old now since its pre-release feature freeze. The same applies to Debian 7 and Ubuntu 14.04 LTS. All those systems are feature-frozen and well tested by many, many people before we run our own tests. And this includes non-base software. What those systems guarantee between releases is that major version changes in software will not happen. That change in the configuration files, if any at all, *will be* backwards compatible and not required.

Just an example of how this is important and how this bit us on Gentoo (meaning FreeBSD's ports are sensitive to this issuse too). A company we managed the systems for was running some software based on ImageMagick. Some image processes broke because Gentoo upgraded ImageMagick, which changed default blurring parameter constants in the new (major) version, which wasn't caught by automated tests because no software or API was broken. It was caught many weeks later. That would never have happened on a non-rolling release distro because you test the new release from all the angles for weeks/months anyway. It just physically can't be done on a rolling release distro.



> I can't believe what you just said. If you proprietary code brakes from 2.7.3 to 2.7.8 you have much bigger problem than picking an OS for your shop.



I never said we didn't. It's a known bug that is going to be fixed. I was just giving an example how totally unexpected situations may arise and switching over to another OS is far from trivial. It takes months of testing, rewriting your standard procedures, utility tools and above all re-training or hiring new manpower for something like switching from a Linux to a BSD.


----------



## RichardET (Nov 20, 2014)

Is systemd still an issue with FreeBSD? It is a hot potato topic on forums like OpenSUSE, or Ubuntu, because both distributions have drunk the Kool-Aid.


----------



## sulman (Nov 20, 2014)

RichardET said:


> Is systemd still an issue with FreeBSD?  It is a hot potato topic on forums like openSUSE, or Ubuntu, because both distributions have drunk the kool-aid.



It's only relevant if it breaks upstream ports due to dependencies, and there's an increasing groundswell working to mitigate that. I think the wheels will fall off the systemd juggernaut soon. It's expanding far too aggressively, with little scope or specification, and it will surely start to fail under its own complexity.


----------



## NewGuy (Nov 25, 2014)

Agreed, systemd is likely to have very little impact on FreeBSD, especially server instances. I could see it affecting a handful of ports desktop users like (especially software related to GNOME), but I don't think it is going to be a big issue. For most things we can port around systemd or put compatibility libraries in place.

By the way, I entirely agree with AzaShog. FreeBSD is a great operating system, but it is a big undertaking moving from one operating system (like CentOS, Debian or Ubuntu) to another. I work in a small tech shop and spent months testing and running trials. Eventually we found we could switch to FreeBSD 10.0, but it would require a number of changes and setting up FreeBSD with the services we needed took a lot longer than setting up the same environment with Debian/Ubuntu. And then FreeBSD 10.1 came out and stopped working on one of our servers, so upgrading was a dead end. And we're a small shop, fairly flexible. An enterprise level company is going to stick with the idea of "it's not broke, don't fix it".


----------



## zirias@ (Nov 26, 2014)

NewGuy said:


> An enterprise level company is going to stick with the idea of "it's not broke, don't fix it".


And that's a good policy for production systems. I'm working in a shop using Microsoft .NET for everything and that's ok, it's a decent framework allowing for a lot of rapid development.

For my private boxes though, I always used Debian GNU/Linux, as it's free (although, unfortunately, NOT like in "beer" *g*), manageable (even in spare time) and does everything I need. In fact, systemd was THE issue bringing me here¹ ... having my share of pain with pulseaudio and seeing another big moloch by the same author on its quest to conquer and assimilate systems -- I thought it was about time to try something different. FreeBSD came to mind immediately. My very first project is getting my notebook operated using FreeBSD, as it is not a critical system. I'm struggling with wifi connection at the moment, I already bought a mini-pcie card that should be supported, but I'm facing kernel panics. Not giving up right now, though. My notebook is undergoing a `make buildworld` from svn right now....

Me, too, I don't think systemd will become a huge problem for FreeBSD. Although it looks like GNOME doesn't care much about portability any more, KDE certainly does, and hopefully a lot of other desktop software. Hard systemd dependencies are probably only an issue with desktops and maybe they will come down to only systemd-logind, which means that in the long run, a service on FreeBSD could be needed implementing the dbus interface of systemd-logind for some of the desktop-related ports. Of course I can't know for sure without looking at this interface, but my impression ist: Can't be TOO hard.

¹ That could be interpreted as a (strange) way of systemd actually helping FreeBSD and other *BSDs (by increasing their user base), at least when I'm not the only one looking for Linux alternatives because of systemd.


----------



## drhowarddrfine (Nov 26, 2014)

Zirias said:


> That could be interpreted as a (strange) way of systemd actually helping FreeBSD and other *BSDs (by increasing their user base), at least when I'm not the only one looking for Linux alternatives because of systemd.



For quite a number of months I have posted on Reddit that I noticed this where I would get downvoted into oblivion and made fun of that this isn't happening at all. (Not that I value the opinions or votes of Reddit. It's one of two times I ever posted there.)


----------



## kurld (Nov 26, 2014)

What strikes me about those systemd topics (and this board in general) is the amount of attention the BSD community gives to Linux. What's going on here - Stockholm Syndrome maybe. At this point systemd is a mess but _end of life _of RHEL/CentOS 6 and SLES 11 is somewhere in mid 2020s (other distros are as irrelevant as BSD in the enterprise area). So no - there won't be any massive movement toward BSD, at least not in the next few years (I'm not talking about basement deployments of a LAMP stack here). And then, I've never heard about anyone switching from AIX just because he did not like ODM.


----------



## pkubaj (Nov 26, 2014)

kurld said:


> What strikes me about those systemd topics (and this board in general) is the amount of attention the BSD community gives to Linux. What's going on here - Stockholm Syndrome maybe.
> At this point systemd is a mess but _end of life _of RHEL/CentOS 6 and SLES 11 is somewhere in mid 2020s (other distros are as irrelevant as BSD in enterprise area). So no - there won't be any massive movement towards BSD, at least not in the next few years (I'm not talking about basement deployments of a LAMP stack here).
> And then, I've never heard about anyone switching from AIX just because he did not like ODM.


1. EoL for RHEL and SLES may be in 2020s, but not so for Debian 7, which is the last with SysVinit.
2. FreeBSD developers want systemd-like init too: http://www.phoronix.com/scan.php?page=news_item&px=MTg0ODE


----------



## zspider (Nov 27, 2014)

"We need to be open to fundamentally new approaches and ruthlessly cull what is no longer demonstrably useful to the 99%"


----------



## Crivens (Nov 27, 2014)

zspider said:


> "We need to be open to fundamentally new approaches and ruthlessly cull what is no longer demonstrably useful to the 99%"


zspider, when I put your posting next to the Blockupy movement, interesting thoughts begin to take shape 

But to add to the topic - the attention brought towards Linux is mainly (in my humble opinion) based in the fact that most of our application upstream is there. Should something go on there that would cut off any chance to use new versions of (for example) KDE, any KDE user in *BSD would be in trouble. It is only natural for humans to keep an eye on possible threats, real or imagined. Also, Linux is kind of a tidal pool where some evolution is going on and which is being reset at a regular basis. It might be interesting to watch - but not interesting to enter. Wow, that analogy really seems to fit


----------



## Oko (Nov 27, 2014)

kurld said:


> What strikes me about those systemd topics (and this board in general) is the amount of attention the BSD community gives to Linux.


Maybe because many of us run Linux for living and can't believe one after another non-sense coming out of RHEL kitchen. 



kurld said:


> So no - there won't be any massive movement toward BSD, at least not in the next few years


I would not be so sure. It took Linux only 15 years and tens of billion of dollars investment from Silicon Graphics, Compaq, HP, IBM, Red Hat, Novell, and Canonical to come close to Solaris. Current direct investment in BSDs is measured and hundreds of thousands. Let see one/two large corporations standing seriously behind one of BSD projects.


----------



## Oko (Nov 27, 2014)

LukeWolf said:


> However the entire reason I started this thread is that until that OpenBSD GSOC project nobody was moving forward on said workarounds and Desktop Developers are already moving forward on shifting away from Consolekit (As far as I know Gnome is now shipping in degraded mode for systems not supporting the logind dbus interface) and distribution specific code towards systemd's interfaces.


This is because FreeBSD developers unlike OpenBSD developers are running OS X on their desktops so as far as they are concerned anything desktop-related is irrelevant.


----------



## zspider (Nov 27, 2014)

Crivens said:


> zspider, when I put your posting next to the blockupy movement, interesting thoughts begin to take shape
> 
> But to add to the topic - the attention brought towards Linux is mainly (in my humble opinion) based in the fact that most of our application upstream is there. Should something go on there that would cut off any chance to use new versions of (for example) KDE, any KDE user in *BSD would be in trouble. It is only natural for humans to keep an eye on possible threats, real or imagined. Also, Linux is kind of a tital pool where some evolution is going on and which is being reset at a regular basis. It might be interesting to watch - but not interesting to enter. Wow, that analogy really seems to fit



Actually that was a direct quote from the slideshow on the Phoronix article.


----------



## zirias@ (Nov 27, 2014)

Crivens said:


> But to add to the topic - the attention brought towards Linux is mainly (in my humble opinion) based in the fact that most of our application upstream is there.


I think this is exactly the point. Supporting an operating system, you have to take into account that it's the applications getting the work done, the OS is just the infrastructure for them. As such, it is very important, but doesn't do anything useful by itself. So if some of these applications start depending on things only available on one specific OS, this is where the trouble starts...



pkubaj said:


> FreeBSD developers want systemd-like init too:


Hmm, there's probably nothing wrong with modernizing init. Existing inits have their flaws (e.g., on my FreeBSD installation, `service hald stop` always leaves some hald processes running). But implementing new interfaces, pulling in lots of responsibilities through modules using these interfaces, and having it all tightly coupled to a specific OS; I think this is clearly NOT the way to go.


----------



## protocelt (Nov 27, 2014)

Oko said:


> This is because FreeBSD developers unlike OpenBSD developers are running OS X on their desktops so as far as they are concern  anything desktop related is irrelevant.



While maybe true for some developers, this is obviously not the case across the board or there wouldn't be a use for a Desktop Usage section here on the Forums.


----------



## youngunix (Nov 27, 2014)

drhowarddrfine said:


> And GNU userland isn't Unix either.
> 
> That's my point. Why should FreeBSD be concerned about the Linux proprietary systemd when large swaths of themselves don't use it?




```
Proprietary software or closed source software is computer software licensed under 
exclusive legal right of the copyright holder with the intent that the licensee is given the right 
to use the software only under certain conditions, and restricted from other uses, such as 
modification, sharing, studying, redistribution, or reverse engineering. Usually the source code 
of proprietary software is not made available.
```


----------



## drhowarddrfine (Nov 27, 2014)

kurld said:


> What strikes me about those systemd topics (and this board in general) is the amount of attention the BSD community gives to Linux.


Without adding up the numbers, most of these threads come from Linux posters on this board, or posters with post counts of one or two or so which makes me question why they posted here. Otherwise, threads about Linux are fairly rare here so, no, this BSD community does not give much attention to Linux.

As far as I care, they could all be deleted because they are usually pointless to the BSD community.


----------



## Martillo1 (Nov 28, 2014)

drhowarddrfine said:


> Without adding up the numbers, most of these threads come from Linux posters on this board, or posters with post counts of one or two or so which makes me question why they posted here. Otherwise, threads about Linux are fairly rare here so, no, this BSD community does not give much attention to Linux.
> 
> As far as I care, they could all be deleted because they are usually pointless to the BSD community.


That is also my impression. 

"Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to trolling BSD forums to spread FUD".


----------



## wblock@ (Nov 28, 2014)

Like it or not, systemd has already affected FreeBSD.  There are more than a few new FreeBSD users because of it, for one thing.  It has also forced a reevaluation of init systems, and brought up the question of how FreeBSD can be compatible with software that is written to depend on a Linux monoculture.


----------



## J65nko (Nov 28, 2014)

What some expected has happened: Debian forked over systemd


----------



## DutchDaemon (Nov 28, 2014)

And so it begins. The inevitable fragmentation of Linux. 

Oh, wait.


----------



## kpa (Nov 28, 2014)

DutchDaemon said:


> And so it begins. The inevitable fragmentation of Linux.
> 
> Oh, wait.



Didn't it start already in 1994?


----------



## zirias@ (Nov 28, 2014)

This might not be directly relevant for FreeBSD ... but in fact, it's a good thing that SOME people working on/with Linux oppose to systemd. Linux is so widespread in the FOSS world, if everyone in this sphere would adopt systemd, this would probably lead to more and more applications ditching portability and hard-depending on some systemd component. So, cheers for the effort


----------



## Oko (Nov 29, 2014)

Oh wait, wait FreeBSD is getting launchd.
http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years

Maybe somebody should fork FreeBSD. Ah yeah. Somebody already did that 10 years ago  so FreeBSD is already ahead of the curve comparing to Debian. As usual...


----------



## NewGuy (Nov 30, 2014)

wblock@ said:


> Like it or not, systemd has already affected FreeBSD.  There are more than a few new FreeBSD users because of it, for one thing.  It has also forced a reevaluation of init systems, and brought up the question of how FreeBSD can be compatible with software that is written to depend on a Linux monoculture.



I tend to agree. There have been several disruptive technologies introduced in the Linux community in recent years. As a result I've been spending more and more time experimenting and evaluating FreeBSD. Some of my servers are now running FreeBSD where they used to run Linux because the migration path to FreeBSD was easier than the upgrade path to systemd.


----------



## Carpetsmoker (Dec 4, 2014)

It's not just systemd; my laptop for example can't even run FreeBSD, since it's a Haswell system of about a a year old. The drivers haven't been ported from Linux, and I can only use the vesa driver with Xorg (which is not good enough). I haven't even checked at the other parts, such as the WLAN or webcam.

I bought a small ZBox Nano system about a year ago (AMD), which _also_ didn't work for the same reason, except that here it were the AMD drivers that weren't ported yet.

OpenBSD does support Haswell by the way, and has since may 2014 (5.5)...


----------



## tzoi516 (Dec 5, 2014)

Carpetsmoker said:


> OpenBSD does support Haswell by the way, and has since may 2014 (5.5)...



Really? I tried to install OpenBSD 5.5 on my Haswell/Optimus Toshiba laptop, with a i7 CPU and Artheros Wi-Fi and Ethernet. The graphics weren't accurately detected, and it couldn't detect my network hardware.

Ended up going with Arch Linux.


----------



## abishai (Dec 5, 2014)

tzoi516 said:


> Really?


Yes. FreeBSD addicted to binary blob too much.


----------



## Carpetsmoker (Dec 5, 2014)

tzoi516 said:


> Really? I tried to install OpenBSD 5.5 on my Haswell/Optimus Toshiba laptop, with a i7 CPU and Artheros Wi-Fi and Ethernet. The graphics weren't accurately detected, and it couldn't detect my network hardware.
> 
> Ended up going with Arch Linux.



That's what the release notes for 5.5 say. I didn't test it myself yet due to lack of time and a sort of okay working Arch Linux system.


----------



## sulman (Dec 11, 2014)

Oko said:


> Oh wait, wait FreeBSD is getting launchd.
> http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years



It's just a presentation of an opinion. Hubbard doesn't actually influence whether it's adopted or not.


----------



## Martillo1 (Dec 13, 2014)

abishai said:


> Yes. FreeBSD addicted to binary blob too much.


If you mean NVIDIA drivers, the situation is the same as in Linux.


----------



## torimus (Dec 13, 2014)

Another former Linux `convert' here. Heavily testing migration now, so far so good (LDAP, Postgres, Nginx, NFS, VPN, rsync, Puppet etc). Need only to study documentation to IPFW, jails and ZFS as the only really different replacements. Specific system settings and services handling are so simple to grasp, not worth to count in. The time and effort spent I find more meaningful than learning the systemd ecosystem and refreshing skills with gdb and strace I did believe I will never need at my admin job. I have the "luxury" to afford such a change as a complete solution supplier. Would be much more difficult as a corporate employee.

Having also good results with FreeBSD-current on my work lappy (i7, Sandy Bridge, Intel HD3000, Nvidia GT540M - disabled, Broadcom Wifi and Bluetooth, reliable ACPI S3).

I'm sick of the propaganda and FUD systematically fed by authors and spread by zealots, even in the Debian community I did believe is more conservative and too experienced then to succumb to a few individuals without a history or even identity and playing on an emotional basis. See how even in this thread is spread misinformation about forthcoming adoption of systemd/launchd-like init by FreeBSD.

I don't intend to stir up the situation even more but out of curiosity I'd like to know what existing significant projects are actually threatened with losing portability due to enforced hard systemd-subsystem dependency. I'm aware systemd merged a lot of code/functionality from recently standalone projects and am curious how difficult it would be for KDE developers for example to keep independent interfacing to user sessions, power management, backlight settings, logging, credentials etc. Speaking about ports of course, not concerned about system.


----------



## abishai (Dec 21, 2014)

Martillo1 said:


> If you mean NVIDIA drivers, the situation is the same as in Linux.


No. Linux has nouveau.


----------



## Martillo1 (Dec 21, 2014)

abishai said:


> No. Linux has nouveau.



And how does it work?


----------



## scottro (Dec 21, 2014)

I haven't used it since last year or so, but at that time, it would frequently freeze a machine completely--this seemed to be independent of quality of the machine and distribution.  Judging from Fedora forums, that I still view, it still has issues.    However this might just be FUD from me.  It is still, though, as far as I can tell, a work in progress.


----------



## abishai (Dec 22, 2014)

Martillo1 said:


> And how does it work?


I used it on Linux Mint installation. 2D obviously works, 3D games works as well in Wine, but with opproximatelly 50% loss of framerate in comparison with Nvidia blob. AFAIK it's because of unimplemented clocking control (nouveau driver can't reclock video card as it boots in energy save mode).
I remember an attempt was made to port nouveau to FreeBDS, but it was never succeed.


----------



## Martillo1 (Dec 22, 2014)

50% is not bad. However I give more importance to a working 2D configuration. The change from XAA to EXA made OpenBSD unusable for me.


----------



## wblock@ (Dec 23, 2014)

This thread has diverged widely from the topic, so let's close it and start new ones that are more direct.


----------

