Microsoft cackles with glee

Story: Systemd fallout: Two Debian technical panel members resign Total Replies: 18
Author Content
Bob_Robertson

Nov 19, 2014
11:57 AM EDT
n/t
flufferbeer

Nov 20, 2014
1:01 PM EDT
.... and now Ian Jackson is resigning from DebTechComm as well.

Seeing that Red Hat's been an enormous competitor to M$ for a long time, I just don't see how M$ can be so gleeful of their competitor's systemd invasion into Linux distros like Debian and the other biggies.

2c
Bob_Robertson

Nov 20, 2014
3:46 PM EDT
Discord and discontent serves them very well.

The Linux "competition" is being torn asunder, sown with discord.

Anything that causes problems within the community serves Microsoft. That is why my gut reaction to systemd and pulse audio is that Microsoft is paying Pottering.
lcafiero

Nov 20, 2014
10:16 PM EDT
Bob_Robertson: I'd be willing to bet that Microsoft couldn't find FOSS with a flashlight and a GPS, let alone caring the least bit about whether Debian loses developers, developers, developers.
linux4567

Nov 21, 2014
12:22 AM EDT
I'm sure Red Hat is the one cackling with glee here as Debian (with it's countless derivatives including such important distros as Ubuntu and Mint) has always been the primary obstacle for Red Hat to totally dominate the Linux ecosysytem.

Now that systemd has forced itself into almost every distro the only thing that's left for Red Hat to eliminate is the deb packaging format, once that's gone all distros of any importance will be following Red Hat standards and Red Hat will therefore be able to set the direction for Linux as it pleases.

So I wouldn't be surprised if systemd will introduce a dependency on rpm soon forcing Debian to switch to rpm.

Fettoosh

Nov 23, 2014
12:16 AM EDT
Quoting:So I wouldn't be surprised if systemd will introduce a dependency on rpm soon forcing Debian to switch to rpm.


I am really puzzled. The way I understand this is that, one program makes another program dependent on a third one? How could systemd make dpkg or apt dependent on rpm to prevent them from running independently on Linux? Is systemd taking the place of the OS? In that case, this means that the developers of systemd can make it prevent any application from running on Linux if they choose.

Even if this could become possible, which I strongly doubt, systemd is open source and the Debian guys can hack the heck out of systemd to neuter it and remove whatever is causing Debian any headache.

Aren't we going a little too far exaggerating the dependency issue?



jdixon

Nov 23, 2014
7:05 AM EDT
> I am really puzzled.

A dependency is any program which is required for another program to run or compile (you can have compile time dependencies which are not required for running a program, and vice versa), If systemd requires rpm to run, then you have to have rpm installed if you want to run systemd.

There's absolutely no reason systemd should be built in such a way as to require rpm, but then a good bit (some would go so far as to say most) of the way systemd is designed makes no sense to long time Linux/Unix users.

Now having rpm installed isn't the same thing as using it as your package manager, but again, who knows what systemd will require in the future. It could be built to make calls to rpm that expect rpm to be the package manager.

> Even if this could become possible, which I strongly doubt, systemd is open source and the Debian guys can hack the heck out of systemd to neuter it and remove whatever is causing Debian any headache.

At what point does it become simpler just to dump systemd, rather than hack it? But if dumping systemd also means you can't compile Gnome or any of it's compatible programs, what then?

> Aren't we going a little too far exaggerating the dependency issue?

Probably, but that the idea could be mentioned even semi-seriously tells you a lot.
Fettoosh

Nov 23, 2014
11:45 PM EDT
@JD,

The point I am making is that, there is no way systemd can be made to require a specific package manager. A package manager is totally independent program. To force a specific PM to run would mean systemd should be able to prevent specific program from running. Only the OS is able to do that
Quoting:It could be built to make calls to rpm that expect rpm to be the package manager.


I am sure that can be disabled.

Quoting:At what point does it become simpler just to dump systemd, rather than hack it


My view about this issue is very simple. Let systemd be whatever they want it to be. It might have really bad things and some really good things. When the time comes and all is debugged and ready for release, fork it, remove the intrusive & undesirables, keep the rest, modify some & add more to make it a better complete systemX.

Isn't that how FOSS supposed to be?

JaseP

Nov 24, 2014
10:05 AM EDT
Quoting: My view about this issue is very simple. Let systemd be whatever they want it to be. It might have really bad things and some really good things. When the time comes and all is debugged and ready for release, fork it, remove the intrusive & undesirables, keep the rest, modify some & add more to make it a better complete systemX.


Systemd is already released,... Debugged & finished?!?! That's a different story. But, your point is a good one. Since systemd is a big enough part of the ecosystem, there will be a fair amount of developer attention. I am sure there will be one or two tweaks to it, along the way. In fact, I am more than hoping for it.
jdixon

Nov 24, 2014
6:15 PM EDT
> The point I am making is that, there is no way systemd can be made to require a specific package manager.

And my points are that a) yes there is, and b) given the history of the systemd developers, I wouldn't put such a thing past them.
gus3

Nov 25, 2014
1:24 PM EDT
How did The Gimp come to depend on systemd? By accident?
Fettoosh

Nov 25, 2014
5:16 PM EDT
Quoting:How did The Gimp come to depend on systemd? By accident?


Not by accident, but by design, and by making GNOME dependent on systemd, but it doesn't mean GIMP can't be modified to be independent of systemd.

I would like to know how can systemd developers make dpkg or apt/aptitude dependent on systemd? Even if they can, Debian developers for sure can replace whatever is the culprit to make them free again.

