Debian Votes Against Mandating Non-systemd Compatibility 581
paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.
This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.
However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.
Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.
This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.
However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.
Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.
Go back in time 5 years (Score:5, Insightful)
Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers. One massive program running at PID 0 doing 100 different jobs from startup scripts to DNS resolution complete with binary log files and a completely different (but the same) set of tools o manage them (grep less awk tail). You would be laughed at and run out of town. Nobody would ever take you seriously again.
Can't wait for all of /etc to disappear and be merged into a single binary file like the Windows registry. I first ran into this nonsense when playing with a BeagleBone Black board. Go ahead and see if you can figure out how to change the ip address. In case you can't here is how you do it:
http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
Tell me why any of that is necessary? It's exactly like how Windows manages network interfaces.
Re:Go back in time 5 years (Score:4, Insightful)
Agreed. I don't get systemd. If people want to use it, fine. But, like Windows 8 taught Microsoft, giving people a one-click way of going back to the old-and-tested interface is always a) possible and b) sensible.
If systemd was really that good, I wouldn't need it foisted upon me forcibly, I'd be voluntarily choosing it rather than the default init on every distro I boot.
I think worse than pushing it on your users is this - saying you won't support the old way of doing for those that don't want to change.
All we need is one remote-root in systemd and people might start to think again.
Re: (Score:2)
I think the way forward will be a lot of systemd forks that strip away functionality, and implement other functionality. That which will bring about the need for a common, standardized interface. And then, choice in init systems will be an option again (but timezoned, hostnamed, logind will be required).
Re: (Score:3, Insightful)
Re: (Score:2)
How practical is this for the desktop?
This is actually a serious question. I'm not overly familiar with BSD but have been thinking about giving it a shot on the desktop. I've been a Gentoo user for many years and am reasonably comfortable diving into stuff, so I don't anticipate user friendliness being a show stopper, more likely something I can currently do on Linux won't be available or will have poor support in BSD.
The main things I'm concerned with are Minecraft/FTB, mplayer, flash, VirtualBox, OpenRA,
Re:Go back in time 5 years (Score:4, Informative)
How practical is this for the desktop?
This is actually a serious question. I'm not overly familiar with BSD but have been thinking about giving it a shot on the desktop. I've been a Gentoo user for many years and am reasonably comfortable diving into stuff, so I don't anticipate user friendliness being a show stopper, more likely something I can currently do on Linux won't be available or will have poor support in BSD.
The main things I'm concerned with are Minecraft/FTB, mplayer, flash, VirtualBox, OpenRA, and jack/rakarrack. I'm open to alternatives as long as they actually work.
Flash I could probably live without, but much as I hate it, browsing the web sans-flash does still pose the occasional problem. jack/rakarrack I could also probably live without. I currently use my desktop as a quick-n-dirty guitar amp/effects stack. OpenRA is the thing I anticipate having the most problems with, but I play it somewhat obsessively so very much desired.
At some point I'll probably just try it and see, but I'm curious if any other slashdotter has gone this route and has anything interesting to say about it.
I installed PC-BSD after a couple of weeks w/ Windows 8, & by & large, it's been good, for the things I do. Unfortunately, my Wi-Fi wasn't recognized, so I have to run an ethernet cable to my laptop. Other than that, the experience was generally okay, but could have been better.
The first time I tried installing it, it took a few guesses for me to go into BIOS, disable UEFI (at that time, I was installing 9; now, under 10.1, UEFI is supposedly supported, if you're installing from scratch), and then go into install. I had a few hiccups in getting the system not to go into a loop while installing, but once I got around it, the installation was a breeze - except of course, for the non-support of the Centrino
Once I logged into the first account created, I had some glitches in creating more user accounts from the GUI - had to do an adduser from the CLI (that bug has since been fixed, since more recently, I can). I created different accounts for different roles - one primary one to do all my day to day work like banking, making payments to various cards, personal emails, et al. And others for different things that I do, such as job exploring, or posting to /. here. Each of them, I try different DEs, such as Lumina, LXDE, KDE and GNOME.
This week, I upgraded the system to 10.1, and a lot of the bugs I had went away. I still haven't enabled UEFI, since that would require backing up all the data and then doing a fresh install, and there is no single utility in PC-BSD to do all that, and this is not a hot issue w/ me. So, right now, I'm happy w/ my system.
On the things you were asking, there is Virtual Box, but I haven't tried the other things. For sound players, there is VLC and a whole host of other such utilities. Talking about Flash, I've installed it in FireFox, but not in Chromium (Chrome itself is not there in FreeBSD). But I have no issues watching YouTube videos, if that's what your need for Flash is, w/o Flash and under Chromium, in HTML5. Not tried Minecraft, for me, the favorite game is FreeCiv.
One thing that PC-BSD does great is integrating things, so that any utility will work in any DE. For instance, GTK apps work great under Qt based environments like KDE, Lumina and LXDE, while Qt apps like Calligra work great under GNOME 3.14. One thing - the PC-BSD control panel is quite advanced, and does a better job of system management than trying to edit files in /etc. I tried that last week when I had to replace a router and change the default gateway address - it refused to save my changes to /etc/resolv.conf, but when I went into PC-BSD control panel's network and changed it there, it worked like a charm.
As usual, YMMV
Re: (Score:2)
Stripping away functionality is going to be hard to do. For example if standard hostnamed is not going to able to support all the features of the systemd version. Which means either:
a) System admins are going to be directly exposed to complex use case reverse engineering when they can or cannot use the less powerful daemon
b) The daemons are going to need to keep up with systemd's feature set and interfaces which means for all practical purposes being part of systemd.
Re: (Score:3)
There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.
Re: (Score:3)
This isn't about system admins.
Of course not, that would suggest that the primary users actually have influence on the development process. It's just unthinkable.
Re:Go back in time 5 years (Score:5, Interesting)
There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.
The sysadmins are the meal ticket of developers. For years now, we've been saying we don't want systemd unless it can be made compatible and standalone. Now Red Hat calls me and wonders why I choose to install RHEL 6 on new systems, given that RHEL 7 is out. Why? Because we told you in advance what we wanted, and you chose not to listen.
Sysadmins are in a position to choose their operating systems. The developers are not in a position to choose their customers.
Re: (Score:3)
RedHat has clearly picked their direction with IaaS and PaaS. Just as they moved from desktop to server they are moving from small server deployment to large server deployment, moving up market. Mostly I suspect traditionalist sysadmins were running CentOS anyway.
Re: (Score:3)
My platform, and the 130 developers that code for it, are moving to Slackware when Jessie comes out. Fuck'em.
Re: (Score:3)
I'm interested in the next year of quarterly earnings reports. If sysadmins successfully communicate that they would rather not purchase support for systemd distros, then the market has spoken.
A thousand angry nerds on the internet mean little compared with one lost contract.
The financial impact will be slow to show, and the response will probably be immediate, but again slow to slow. Then things should move rather quickly.
Whether there are responsible people in the role as CTO of large businesses will so
Re:Go back in time 5 years (Score:4, Insightful)
Apparently any Debian developer can now chose to make their package only work with Systemd. So, any maintainer of a package that he uses has the opportunity to become that jackass.
Re: (Score:3)
I think most DD will be much more inclined to keep supporting non-systemd inits if they weren't called "jackass's", and their name and their distro weren't constantly attacked, and their mailings list trolled by people who want them to keep supporting SysVinit.
It is a failed strategy to think open source development is done by harassing developers and throwing tantrums on developer mailing lists and in bug trackers. Asking nicely and making an effort to help will bring much better results.
Re: (Score:3, Insightful)
Most debian developers force you to use the linux kernel.
While I agree with most of your post this bit is wrong. Many (most?) Debian packages do not force you to use the Linux kernel.
Re: (Score:3)
Re: (Score:3)
Tell that to BetaMax.
Re: (Score:3, Informative)
Because:
apt-get install sysvinit-core systemd-shim
is too hard for them.
Re: (Score:3)
Red Hat. Via GNOME.
Re: (Score:2)
More details. How did the "infection" occur? Magic? Did your installation include Gnome? If so, why?
Re: (Score:3)
As a Gentoo user, I can kinda relate to this.
I've had to use the blacklist for the first time in a long damn while because (said in McBain voice) the USE flags, they do nothing!. Gnome indeed would seem the biggest offender. I don't even use gnome (openbox/xfce), but I have enough libraries and little utilities that were pulled in as dependencies for various things that I still had to spend hours dealing with stuff trying to pull in systemd.
So even on a source based distro where systemd isn't the default it
Re:Go back in time 5 years (Score:4, Informative)
Re: (Score:3)
It is more opaque and nonstandard.
However, the thing that makes it a dealbreaker for me is that it reduces the granularity and flexibility of the system. It absorbs far too many system services. If it were just an init manager, I'd have no real qualms with it. That it goes way beyond that, and important applications are beginning to require it, means that it signifies a huge shift away from the sort of system architecture that is the very reason I'm using GNU/Linux systems to begin with.
Since it's removing
Re: (Score:3)
Re:Go back in time 5 years (Score:5, Insightful)
I don't see why your BeagleBone black example is systemd's fault. It has a convoluted way of managing network interfaces because it uses connman [01.org], a network-management daemon from Intel that is not part of systemd.
Re: (Score:3)
I don't think he is saying that it is Systemd's fault. He is using it as an example of what he expects Systemd to become.
Re:Go back in time 5 years (Score:4, Insightful)
And that's why no criticism of systemd is to be taken seriously: it's always about how terrible it will become in the future, never about actual problems it might have today.
Re:Go back in time 5 years (Score:4, Interesting)
Don't worry, there will be plenty of those. Here's one:
I am testing Jessie with systemd and find that systemd absolutely refuses to mount a btrfs filesystem in degraded mode even though I explicitly set the option in fstab.
Can anyone tell me how to either force it to at least attempt mounting or to have it leave fstab alone and call my script to do the mounting?
No, dropping to an emergency shell so I can mount it manually over IPMI is not an acceptable alternative.
Re: (Score:3)
Re: (Score:3)
The point here is that of all of the advocates claiming systemd skeptics are just afraid of change and that systemd is just fine as is cannot seem to come up with a solution to this problem. It's almost as if they don't actually know anything about the software they advocate...
As for solutions, I know a free one involving going back to sysvinit. I'm not going to get paid support for a test installation. If a simple problem can't be solved simply, it will just be rated not ready for prime time.
Re: (Score:2)
There have been plenty of those: legitimate, technical complaints about design flaws, suitability, and downright broken shit. Yet, somehow, that all seems to fall under the "Lul Change-hating luddite uniz nekbeard" response. So I really don't think we can take any proponents of systemd seriously, either.
Since Debian's not going to protect me from this svchost-cum-kitchen-sink abortion after all, looks like we're going to FreeBSD!
Re: (Score:3)
Since Debian's not going to protect me from this svchost-cum-kitchen-sink abortion after all, looks like we're going to FreeBSD!
See how that works? Then you'll be able to feel as superior about your OS to other linux distros, as you do about Windows.
Systemd pain now (Score:3, Informative)
...and I don't understand why "systemctl isolate multi-user.target" vs. "systemctl isolate graphical.target" [try explaining THAT pair of command lines to start with] can't be expected to b
Re: (Score:2)
I'm not sure if there if Angstrom ships with a better network manager, but Arch Linux Arm on the Beaglebone uses the netctl [archlinux.org] by default, which makes this process quite simple. Just copy and edit the ethernet-static config and systemctl start netctl@enp2s0.
CONNECTION='ethernet'
INTERFACE='enp2s0'
IP='static'
ADDR='192.168.0.200'
GATEWAY='192.168.0.1'
DNS=('192.168.0.1')
Re: (Score:3)
Well, ifconfig on Linux hasn't had a release since 2001, and is considered deprecated by the Linux devs. Some distributions provide its former functionality via iproute2 [linuxfoundation.org], which is sort of a successor. However it's pretty low-level. In some environments (esp. servers sitting in a colo) it's perfectly fine. It tends not to do what people expect from a network stack on movable devices though: saved wifi networks and wifi autoconnect, sane management of hotpluggable interfaces, etc. For that, you need some kind
Re: (Score:3, Interesting)
Funny thing, i could have sworn that even Torvalds claimed he would stop using ifconfig when they pried it from his cold dead hands. And i can see why. The ip command is convoluted to the extreme. Just looking up the interfaces and their addresses seems to need some switch or other, never mind toggling a interface state or changing the address.
Re: (Score:3)
in the old days if you wanted to set your DNS servers on Linux you edit /etc/resolv.conf and change them.. Done. no reboot or ifdown/ifup necessary. Nowadays? on Debian and Ubuntu at least with the resolvconf package you have to edit /etc/network/interfaces then ifdown/ifup your interface and if the interface is the only one and you are connnected via ssh you are screwed. or you have to reboot the server to get the changes to take effect. Or you have to type a fucking convoluted command eg:
echo "namese
Re:Go back in time 5 years (Score:5, Funny)
Tell me why any of that is necessary? It's exactly like how Windows manages network interfaces.
Don't worry - systemd will handle that for you, and bring your interfaces up whether you want them up or not, using hundreds of sensible MSDOS .ini files. And if you run into problems, you can always check the systemd-journald binary logs through a suitable systemd secret decoder program. Unless, of course, the system went down before the non-transactional logging went to disk.
Re:Go back in time 5 years (Score:5, Insightful)
I don't know what trolling with massively inaccurate information gets you. It's not a massive program, it's a collection of small daemons implementing basic OS services needed by modern desktop and server deployments, one of which is PID 1.
Re: (Score:3)
All so completely co-dependent that they are an all or nothing proposition. Thus, one massive program.
No it isn't. It is completely modular. In only have the init part installed, I can choose to opt in to other modules as I wish. It is all one project, but it is a MODULAR project.
Go back in time 5 years (Score:3, Interesting)
You are aware that most of the systemd daemons do NOT run on PID 1 (and none of them on PID 0), right?
Re: (Score:3, Interesting)
Re: (Score:3)
THIS (* see below) dizzying pile of config files with nondescript names. And that doesn't even include the set of names that are magically generated either implicitly and from other files. For reference, /etc/init.d has less than half this many files. Furthermore, to know what actually is going to boot, I cd into a directory and type "ls". Can anyone tell me which of these is actually going to execute when my machine boots?
To answer a non-rehetorical question: Can any of the systemd lovers (or haters,
Re: (Score:3, Informative)
To be fair, you'd be laughed out of town for saying that today, too, partly because the init daemon runs at PID 1 (not zero), and partly because not all of the systemd daemons run at PID 1. There are quite a few of them and only the first has PID 1. If you'd like to learn more about systemd, or at least mask your obvious unfamiliarity with init systems, you may want to start with Wikipedia [wikipedia.org].
Re: (Score:3)
Actually, I think it's a problem that the anti-systemd forces keep going on about "the unix way" and what-not... haven't they been paying attention to the way things really work? (Hint: if esr says it, it's probably not quite right. [1])
Perl kicked Bourne butt by merging nearly everything you want into one process-- that's something you'd think a sysadmin would've noticed.
It is however a point that betting your system security on a new, gigantic project is kind of dubious, and I have a lot of sympathy
Re:Go back in time 5 years (Score:4, Interesting)
BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.
Re: (Score:3)
BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.
What you say doesn't hang on a pitchfork.
If the big commercial unix versions (Solaris, AIX, HPUX, IRIX) failed due to their complexity, the solution for the winner, Linux, is not to increase complexity. It's because of the toolbox approach where you can always upgrade one component without touching others that Linux won. Going back to smit-like administration abstracted five ways from hell and with tentacles into everything and its godmother isn't going to make people flock to Linux.
Splitting sysv init in
Re: (Score:2)
Case in point, Dell's NetExtender software - on Windows it won't let me connect to a VPN because the cert is self signed. On Ubuntu the NetExtender client presents a dialog to the effect that, and I'm paraphrasing "The cert is self signed, do you want to continue?" the first few times and
Re:Go back in time 5 years (Score:4, Funny)
Soon, all linux distros will contain 3 files: /boot/image-blah /vmlinuz /sbin/systemd
You won't need anything else!
Re: (Score:3)
Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers.
That depends on how you do it. If you were to use the massive disinformation campaign you're perpetuating, and those who know better didn't speak up, then systemd would die on the vine. However, if you accurately describe what systemd does, then Linux would be five years ahead of where it is now.
Having actually read what systemd does, I'm looking forward to seeing it on my machines. It seems to solve several important problems, and seems to be well architected.
So far, every argument against systemd I've
This is the same community (Score:3, Funny)
This is the same community that you can still start a street fight, or at least a troll war, by asking "Which is better: emacs or vi?" I'm not sure they're ever going to get over this. But, like the above question, the world will move on and leave them behind.
Re: (Score:2)
And the street fight always ends with a dozen more forks. ;-)
Re: (Score:3)
Take your vim and shove it! </sarcasm>
Re:This is the same community (Score:5, Insightful)
Yes, you are right. It is always better to not fight. If something inferior is becoming the new standard then oh well. It is better to just let it happen than to show the outside world an ounce of disagreement. As soon as a community does that they might get some internet person posting snarky comments about leaving them behind. The horror!
Re: (Score:3)
But commercial isn't the same at all. Commercial developers are employees. They don't have to like the direction their product is going. They are paid to work on it, they are paid to do what their bosses tell them to do. I work on commercial software myself. Sometimes I don't like the direction my company takes. I can give my bosses my thoughts, sometimes it even makes a difference. At the end of the day I compromise by doing what I am told to do and they compromise by signing my paycheck.
Why would a d
Re: (Score:3)
Systemd won all the hipsters who think Gnome devs make good decisions. The working sys admins are still on the other side of the room, admiring BSD.
It's the developers who made this choice, if they were a minority then the majority could easily continue maintaining distributions with SystemV init systems and the systemd distros would die out. I understand not everybody can be a developer but the core concept of open source is that if you don't like what the author has produced you either develop it yourself or pay somebody to develop what you want for you, it seems people are reluctant to do that and are instead choosing to move to BSD. But that's not
Re: (Score:2)
It ain't just the linux community. Look at islam vs every other religion. Look at national politics. Look at yes-manmade-climate-change vs no-manmade-climate-change. Look at yes-carbon-sequestration vs no-carbon-sequestration. Look at yes-nuclear vs no-nuclear. Look at just about every area of contention in present-day society.
Re: (Score:2)
Funny enough... after 2 decades of hearing that argument.. I don't hear anyone care anymore. They both have found niches and GUI oriented IDEs have mostly replaced both as developer's day to day choices. This one was finally settled by going from 2 main options to 50 options.
No, wrong community (Score:3)
Yes, there are emacs/vi fights, but in truth these are in fun. There is not a single vi user who would say that they should build a distribution where emacs did not work. There is not a single emacs user who would say it is OK to build a distribution where vi did not work. Everyone in this community would really say, even though you may be stupid for making your choice, our distribution should work under whichever you choose.
This General Resolution was about making certain that the distribution still wor
Kum-ba-yah (Score:4, Insightful)
some developers are already trying to mend the community and soothe the wounds.
I'm not sure that giving people warm fuzzies should take priority over steering the ship in a direction that has proven successful for more than a generation, and which has allowed diversity to flourish.
Insight (Score:4, Informative)
not quite; voted not to decide the issue this way (Score:4, Informative)
It's a bit more of a meta-outcome. The option that won the vote said, more or less: the General Resolution (GR) process in Debian is not the right way to resolve this dispute.
There was a proposed option which would actually have explicitly said: packages are not required to maintain non-systemd compatibility. But that option did not win.
Comment removed (Score:4, Interesting)
Re: (Score:2)
SystemD is controversial enough that Debian should give the user the choice to decide whether they want systemd.
This is exactly what some other distros are doing, gentoo for e.g. Leaving parallel openrc with eudev as base or one can move onto a systemd implementation. Recent install handbook reflects both methods. Why can't Debian do something similar ? Manpower purposes? Too much of a split or too confusing for the user base ? I fail to understand the reasoning for choice as well.
Re: (Score:2)
I haven't used some of the distros you listed but, I know distros such as gentoo are a build your own linux kit wheres Redhat and Ubuntu are intended to "work out of the box" with Debian somewhere in the middle. That makes a major difference in how the maintainers set things up and what level of alternatives they wish to supply. Each method has their advantages which is why each type exists. Most 3rd party products for linux prefer the Redhat and Ubuntu approach because they have a much better idea of w
Re:its all about choice. (Score:5, Interesting)
I fail to understand the reasoning for choice as well.
I think I get this.
One example: I have a handful of shell and perl scripts that I use to manage virtual machine interdependencies at startup time - this vm needs to be listening on this port before I can think about starting this other vm, etc. and I express that in a JSON tree for configuration.
I've recently been noticing that the dependency "engine" is a bit buggy and also duplicates much of what systemd already provides (pre-dating it by some years), so I'm going to look at making it work with systemd instead and cutting out a bunch of the code. That also gets me pretty easy dependency tracking on various filesystem mounts, network status, etc., so it could be better than 'sleep 20' in some spots.
Now, if I wanted to offer that up to the community, somebody could choose to package that into Debian. Assuming my experiment works, systemd would be a hard requirement to use this particular system.
Somebody in the Debian community proposed that for this package to be accepted I would also have to [re]write another dependency engine and support that. I can't see doing that if the systemd approach works.
Does it make sense that people who don't want to run systemd (which is fine) also can't impose additional work on developers who do want to use systemd?
Re:its all about choice. (Score:4, Insightful)
Why do KDE and Gnome require Systemd as designed? Can someone explain that to me? I really don't get it. They are Desktop managers. They put decorations on windows and shortcuts plus widgets on the desktop. Systemd is an init replacement. It manages the starting of daemons. What the h377 does one have to do with the other? I think Systemd is not the only bloated, over-reaching project if this is a problem.
Re:its all about choice. (Score:5, Interesting)
They want a process to handle things like shutdown, reboot and hibernate via a UI dialog. Previously, Consolekit was that process. But Consolekit was scuttled in favor of Logind. And Logind is dependent on Systemd running as pid1.
Btw, the guy that had the reins of Consolekit at the time of its closure was Poettering...
Re:its all about choice. (Score:4, Insightful)
The only reason, AFAIK, is because it's of strategic advantage to the systemd project, and by extension, Red Hat. (If someone has evidence to the contrary, I'd love to hear it.)
I've used systemd since mid-2013, and since then I've acquired a fair few reasons to dislike it, but it's the management of the project that bothers me more than any technical aspect. The systemd modules all seem to depend on the process manager and journal. The process manager requires that systemd also acts as init,* and user instances require a root instance. None of these dependencies need to exist - even the journalling library could be replaced by a shim that just forwards everything to stderr. Traditionally they would have been separate projects and such dependencies wouldn't exist.
* Systemd is a much better process manager than SysVinit, but there was never any reason to prevent the user from choosing another init.
Re: (Score:3)
For one thing, they are using systemd to query and make changes to the system config, since they have GUIs that need to do this. IMO they should be written to fall back to the old way of doing this directly if systemd is not present, but the tradeoff is extra programming and maintenance work.
Re: (Score:3)
They could just call /sbin/shutdown. I used KDE for years BEFORE there was such a thing as consolekit and it worked this way just fine!
Debian OS is no longer of use to me now (Score:3, Interesting)
I intensely dislike systemd and all of its methodology - it's not the Unix way, and I really dislike the systemd developer's attitudes towards bugfixes and other problems with their processes. Systemd is a solution looking for a problem.
As an admin in a company with something like 50,000 *nix machines, of which I have root on about 10,000 of them, systemd will not be making an appearance on any of these systems and the vendors have been appraised of this fact. Any vendor that cannot provide an alternative to systemd will not be in the running for the next phase of server rebuilds.
Personally, I think I'll be migrating all my own personal servers and the servers of my University's computer society to something a lot more useful and not requiring systemd to boot. Going to be a fun time.
Re:Debian OS is no longer of use to me now (Score:5, Insightful)
Sysadmins live and die by their automated scripts. There are scripts that were made 15 years ago for FreeBSD, and they still work to this day. Linus takes the stance of "don't break userland". If you're going to break your user's scripts, you'd better have a damned good reason.
Systemd Is Inevitable (Score:2)
Re: (Score:2)
From what I gather, it's not *that* bad - most apps depending on systemd do so for the cgroups support. If one could extract the cgroups functionality into a separate library and get projects to use that instead, the need for systemd would be a lot less.
Systemd is eating up everything low-level though. Before systemd, a Linux system would look like this:
Kernel -> (collection of init/syslog/pam/udev/whatever) -> Bash -> GUI
Now it's
Kernel -> systemd -> Bash -> GUI
And to be quite honest, I'm
Re: (Score:3)
That's the case now but soon desktop environments will start using logind and applications may start using journald. As systemd continues to offer more tightly-coupled modules, applications will likely start relying more on these modules until the point that systemd will likely be a requirement for almost all applications and desktop environments.
Re: (Score:2)
As the tentacles of systemd reach out and penetrate more areas of the system, more applications will inevitably require systemd which means that a Linux installation without systemd will only be able to run a small subset of Linux apps. Even though there are alternatives currently in the works for the init portion of systemd, applications are beginning to depend on the tightly-coupled processes that systemd requires which means that the only viable replacement for the entirety of systemd is another implementation of tightly-coupled procs which defeats the purpose of writing an alternative in the first place.
This isn't how it should have to be.
One of the major faults with init scripts was that when you had inter-dependent systems you had to modify scripts to allow for the mandatory and optional pre-requisite processes and resources. What systemd could have been was an Inversion of Control framework where the initscripts morphed into wireable components so that the system administrator could define whatever network of dependencies he/she required.
Instead, the components are limited in functions compared to init
Re: (Score:2)
I'm starting to think... (Score:5, Interesting)
That SystemD is bad for Linux not because of the technical merits but the political BS drama it's spawning. Technical wise I can see why server admins want to have the fine grain control of their start up through individual scripts. It makes sense to me even though I don't do administration. KISS is the order of the day and flat text files beat out binaries any day. Now for desktops SystemD seems fine to me for people who run out of the box systems.
Honestly the whole thing sounds to be a fix that works better for some things but is getting shoved in to other areas where it isn't needed, wanted, and maybe even detrimental to the operation of other systems. Kinda like when Ubuntu/Gnome went with more touchy modern interfaces on desktops when really it was tablets and phones their interfaces made the most positive impact while negatively effecting others on the desktop.
I think it's time for some people to get over the one size fits all mentality in the Linux community. Obviously other people have problems with it and it's going to end up tearing you apart in the long run while scaring off others who sit on the sides playing with the toys you folks made up to this point. That's going to leave companies like Microsoft grinning like a Cheshire Cat.
Systemd appears to me like the Dolphin of init. (Score:2)
Systemd appears to me like the Dolphin of init. Dolphin had the clear mission: To be simple to use. They were willing to ditch the superiour Konqueror for it. OK, if for them one mission statement weighs enough to justify that, go right ahead. I think I'd still prefer Konqueror allthough I couldn't say if I'd be bothered to install it if presented with Dolphin as a default. Same with Systemd vs. init.
I personally am not sure if this thing turns out well. It all comes down to how good the systemd camp is at
too... many... links... in... article.... (Score:2)
STEP 1: Big change, didn't really think that one out...
STEP 2: Community outrage, people whining, people migrating away
STEP 3: Some development versions away, things actually starts to work, requested features are being added
STEP 4: We get to a pretty nice project in itself, it has identity, it has what was intended, it has far less users (ungrateful bastards!!!)
PROFIT?
Should we get involved into the design of systemd and make it take on our own problems I'm
The GR outcome (Score:2)
IMHO it was good that it ended up with the outcome it did. You'll notice that the option "we should not have a GR about this" won. What it means is that Debian elected NOT to try to force any particular solution through, but let things settle themselves through consensus decisions by individual package maintainers.
If enough people care about sysvinit, it will survive and thrive - if not, it will die in Debian, just like other things that have been abandoned. Whether project X is your pet project or not, thi
Re:The Systemd Fiasco or Hello FreeBSD (Score:5, Insightful)
Linux has become the laughingstock of the computing world thanks to the Systemd Fiasco.
An entire operating system trashed by a single incompetent clown and his shit pet project rammed down distro throats by his foaming at the mouth fanboys.
A healthy open source community would never have let this fiasco happen.
Hello FreeBSD. A pure Unix operating system run by grownups only interested in technical excellence.
There seems to be a little foaming at the mouth going on right there in your own post.
Re: (Score:3, Funny)
Rubbish. FreeBSD is insecure crap. You should be using OpenBSD.
OpenBSD is run by that thug Theo, you should try NetBSD.
What a jerk - only a loser would use NetBSD, it's DragonFly or nothing.
Re: (Score:2)
Systemd works OK in Fedora
In the same way as ketchup works ok on dinner.
It depends on what you eat, and whether you want diversity or accept ketchup-compatible slop served on fancy plates.
Systems that cater to 90% of the users isn't good enough for Unix-like systems. Because the 10% provide 90% of the innovation.
Re: (Score:2)
Systemd works OK in Fedora
In the same way as ketchup works ok on dinner.
With some dinners (eg: liver) ketchup is mandatory to kill the gross taste. For others, not.
Prediction: The *BSDs are going to receive more interest. No ketchup required.
Re:Systemd works OK in Fedora (Score:5, Insightful)
Linux distros seem to be going the way of "We're awesome, so we'll alienate all the non-awesome people and then everyone will be awesome!". Only to realize later that they gutted what made them great in the first place. They don't realize how important it was to have things the way they were because they didn't use them. Screw those power users! Who needs them anyway? Like a corporation that just let go all of their engineers and now only have marketing and sales. How long will it last? Who cares! It looks great on the quarterly report!
Re: (Score:3)
I'd doubt that Linux is alienating power users. What it is alienating is traditionalist system admins.
I know a lot of non-sysadmin Linux users who very alienated by this whole thing.
Re: (Score:2)
Or try it with some fava beans and a nice chianti.
Re:Systemd works OK in Fedora (Score:5, Insightful)
Systemd works OK in Fedora, so I don't see a serious need to run to Slackware, but if I was running a server, then I would probably use FreeBSD anyway, not Linux.
Not.
I got reminded why I didn't like this idea yesterday.
System wouldn't reboot. Flipped to the alternate consoles to see the logs and command shell. GONE.
Finally figured it out. It was a USB device and it had to be unplugged or the whole boot process would hang without any information displayed.
I've said it before and I'll say it over and over. I like the concept of a wireable process management system. But what systemd did to logging is an abomination. I didn't like binary logs in OS/2 and I still despise them.
Re: (Score:2)
Nope. It's a clear enough sign that the some people are incapable of adapting to change and cling to outdated concepts for no good rational reason. These people don't ever get any better. They simply die and younger people without such preconceptions take over. Some people think the social and cultural ideals of the 1950's are perfect and should live forever. Others think the Unix system architecture of the 1980's through the 1990's is the ideal and should life forever.
So are you saying brilliant minds such as Ken Thompson , Dennis Ritchie and Brian Kernighan (to just name a few) had it all wrong ? Quoting [wikipedia.org] as I couldn't put it better myself. The Unix philosophy emphasizes building short, simple, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design. [wikipedia.org]
Re: (Score:2)
While I do merit most of your comments , why are so many fighting against choice? This is a fundamental philosophy from previous times that should still hold merit to this day.
Re: (Score:2)
Doesn't seem much different when anyone brings up X11 vs Wayland, etc. It all boils down to 'I DON'T LIKE CHANGE!!11'
It's funny. Is there a single Linux component that people are eagerly waiting for in Slashdot?
Like "can't wait for this, it's going to make the Linux ecosystem so much nicer"?
I expect the next round of silly whining to start when distros begin to adopt KDE5. Will stock some popcorn for that one.
Re: (Score:3)
Yeah it is a remarkable change in attitude on /. over the past 15 years. People used to be thrilled about change. Now they hate it. If it were the old fogies like me I can understand, get off my lawn... But it is the young guys who seem the most fearful of change and stuck in their ways. I really realized this during the IPv6 debates when the idea of changing a network system was unthinkable. Dammit where would you all be if my generation had ripped DECNet et al out?
Re: (Score:3)
It's funny that you mention Wayland.
systemd is all about putting the kitchen sink into the startup proces.
Wayland is all about removing the kitchen sink from the window manager. (seriously, why does it include a network protocol?)
Re: (Score:2)
Why SHOULD they have gotten on board? Are they employees, paid to do what they are told? If not then they have every right to support or not support Systemd. They could have just forked. You can argue all day that excesive forking is unhealthy to the open source community. You could say that it spreads developers too thin and wastes time on duplicated effort. You would probably be right. It doesn't matter though. You can't expect an unpaid volunteer to keep working their asses off on something that the
Re: (Score:2)
Pardon my French, but that is a bullshit philosophy. It's like:
"The fascists won the election. Let's all get on board and work with them. If they won't, they are sore losers."
Another Annoying Dependency? (Score:5, Insightful)
You're barking up the wrong tree. I don't think you remember how things were before PulseAudio.
You had /dev/dsp or later /dev/snd. Since the kernel doesn't do sound mixing, they were one user only, unless the soundcard provided mixing. Which a lot of them didn't. So esd, artsd and similar appeared. Running KDE and want sound in the one Gnome app you use? Have fun making esd run against artsd. Want to run an old game or app that only knows about /dev/dsp? Sorry, artsd has it busy. You make it auto-close the device when unused? Unreliable as hell. USB audio? what is that? Certainly no plugging and unplugging support there. For a while dmix was all the rage. Thing is, dmix is implemented in the ALSA libraries, which means it does nothing for you unless your app uses ALSA libraries, so it doesn't help your any with your /dev/dsp using app.
PA was created to solve all this mess. PA basically handles everything and provides interfaces for everything, so finally pretty much all apps can talk whatever protocol they like, and work. And audio can be reconfigured as you plug and unplug devices.
Was it unreliable for a while? Yes. But there is still nothing better. The kernel doesn't mix audio. You need a daemon by design, and you need something PA-like to provide a modern level of functionality. The only way to do without PA is have the kernel implement all that, and as far as I know, the kernel devs don't want it.
Re:Another Annoying Dependency? (Score:5, Insightful)
I don't think you remember how things were before PulseAudio.
No, we remember quite clearly. ALSA worked just fine, with only one easily fixed issue: distros needed to set asourdrc to use dmix by default. Those of us that have multiple soundcards and pre demanding requirements (music pa/production)went through the minor trouble of setting up jackd, which solved all the rest of the problems regarding synchronization and very-low-latency data processing.
Really, the only thing that ALSA needed was a nice GUI editor/frontend for the config file. Those of us that used jackd already had such an editor (qjackctl, among others).
Oh, what's that? You want to claim that PA forced better drivers? That may be true, but it is not a feature of PA, nor a reason to use it. (driver fixes are orthogonal, to which software uses the drver) . Some of us actually read the hardware compatability lists before buying our hardware, too, and never had a problem with stabilitgy.
PA basically handles everything and provides interfaces for everything,
Yes, it is a wrapper around ALSA (unless you someohow usedd some some other type of sound driver than the ALSA snd-card-*.ko kernel modules). It adds latency and a giant pile of useless overengineering, when a simple config file was all that was needed (and maybe GUI editor for that file). Any of the fancier features provides were better served by jackd anyway.
Oh, and that's when it works. Even just a year ago, when I last tried PA, it introduce a shocking number of compatability problems for no good reason, and stilll added a LOT of latency.. I'm not even talking about the non-sound issues!) by simply uninstalling PA so everything fell back to using ALSA by itself. The list is so large now, that even non-technical people I know make jokes about how bad PA is.
As usual, while there is some need for improvement in ALSA ( and other linux features, but the bloated, non-working, latency adding mess called PulaseAudio is *not* the solution.