SoylentNews is people
SoylentNews
Debian Jesse is going to have Gnome3 as the default desktop.
The desktop re-qualification page, used to help choose which desktop will be default, has in the Jesse version a weight for systemd integration, and of course only Gnome3 does it (at least for now). This will surely make the systemd/gnome3 fanbase happy, but possibly will make others unhappy, as it [may] be seen as another step towards mono-culture, until we soon end up with all distros being redhat clones.
This discussion has been archived.
No new comments can be posted.
Integration with systemd Making Gnome3 the Default Debian Desktop
|
Log In/Create an Account
| Top
| 135 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You are always busy.
(Score: 2) by caseih on Wednesday September 24 2014, @02:48PM
And what problems are these? Please list them.
It's really surreal to read about systemd on sn and sd. Groupthink is clearly against systemd with very little argument against systemd other than some weak philosophical arguments, or saying that old sys v init scripts were good enough. Very few arguments against systemd come from people who've spent any time to understand its architecture, to say nothing of actually *using* systemd. One person on sd actually claimed he preferred using Windows to Linux with systemd, which is pretty bizarre, given Windows' service architecture. systemd really has zero impact on 90% of users, and a huge benefit for many, including those impacted by it (system administrators, for example).
Many systems, desktops and servers, are running a distro with systemd and I have yet to hear of any real problems that show systemd is inherently flawed. And in fact some system administrators really like systemd because it's soo much simpler to get services up and running with simple config files instead of hundreds of lines of fragile shell code. Is systemd a solution in search of a problem? Hardly. I sound like a broken record, but old init scripts have lots of issues. Hacks with PID files, grepping the process list, to determine if a process is already running, or has died, hacks to keep processes running. To say nothing of the issues that laptops and desktops have with suspend and hibernate. sys v init was never designed with that in mind. But systemd doesn't prevent you from writing and using fragile init scripts. It will happily run them for you. systemd does make it super simple and easy to make a daemon out of just about any program or script, without having to mess with daemonizing in your own code. And you get process supervision for free if you want it, and process management without manually messing with PID files or other forms of fragile locking.
Not that following others is reason in itself, but Solaris abandoned sys v init scripts years ago, though I can't argue that SMF is fun to work with.
(Score: 2) by tangomargarine on Wednesday September 24 2014, @04:13PM
and a huge benefit for many, including those impacted by it (system administrators, for example).
Please feel free to tell us what those benefits are. So far all I hear is, "There are no advantages to systemd on the server. Nobody cares about boot time on servers."
I have yet to hear of any real problems that show systemd is inherently flawed.
The one I keep hearing is that if systemd shits the bed you can't really read the log files without relying on systemd itself...which sounds problematic.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by VLM on Wednesday September 24 2014, @04:31PM
So far all I hear is, "There are no advantages to systemd on the server. Nobody cares about boot time on servers."
I would moderately correct your remark in that I actively see parallel booting as an intense disadvantage for servers or any professional application (embedded, pretty much everything but generic "who cares" desktops). When some insane kernel panic happens I REALLY need to know its because of the previous log line that it was starting up mysql so start looking there. I have a huge financial incentive in not wasting time looking at mysql when the real problem is it started up 15 things at once and the sheer load blew it up or some random malloc failed or parallel process #6 tried to enable ipv6 on an interface at the same time as parallel process #7 tried to disable ipv6 or whatever other form of parallel race condition idiocy that doesn't really need to exist anyway.
In a professional environment, the only thing worse than parallel init, is dependency based or semi-non-deterministic init. So if mysql takes an extra 100 ms to start because the NAS is a bit slow today, then, and only then, does apache decide to crash, and since its at the same time its a PITA to troubleshoot and all that really matters is reboots are no longer a way to get the system to a deterministically stable state, they just kinda randomly don't work sometimes. Awesome, just what I want in a server OS (not!).
I would much rather lose 5 seconds of uptime on my redundant load balanced servers per monthly reboot than have to randomly and unpredictably have to spend hours troubleshooting race conditions once per year, not to mention potential data loss and lost labor time of the users and lost revenue. That just doesn't work out well mathematically for me.
So yeah, just architecturally, I bitterly hate the idea of systemd on a server and will actively do anything to avoid it. Its just inherently amateurish and unprofessional to use. Its an epic noob move, both technically and from the business side, to trade reliability via elimination of an entire class of potential problems for being 1% faster at something we practically never do anyway. Being dragged kicking and screaming by the OS vendor is "probably" safe, but making a business decision like that independently would be reasonable grounds for termination.
(Score: 2) by VLM on Wednesday September 24 2014, @04:14PM
"I have yet to hear of any real problems"
Product tying.
Go ahead, try to run "GIMP the image editor" with the "wrong" init system. There is no rational reason to product ty those unrelated tasks unless you have a hidden agenda, and hidden agendas aren't usually very good aka they're hidden for a reason.
(Score: 2) by tonyPick on Wednesday September 24 2014, @04:16PM
Fundamentally? systemd is trying to do Too Damn Much and weld it in via the init system, which could be better, but isn't terribly broken for most all the traditional use cases.
Removing and improving on legacy init is one job (which does need doing). The consolidation and centralisation of a grab bag of system capabilities into a common infrastructure is a different job; systemd is munging them both into one thing. Bad.
So for any core system update you're balancing risk, benefits and costs: As a developer/user (primarily in the mid-range embedded space) I'm seeing no solid benefits, large risks and massive knock on costs on the future of the infrastructure, as systemd becomes an increasingly pervasive dependency for everything from logging to authentication to networking etc...
It's not a "vi versus emacs" that if you don't like it you pick something else and go with that - it's becoming increasingly hard (as per TFA) to avoid the damn thing. This should be because it's *better*, but it isn't - it's because it's *different*. This is not a problem for Gnome and Redhat, and if you're looking at their distribution then this may even be a good thing, but the world is not RHEL, and we aren't all worried about containerised Gnome.
I could go on, but whilst I don't agree with it all this essentially covers a lot of what I would say: http://ewontfix.com/14/ [ewontfix.com]
Now having said all that; I'd _like_ to be wrong, and for it to be a painless improvement, but having looked at it I'm not seeing anything persuasive from the systemd folks and from the sheer level of crud thrown about (e.g. the Kernel debug line debacle, wrong on *so* many levels) to the state of the docs (quantity != quality) to the source code in the repo (journal-qrcode.c? Seriously?) don't fill me with the warm and fuzzies.
(Score: 2) by tonyPick on Wednesday September 24 2014, @06:49PM
And replying to myself here, but you always stumble across the best link after the event....
http://blog.lusis.org/blog/2014/09/23/end-of-linux/ [lusis.org]
(Score: 2) by sjames on Wednesday September 24 2014, @11:10PM
With barely a minute's thought, it seems obvious that there's nothing systemd does that couldn't be accomplished by putting it in the place of rcS and letting the old init call it.
Proper design would ask how minimal can the change be and still do the job and how far up in the tree can it go. They're doing the opposite of proper design here.
(Score: 0) by Anonymous Coward on Wednesday September 24 2014, @04:32PM
Systemd is a security hole. It circumvents traditional unix permissions.
It is huge and has untold numbers of root exploits in it.
It is a gift for and by the NSA.
There you go.
Fuck you.
(Score: 2) by sjames on Wednesday September 24 2014, @11:06PM
I keep hearing about these 'hundreds of lines' of shell script. However, generally, only a few lines are actually necessary.
My big concerns are debugging when the system won't come up and for cases where a different init is needed but systemd is locked in place by a hairball of ill-considered dependencies (the desktop, REALLY?!?)
Consider using init=/bin/bash as a debugging aid. Look things over, make a few changes then see if it works by calling rcS. Can't do that with systemd because it will insist on being PID1 but can't be because that's my shell.
Meanwhile, I'm having a hard time seeing what systemd can do for me that a few helpers that register with dbus can't do. Perhaps you'd like to explain?
(Score: 1) by gcrumb on Thursday September 25 2014, @04:57AM
Groupthink is clearly against systemd with very little argument against systemd other than some weak philosophical arguments, or saying that old sys v init scripts were good enough. Very few arguments against systemd come from people who've spent any time to understand its architecture, to say nothing of actually *using* systemd.
Those 'weak' philosophical arguments are coming from people whose careers have been spent un-fucking systems. It might be worth your while to take the same advice you give further on, and actually spend some time working and living with the issues that you consider to be so 'weak'. But if you're too impatient for that, you can always try reading this [lusis.org]. Specifically, this from the systemd design docs:
Any experienced systems administrator doesn't need to be told why this is a terrible idea. If you don't see the problem, then you're not really qualified to comment on how strong or how weak the 'philosophical' arguments are. I don't mean that dismissively. On the contrary, I'm suggesting you read up to the point where you do get the point, so that you can educate yourself. It's a shame, really that Sievers and Poettering haven't chosen to the same.
Crumb's Corollary: Never bring a knife to a bunfight
(Score: 2) by caseih on Thursday September 25 2014, @06:19PM
Interesting. You keep on saying the very things I called people out for in my original post. Systemd is self-evidently bad. Sorry but that's not an argument. You quote a paragraph on how systemd is architected and say how bad that is but you fail to say specifically why it's bad and what problems are occurring, or even potentially could occur. "An experienced sysadmin doesn't need to be told this is a terrible idea" you say. Go on, tell me why it's a terrible idea. Specifically. Otherwise I stand by my claim that arguments against systemd so far have largely been weak.
The fact is that among the sysadmin communities I'm a member, including the official RHEL mailing lists, there is nary a word about actual systemd problems.
Don't patronize me with saying "educate [yourself]." The onus is on you to provide evidence, not tell me just to go look for it. I keep waiting for specific arguments against and problems with systemd but so far I've been disappointed.
By the way I am an experienced sysadmin, maybe not as much as many of you here. But I've worked with Linux and Unix for 14 years, adminning many servers hosting different kinds of services. I can talk about problems with init scripts because I've worked with them. I've had systems not boot because of a problem with a service starting (OpenLDAP on RH 4 and 5, I'm looking at you!) I've written my fair share of init scripts. I've also worked with other init systems too.