It is not a matter of systemd developers making apps dependent, it is a matter of maintainers of apps making or keeping them dependent on it.

me1010

Nov 25, 2014
8:05 PM EDT
@gus && Fettoosh Please stop propagating incorrect information:

There is no systemd dependency for GIMP.

Check sources before posting incorrect information.
Fettoosh

Nov 25, 2014
8:47 PM EDT
@me1010,

I recall you have mentioned that in another thread with a link. I didn't find any definite clear answer that it doesn't. You may be right though.

But what I am saying is, even if it was, GIMP maintainer(s) could easily remove any dependency if they choose to. That applies to any applications that runs on Linux. systemd developers have to hijack all GNU code in order to make Linux application dependent on it.

frankiej

Nov 25, 2014
9:20 PM EDT
Quoting: I recall you have mentioned that in another thread with a link. I didn't find any definite clear answer that it doesn't. You may be right though.
I do believe me1010 is correct. I have been curious about it myself and have been looking around. The best summary, assuming it is correct of course, that I found is this post on the Debian forums:

For kicks, I downloaded the latest source (2.8.14) onto my Slackware system and ran configure. No where in the output does it mention anything about systemd specifically. D-Bus is listed as per the post:

Optional Features:
  D-Bus service:       yes
  Language selection:  yes
I would speculate that the systemd + GIMP dependency originates from systemd distributions that use a package manager with dependencies. If D-Bus is somehow incorporated into systemd, and the GIMP packager enables D-Bus in the GIMP build, then I would assume the systemd dependency would naturally work itself into the package that way.
flufferbeer

Nov 25, 2014
9:51 PM EDT
@jdixon,

> The point I am making is that, there is no way systemd can be made to require a specific package manager.

>> And my points are that a) yes there is, and b) given the history of the systemd developers, I wouldn't put such a thing past them.

Their ever-increasing power is Sauron scary!! One systemd to rule them all, one systemd to find them, One systemd to bring them all and in the darkness bind them.

@gus3,

>> How did The Gimp come to depend on systemd? By accident?

I take the discussiion above to proceed logically as follows: a) Gimp can be made by its maintainers to depend upon D-Bus, b) D-Bus can be chained to systemd, c) therefore, Gimp could CERTAINLY be made to depend on systemd (systemdwraiths' adamant claims aside!) even if it isn't doing so at present. Fairly straightforward really.

2c
me1010

Nov 26, 2014
9:47 AM EDT
@flufferbeer:

GIMP does not depend on systemd. It is very unlikely to ever depend on systemd in any mandatory way because at least 50% of its users run MS Windows. The same is true of: Inkscape, Blender, LibreOffice, Firefox, Hugin, and nearly all the most commonly run desktop applications.

Please:
Quoting:Check sources before posting incorrect information.
number6x

Nov 26, 2014
11:56 AM EDT
On fedora 21:

[liveuser@localhost ~]$ yum deplist gimp | grep systemd 


results in:

[liveuser@localhost ~]$  


So it looks like gimp does not depend on systemd in fedora 21

same results with

[liveuser@localhost ~]$ repoquery --requires --resolve gimp| grep systemd
vainrveenr

Nov 30, 2014
10:46 PM EDT
Quoting:I take the discussiion above to proceed logically as follows: a) Gimp can be made by its maintainers to depend upon D-Bus, b) D-Bus can be chained to systemd, c) therefore, Gimp could CERTAINLY be made to depend on systemd (systemdwraiths' adamant claims aside!) even if it isn't doing so at present. Fairly straightforward really.


According to the Debian User Forum topic 'The future with Systemd', found at http://forums.debian.net/viewtopic.php?start=120&t=116860#p554403 :
Quoting:I would clarify that GIMP does not require systemd. GIMP uses DBus (which has apparently been subsumed by the systemd project), if it is available, for one very simple task: if you invoke GIMP from the command line with a filename and an instance of GIMP is already running, a DBus message will be sent to open that file within the already running GIMP (if DBus is not available, a new instance of GIMP will be started). On platforms that don't have DBus available (e.g., Windows), a dedicated auxiliary command, gimp-remote, is typically provided to handle such operations.

I also saw mentioned on one of the Debian mailing list that GEGL (which GIMP does require) is dependent upon libSDL (which is allegedly dependent upon systemd). GEGL will make some libSDL features available if libSDL is installed, but it is not a requirement that libSDL be installed. The situation is the same for libJPEG (except libJPEG hasn't been caught up in the systemd einschluss :) ) -- if it is not available then you can't load and save JPEG files, but GEGL does not require that libJPEG be available.


...........................................................................................................................

Quoting:Even if this could become possible, which I strongly doubt, systemd is open source and the Debian guys can hack the heck out of systemd to neuter it and remove whatever is causing Debian any headache.


Another concurrent LXer thread discusses the Debian fork, Devuan, as a viable effort to "remove whatever is causing Debian any headache". See the thread 'First step in the right direction' found at http://lxer.com/module/forums/t/35677/

As writen in the actual iTWire Devuan piece:
Quoting:"We believe this situation [of Debian's adopting systemd for Jessie] is also the result of a longer process leading to the take-over of Debian by the GNOME project agenda," the new project leaders said in a statement.

"Considering how far this has propagated today and the importance of Debian as a universal OS and base system in the distribution panorama, what is at stake is the future of GNU/Linux in a scenario of complete homogenisation and lock-in of all base distributions."

The new project says its priorities are to "enable diversity, interoperability and backward compatibility for the existing Debian downstream willing to preserve Init Freedom and avoid the opaque and homogenising systemd avalanche".










Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!