Slashdot Mirror
Debian Votes Against Mandating Non-systemd Compatibility
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 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.
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.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
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.
more insightfult news and posts from lwn. Regarding burnout and voicing concerns over systemd. lwn.net lwn.net
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Im not sure who at debian proposed this idea, that packagers be required to maintain support for non-systemd applications, but its untenable at best. It would mean a redesign of gnome, KDE, and a dearth of other code that in many cases makes no sense (how does networkManager get this treatment outside the scope of systemd?) this particular vote also smacks of an attempt at debian character assassination. the fact is that Debian, and Ubuntu, need to sit down and recognize is that open source software means If i, or users, want rc-init support in Debian for a package we can code it.. If the package doesnt do what we want we can either commit, fork, change packages, or change operating systems. Bureaucratic red tape seems to be an Ubuntu specialty thats strong-armed its way into debian from the start of Systemd. pointless electoral procedures avoid the cusp of the communities argument. SystemD is controversial enough that Debian should give the user the choice to decide whether they want systemd.
Good people go to bed earlier.
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.
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.
My feelings on this matter? :(
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.
- This sig deliberately left blank. Nothing to see, move along.
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.
You are aware that most of the systemd daemons do NOT run on PID 1 (and none of them on PID 0), right?
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.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
PulseAudio, Plymouth, or other horrible things made mandatory. Still have issues with pulse introducing noticible latency in older apps, or it will freak out unplugging and plugging in USB audio devices. Plymouth had random issues with brand new hardware. They make these things really hard to remove off the system.
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.
~~ Behold the flying cow with a rail gun! ~~
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.
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.
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 they don't even believe in. At least rather than forking, they tried to steer the project back in a direction they could support. They didn't even try to eliminate Sysemd, they just tried to keep their prefered choices alive. Apparently the people making the choices don't care. Why should they even stay with Debian now?
Still have problems with Pulse introducing latency and buffering issues in older apps. Still occasionally freaks out adding and removing USB audio devices. Occasionally have issues with Plymouth and new hardware. Why do they build up all these layers and dependencies, and make it hard to remove them?
And trying to be too much to too many different people may explain why we have 90 different daemons and systems for every single thing. Just because something isn't monolithic, doesn't mean it's automatically better.
Those folks were all brilliant for their day. The computer culture and it's users have changed significantly since their heyday though. If the past is blocking actual progress (which isn't measured in how many forks a project has), why are we so intent on fighting for it?
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 offering incentives to move to it and how well they develop. If the entire thing in the end turns out better than init and has less problems the bickering will stop. If not, Debian will switch back eventually and the systemd camp will be burnt for a long time.
We suffer more in our imagination than in reality. - Seneca
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, 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 of wrapper around it, which is what network-management daemons provide (in varying forms).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
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.
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.
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 worked even if someone chose to use a different init system. I am not sure why that is contentious.
That right there is the kind of voodoo behavior that soured many a happy Linux user on Windows (recall a Windows install that would hang unless a sound card was removed from its slot. Just hang, no error message or anything). And now it is invading Linux. That there is backlash should not surprise anyone.
They already are. A lot of the FreeBSD people are sysadmins and there's already conversion stories where these FreeBSD guys admin datacenters and some of their clients are already completely switching to FreeBSD because their sysadmins hate systemd. Then the clients realize how awesome FreeBSD is and start tell their friends, who are also sysadmins. ZFS is like crack, once they've tried it, there's no going back.
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!
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.
Watch this Heartland Institute video
Or try it with some fava beans and a nice chianti.
Watch this Heartland Institute video
I expect things to happen just like GNOME3:
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 sure it will turn out just fine. After all, the stakes are high, the stakes are many. I for one eagerly await for systemd to add plain text log/config support, just like mother UNIX wanted. Until then begone!
uhm...
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.
Except that thanks to people complaining, real work has been done on X11 compatibility. I might even be able to run a window manager like window maker on weyland without needing an entire goddamned desktop environment.
Meanwhile, people complaining about the kitchen sink nature of systemd have mostly been ignored. Is there even a promise that systemd will work properly if we choose to continue to use static network configuration for all of our servers' static interfaces over systemd-networkd? Can we keep using bind with the 20 years of accumulated cruft to manage our DNS (that none of us here dare touch because it finally works) or will we have to install systemd-resolved because systemd-* decides to abandon "legacy" nss resolution functions for a kdbus interface to -resolved that changes regularly?
Systemd is an ambitious project and it looks like it will have a lot of awesome stuff in it once it's done, but it's not done. The worst part is that it tears down the stuff everyone else has made that is done, and erects a facade that looks like it should work but then you go to open the bathroom door and it just leads outside because none of the developers have needed to use it yet. There are bugs open for over a year now on boot/shutdown dependencies for networked filesystems. It looks like they'll never be fixed and that the workaround is to just not have systemd mount your network filesystems and use an automounter daemon instead. rc and mount solved this ages ago with two passes through fstab, one mounting all of the non network filesystems and one mounting the network ones that comes after the network is up, but that process is limited by the fact that rc has no idea what networks are up and present or not. Systemd's promise here really shines: "When you're at home systemd will detect your home network and mount your home fileserver!" the reality is that the plumbing hasn't been installed.
I'd appreciate it if people would stop using death threats and being assholes to the developers, though. That's just clouding the real issues and making those of us with legitimate gripes have to gripe louder which just makes us look like assholes even when we're not threatening anyone.
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, this is just natural software evolution. You can't be in the software world for long without seeing something you like rot and be disbandoned.
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."
https://lists.debian.org/debian-ctte/2014/11/msg00091.html
I am resigning from the Technical Committee with immediate effect.
While it is important that the views of the 30-40% of the project who
agree with me should continue to be represented on the TC, I myself am
clearly too controversial a figure at this point to do so. I should
step aside to try to reduce the extent to which conversations about
the project's governance are personalised.
And, speaking personally, I am exhausted.
The majority of the project have voted to say that it was wrong of me
to bring this GR at this time. Despite everything that's happened, I
respectfully disagree. I hope that the next time a controversial
issue arises, someone will step forward to advance what might be a
minority view.
Thanks to everyone who has served with me on the TC. I wish those who
remain on the TC the best for the future and I hope that you'll find
colleagues who are as good to work with as you have been to me.
I now hope to spend more of my free software time doing programming.
dgit is at the top of my Debian queue, but some of my GNU and SGO
projects could do with attention too.
Thanks,
Ian.
Hello FreeBSD. A pure Unix operating system run by grownups only interested in technical excellence.
...because no infighting ever happens with FreeBSD and causes it to fork off other distributions such as OpenBSD and NetBSD.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Neither side is being particularly constructive in helping fix systemd's issues.
Those in the systemd camp largely plug their ears and just think doubters are merely stubborn or unsophisticated enough to understand just how *awesome* it is and that it is worth the downsides (if they'll even admit something is a downside).
On the other side, mostly the criticism is just roll back and leave things as-is. Which leaves systemd advocates unhappy because they don't get their shiny capabilities at all. Not much discussion is had on how to amend certain strategies to placate the sensibilities of today while delivering the capabilities of something new. For example, if journald simply made plaintext logging alongside (not as a downstream add-on by piping to syslog, natively doing it alongside binary data), people would probably not balk nearly so much. If a systemd unit could degrade to start without being able to talk to pid 1 or cgroup support available (with loss of function), then some debug activity is made more straightforward in a rescue environment that may chroot (yes, spawning a container is usually possible, but why not degrade to cope to the extent possible). If open ended init scripts were better accommodated and didn't try to forcibly constrain sysv init scripts to force it to fit the only models that systemd understands.
Of course some concerns are more fundamental (bringing everything possible under one monolithic development effort rather than modular design that has discrete owners using simplistic yet consistent vocabulary to communicate with each other). But a lot of the specific technical issues could be alleviated by modification of systemd while preserving the stuff that there is to like.
XML is like violence. If it doesn't solve the problem, use more.
recall a Windows install that would hang unless a sound card was removed from its slot. Just hang, no error message or anything
When is this example from, 1993?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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?)
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
They are not wrong, What is wrong however is the claim that systemd somehow should be anti the Unix philosophy, actually last I checked, systemd contained of a lot of binaries that each did one thing. Even claiming that SysVinit does one thing, or that it does it good, is bending reality.
I started in the early 90s with freebsd...
Now I'll be going back...
Its like going back to an old friend. One who trusts and respects you..
Instead of forces things on you... for your own good...
I'm not against change... but sometimes you gotta stick with what works...
It seems everyone has a dealbreaker... for me its binary logs. and the unending "Embrace extend extinguish" model. It feels infectious...
Of course the debian devs voted for it... for them , it makes their job easier.... Screw the people who actually have to use it!!!!
I don't need my servers to boot in 3 secs They have years of uptime. .. Hell the Dell bios takes 40 secs alone... I dont care about how fast the devs can make their macbook boot debian!!!!!!!!!!!!!!!!!!!!!!!!
With the failure of this GR, it is clear that I can not trust Debian to ensure that systemd remains optional. As such, I cannot trust Debian to remain a distro that meets my needs. It's all well and good that the dependency will remain avoidable in Jessie -- that gives me enough time to enact my escape plan to BSD with minimal disruption.
I am so saddened by this whole thing. I am even more saddened that a wonderful distro that has served me very well has stopped doing so. But, I suppose, times change.
It's my understanding that the app maintainers do not want to maintain both initd and systemd compatibility at the same time... Extra work for little reward.
I, like many other sysadmins out there who do some level of coding to maintain large swaths of servers dislike the change to systemd on the premise that this wasn't a "phased" implementation. The rebuttal on the systemd camp is that it cannot be phased in and too bad, so you have to rewrite a few scripts and make a "few" changes to your administration processes. They do not realize it is more than just a few changes for many though and I think that's where much of the anger lay boiling... lack of empathy on either side.
It can be said that the height of maturity is being able to admit that you were wrong.
The problem with Lennart Pottering, and thus systemd, is the inability to admit that he is wrong sometimes. How he handles responding to a lot of bug fixes makes this very apparent. "Yes this is a bug, but I won't fix it."
Do you really want to use an init system from someone like that? A lot of the systemd bugs will ALWAYS stay systemd bugs. Plus he has openly stated that he eventually wants, basically, his own operating system. Nobody really seems to mention that this is exactly what he is doing now.
I like people with ambition, but watch some of the YouTube videos of him chastising people. He is very rude and arrogant. I don't want anything coded by that guy on my computer. He doesn't deserve it.
I think a lot of the tactics he is using to get systemd adopted/forced on distros now is because he knows it won't happen through pure open choice. He is not wasting any time. In the end the people will have their say. It is a shame that a lot are simply leaving to FreeBSD quietly without giving a solid piece of their mind.
Sounds like the Redhat/Fedora boys...
Now, we are witnessing what happens if you allow the bystander effect to pervade your community. It was ok for everyone to let Red Hat move developers into the lead positions of key projects and become their gatekeepers. Stuff was getting done, and it was mainly on Red Hat's dime, so everyone was content to just sit back and benefit from their work. But then Red Hat decided to make the projects it has control over interdependent on each other in such a way that you will no longer have the choice of cherry-picking what Red Hat technology to adopt for your use. It'll be pretty much all or nothing unless you have the resources of a large corporation to go it your own way. Suddenly the rational behind having multiple distributions is weakened because it you want to run a systemd system with wayland and gnome, why wouldn't you go with a distribution made by the company that's responsible for the creating and maintaining that technology in the first place? Debian's glacial pace of development, which used to be a feature for its stability and reliability, is now a detriment because the versions of systemd, gnome, gtk, selinux, dbus, etc. are going to be perpetually out of date and dependent on an upstream for fixes that couldn't give a shit about backporting patches. Prediction: Debian is not going to exist in 5 years.
The claim that "YOU JUST DON'T LIKE CHANGE" must be one of the most stupid arguments I have seen in this (or similar) debates. As if Linux hasn't changed before. It developed from a minor hobbiest project of a student to a system which took over the UNIX server market, runs on allmost all super computers and cell phones. You think it did not change it all that time?
So, yes, that is long ago, but Windows 2000 implies at least the year 2000.
Linux didn't complain at all.... Yes, I was running Linux back then in dual boot.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
...And all the rest being forked off of 4.3BSD back in the day. So if by "completely separate" you mean "not really separate at all," then sure.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
How the hell do you think changing PID 1 is supposed to be phased?
It is literally the first process which runs on Linux. Please explain "phased change" when something that fundamental is being altered. You might as well say "I'm outraged we had to get kernel 3.x all at once! It should've been a phased upgrade...."
I don't understand how this didn't get modded funny yet. Made my giggle like a school girl. tee-hee
FreeBSD, OpenBSD, NetBSD, and DragonflyBSD, all share a lot of code enhancements. Several times a year you hear how FreeBSD is porting kernel enhancements from NetBSD or OpenBSD is porting some sandbox code from FreeBSD or FreeBSD is importing better thread friendly data structures from DragonflyBSD. There is yet another BSD that recently forked FreeBSD with the sole purpose of being a test-bed for new security code testing, and when something works well, they'll push it upstream to FreeBSD.
I'm running arch. Arch moved to systemd before I understood the issues at stake. I feel the systemd pain every day. I'm trying to get multi-head with nouveau working (a different set of pain, that I'll probably just switch to nvidia blobs to get around -- unless someone can point me where I want to be -- but I digress)
...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 be as dependable as "telinit 3" vs. "telinit 5".
If I couldn't ssh into the box from somewhere else regularly, I'd be hitting the Big Switch a lot and we all know how well file systems take that kind of shenanigans.
I don't need to wait five years to hate systemd. I hate it more and more every day. My feelings do not extend to the authors -- as humans, they deserve my compassion and (in this case) pity. But I hate their software with a passion that grows more intense by the day. This is a sad day for Debian, it was one of the places I was thinking of escaping to.
Still hoping for Gentle Treatment...
you cut all the tall trees down
you poisoned the sky and the sea
you've taken what's good from the ground...
(midnight oil)
and now this.
it's the end of the world
as we know it.
(r.e.m)
it's like climate change - either we get smart, or we get wiped out - debian, clearly, are not getting smart.
fork it.
Wayland is simplifying how windowing works SystemD is complicating things. Wayland does one thing and it does it well, SystemD does everything.
yea, with a brick.
I love Debian. It is the best operating system on Earth and is important for our future.
It does not surprise me that there might be certain actors intending to intentionally disrupt and destroy Debian but fortunately it is more than strong enough to withstand any covert, black op attacks.
Doesn't seem much different when anyone brings up X11 vs Wayland, etc. It all boils down to 'I DON'T LIKE CHANGE!!11'
Someone always brings this up and usually as a bad thing. No one's explained why change for the sake of it, especially whe nthe new system has some obvious deficiencies (as well as merits) relative to the old one.
Change for the sake of it isn't a good thing.
It's funny. Is there a single Linux component that people are eagerly waiting for in Slashdot?
Not sure. The thing is for many people Linux works pretty darn well right now. I don't particularly eagarly await a feature which makes it easier for other users because why would I? It isn't something that affects me day to day.
I mean sure it isn't perfect: nothing is. Given more time, I think I could come up with something. But mot days, I just log on to Linux and get hacking. That means for me, the nuderlying Linux system isn't getting in the way. If it's aiding my work and not getting in the way, then there's nothing terribly pressing that I'm eagarly awaiting.
SJW n. One who posts facts.
Don't wait five years. I find systemd to be more and more annoying every day. The closest things I can find to "telinit 3" and "telinit 5", "systemctl isolate mulit-user.target" and "systemctl isolate graphical.target" (and talk about convoluted command lines!) can't be counted on to stop and restart the GUI part of my arch box.
Give me back my sysvinit. It may have looked crufty to some but it worked. systemd? meh
Still hoping for Gentle Treatment...
Disagree and commit is a bullshit philosophy, for government. However it's ideal for corporations to actually get work done without endless internal squabbling.
Wayland is all about removing the kitchen sink from the window manager. (seriously, why does it include a network protocol?)
Simple answer: it doesn't. It's amazing how much the criticisers of X fundementally misunderstand the architecture of it. The window manager just makes xlib calls. It happens to work over the network because the underlying transport for the API can (note the optional part of that: can) go over a network. Nobody puts networking protocols into window managers.
SJW n. One who posts facts.
There used to be, I feel like things are worse than they were 7 years ago now.
Compiz was stable, drivers were good, motherboard support was better, Gnome 2 just spoke to me in it's looks.
I haven't built a system for a while, but the last one I built won't boot with a USB drive plugged in, the desktop environments were shaky, video acceleration meant playing h.264 videos, and that was a no go. Gallium still isn't working.
Ubuntu 7.04 was for me, the peak of usable, workable Linux vs other OSes. 7.10 introduced a locking while heavy disk bug, and Linux in general has been frustrating since then (I've dabbled in Linux, or run it as my primary desktop for over 15 years).
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Yeah, just because I don't need that feature, lets rip it out for everyone, right?
That is very short sighted thinking. Sure the code is old. Sure it is crufty, but it works! Why remove something that is working now for something that may be created in the future? It would be a shame to throw out working code for a new unproven shiny binary. I'm all in favor of new stuff, but not when developers remove working features and promises they'll get to it later. It won't happen; if they wanted to do it, it would be done at the same time. It's a hard problem, and chances are, later will never come.
Before you criticize it, have tried to use the feature? It is immensely useful to be able to be able to render a single window locally without having to drag the system down rendering an entire desktop via VNC, RDP, NX, etc... Can single windows be rendered through RDP? Yes, sure. However, that requires some setup, where on Linux I just hop over to that server and type the command (usually with a &) and bam, local view of remote server.
All that aside, I'm not the only user of the technology. Other projects use it as well, such as WinSwitch, x2go, FreeNX, NoMachine's NX - although maybe less so since version 4. Try some of these, you might light what they offer.
I'd doubt that Linux is alienating power users. What it is alienating is traditionalist system admins. Going back traditionalist system admins had traditionally been drawn to BSDs and the big box Unixes. Most likely those guys learned to admin on Linux when they weren't traditionalists and became traditionalist with time. The product no longer fits.
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?
That's a reasonable comment. And the answer is.... most likely no. Older configurations probably won't work. Systemd one the server side is tied to IaaS and PaaS deployment. Most likely those old fashioned systems will migrate to some traditionalist child of Debian that doesn't use systemd. They are legacy systems and should be handled like legacy systems.
Honest question. What does Linux offer for servers that BSD does not?
Ken Thompson , Dennis Ritchie and Brian Kernighan were trying to build a smaller simpler Multics. They agreed that given additional hardware resources the Multics approach fit many use cases better. If you are going to cite their ideas cite them accurately.
No one is fighting against choice. The way Linux has traditionally delivered choice in the sorts of situations where it is an true either / or situation is through the distributions. Different distributions had different application stacks. Debian eventually primarily became a parent distribution so that the children under it could specialize. That's the way choice should be preserved. There should be a non-systemd traditionalist child distribution of Debian. Several of these distributions that are non systemd already exist.
But the general purpose Debian should mostly follow the Linux community.
It possibly could have been phased for Jessie. If the proposal had been Jessie is a transitional distribution and the next one is systemd only, that might have worked. The problem is the anti-systemd people wanted non-systemd long term.
The option of a smooth transition is the sort of compromise that heated debate destroys.
Fork. Go ahead. The systemd people have always supported a child distribution of Debian that doesn't support systemd. That "threat" had the full support of systemd. In fact if you can submit patches to keep stuff working on initd as dozens if not hundreds of upstream developers start dropping init support all the better.
Please do it.
Unfortunately, you summary is accurate. I still do not understand how these people could creep in. The sheer magnitude of resistance should give them pause and reconsider whether they may be doing something wrong. Instead: Total confidence, absolutely no acknowledging of problems, no interest at all in compromise. It it is almost like arguing with religious fanatics...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. Basically they voted to keep this unresolved for the moment. Of course, the systemd fanbois want to sell this as a victory for their side.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If the systemd movement was sane, that is exactly what would happen. Instead they have the total confidence and unshakable faith in their chosen fetish that otherwise only religious fanatics have. From the time I realized this, I have lost all respect for them and all motivation to argue the case: These people are not sane or rational. They do not want choice or freedom. They do not listen to arguments, no matter how accurate or justified. They want their thing to be the only thing allowed and though shalt not have any other thing. They are the enemy and must be fought.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Perl is hardly an example of improvement. Its widespread usage despite its fundamental flaws has given us a large body of software that is often entrenched and almost always a maintenance nightmare. I hope our OS distribution maintainers have the sense not to repeat that mistake with our init system.
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.
Crux and Alpine have both said their long term plan is non-systemd. They intend to drop packages that can't be made to work without systemd.
Slackware is going to hold out as long as it can. Patrick doesn't think that's more a couple more years.
Gentoo because of the lack of integration will likely in a formal sense be able to hold out forever. They have however mostly abandoned their own OpenRC alternative. So they know they are in a holding pattern at best.
PCLinuxOS is KDE-desktop based. I'm shocked they aren't already systemd. No chance they holdout.
Me thinks you need to get a grip.
Possibly since there is a fire. But I don't many Debian users who aren't system admins. It was never a particularly good desktop or workstation distribution. Once the debian repository became available in other distributions like Ubuntu...
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, a network-management daemon from Intel that is not part of systemd.
I installed ubuntu 14.04 on my BBBs. (Had to upgrade the kernel a little later because the 3.13.0 kernel wasn't ported to arm-on-bone in time to go out with the original 14.04 distribution and the 2.whatever they shipped didn't handle a class of USB device I needed, but it's fine now at 3.13.6-bone8.)
Changing to a specified, fixed, IP address was just a matter of editing /etc/network/interfaces, which was commented well enough (in combination with the man page on my ubuntu laptop) to make it easy.
(Main problem was that DeviceTree overlays weren't supported by 3.13.0-6, so I had to hack the boot-time base device tree to reconfigure for the onboard device functionality I wanted, rather than just overlaying the deltas during or just after the boot procerss.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
In less than two weeks we have had three significant resignations:
8 Nov, Joey Hess, from Debian entirely
17 Nov, Tollef Fog Heen, from the systemd team
Today, Ian Jackson, from the technical committee
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Yeah, pretty ridiculous then that a Linux distro will start exhibiting that sort of behavior in 2015, don'tcha think?
It's rather telling that systemd introduces and relies on MSDOS .ini files from the 80s-90s era.
In ten years time, the systemd will probably introduce the registry too.
Porting an HP-UX ServiceGuard system, I collapsed 40-odd services into runlevel 3 and 4. These became aliased essentially to ON and OFF for my operations people. This worked, but I would have appreciated granular control.
Inittab has a "respawn" function that lets init watch for your program and restart it when it dies - IF you don't daemonize. You also don't get the ability to launch as a non-root user (had to write a shim for that) or establish environment variables (had to script a shim for that).
I also wrote an /etc/init.d script to start any oracle instance mentioned in /etc/oratab with hard links to the script. systemd is not QUITE as flexible there, requiring me to maintain a separate service instance files for each ORACLE_HOME.
So yes, on the whole, I would have jumped all over systemd 5 years ago. As it is, I am even now looking forward to trashing all the glue I wrote.
That said, systemd needs a BSD-licensed multi-call binary like busybox.
p.s. Parent, it's PID 1, not zero. :)
it's ideal for corporations
Corporations like...Debian? Uh...
.: Semper Absurda
Normally I might feign something. But for real, how did you figure it out? Because that makes a huge difference.
I was asked to get my girlfriend's mom's pictures off the hard drive. I took peripherals out, and decided the keyboard had to go. The keyboard of the notebook. So I hooked up some USB stuff and booted the thing and copied things and all was good.
I didn't have log files, and I didn't need them. So how did you figure it out, and would it have been different with text logs?
except in a VERY black way.
Still hoping for Gentle Treatment...
With some dinners (eg: liver) ketchup is mandatory to kill the gross taste.
If your liver tastes gross, the person preparing it is probably not a very good cook and no amount of ketchup will cover up the taste.
And that seems to be working an analogy as well.
The mountains of madness have many little plateaus of sanity - Terry Pratchett.
If that's the case, why isn't there a simlar shit storm about Wayland?
Easy, because:
1) Wayland is truly optional and essentially a drop in replacement for X
2) Wayland is not attempting to take over other functions it's not supposed to be touching
3) Wayland does not do binary logging or make you jump through hoops to actually see what's wrong with your server if it doesn't boot
I really like Wayland, since it is an improvement on X. I hate systemd with a passion (this is after having to put up with systemd zealots like you), because it's a bloated piece of software, with an ever increasing feature creep that destroys the modular architecture of Linux, while not being an improvement over the current systemV init.
The mountains of madness have many little plateaus of sanity - Terry Pratchett.
- parallel read/write to multiple disk in RAID5 in btrfs (speed!, specially when multiple reading/writing userspace processes on btrfs which contains 10+ disks)
- pull back multi-path mgmt at FibreChannel driver level in kernel (WTF userspace need to know that scsi device have multiple path, userspace just get device and use it, rest is kernel work to handle, IMHO)
- throw out interface teaming (bonding is more that good, long time used in production, with VLAN tagging. 0 problems :)
p.s. you ask for Linux, not GNU Linux. Right? :)
There is a lot of heat in this discussion, but not much light.
It seems the systemd developers and their managers have lost contact with some of the people that build and run linux server systems.
I am not taking any position on whether systemd or sysVinit is 'better'., but
What are the developers going to go off and change next?
Has the master forsaken us?
--
The year of linux on the desktop approaches, because the server rooms will all be BSD.
I don't normally disassemble my computer when it stops running after a software upgrade. I don't normally expect a software upgrade to make the system unbootable. Maybe it's because I don't run Windows.
And when I do have problems, I normally start by trying to boot into single-user mode and looking at the logs. Assuming that - as the case used to be - I didn't see something alarming flash up on the console while it booted.
I lost the better part of a day's productivity learning about this USB quirk after I couldn't get access to the logs - or at least the stuff I was used to seeing. I really wasn't in the mood to wait while it rattled up and down 2 years worth of binary data while disconnected from help resources on the Internet. I didn't used to keep 2 years of logs, but systemd's default is based on how full your disk drive is, not how much info you really need. And as far as I've ever determined, there's no simple systemd equivalent to relocating the primary log, starting a new one, chopping out just the parts you want to retain via head/tail/grep/snip, whatever. OR just having it sliced into tidy chunks automatically via logrotate.
I've got to stop now. My blood boils just thinking about it.