Exactly, so imnsho this is simply wrong and should be un-done. Systemd should do those things that can only be done at init time and/or those things that need to be there and no more and leave the rest of the lifting to those tools that we already know how to use and that have stood the test of time. Otherwise we end up with 2 sets of incompatible tools with one of them not only re-inventing the wheel but replaying a whole bunch of security issues from the past on top.
This is the worst case of feature creep in system land in a long time.
That is a good architectural design, but is in direct opposition to the projects mission statement of "embrace, extend, ..." you guess the third word.
If a group is actively trying to ruin something, noticing that they're trying to ruin things isn't going to stop them. That's a useful strategy with accidents and friendly groups, but not with actively aggressive oppositional destructive groups.
Mostly I'm just angry about having to waste the labor hours moving everything to Freebsd from Debian. Its interesting, but not exactly productive.
Funny, that was exactly my response to all this, if Linux insists on copying the worst of windows in the future then I'll be more than happy to go with FreeBSD. I'm a bit rusty but I'll survive.
Last I looked FreeBSD used rc.conf but it's years ago.
I don't see FreeBSD's init trying to absorb most of the userland system utilities.
Whether or not it is in one repository isn't really the issue at hand here. It is that a bunch of desktop related stuff is worming its way into the systems to the point where you'll be running a whole slew of new, buggy and sloppy code on your servers if you're not very careful just so that the systemd folks get to scratch their NIH itches.
Everything in one repository, yes. Tightly coupled, no.
And even when in one repository i think you can grab the BSD utils without getting the kernel and whatsnot in one big tar-ball.
If you try to grab say just the dns daemon from systemd you can't do so directly. you would have to grab the tar-ball for the whole of systemd, and then attempt to extract just the parts dealing with the dns daemon.
Damn it, LFS have found doing this for udev so demanding that they have switched to eudev for their non-systemd edition (yep, they now have their own systemd edition going alongside the "traditional" one).
I think we've reached the point where we can start being pedantic about what "Linux" means.
I don't think the kernel developers care that much about what systemd is doing (except for the notorious clash about systemd interpreting a debug option meant for the kernel and crashing the boot...), so you can't say the kernel is copying or doing anything.
The distros, however, are possibly the ones you want to blame for pushing and supporting systemd. Which is actually funny because the way it's going, systemd is laying foundations for a new kind of linux distributions to which distributions will certainly have to adapt if they want to keep it.
Right, because it drives people from linux to FreeBSD. Well, here is my take on that: the reason I run Linux is because my desktop runs linux, and I try to keep as little knowledge about systems in my head as I need to get through the day in one piece. Since FreeBSD lost more and more ground to linux when it came to supporting the kind of hardware that PCs (desktops) ship with I ended up standardizing on Linux. I know full well that if I switch back to FreeBSD I'll end up running it on my desktop as well and that's when I will probably regret my move. Let's hope the situation has improved over the years.
Systemd is a cancer, it will end up killing Linux if this goes on unchecked. At least Torvalds seems to (most of the time) know his stuff, the way they replaced the memory management left me with a bad taste but in the end it worked out. What's happening with Systemd is absolutely unpalatable and I hope that Redhat and other distros take note, there are a lot more Linux systems on servers than on Desktops and if they believe that expending all this effort on Linux on the desktop so they can better compete with Windows they might just lose their dominance on the server because of it.
> I hope that Redhat and other distros take note, there are a lot more Linux systems on servers than on Desktops and if they believe that expending all this effort on Linux on the desktop so they can better compete with Windows they might just lose their dominance on the server because of it.
Red Hat is developing systemd. It has nothing to do with making Linux palatable on the desktop, but a severe case of NIH, which to be honest is hardly new in Linux-land.
systemd won't kill Linux. Linux development is out of the hands of hobbyists and enthusiasts now and corporate users and developers don't care about the holy wars. Red Hat ships systemd, Red Hats users will use systemd and that will be that.
RH is pushing heavily into cloud computing, and appears to use systemd to do so (notice the amount of containerization talk there is in relation to systemd these days).
Their existing server customers are likely to be sitting on RHEL7 for quite some time. And i suspect that the workstation customers, mostly military as best i can tell, are in part pushing for systemd. Logind etc after all is heavily focused on multi-seats.
I'm one who you speak of. Systemd to me is just a scarily large attack surface. Working through my servers slowly replacing them with FreeBSD. ZFS raid root out of the box on install! That one really impressed me.
>Mostly I'm just angry about having to waste the labor hours moving everything to Freebsd from Debian. Its interesting, but not exactly productive.
It's scary for me, because everything I've done has been in a Linux, but it's also educational for me, because everything I've done has been in a Linux. If the systemd invasion results in a lot of attention going to the BSDs, it's not entirely a bad thing.
The biggest change will be that you might find it sometimes harder to get exotic hardware to work and that BSD tends to put stuff in different places. Most of your other unix knowledge (userland) will transfer just fine, the sysadmin stuff is a bit harder but learning another dialect of unix is along the lines of learning Spanish when you already know Italian.
FreeBSD always was targeted on running on servers. So if that's where you will run it then you should have minimal issues with drivers. If you plan to run it on desktop it might be more challenging.
As suggested reading "man hier" is a great way to understand the filesystem layout. I personally also really like clear separation between the system and applications. For example all ports/packages are installed in /usr/local including configuration files (in /usr/local/etc).
Read the hier man page of your chosen BSD, first. It is a great eye opener. From there OpenBSD and FreeBSD have some great documentation (not sure / no slight intended to NetBSD or Dragon Fly BSD as I have not used them much).
But that's not in line with what systemd intends to be. It's meant to be the standard suite that you sort of plug in as a middleware between GNU and Linux.
Your proposal would require a radical paradigm shift as to the fundamental project goals of systemd, in which case it'd probably become something like uselessd.
This is the worst case of feature creep in system land in a long time.