SoylentNews is people
SoylentNews
Controversy is nothing new when it comes to systemd. Many people find this new Linux init system to be inherently flawed in most ways, yet it is still gaining traction with major distros like Arch Linux, openSUSE, Fedora, and soon both Ubuntu and Debian GNU/Linux. The adoption of systemd for Debian 8 "Jessie" has been particularly fraught with strife and animosity.
Some have described the systemd adoption process as having been a "coup", while others are vowing to stick with Debian 7 as long as possible before moving to another distro. Others are so upset by what they see as a complete betrayal of the Debian and open source communities that there is serious discussion about forking Debian. Regardless of one's stance toward systemd, it cannot be argued that it has become one of the most divisive and disruptive changes in the long history of the Debian project, threatening to destroy both the project and the community that has built up around it.
(Score: 3, Insightful) by tonyPick on Sunday September 28 2014, @12:32PM
The fork could be as minimal as a repo that never stops shipping alternative inits.
Unfortunately the dependencies of userspace packages on other parts of systemd appear to make this a non-starter.
So, for example when something like Gimp requires systemd (oh yes, yes it does) you're way beyond just dropping in another init. There's a fair amount of package reworking (at least rebuilding and bundling) which looks unavoidable, and going forward then compatibility with BSD and older systems doesn't appear to be something the systemd clients are losing sleep over, so syncing with a BSD distro might be simpler, at which point you might as well just bite the bullet and go the Open/Free BSD route.
(I suppose you could run a ports on a Linux kernel, perhaps. Don't know if anyone has done that though...)
See also: https://people.debian.org/~stapelberg/docs/systemd-dependencies.html [debian.org]
(Score: 3, Interesting) by Marand on Sunday September 28 2014, @01:00PM
I've seen this stated a few times in this and other discussions on SN and I'd like to know: what causes gimp to depend on systemd? I see nothing to indicate that when checking apt-rdepends gimp in Debian testing. I'm no systemd advocate, and I don't ask this to discredit; I just keep seeing the statement and I'm just curious where that particular belief came from. Is it an oddity in another distro?
The only tie I can see in Debian is that, if you follow recommended packages (apt-rdepends --follow Depends,PreDepends,Recommends gimp) you get a dependency for libsystemd-login0 by way of dbus. However, that is a recommendation, not requirement, and thus optional. It's also not systemd, it's a library for interfacing with systemd. Dbus, for example, doesn't require systemd itself, while udisks2 and policykit have direct ties to systemd and will not function without it (apt-rdepends --reverse systemd).
The curious one is udev. For a bit, Debian testing (jessie) wouldn't allow updating udev without also installing systemd because of a library it used requiring systemd. That doesn't seem to be the case currently, so it may have been a mistake. However, during that brief time, thanks to udev, nearly everything required systemd.
(Score: 2) by tonyPick on Sunday September 28 2014, @02:02PM
I've seen this stated a few times in this and other discussions on SN
Me too, and this is what I get for repeating things without researching them fully first :)
You've basically hit the nail on the head with udev AFAICT - So there's a few links on google which talk about the breakages, but primarily the problem seems to be that the Gimp dependencies themselves have dependencies which will be tied to systemd components.
So, apart from the the standard system backbone stuff like glib, dbus, etc, then the big one is gudev, which (I'm guessing, from a quick sweep through the source tree) Gimp uses to work input device management for things like graphic tablets.
From LP himself back in May:
this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.
http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI [phoronix.com]
So, it is possibly to build without systemd (and lose functionality), and it looks like the eudev branch is providing a viable alternative for the dependencies for now, but how compatible that is I couldn't say.
Basically this isn't as big a problem as I thought, but if Debian just goes systemd and/or doesn't package the right eudev then forking this will need more work than repackaging and it's a good example of how systemd migrates it's way through the system deps.
(I'm looking at the gentoo deps list here: http://gentoobrowse.randomdan.homeip.net/package/media-gfx/gimp [homeip.net] and the LFS http://lfs-matrix.net/blfs/view/systemd/xsoft/gimp.html [lfs-matrix.net])
(Score: 3, Interesting) by Marand on Sunday September 28 2014, @02:57PM
For now, at least, it's still just a case of a software recommendation that eventually leads back to systemd. The problem there is that Recommends are usually installed automatically, so the average user is likely to conflate this with a requirement when it's still optional*.
As for Poettering's comment about not supporting systemd, that may be the case but there's still eudev (as you mentioned), and Debian has systemd-shim as a way to use other systemd (and udev) bits without requiring the init side. I don't know how long that will remain the case, but Debian has that kFreeBSD port, which can't use systemd, to consider, so it's hopefully going to last a while. Poettering and co. don't have any interest in non-Linux systems and kernels, and the longer it takes to port systemd elsewhere, the longer Debian will avoid complete tie-in.
If you don't have access to Debian or Ubuntu directly, you can look at Debian and Ubuntu deps at packages.debian.org and packages.ubuntu.com, respectively, for an idea of how their dependencies work out. If you do, though, apt-rdepends is probably the best way to check the dependency tree. Even allows output in a format springgraph (from signing-party package) understands for creating an image from the relationships.
---
* For the curious: synaptic has a checkbox to turn this off; apt-get has --no-install-recommends switch; aptitude has a checkbox to disable it; or you can change it by hand by putting APT::Get::Install-Recommends "false"; in a file in /etc/apt/apt.conf.d/
I turned off auto-recommends years ago because it kept trying to add a lot of insane cruft I didn't care about. Good default for newbies, crap setting for Linux vets.
(Score: 2) by tonyPick on Sunday September 28 2014, @03:51PM
I don't know how long that will remain the case, but Debian has that kFreeBSD port, which can't use systemd, to consider, so it's hopefully going to last a while.
Yes, but it's pretty clear that the solution to that is that "supporting the kFreeBSD port isn't important" by at least some of the package maintainers, so I'm less hopeful.
Skip to around 21:30 in this (Michael Stapelberg from Debconf 2013): http://www.youtube.com/watch?v=Hvy0e9kbAos [youtube.com] and the first two questions cover this (or watch it all; it's rather good and not very long).
(Score: 1) by canopic jug on Monday September 29 2014, @09:43AM
It's on the chopping block [debian.org] as far as jessie is concerned due to needing more porters. If a few more porters show up very, very soon, then the risk goes down.
Money is not free speech. Elections should not be auctions.
(Score: 2) by Marand on Monday September 29 2014, @10:27AM
Great, if that happens, we'll be lucky if the systemd-shim lasts beyond jessie's release. :( One Redhat to rule them all...
(Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:56PM
I've been using both GIMP and Debian since the very early days.
You know what? Fuck GIMP. It won't even let me ctrl-s anymore without awkard plugins or stay in its own desktop workspace. I never liked the feel of KDE much, but I'm sure there's an image manipulator tool there which hasn't gone full retard. And it has gotten to the point where I'm willing to give up my years of muscle memory and working knowledge of the program.
(Score: 0) by Anonymous Coward on Monday September 29 2014, @11:51AM
Yeah, the new versions of GIMP are really confusing for me, too. Why do I have to "export" to save as a PNG? Why does "save" only support XCF files? Why doesn't it just let me "save" as PNG, like it used to?
(Score: 0) by Anonymous Coward on Monday September 29 2014, @04:37PM
So you don't accidentally hose all your layer/undo information!
I actually did that on a project years ago. Thankfully it turned out I still have a previous copy in xcf format, but as far as idiot proofing goes, it isn't a bad idea.
On the other hand gtk-3 got me to drop everything gtk/gnome related until my desktops had 3d acceleration. GTK-3 is easily 3x or more slower than gtk 2 on non-composite capable hardware. I have no idea why, or if it has been remedied, but I've stuck to gtk2 or qt apps for everything now. And honestly given QT being under the LGPL for the past 3+ revisions I see no reason to use gtk2 if you're writing a C++ app, and if you're writing a pure c app, there's far far better alternatives than gtk3+glib that are far more likely to provide future compatibility and far fewer compatibility headaches.
(Score: 1) by GeminiDomino on Monday September 29 2014, @04:40PM
Because the developers know better than you what "users" want.
And by "users", they mean "professional users", of course. There are "plenty of alternatives for amateur" use. (Yes, this was actually their excuse).
Nevermind the fact that "professional users" are all using photoshop et al... which behave the same way that the old GIMP used to, wrt saving.
In other words, more of the same self-indulgent wankery by asshole developers who apparently don't understand what a "Use case" is and bring us things like GIMP 2.8+, "Unified interfaces", and everything LP's ever shat out.
"We've been attacked by the intelligent, educated segment of our culture"