Could systemd be an inconvenient on portability?
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
One of various nice things that Unix has is it's philosophy on portability "Choose portability over efficiency"[1]. Since GNU was meant to be a Unix-like, we got this nice thing on GNU too. This means that software developed on FreeBSD (another Unix-like) can be ported without too much trouble to GNU, or software developed on GNU/Hurd ported to GNU/Linux, or basically any Unix-like. But then, systemd aims to be "the simple building blocks for operating systems" without taking care of portability, making systemd Linux only. And systemd is starting to be widely used, so:
Is systemd going to be an obstacle when people want to port applications to GNU Hurd or other Unix-like systems?
Do you know any other inconveniences of systemd?
[1] The UNIX Philosophy, by Mike Gancarz.
I won't offer anopinion on the real problems systemd may present, but anyway:
""the simple building blocks for operating systems" without taking care of portability, making systemd Linux only."
How can ":the simple building blocks of an OS" be "Linux only"?
" can be ported without too much trouble to GNU, or software developed on GNU/Hurd ported to GNU/Linux"
Those are 1 OS with different kernels (though that in turn means there are awfully significant differences), no?
> I won't offer an opinion on the real problems systemd may present
You mean that I did? Sorry, I thought it was neutral, but I guess that's even more difficult than I thought.
> How can ":the simple building blocks of an OS" be "Linux only"?
The implementation of systemd uses cgroups and it's only available on Linux.
> Those are 1 OS with different kernels (though that in turn means there are awfully significant differences), no?
Yes, in this case even the kernel arquitecture differ, but as long as they both aim to be Unix-compatible, applications should be compatible between them. That's true unless you make various system components that aren't Unix-compatible (systemd in this case).
You mean that I did? No but neutral opinions like yours and not-yet-made ones like mine doesn't seem to be what is supposed to be discussed here assuming the premise of this thread is to be a continuation of the Systemd discussions in the MATE thread, and so since my post didn't give an opinion I simply decided to explicitly say that it doesn't so as to prevent people thinking I was trying to offer one.
Sorry if the comment wasn't supposed to be written like that.
oops, my bad. For some reason I read "won't" as "wouldn't" until now I realized there wasn't any "uld" in there. I guess is finally time to accept it and use reading glasses.
> neutral opinions like yours and not-yet-made ones like mine doesn't seem to be what is supposed to be discussed here assuming the premise of this thread is to be a continuation of the Systemd discussions in the MATE thread
It wasn't meant to be an opinion, but fine with me if you found it neutral at least. I made this thread with two purposes, the first one is to address the concern on systemd being Linux only while aiming to be "simple building, etc, etc" you know a system core component(s). The second was to give a space where the people from the MATE thread could keep debating without messing t3g's thread.
danieru,
Is systemd portable: no!
Is it an obstacle to development: yes and no.
Yes, if you want create to programs that do not depend on it or can be used on BSD etc..., no if you only want to write systemd/Linux programs.
Pottering does not care about BSD, he does not care about the Linux kernel team, and he stated many times that he does not care if systemd breaks other OS's, or DE's outside of Gnome. The goal of the systemd team is to create a complete OS from the kernel up to the DE. Again stated by Pottering and Kay themselves.
systemd as only an init system, no problem, but systemd as an uncontrollable monolithic program will cause many problems.
Pottering and Kay do not care about Unix or POSIX. With systemd, GNU/Linux is no longer POSIX compliant.
Nice thread by the way. :)
References needed. Facts, not conspiracy theories.
I showed you that you have systemd-logind installed on your system (assuming you run Trisquel, even Trisquel Mini). The same holds for the authentication module (and no, they do not depend on each other). Yet, you still write that systemd is a "monolithic program".
>Is systemd going to be an obstacle when people want to port applications to GNU Hurd or other Unix-like systems?
I suppose you mean “programs”. See my comment about the word “application”.
We have always had system-specific features and programs and they are by themselves not an obstacle to portability, but it is an obstacle to portability when other programs require these features or depend on these programs (instead of having them as a so called “optional dependency”).
For instance, using systemd to start an UNIX service (for instance the HTTP server lighttpd) is not an obstacle to portability, We can readily use System‐V style init or Upstart in another system (which may be just another installation of the same distribution, a different distribution, or a different operating system). It would be an obstacle to portability if lighttpd did not work without systemd.
Bear in mind that the primary goal of GNU/Linux (at least for free software supporters) is to provide a fully free operating system. Portability is a technical consideration; it is usually good to have, but it is not a requirement of a fully free OS.
>Do you know any other inconveniences of systemd?
I can not comment on the vices and virtues of systemd, but there is plenty of discussion in the web. Some of that discussion, however, is based on misunderstandings of what has been said in previous discussions.
> For instance, using systemd to start an UNIX service (for instance the HTTP server lighttpd) is not an obstacle to portability
Systemd as an init maybe not for the time being. But I meant to systemd as any of it's components (that can become a dependency), like logind or udev.
> Bear in mind that the primary goal of GNU/Linux (at least for free software supporters) is to provide a fully free operating system. Portability is a technical consideration; it is usually good to have, but it is not a requirement of a fully free OS.
I completely agree with the first sentence, GNU should always have freedom as the first priority. But GNU also has compatibly between *nix systems as a nice and desirable thing to have, although not a critical requirement of course. I don't agree with "it is usually good to have". Why usually? Are there situations where portability isn't good to have?
>Systemd as an init maybe not for the time being. But I meant to systemd as any of it's components (that can become a dependency), like logind or udev.
I commented about system specific features and software in my first reply.
>I completely agree with the first sentence, GNU should always have freedom as the first priority. But GNU also has compatibly between *nix systems as a nice and desirable thing to have, although not a critical requirement of course. I don't agree with "it is usually good to have". Why usually? Are there situations where portability isn't good to have?
Yes, in some cases it is better to not to have portability. When there is a piece of free software that has no proprietary counterpart, or is by far technically superior to that technical counterpart, then it is usually better that it runs only on a fully free operating system so that is not portable. This adds a practical reason for people to use the free operating system. There is some rough similarity to the effect of Copyleft licenses. Copyleft licenses directly give an incentive to develop free software, while in this case, absence of portability just gives a reason to use free software, but as I explain next, this still results in a similar benefit to that of Copyleft.
The benefit in this case is not in making people who don't care about freedom of computing use free software because it is more convenient, but in that this increased usage may result in the free OS be more widely used instead of proprietary OSs and in turn this reduces the founding and pressure of proprietary software and promotes development and further adoption of the free system, which benefits those who we support the free software philosophy and may lead more people to know about the problems of proprietary software and centralization, and adopt the free software philosophy. Many of us became aware of the free software philosophy through using GNU/Linux and initially not knowing about GNU or free software.
However, it seems than more often, it is better that free software works on the popular proprietary operating systems to ease transition from those OSs to a fully free one, and also because it may reduce the usage of proprietary software in those proprietary OSs in favor of free software, with the benefits mentioned above.
I am a member!
- systemd requires the kernel Linux
- GNOME requires systemd
- GNOME requires the kernel Linux
- GNOME, the most common desktop environment, cannot run on most POSIX-compatible systems, including some GNU systems
I am deeply scared of this.
[EDIT: s/all/most/]
[EDIT: added code tags]
[EDIT: added list item "GNOME requires the kernel Linux"]
GNOME certainly has add obstacles at porting it over other systems, BSD has slowdown on porting GNOME because of this.
XFCE on the other hand takes portability seriously as they describe itself as "A lightweight desktop environment for UNIX-like operating systems". They even fork consolekit into consolekit2 just to keep portability[1], at least until systembsd is mature enough, which by the way isn't meant to be BSD-specific, so it should run fine on any Unix-like platform.
[1] https://erickoegel.wordpress.com/2014/10/20/consolekit2/
That is not true: https://blogs.gnome.org/mclasen/2014/02/19/on-portability/
You can also look at the announcement of OpenBSD 5.7, released last month: http://www.openbsd.org/57.html
One of the highlights is "GNOME 3.14.2".
Interesting, for the time being GNOME seems ok with portability. Let's see what happens in the future, and hope for any unportable component not becoming a hard dependency, or loosing features because of unportable components aren't present. Because either way it would be disadvantageous for other *nix systems.
In the context of UNIX development, portability actually means the system can operate different computer architectures (in the 70s, every computer architecture had its own operating system).
Anyway, who can list programs that do not run on a system with systemd? Or even programs that required significant alterations so that they could run on a system with systemd? I am not talking about taking advantages of systemd's new features. Just compatibility.
Second question: should GNU/Linux never take advantage of the most advanced features in Linux (such as the cgroups) because the less popular kernels (BSD, Hurd) do not have them? A yes answers means our operating system cannot evolve faster than the least active kernel project.
> In the context of UNIX development, portability actually means the system can operate different computer architectures (in the 70s, every computer architecture had its own operating system).
I'm pretty sure portability only meant what you said in the early days, but the "P" in POSIX means portable, and it's not related with CPU architectures but with compatibility between *nix systems. So I would say that it means the two since the 80s.
> Anyway, who can list programs that do not run on a system with systemd? Or even programs that required significant alterations so that they could run on a system with systemd? I am not talking about taking advantages of systemd's new features. Just compatibility.
That's not the issue as it's obvious that a program isn't going to run better or worse because you have some component that the program doesn't use. But it is not going to run if you have unmet dependencies, and software can depend on systemd, then we have the issue: systemd's implementation isn't portable, which is going to be a problem at porting software over to GNU Hurd for example.
> should GNU/Linux never take advantage of the most advanced features in Linux (such as the cgroups) because the less popular kernels (BSD, Hurd) do not have them? A yes answers means our operating system cannot evolve faster than the least active kernel projects.
I wouldn't say simply "yes" to that, but even if I did that doesn't mean GNU/Linux has to evolve as slow as the others, just in a compatible way. I'm not against using features that aren't available on other *nix systems in general, just against unportable system components that can become dependencies of programs.
I'm not against using features that aren't available on other *nix systems in general, just against unportable system components that can become dependencies of programs.
Well, as long as you use a feature that is absent from another kernel, it will not work on that other kernel. A fallback can be implemented when the feature is a detail. In the case of systemd's pid 1, the cgroups are central to the design (so that daemons cannot escape supervision). The real solution for other operating systems that want systemd is to have their kernel catch up with Linux. As far as I understood, GNU Hurd's developer are actually considering the implementation of a cgroups-like feature so that systemd could work on top of it.
> The real solution for other operating systems that want systemd is to have their kernel catch up with Linux.
I agree, but I don't think that's the best way to develop "simple building blocks to build operating systems". I was thinking on something like a portable protocol on which not only primary Linux developers would contribute, but also GNU Hurd, BSD, Minix and any other free-as-in-freedom OS/kernel developer. If we can't do that without falling into multiples disputes without taking ever or very few times some well agreed decisions. Then maybe we need to focus on improving the communication between the member of our big community.
> GNU Hurd's developer are actually considering the implementation of a cgroups-like feature so that systemd could work on top of it.
Well, that's just speculation but, would that be the best way to aboard the problem considering what I wrote above? In the short-mid time maybe, but what about in the long run?
Please don't get me wrong, I have nothing against cgroups itself nor it's implementation on GNU Hurd or any other Unix-like, what I'm trying to put into words is deeper than mere API preferences.
Again, cgroups are central to the design of systemd's init. If the kernel does not support something similar, then another init had better been used (many FreeBSD people are not happy with sysvinit, they do not want to implement cgroups, so they consider porting launchd instead: https://github.com/freebsd/openlaunchd). User programs can implement a fallback in case systemd is absent. That is what GNOME did. Now, obviously, that is additional work that smaller project may not want to do in the long run. But, like I wrote: "should GNU/Linux never take advantage of the most advanced features in Linux (such as the cgroups) because the less popular kernels (BSD, Hurd) do not have them?".
Well, that's just speculation but, would that be the best way to aboard the problem considering what I wrote above? In the short-mid time maybe, but what about in the long run?
In the long run, cgroups could enter the POSIX specifications.
> In the long run, cgroups could enter the POSIX specifications.
That could work too. I just hope that (if that happens) the committee in charge of bring cgroups to POSIX is competent enough to make a good review of cgroups and change it if necessary if it's not reasonable easy to implement on other *nix systems. Remember that cgroups is develop on and for Linux. So other *nix could end up reassembling part of Linux if they want to be full POSIX compliant.
Magic,
One major program is Gnome DE, it requires systemd as a hard dependency. Again, not heresay, it is stated in several places by Pottering and Kay, mainly on their own blogs and various iirc's.
http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/
The question people should ask, is not is systemd good or bad, but why are Pottering and crew making it a "requirement" or hard dependency for so many programs, and the list keeps growing!
As an example, systemd started out as, and was promoted as a modern init ...however, look at the current list (39 programs):
http://www.linuxfromscratch.org/lfs/view/systemd/chapter06/systemd.html
Christ, your patronizing attitude toward software developers makes me sick. What do you think we are, children?
I write programs which are dependent on third-party software all the time. More specifically, I have never written a program that doesn't. There is nothing special about a programmer choosing systemd as a dependency. It happens because the programmer wants to use systemd, not because of some kind of mass conspiracy to force him to use it.
But hey, if you want to talk about non-portable dependencies, how about X? You know, the window system most commonly used for the last ~30 years. Seriously, it's exactly the same deal. You'll find several programs in Trisquel's repo dependent on X,[1] and in particular every screencasting program for GNU/Linux is dependent on X. From my understanding, Mir and Wayland either have implemented or are implementing X-compatible interfaces specifically because of this. You know, kind of like when the BSDs make systemd-compatible interfaces they can use. Because that's the only way to make these X-dependent programs run when you don't have X.
Neither X nor systemd are grand conspiracies. Please give us programmers some credit, rather than assuming we're nothing but sheep being herded by the evil systemd superiority conspiracy.
[1] A short list of some examples: recordmydesktop, xbill, xjump, xgalaga, xpuzzles, xsol, xscavenger. Lots of other packages with names that begin with "X" also fit the bill.
>But hey, if you want to talk about non-portable dependencies, how about X? You know, the window system most commonly used for the last ~30 years. Seriously, it's exactly the same deal.
>The X library is not any more portable than systemd: it only works with X.
Most of the time, when “portability” is mentioned in the context of informatics, it means the property of a software that runs on several operating systems. The X Windows System is portable: it runs in several operating systems, so depending on X doesn't makes a program unportable, while depending on SystemD does. SystemD is not portable, it only runs on operating systems that use Linux as the kernel, so it is not comparable to the X Windows System in this regard.
The X library only works with the X Windows System because it is a component of the X Windows System, it is not comparable to SystemD which is a whole software package.
I think that's an overly technical distinction, and not particularly relevant. The point is that dependencies on both of these cause programs to not work on some systems without specific efforts to make them work (a real-world example in the case of X is Mac OS X, which from my understanding has some sort of compatibility layer to cope with this), and both are a result of programmers deciding that's an acceptable loss given the API they gain access to.
One major program is Gnome DE, it requires systemd as a hard dependency.
That is not true: https://blogs.gnome.org/mclasen/2014/02/19/on-portability/
You can also look at the announcement of OpenBSD 5.7, released last month: http://www.openbsd.org/57.html
One of the highlights is "GNOME 3.14.2".
http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/
Besides trying as much as it can to do sensationalism (it is a news article), the article makes points that are precisely the opposite of what you write. On compatibility (what started this thread): "systemd is compatible with SysV and Linux Standard Base (LSB) init scripts". On the relation with the Linux kernel them (you wrote that "Pottering does not care about [it]"), Linus Torvalds say that he doesn't "actually have any particularly strong opinions on systemd", only "details, not big issues"; Ted Ts'o say "the bottom line is that [systemd's developers] are trying to solve some real problems that matter in some use cases".
And when it comes to the sentence "the GNOME 3.8 desktop and newer now requires systemd" (the point you actually wanted to make), the associated link leads to https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ where you can read the truth repeated over and over (how the article translates that into "the GNOME 3.8 desktop and newer now requires systemd" is a mystery... or simply sensationalism):
At most 3 weeks ago I noticed by then already month old thread on gentoo-dev discussing that GNOME 3.8 has a dependency on systemd. At most this should be about logind, even though logind is optional. (...) Figuring out why Gentoo really believes systemd is a requirement took a while to figure out. (...) Apparently our (=GNOME) assumption that logind was independent from systemd changed since systemd v205 due to the cgroups kernel change. This is really unfortunate, but GNOME 3.8 does not require logind. (...) This despite clarifying that GNOME really does not need systemd, nor logind and trying to help out with issues.
As an example, systemd started out as, and was promoted as a modern init
systemd is an umbrella project. Not only an init.
however, look at the current list (39 programs)
This is called "modularity". The opposite of "monolithic". You seem to confuse those terms.
> The question people should ask, is not is systemd good or bad, but why are Pottering and crew making it a "requirement" or hard dependency for so many programs, and the list keeps growing!
Why should that be the second important question after the freedom question? If systemd is free software, well designed, documented, etc then it isn't a bad thing. Is it? So I think before supposing that systemd is bad because Red Hat is lobbying to impose it, we should simply find whether systemd is "good or bad".
the hyperbole is thick with some.
systemd is as much a practical concern as it is a philosophical concern. It violates the Unix and GNU/Linux principles. Keep in mind that GNU/Linux was designed to "not be Unix, but Unix like", it was not designed to be a free and opensource version of Windows or Apple for example. systemd also has the problem of taking GNU/Linux closer towards being more Windowish. As an example, one great feature of Unix and GNU has been the low risk of malware and viruses, and if someone does happen upon one, the damage is minimized, due to structure of the system. systemd, however, also introduces some virus problems (potential anyway), the autoreloading feature, can cause a malware program to continue to reboot/reload creating an endless loop. This was addressed by Linus to Pottering, whose reply was something along the lines of who cares, we will fix that in the future. Besides the benefits outweigh the risk.
I am not addressing conspiracies, just practical concerns. SysV was never made a requirement, nor OpenRC, nor BSD style scripts etc..., yet systemd is, that should raise questions. If something is great, then why not let people and distros, choose to either use it or not.
Onpon, don't be ridiculous, it is the 30+ year developers who are the most concerned with systemd, the ones jumping on the bandwagon tend to be the under 30 year old group, who were in diapers when the old timers created the foundation of the systems that we all enjoy. Good question, why are the older programmers not liking systemd, why are their concerns considered conspiratorial and not taken into consideration?
Again, perhaps, more questions should be raised and perhaps, systemd should slowly be analysed and introduced rather than pushed on the community. If it is great for RedHat, why not let them keep it like SELinux? If they want to make it a requirement for themselves, have at it...
It is a good thing that Trisquel is LTS perhaps over the next few years another alternative will come up, or perhaps systemd will be reigned in and return to just being a more modern init system.
It is laughable, that the original idea behind systemd, was to make it easier for junior coders and administrators to not have to remember different scripts or to even learn scripting in the first place, just tell them to type systemctl start... systemctl enable....
That alone says alot. Why onpon and Magic Banana cannot discuss this civilly is beyond me.
Same replied as your first post: "References needed". Let see if some come up this time...
systemd also has the problem of taking GNU/Linux closer towards being more Windowish.
What does it even means?
As an example, one great feature of Unix and GNU has been the low risk of malware and viruses, and if someone does happen upon one, the damage is minimized, due to structure of the system.
Will you actually defend the idea that arbitrary Shell scripts are more secure than a declarative definition of the services to run? That daemons that can escape any management is good for security? systemd fixes all that and more.
If something is great, then why not let people and distros, choose to either use it or not.
Distros chose to use it (or not, like Slackware, which always take a while to adopt a new technology). For example, Debian's technical committee voted for systemd first, Upstart second and sysvinit last. Nobody forced the committee to vote the init systems in that order.
If you do not want to use a distribution with systemd, don't. Is anybody forcing you?
the old timers created the foundation of the systems that we all enjoy.
So, basically, your argument is that 30 year-old software necessarily is good and should not be replaced for that reason (young developers suck?). I guess it does not matter that, since then, devices became hot-pluggable (sysvinit cannot start a service once a deice is plugged), processors became multi-core (sysvinit does not parallelize), etc. And who needs process supervision? If a deamon crashes, just do nothing. Anyway, sysvinit cannot do anything once the daemon has double-forked (as it should).
And you pretend that "all enjoy sysvinit" even if there exists many alternatives (systemd, upstart, dmd, openrc, initng, openlauchd, etc.) and that they are all unanimous: sysvinit has fundamental flaws. And, unless you do not use Trisquel, you do not enjoy sysvinit. Trisquel has been using Upstart since it is based on Ubuntu (i.e., since 2008). Are you even aware of that?!
Again, perhaps, more questions should be raised and perhaps, systemd should slowly be analysed and introduced rather than pushed on the community.
I lied: the choice voted last in Debian's vote was "further discussions" (sysvinit was right before). Indeed, the topic was extensively discussed. In the middle of the noise generated by conspiracy theorists that do not seem to know anything about the init system. That noise made many Debian developers quit at least some of their tasks. For instance, Tollef Fog Heen resigned as a Debian systemd maintainer last year ("because the amount of crap thrown [his] way just becomes too much").
It is laughable, that the original idea behind systemd, was to make it easier for junior coders and administrators to not have to remember different scripts or to even learn scripting in the first place, just tell them to type systemctl start... systemctl enable...
Why is it laughable? Things must be hard, ugly and insecure like a arbitrary Shell script? Even if there are simple, secure and elegant solutions like a descriptive language? I guess you then also find better that sysvinit requires fifteen steps to make a daemon: http://www.freedesktop.org/software/systemd/man/daemon.html
Do you choose Brainfuck when you have something serious to program?
If you cannot have an intelligent discussion and debate with decorum, then you only continue to show the folly that is the future of systemd.
GNU/Linux began with debate/discussion when did that end?
You might enjoy this thread:
https://forums.freebsd.org/threads/will-systemd-make-freebsd-more-popular.50107/
Are you not concerned with errors crashing the entire system, rather than one component which would have happened with a script based init? Also, how do you feel about systemd running processes that you cannot see, or binary logs and the inherent security concerns they pose?
Are we here to discuss this intelligently or only squabble about who is right or wrong? If the later, this long time opensource advocate is not interested.
If you cannot have an intelligent discussion and debate with decorum, then you only continue to show the folly that is the future of systemd. GNU/Linux began with debate/discussion when did that end?
That may have ended once some users started considering that they are entitled to take part in a technical discussion without knowing shit about the technical problems that are solved. You did not even know that you run some systemd modules (and even after I point it out, you still write that systemd is monolithic...) on top of Upstart (you write that "we all enjoy sysvinit" when Trisquel has actually been using Upstart since 2008)! With such a level on expertise on init systems, how can you even imagine that your discussion is intelligent?!
Your supposedly "intelligent discussion" is not based on facts. You do not give any reference (a discussion on a BSD forum does not support any fact). Not even when I repetitively ask for such references. I sincerely would like to read on how Red Hat forces systemd onto other distributions, on its wish to have its own kernel, on how systemd makes the system prone to viruses, on how it hides running processes, on how binary logs are less secure... but I guess those are just lies.
Like the lies you told about GNOME requiring "systemd as a hard dependency", about Kay Sievers trying "to hardwire the kernel to require systemd", or about "Debian's board replaced with Red Hat employees". I took the time to show, through references, that all this is pure bullshit:
- https://trisquel.info/forum/could-trisquel-8-switch-mate#comment-71427
- https://trisquel.info/forum/could-trisquel-8-switch-mate#comment-71493
- https://trisquel.info/forum/could-systemd-be-inconvenient-portability#comment-71619
I have better things to do. Unfortunately, those users, who feel entitled to discuss technical topics they know nothing about, tend to be more and more numerous. They repeat the lies like-minded users wrote before them. And the whole thing generates tensions. Tollef Fog Heen wrote in http://err.no/personal/blog/tech/Debian/2014-11-16-23-55_resigning_from_pkg-systemd about a "poisonous" environment:
Apparently, people care when you, as privileged person (white, male, long-time Debian Developer) throw in the towel because the amount of crap thrown your way just becomes too much. I guess that's good, both because it gives me a soap box for a short while, but also because if enough people talk about how poisonous the well that Debian is has become, we can fix it.
Are we here to discuss this intelligently or only squabble about who is right or wrong?
Are you really writing that an "intelligent discussion" should not be based on "right" things, on facts? Unbelievable.
If the later, this long time opensource advocate is not interested.
Good. Let us stop here. Please. This long time *free software* advocate is not interested in discussing with people that believe that lies are OK.
> it is the 30+ year developers who are the most concerned with systemd
I gave you a very specific explanation as to why systemd is being depended on, and even gave you another real-world example of the exact same thing which cropped up some 30 odd years ago. And your only response, apparently, is to give a vague argument from false authority and continue asserting that systemd is being "pushed on the community".
Oh, and then you conclude your message by insignuating that Magic Banana and I are bing uncivil. Well, my response to that is two words: "Prove it."
How about responding to my actual argument? Please, enlighten me as to how it's the choice of individual programmers when it happens with X, but "pushed on the community" when it's systemd.
"systemd is as much a practical concern as it is a philosophical concern. It violates the Unix and GNU/Linux principles."
Unix principles? I'd say that's more of a light technical concern, rather than a philosophical concern.
At this point, the GNU/Linux landscape is so diverse and varied that there isn't a "GNU/Linux principle," at least, not anymore.
"As an example, one great feature of Unix and GNU has been the low risk of malware and viruses, and if someone does happen upon one, the damage is minimized, due to structure of the system. systemd, however, also introduces some virus problems (potential anyway), the autoreloading feature, can cause a malware program to continue to reboot/reload creating an endless loop."
One bug and we should toss an entire program out? You only bring up that one bug to defend the idea that it will make GNU/Linux more prone to viruses.
"Again, perhaps, more questions should be raised and perhaps, systemd should slowly be analysed and introduced rather than pushed on the community."
systemd isn't being forced on anyone-- it is being widely and rather rapidly adopted because of it's various advantages.
"It is laughable, that the original idea behind systemd, was to make it easier for junior coders and administrators to not have to remember different scripts or to even learn scripting in the first place, just tell them to type systemctl start... systemctl enable...."
So user-friendliness isn't a valid goal? OK, then...
X, or Wayland are not the same as an init service.
systemd is doing things an init service should not do. Agree that SysV needed to be fixed, but why not fix it, why not replace it with a more modern but simple service, why a complex service that continues to grow and consume (merge) more and more services?
Again, you use the term "argument", who is arguing, this is a discussion, and yes arguing in a discussion is not civil.
Would you accept it if SELinux were a hard dependency or requirement of sysytemd for security purposes? Not saying this will happen, but would you be ok if it was? Who determines the limit of what systemd can and cannot do?
These are the questions that should be asked by kernel coders, programmers, and the general GNU/Linux user or student, as it affects the future direction of GNU/Linux.
> X, or Wayland are not the same as an init service.
And that has nothing to do with what I was saying. I was talking about programs being dependent on software which is not portable. The X library is not any more portable than systemd: it only works with X. That's why you have programs like XScavenger being entirely rewritten to use different libraries: it's the only way to get these programs to work on non-X systems!
So, again, why is it the individual choices of programmers when it's X, but "pushing it on the community" when it's systemd? Stop dodging the question.
> Again, you use the term "argument", who is arguing, this is a discussion, and yes arguing in a discussion is not civil.
I don't know if English is your native tongue or not, so I'm not going to fault you for not knowing what an argument is. But since you clearly don't understand, here is the relevant dictionary definition from the Merriam-Webster dictionary:
2 a : a reason given in proof or rebuttal
b : discourse intended to persuade
There is nothing "not civil" about argumentation. What do you expect us to do, just agree with everything you say, even when what you say is patently absurd and insulting?
> Would you accept it if SELinux were a hard dependency or requirement of sysytemd for security purposes? Not saying this will happen, but would you be ok if it was?
I really don't care. If the systemd developers find some SELinux facility to be so useful that they prefer to make it a hard dependency like that, and SELinux is libre software (which it is), it doesn't matter to me. The only point where it could matter is if the use of SELinux caused some secondary trouble for me, such as worse performance. But such a problem being caused by a dependency is no different from the same problem being caused by simple developer incompetence.
And, news flash, if SELinux did bother me so much, I would still be perfectly capable of not using systemd, or modifying systemd to remove the dependency.
> Who determines the limit of what systemd can and cannot do?
Whoever contributes to it. It's not that complex.
If you don't like the direction systemd is taking, fork it. If a bunch of people agree with you, they'll contribute to and/or use that version. If they don't, you carry a minority viewpoint on how systemd should be, and the simple fact is you have to deal with that.
> I was talking about programs being dependent on software which is not portable. The X library is not any more portable than systemd: it only works with X
Uhmm, I'm confused, portability in this context means "portability between *nix systems". I'm I correct? And the X Window System is for Unix-like systems (it works on Linux, GNU Hurd, BSD, Minix, Solaris, etc...). So, why do you say that X isn't portable?
I think Magic Banana's trying to talk in that particular post about how apps that depend on X don't simply run on other display servers.
Then again I'm not particularly competent in this matter which is why I haven't posted my own position yet.
It was me, not Magic Banana, but yes, that's exactly what I was talking about. :)
Context: https://trisquel.info/en/forum/could-systemd-be-inconvenient-portability#comment-71618
Ah yes! Sorry (I was also looking at a few of MB's posts here so must've mixed up yours with his).
Don't know either what you're talking about nor how was the adoption of X. All I know is X is portable between *nix systems and was intended to be used in GNU. So if the adoption of X was any better than systemd, maybe that had something to do.
Also, how systemd replaced other inits in some distributions, could have something to do with why people feel is being imposed.
An ex-user of Fedora:
I ended up figuring out a way to install Fedora 15 starting from a minimal system without using Systemd. And it worked, too. But I had to maintain the SysV scripts myself with rsync after every system update because the various package maintainers were beginning to make their update rpms delete their old SysV and Upstart stuff.[1]
In arch linux systemd was pushed by updates, so if didn't saw the change list before applying the update, you would got another init without ever asking.
An ex-user of Arch:
In a recent update, it was made apparent to me that systemd includes udev, and dbus requires systemd (on Arch) in order to function. Since I was unable to excise systemd from my Arch Linux installation[2]
[1] https://www.linuxquestions.org/questions/linux-from-scratch-13/what-is-so-bad-with-systemd-4175500300/#post5145285
[2] http://sporkbox.us/misc/old_posts/95.html
Argumentation is defined here as: the act or process of forming reasons and of drawing conclusions and applying them to a case in discussion"(1)
So how can argumentation not be considered civil in a discussion when nothing in the definition says so?
And how can arguing be considered not to be civil when it's a sinonym of discussing(2)? What's your mother tongue (mine's not English but I posted citations)?
1. http://www.merriam-webster.com/dictionary/argumentation
2. http://dictionary.reference.com/browse/argue
I am a translator!
I hereby mark this thread as "solved"
Discussions are never solved, they just fade away unless pinned until someone posts bump into it and breathes new life to a thread just like that.
On May 31 22:45 2014, Lennart wrote:
Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
> Unless the systemd-haters prepare another kdbus userspace[,] until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.
So according to Lennart anyone who wants udev without systemd is automatically a "systemd-hater". So for example those GNU Hurd/BSD/Etc.. guys who want to port Wayland (which use udev) are also "systemd-haters".
> Gentoo folks, this is your wakeup call.
What's this? Some kind of ultimatum?
Some Gentoo developers, who happen to hate systemd, forked udev in 2012, right after udev was merged into systemd. The fork is called eudev. Up to last year, systemd could still use the old-style udev. With the message you quote, Lennart Poettering announces that this support will stop. To follow their plans the Gentoo developers either had to "prepare another kdbus userspace" or ship eudev. They chose the second option, by the way.
> Some Gentoo developers, who happen to hate systemd
I know, but even so Lennart isn't a lead developer of any project. Systemd aims to be "the simple building blocks" for all the GNU/Linux distributions as they want to "unify many of the needless differences between the distributions", it is clear that systemd aims to be a very important piece of the system core components. So I would expect more professionalism and seriousness coming from someone like him, and not that kind of statement that you would expect from any random guy in the Internet defending systemd. And on top of that, Lennart is being paid while the vast majority (if not all) of the Gentoo developers are volunteers. So in summary: That kind of attitude is disappointing.
> forked udev in 2012, right after udev was merged into systemd. The fork is called eudev. Up to last year, systemd could still use the old-style udev.
Just for the people that didn't knew of eudev: The reason why Gentoo fork udev into eudev was to keep udev separate of systemd and therefore software that depend on udev separate of systemd. As udev is one of the components that can't be "Reimplementable Independently"[1].
> With the message you quote, Lennart Poettering announces that this support will stop. To follow their plans[,] the Gentoo developers either had to "prepare another kdbus userspace" or ship eudev. They chose the second option, by the way.
Uhmm, or ship eudev? What do you mean by "ship eudev"?
[1] http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
That kind of attitude is disappointing.
I agree.
What do you mean by "ship eudev"?
I thought that eudev was not stable at that date. But, I was wrong: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/eudev/ChangeLog
eudev 1.1 entered Gentoo stable (without a subsequent revert) in August and September 2013 (depending on the architecture).
Just for the record:
On Apr 3 2012 Kay Sievers said:
The udev built from the systemd source tree will stay compatible with non-systemd init systems for a long time.
https://lwn.net/Articles/490413/
Then only four months after Kay's e-mail, in Aug 1 2012 Lennart said:
Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
Since when 123 days are considered "a long time" in terms of stable software?
That's exactly what it was danieru. An ultimatum not just for Gentoo but for anyone not on board with systemd. Nice post by the way.
Pottering's attitude is what has many dev.'s question the intention of his project, and the overall scope of his plans. Never seen anything like it before, at least not on this scale and level.
Gentoo will continue to develop OpenRC and give its users the choice during install whether they want systemd or openRC or a combination of the two.
Slackware, Crux, BSD's and others are against systemd, and have no plans to implement it. Slackware has gone so far as to drop any support for Gnome and its programs as a result of its stance against systemd and RedHat influence in general.
Slackware has gone so far as to drop any support for Gnome and its programs as a result of its stance against systemd and RedHat influence in general.
That is one more lie. Slackware dropped GNOME's support between versions 10.1 and 10.2 in 2005, i.e., five years before systemd's initial release: http://distrowatch.com/slackware
ftp://ftp.slackware.com/pub/slackware/slackware-10.2/ChangeLog.txt gives a precise date for the remotion of GNOME from Slackware, "Sat Mar 26 23:04:41 PST 2005". Here is the relevant message in the ChangeLog, where Patrick Volkerding asks to "not incorrectly interpret any of this as a slight against GNOME (...) a decent desktop choice" :
gnome/*: Removed from -current, and turned over to community support and
distribution. I'm not going to rehash all the reasons behind this, but it's
been under consideration for more than four years. There are already good
projects in place to provide Slackware GNOME for those who want it, and
these are more complete than what Slackware has shipped in the past. So, if
you're looking for GNOME for Slackware -current, I would recommend looking at
these two projects for well-built packages that follow a policy of minimal
interference with the base Slackware system:
http://gsb.sf.net
http://gware.sf.net
There is also Dropline, of course, which is quite popular. However, due to
their policy of adding PAM and replacing large system packages (like the
entire X11 system) with their own versions, I can't give quite the same sort
of nod to Dropline. Nevertheless, it remains another choice, and it's _your_
system, so I will also mention their project:
http://www.dropline.net/gnome/
Please do not incorrectly interpret any of this as a slight against GNOME
itself, which (although it does usually need to be fixed and polished beyond
the way it ships from upstream more so than, say, KDE or XFce) is a decent
desktop choice. So are a lot of others, but Slackware does not need to ship
every choice. GNOME is and always has been a moving target (even the
"stable" releases usually aren't quite ready yet) that really does demand a
team to keep up on all the changes (many of which are not always well
documented). I fully expect that this move will improve the quality of both
Slackware itself, and the quality (and quantity) of the GNOME options
available for it.
Note to Rueben, people should not be able to +1 their own posts.
Magic. You are correct about when they dropped Gnome, however, you obviously cannot tell the difference between Patrick (public voice/P.C.) and how he feels about certain things in GNU/Linux. That is obvious.
Here is a link to several of the Slackware dev's and users discussing systemd, pay close attention to Pat's and AlienBob both developers for along time...and keep in mind that Slackware is the oldest distro, and has the street cred's to back up what they say.
https://www.linuxquestions.org/questions/slackware-14/systemd-and-slackware%27s-future-4175416339/
I am a translator!
Ha! It's true! You can up-vote your own posts. Just did that with the hamster and cookie. That is soo 90210!
And now, if you excuse me I have some own-posts to up-vote.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires