Guest post by The latest version of FreeBSD has been released. The new version, 10.1, is a incremental update to the 10.x series and mostly focuses on minor updates, bug fixes and performance improvements. A few of the more interesting new features listed in the release announcement include support for booting from UEFI, the ability to utilitize SMP on multicore ARM processors, ZFS performance enhancements and the ability to automatically generate host keys for OpenSSH if keys have not already been created.
The new version of FreeBSD is an extended support release and will receive security updates through to the end of December 2016. Further details on the FreeBSD 10.1 release, along with instructions for upgrading from previous releases, are available in the project’s release notes. Installation images can be downloaded from the project’s mirrors.
I’ve been waiting for this release of FreeBSD/PC-BSD, because I want to install it and give it a try. My motive is to escape systemd, which is due to start polluting Ubuntu 14.10 (which I now use) in the months ahead.
I’m not sure if FreeBSD will fulfill all my needs, but it’s worth a try. The other alternative I’m considering is Gentoo.
Edited 2014-11-15 01:48 UTC
I simply don’t get all this hate over a replacement for init. From what I understand, systemd might be an improvement on init. If you want to use FreeBSD or PCBSD because it is cool, which it is (or because it is a system that does what you want) then you have a good reason to use FreeBSD, but to avoid systemd wtf.
I do understand systemd might be a threat to UNIXes because it needs the Linux kernel I can see issues there but this apparently irrational hate from within the Linux community mystifies me.
My opinion is that it’s the prevasiveness, bull-headedness and exclusionary nature of it that people are finding offensive.
As a user of a few unixes I really dislike this idea of desktops coming to rely on something that is Linux only, open source software benefits everybody by being portable not restricted.
I can’t tell – are you against systemd, or against the GPL2+ license that prevents it from being ported to other OSs like FreeBSD?
– Brendan
It is not the GPL that prevents systemd from being ported to other operating systems such as FreeBSD. Lots of software that is licensed under the GPL runs on FreeBSD. What stops systemd from being ported is its heavy reliance on Linux-specific features such as cgroups. Plus the systemd developers have stated they will not accept any patches upstream that make systemd more portable. Which means even if someone does port systemd to FreeBSD, the software will remain a moving target and the patches will have to be constantly updated downstream.
The uselessd project attempts to port an earlier version of systemd to FreeBSD, but it requires pulling out a lot of features.
It’s written directly against Linux, in order to make the best use of Linux features, like cgroups which it relies heavily on.
This is exactly what FreeBSD is doing with Jails which is a FreeBSD exclusive functionality which it’s userland tools calls upon.
But somehow (hypocrisy ?) when FreeBSD is writing their userland tools directly against it’s own exclusive functionality it’s ok, but not when someone is writing a userland directly against Linux functionality…
Perhaps you are unaware that FreeBSD jails work with GNU userland tools too? As a practical example, the Debian GNU/kFreeBSD distribution supports jails with a mixture of the FreeBSD kernel and GNU userland and GNU C Library.
With big limitations, as I recall you can start a jail under GNU/kFreeBSD and that’s about it, none of the jail administration functionality is supported, which is not surprising as that is done by FreeBSD userland tools written directly against that FreeBSD kernel specific functionality, like jail, jexec, jls .
This is again the same as with systemd tools, which is written directly against Linux functionality.
The difference is, FreeBSD Jails isn’t a core dependency of any software other than tools designed to work with Jails. Jails matter only if your intent is to use jails.
Systemd, however, is something that can become a requirement for unrelated pieces of software. Gnome3 is a major example, and there will surely be more to come. In this way, systemd matters even if it is something you don’t use personally.
Only if said software relies on functionality which only systemd provides, currently that would be logind which handles user session tracking, previously handled by the since long unmaintained ConsoleKit.
Of course anyone can pick up maintenance of ConsoleKit again which is what XFCE is doing through their fork, or provide the same functionality in a new maintained package outside of the systemd project, systembsd, systemd-shim comes to mind.
That said, the amount of software (particularly desktop software) which needs any systemd functionality would be very slim, a desktop environment like Gnome/KDE certainly fits the bill since they need to track user sessions, handle power management etc, but your typical desktop app will not need to access systemd functionality.
There are lots of reasons (good or bad) people don’t like systemd. Some feel that it is being adopted too quickly. It may be a good init replacement, but given the known bugs systemd may not be ready for some environments. This makes its rapid adoption by projects like Debian and RHEL unwelcome to some.
Some people aren’t crazy about the upstream developers’ attitudes toward the community. Some of them have been less than diplomatic and that doesn’t win any converts.
systemd strives to take over a lot of roles, not just init. Some people who have been using UNIX-like operating systems for a while naturally distrust software that tries to fill many roles such as mounting, init, logging, etc. Some people like a centrally controlled OS, others feel this feature creep is a sign the OS relies too much on one project.
Personally, for me, it’s a practical issue. I’ve tested multiple versions of systemd across multiple distributions. I’ve run into a number of bugs, poor documentation, daemons which no longer work when run under systemd and scripts that no longer function properly. For me, systemd does not appear to offer any benefits over the existing init software. My options were to either patch services and scripts to work under both systemd (for new installations) and SysV/Upstart for existing systems…. Or I could migrate to an OS that wasn’t using systemd. The latter, I found after some experimenting, proved to be less work.
For a desktop OS I don’t care much about which init software is running since I rarely interact with it. But on a server OS, systemd causes too many problems and offers no practical benefits for me, so I don’t use it.
Gone fishing,
SystemD is an octopus. It’s a monolith design that just keeps growing without scope. It’s perfectly legitimate to ask if A) this is actually the best way to provide system services, and B) to what end will this kind of feature creep continue to load more core services into systemd?
This rubs many in the community the wrong way because traditionally *nux is about choice and keeping things simple, each tool doing one thing and doing it well. With systemd, it does so many things and it’s only going to become more difficult to do them any other way. Once systemd becomes a system dependency for a significant number of packages, it will become very difficult to choose alternatives, even if those alternatives would be better for the user. So it shouldn’t be surprising that many users are extremely nervous over this power-play by Lennart P to control all linux core services. And it’s not helpful that he has a history of disregarding the rest of the community.
For what it’s worth, I personally dislike SysV init scripts, I won’t miss them in the least. Linux could migrate to a better designed init system. What’s makes systemd controversial (to me) isn’t that it replaces SysV scripts, but it’s unbounded scope. An init system should be the simplest system on a linux box. It should explicitly stay away from the kinds of feature creep that plague systemd.
Many users really are indifferent, and you might not care about any of it, but there’s no reason to say those in the community who dislike it are irrational.
https://fitzcarraldoblog.wordpress.com/2014/10/04/my-thoughts-on-sys…
http://www.linuxinsider.com/story/81262.html
http://beta.slashdot.org/story/14/05/08/1232225/ask-slashdot-practi…
Edited 2014-11-15 17:22 UTC
On the other hand, you could turn the exact same argument on its head and say systemd does away with one thing that’s plagued Linux and Unix in general, which is fragmentation. In my opinion, it also works very well (cuts ten seconds off my boot time, down to about two) and is easy to configure and use.
No it isnt
I think this fragmentation perception generally exists at the macro-level, such as a novice deciding which linux distro and window manager to install. For example, it took me several years before I became comfortable choosing one kind of distro over another, I tried slackware, gentoo, debian, fedora, suse, mandrake and maybe others. The fragmentation of distros impeded my uptake because I found it so difficult to choose. I concede this macro fragmentation can be a big problem because it forces novice users to make big decisions up front, which is intimidating and confusing.
However when it comes to linux services (ie network setup, login management, device management, storage, logfiles, etc), the vast majority of users just use whatever comes with their distro no questions asked. They are not affected by service fragmentation *at all* unless they’re explicitly seeking to switch their defaults for some reason…in which case a monolithic approach is very bad, and having a choice is good.
It’s relative, you could say it’s because init scripts work poorly. Runlevel service invocation is pretty dumb IMHO, they certainly don’t take advantage of parallelism which is why you see the difference. But like I said, the problem with systemd isn’t merely that it replaces init scripts, it’s that it tries to replace everything in a monolithic way – making it unnecessarily difficult to tweak one piece of the stack independently from the rest. To some of us, this is indicative of poor design choices.
Edited 2014-11-15 22:44 UTC
No, fragmentation is a problem not in that there are zillions different distributions, but in that there are an even bigger number of small applications that supposedly do one thing each and do it somewhat okay-ish. Other applications drag in combinations of these to do more complex tasks, which causes a somewhat bigger number of potential problems. When there’s an infinite number of ways to do something, it also becomes difficult to understand why something doesn’t work. Especially when people insist on using a GUI.
No it isnt,
What do you think you get when you try and shove everyone to a one-size-fits-all solution? Mediocrity.
Think about that, it’s necessarily going to be a least common denominator. This is not necessarily a problem; supporting 80% of the features can nevertheless be adequate for most users need. But therein lies the problem for more advanced use cases, either systemd acknowledges it is NOT appropriate for specialized use owing to the lack of specialized features (which is why hard coding systemd dependencies is a bad idea). Or the alternative is to admit that systemd is adding complexity & bloat that doesn’t benefit the majority of users (making systemd more complex over time than the things it was designed to replace).
Maybe, but it’s not so clear cut because systemd places us at a greater risk of tight coupling and complex interdependencies than independent services did.
I’m not expecting you to change your mind about systemd. But you can understand why it’s not the best solution for everyone else on technical and political grounds, right?
Edited 2014-11-16 01:16 UTC
Now you’re just being silly. Systemd’s ‘least common denominator’ has features no other init provides. If mediocrity is better than the alternative, then what is the alternative? Not good.
No it isnt,
You misunderstand, I’m not referring to the “init” functionality, I’m referring to the rest of systemd that extends outside of init functionality. Systemd replaces specialized services with generic one-size-fits-all systemd ones.
As I said, the one-size-fits-all approach isn’t the best approach for everyone, some people do benefit from alternatives. Even if you aren’t one of them, I would hope that you could at least respect that other people have differing needs rather than masquerading systemd as the best solution for all cases.
Are you still referring to sysv init scripts?
If yes, then personally I do agree systemd’s init functionality is better than that alternative, but this is not the point of my argument. The concern is whether systemd should take over other system services. What is the justification there? This is not being silly, it’s a completely legitimate question. I have yet to see how any systemd provided subsystems are technically superior to alternatives.
You’ll have to forgive me for thinking that systemd is absorbing services just because it can rather than because there’s a technical reason to.
And what features would that be?
There’s a good list of features here:
https://wiki.debian.org/Debate/initsystem/systemd#Functionality
See also the comparison with upstart further down.
Except here was never any real fragmentation when it comes to service managament. Any daemon that works with sysv-init also works with runit/daemontools/upstart/systemd etc. There was never any cron fragmentation, everyone used cron and a standard crontab.
Runit/Daemontools/upstart all captures stdout/stderr and logs it, just as systemd now does.
Most of the existing init replacements also cut down on boot times, it’s not something unique to systemd.
systemd is NIH at it’s finest (or worst, I guess). There are so many good init replacements that existed long before systemd (heck, even upstart is better) yet RH had to go ahead and reinvent the wheel for the millionth time.
I guess they needed a way to stay relevant in the enterprise space because systemd has all the hallmarks of an “enterprisey” system: horribly over-egineered and unnecessarily complex.
Edited 2014-11-16 04:02 UTC
The last time I heared that kind of description in the UNIX world was about Solaris SMF…
The ‘scope’ is to provide an base OS set of tools/daemons which make the best use of available Linux functionality with great integration.
The lack of a de facto standard OS like this is what has often been described as the largest benefit of the BSD’s versus the Linux distro ecosystem.
systemd is not one big binary, it’s divided into several tools each with a specific use, that they are all under the same umbrella and are all written to make use of the other parts of systemd is no different than the userland functionality in the BSD’s for example, I pointed out the the FreeBSD Jails userland integration in another post.
I understand how people who want to keep using their current configuration of tools they know well might find systemd a threat to the future viability of the said tools they use, as upstream is jumping on the systemd bandwagon.
But the reason upstream is flocking to systemd functionality is because it makes perfect sense for them to focus on a solution which handles a lot of stuff for them in what is increasingly becoming a ‘de facto’ standard cross distro solution if we look at distro use.
As for the viability of existing solutions which people are using and want to keep on using, that all comes down to what ‘freedom of choice’ really is in FOSS, which is someone actually bothering to provide and maintain that choice, it does not spring out of thin air.
As upstream abandons support for downstream solutions, downstream has to step up, or they will lose that solution.
Again systemd is not just an init system, the init part is certainly a core part, but it’s just a part of what systemd aims to achieve, which is to offer a cohesive core OS base together with Linux.
So, like we have FreeBSD, OpenBSD, NetBSD, etc which are all full OS’es, this is an attempt to create a Linux+systemd equivalent standard.
Some certainly are, but yes, disliking systemd in itself is not irrational, it really depends on which side of the fence your on.
For instance as you’ve stated in another post, the BSD’s normally wouldn’t care less, except that for desktop use they rely on software written by what is 99.9% 24/7 Linux developers, and obviously those developers have no problem with leveraging systemd, which in turn will require downstream work to be able to use said software.
And of course there’s those who have system tools/workflows which they want to continue using, but are now in danger of being deprecated from upstream.
But just as there is vast consolidation around say, glibc, we are seeing this consolidation around a larger part of the low-level plumbing in the form of systemd, this has as always, both benefits and drawbacks.
systemd isn’t just an init system. It is a reworking of the low level Linux user land and happens to include an init system.
r_a_trip,
I thought it would have been clear, but that’s precisely why it’s so controversial. Instead of doing one thing and doing it well, it tries to replace the entire stack.
It IS an improvement but on the other hand having no init is an improvement over SysV init.
My beef with systemd is that it is too invasive, it does so much more than it should. It also stores configuration files in odd places like “/lib/systemd/system” (WTF??).
Agreed, not the most rational reason to switch.
Meh it’s not really a threat to anything else. On the other hand, Poettering’s stance that only Linux matters, screw posix and other Unices sure isn’t helping the case for SystemD.
How much does systemd affects the userland applications?
GNOME 3.1x hard-depends on systemd-logind or something that implements the same API…. which nothing else does at the moment. OpenBSD is working on a replacement.
This depends upon the application. For many, it won’t have any effect at all. But it can and does affect things in often unexpected ways.
As an example, I’m the author of the schroot(1) lightweight virtualisation tool. It’s not “full” virtualisation system or even using containers, it’s a wrapper around chroot(8) which does setup and teardown of a chroot environment, with support for filesystem snapshotting, PAM authentication, and a bunch of other features including Linux namespaces and personalities. It’s primary purpose was to provide clean snapshots for build environments, but it’s been used by people for all sorts of things.
It was broken by systemd because it internally calls mount(8) to set up the chroot environment and bind mount things into it. No different than doing it by hand yourself. But with systemd it puts them into a mount namespace and they vanish when you log out. Desirable for desktop applications, maybe, but not for other uses.
Is this a bug? It’s arguable. But it is a huge change in behaviour for a low-level system tool and system call. Until we added logic to cope with systemd, it broke things. Let me state this again: “systemd fundamentally altered the behaviour of standard Linux tools and system calls”.
Now, systemd supporters will undoubtedly argue about how much better the new way is. Maybe it is. However, I’ll just say I’m sorely disappointed at the complete break with backward compatibility here. See screen and tmux for other examples of how killing everything on logout screws things up; they similarly needed explicitly patching to work around systemd’s behaviour.
This is just a single selected example; I could continue with many many more. I’m one of the people who has been slowly switching to FreeBSD over the last year. This is largely because systemd nullifies many of the reasons I originally started using and developing for Linux in the first place.
Regards,
Roger
Thanks for this informative post. It’s a good example of the bull-headedness of the systemd implementation.
The article is about FreeBSD, and yet all the comments are ramblings about systemd. Wut?
tylerdurden,
Sure it’s a bit tangential, but there could be larger ramifications for software on BSD.
http://aboutthebsds.wordpress.com/2013/07/16/why-do-bsd-people-fear…
Dat article though. I think I just facepalmed myself into the next millenium.
A great example of the arrogance (and lack of brains) that plagues parts of the Linux community though.
Yes, everyone should know that aboutthebsds.wordpress.com is all about trolling and spreading FUD about the BSDs.
Whoever wrote that piece needs to be slapped with a wet smelly sock, repeatedly.
The person whom runs that blog is a well known deranged troll on the Phoronix forums that posts a hell of a lot of crap from a slew of different accounts.
Edited 2014-11-16 06:56 UTC
tylerdurden,
Haha, yea you and Soulbender are both right. The tone was appalling, yet the gist of the argument might not be so far off.
However I see now from the responses that the tone detracts from the main point. Oops, another tangent has begun
Edited 2014-11-16 07:01 UTC
The argument is so flawed its not funny. The guy is also such a loon he posts as a bunch of fake users to his own blog.
0brad0,
Ok, but you shouldn’t need to resort to an ad hominem to make that case. Let’s put him aside, I think you’ll find there’s a tad of truth in there. Is it a problem when userspace software is built on linux specific features? Doesn’t this software becomes more difficult to port to platforms such as FreeBSD?
Of course the real question is how much systemd will actually influence software development in the long term. As long as there’s very loose or no coupling, then there shouldn’t be a big portability problem. But frankly there’s a risk people like Pottering will be using their weight to add dependencies needlessly and without merit.
Only if the gist of the argument was that some influential Linux developers don’t give a rats ass about portability.
Well there’s that, but also that after all these decades many BSD folk still don’t get what the N and the U in GNU stand for…
Edited 2014-11-16 23:04 UTC
This is an important reminder you provided. Allow me to add the following statement: FreeBSD and Linux are different operating systems.
I think that’s a common misunderstanding when talking about systemd. It is designed for Linux, and for Linux applications. In fact, it’s possible that the whole Linux ecosystem can benefit from systemd integration. On the other hand, BSD is a different operating system. The fact that many programs available on FreeBSD are ported versions from Linux origin doesn’t imply that this possibility is always provided.
The big desktop environments, especially Gnome 3, seem to prefer to follow the “faster path” of development in Linux, where developers can concentrate on Linux and not have to care about the option (!) of being portable to a different OS. This would imply that in the future, there won’t be a port of some software that so heavily depends on Linux (systemd, cgroups, udev, upower and their successors). This is nothing new. Many users remember the trouble when Linux introduced HAL and DBus, causing problems on FreeBSD because those infrastructures weren’t avaibalbe yet. But as soon as they were available, they got obsoleted and replaced by something else. There are still “lurking dependencies” in many peaces of software, and getting rid of them (especially if they don’t provide any feature the user depends on) is hard, but possible. With systemd, this possibility might be lost, but it’s not just about systemd, it could be any Linux dependency that doesn’t have an equivalent on FreeBSD. And it’s not just about “higher complexity software”: As soon as a toolkit provides a “file open” dialog, and that dialog insists on interacting with something Linux-specific, trouble can start. Such dependencies could hide in libraries where the user might not expect them…
This consideration isn’t that far off. Is there anyone who actually expects to be able to compile and run source code for a program intended for “Windows” on an operating system like Linux or FreeBSD? Many would call this assumption stupid, or at least unreasonable. “Write once, run everywhere” is actually hard. Even though FreeBSD and Linux share many similarities, there are also differences, and systemd, among others, may be counted here. So in the future, a user might see the situation that current Gnome is not available on FreeBSD, or an application using current Gtk won’t compile due to missing dependencies.
What options are left? FreeBSD developers could invest time to chase the moving target of systemd, trying to add a “compatibility layer” (comparable to the Linux ABI) to provide systemd “hooks” to programs that expect them. Then, Linux kernel facilities that might get triggered also need to be “mimiced”. And I would even assume that the day this works flawlessly, Linux already uses something different in succession.
There are plans (currently being carried out in early stages) to develop environments designed to work better with FreeBSD than the ported ones can (or will able to be, in the future). Especially with the goal to provide a “native X environment”, there’s potential of advencement in FreeBSD development (GUI-related).
We’ll see how this develops.
I agreed with a lot of your observations, but there was one that stood out as a bit off, in my mind. The suggestion that we shouldn’t expect software built for Linux to work on FreeBSD anymore than we would expect software designed for Windows to work on Linux or BSD doesn’t ring true. While Linux and FreeBSD have quite different implementations, they are both (supposedly) POSIX compliant operating systems. Windows is an entirely different family of OS from the UNIX/POSTIX tradition.
It should be fairly straight forward to patch and build software developed for one POSIX operating system so that it works on another POSIX operating system. That’s why it is usually trivial to get software from the Linux community to run on FreeBSD. It’s why MINIX can easily import NetBSD’s userland and ports. They’ll all working from a POSIX base.
One of the issues with software like systemd (though it’s far from the only example) is that systemd intentionally is not POSIX compliant, it is designed to be Linux-only. Most software in the Linux/BSD/MINIX community is designed to work on POSIX systems, not one specific platform. systemd is an exception to that and upstream’s intentional break with the POSIX tradition bothers some people. Especially those of us who use multiple operating systems and appreciate being able to use the same applications/standards across platforms.
I think it could be argued that it makes sense to focus development on one platform to take advantage of all that platform’s features. However, that means more work for developers on other platforms and more work/headaches for people who use multiple operating systems. Projects like GNOME who are jumping aboard systemd are causing more work for their users and developers on other platforms and that is, understandably, upsetting those users.
Linux is not, and has never been, fully POSIX compliant BTW.
Edited 2014-11-17 08:55 UTC
Doc Pain,
Very well written, great points about the operating systems being different. However just so we’re clear, even in isolation from portability issues, it’s still not clear why tethering so many services to systemd is a good development for linux itself. I’m still finding that many systemd proponents have trouble explaining why a monolithic systemd is needed or beneficial, other than “it’s better than sysv”. What’s wrong with systemd just being a great init system and keeping other services as independent and minimally coupled as possible?
Who knows, maybe I’m just missing something, but thus far nobody has provided satisfactory answers.
Edit: tylerdurden, my apologies for this o/t rambling still going on. WTF indeed
Edited 2014-11-17 03:47 UTC
I think it’s funny to consider that one of the big reasons Linux got any cache was that it was easy to port software from other Unices and that it stayed out of the compatibility nightmares of the Unix war. Now that Linux is the big cheese it’s all “Our way or the highway”.
Perhaps history is repeating itself in a manner that is not favouring Linux….
Edited 2014-11-17 05:06 UTC
It’s funny because of how often Linux users complain that this and that Windows game and application doesn’t run on Linux and boy, why don’t those developers just follow standards like OpenGL and posix to make porting easier.
Now I’m confused, are you implying those linux fanboys doing what you just described were correct/justified all along then?
Edited 2014-11-17 08:21 UTC
AboutTheBSDs? Really?
Show me on the server where the daemon touched you.
For me, the thing that most perplexes me about freebsd (10.1 or any recent release) is that they haven’t updated to the more recent pf. They are still making do with the 4.5 version.
Other than that, I’ve seen a lot of talk and have been pressured by friends to jump onto the zfs train, which I’m reluctant to do. I’m not strictly opposed to the feature set (though I think the send/receive stuff doesn’t belong in a file system); however, the implementation requires a substantial portion of a solaris kernel just to run the filesystem, which feels icky to me.
Admittedly, I don’t run FreeBSD myself since I ended up in the OpenBSD end of things over a decade ago and have been quite happy over here. Lots of friends/colleagues are devs and proponents of the OS though, and I appreciate the value they see in it.
Congrats on another release.
Edited 2014-11-16 18:47 UTC
So far I’ve installed it on one server, one client and a couple of VMs and it’s been trouble-free. The upgrade of the toolchain to LLVM/clang++ 3.4 was welcome.
I thought newcons was going to be enabled by default with this release but it doesn’t appear to be the case on my client with a radeon card; not even loaded when running X11. With 10.0 I’d rebuild the kernel with newcons enabled; I thought this wouldn’t be needed with 10.1 (not complaining, just not what I expected). Maybe it just needs enabling in loader.conf.
From the release notes: