SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
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.
Today is National Existential Ennui Awareness Day.
(Score: 5, Insightful) by Marand on Wednesday September 24 2014, @08:01AM
Not surprising, really. This reeks of the same political bullshit that tainted the discussion about which (if any) init system should replace sysv-init in Jessie. The initial decision to switch the desktop default from GNOME to Xfce was fairly arbitrary and had the GNOME camp up in arms, so it shouldn't be a surprise to anybody that, once they finished forcing systemd on everybody through dependencies and arguments, there would be a push to reinstate GNOME as the default.
That's the problem with the whole thing, not just with Debian: GNOME and systemd are "winning" through politics, not merit. Even if systemd were a flawless init alternative, a lot of us would want to fight it at this point simply because of the heavy-handed way it's being pushed on everybody while trampling on alternatives. If I wanted to live with "I know what you want better than you do, shut up and deal with it" I'd be using OS X, not a Linux distribution.
At least it's just defaults. Debian's installer allows you to choose an environment (or none) at install time, and systemd is still semi-optional with the systemd-shim package. You're still stuck with the non-init parts, because of the incestuous relationship systemd has with other parts such as udev, but systemd-shim lets you use a different init.
. . . For now.
---
(FYI: editors, the release name is "Jessie" [debian.org] with an i.)
(Score: -1, Troll) by Anonymous Coward on Wednesday September 24 2014, @08:17AM
Well then why don't we do some politics of ourselves.
We could go get some pistols and then put it to the backs of their heads.
After that we could pull the trigger on each of those pistols.
If they want to force things, let's force back but worse.
Everything went down hill once the *-women came in.
They became gatekeepers of what once was our thing.
We need to kill those fucks.
With bullets. So that they die.
(Score: 1) by jbernardo on Wednesday September 24 2014, @08:43AM
(FYI: editors, the release name is "Jessie" with an i.)
Doh, seems like the autocomplete in swiftkey betrayed me again. Sorry about that.
(Score: 2) by tonyPick on Wednesday September 24 2014, @10:04AM
if systemd were a flawless init alternative, a lot of us would want to fight it at this point
If systemd were a flawless init most of us probably wouldn't care, and would in fact _like_ a "better init". The fact it's a bag of spanners is what's causing most of the problems.
(Score: 2) by Marand on Wednesday September 24 2014, @10:19AM
Well, yeah, but the point was that it's hard see any good in it when you're pissed about the method of delivery. Even if someone's giving you free diamonds, it's easy to be annoyed about it if the method of delivery is "mixed with feces and thrown at your face". Unless you have a fetish for that sort of thing, and then you'll love it, I guess. Just like systemd.
(Score: 2) by tonyPick on Wednesday September 24 2014, @11:14AM
Fair point, although it's easier to forgive the odd moment of muppetry if you're actually making something better, versus something which is "less good, just different". At which point everybody else is much more insulated from the level of original delivery.
So I might put up with the crap-in-your-face for the odd diamond, at which point somebody else might be prepared to pick up my "crap filtered" stream of diamonds, and so on. But nobody is going to pile through this for nuggets of yet more crap, and that leads to the problem that all you have is the core group and not much else. (Have I strained that comparison to breaking point yet?).
Likewise if systemd was a well designed init replacement then most folks wouldn't be even hearing about this - it'd be like the device node to devfs to udevd moves, or the procfs/sysfs/sysctl migrations, or any one of a hundred other technical changes that have run through into wider distribution and "just got done".
To put it another way: both Theo de Raadt and Richard Stallman have managed to mightily piss off whole sections of the human race on occasion, and each other pretty regularly, yet they both produce software that people want to use, and have generated communities around that which means you can ignore their....quirks. Mostly. Something that the systemd guys seem to be failing spectacularly to do on any scale...
(Score: 3, Interesting) by Marand on Wednesday September 24 2014, @11:42AM
Probably. As far as analogies go, it was a rather shitty one to begin with. (don't hit me)
Funny that you mention udev, since it (and its creator) are unfortunately tied into this as well, which is part of the problem. I'm not sure if Sievers just happened to make something useful by mistake, or if he got infected later by Poettering's brand of development while working on systemd.
At least you can shut udev off and go back to manually created device nodes in an emergency and still have most things still work just fine. Or you could before it got tied with systemd -- haven't had a need to kill udev since that change. It's getting very difficult to avoid systemd in the same way.
(Score: 2) by VLM on Wednesday September 24 2014, @04:11PM
the method of delivery is "mixed with feces and thrown at your face"
This will go down in internet history as the strangest way to describe "E E E via submarine patents" that I've ever seen.
Think about it... is there a better rational reason for really weird and illogical technical decisions being made that are being pushed via expenditure of enormous amounts of political capital (which takes time and money)? One unanswered question is who's paying to destroy linux...
(Score: 1) by quixote on Wednesday September 24 2014, @09:14PM
The money angle hadn't occurred to me earlier. But now that you mention it ... it does make creepy sense.
Move away from simple, text-based logs, modular implementation toward opaque interdigitated total interdependence, and, yes, I could see submarine patents suddenly wreaking havoc.
And just recently I saw in the financial news that Novell, who'd been bought by Attachmate a few years back, has now been bought by Micro Focus. Somewhere in there I remember something about a consortium that includes Microsoft. Although, to be honest, the GOOG has been much more of a destructive parasite on Linux than even Microsoft.
Not that I wear a tin foil hat or anything.
(Score: 2) by VLM on Wednesday September 24 2014, @09:41PM
Doesn't even have to be evil empire totally destroys linux, just some jerk of a patent troll figuring.. hmm... how about I ask for $1 for every linux distro cd/dvd ever made or downloaded? That's pretty cheap compared to microsoft windows or osx licensing but a pretty good haul for a patent troll...
Or, Debian isn't under corporate enough control, whats a good way to destroy Debian so the only linux out there is corporate linux, maybe with TPM/big brother inside DRM control by the NSA... Hmm license something for $1/yr that wouldn't meet DFSG... so they can give up on the DFSG or go under... Hmm.
Or just plain old FUD. You know who (voldemort?) didn't get too far claiming "unix" source code in linux, but you know who does stupid things like monolithic designs with registries and binary logging and ... Even if you lose in court, even if you know its a lost cause, you can FUD FUD FUD for many years... This isn't tinfoil hat, its a reasonable assessment of "round 2" of an ongoing fight. If you know who doesn't attack on this angle, what is wrong with them? It seems obvious.
(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.
(Score: 2) by Bot on Wednesday September 24 2014, @06:26PM
Account abandoned.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @08:36AM
False flag operation for either compromising patches of the userspace, or kernelspace.
Maybe somebody with the knowledge, tools, or manpower could look into that for us?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:14AM
Probably. But they have already won. You can only fight governments through force. The people compromising debian are not going to give up their positions if their masters are the agencies and a government.