Re: Re: If Not Systemd, then What?
Martin Read: 1. The init daemon should fork exactly once; in the child it should exec another program, while the parent (PID 1) does nothing except reap zombies. 2. As (1), except that if the initially-forked child process exits, PID 1 should repeat the fork and exec-in-child procedure. Whilst you were primarily making a point about the idea of requring interchangeability of tools that involve different design decisions, you did make a common error in two of your examples that should be addressed. Whilst these are commonly-held positions, they are only commonly held by people who have never actually written a process #1 program that functions in production systems; because experience (as I can attest) teaches otherwise. There are, in fact, several things that various operating system kernels and other programs demand of process #1 that one simply cannot escape. People think, as above, that acting as the parent of orphaned processes is the prime function. Ironically, it is (with recent Linux kernels) a part the system that one can largely factor out of process #1 into other processes, whilst the things that people usually forget in their off-the-top-of-the-head designs (such as handling SIGINT, SIGPWR, SIGWINCH, and so forth sent from the kernel and enacting the various system state change requests) are the parts that one cannot. To see what one actually has no choice but to do in process #1 programs, look at the overlaps in the operation of Gerrit Pape's runit, Felix von Leitner's minit, and the system-manager program from the nosh package. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f44d3.9010...@ntlworld.com
Re: init scripts [was: If Not Systemd, then What?]
On Ma, 18 nov 14, 23:12:48, Miles Fidelman wrote: I still don't think I'm seeing your point. Mail servers, and servers in general need to be initialized, usually rely on the o/s init system, and generally come packaged with a collection of init and utility scripts. To date, every single major server we rely on, for a relatively standard collection of web, mail, list, and database servers comes stock with ONLY sysvinit scripts. To me, that's caring about the init system. Can you elaborate on what you mean by don't care? ... Again, this seems like a backwards perspective. When I put on my product manager's hat (which I've done at one time in my life), from a developer's point of view, one generally tries to develop for cross-platform compatibility. Having to package, or be packaged for a specific environment is a major inconvenience - especially when said packaging relies on human beings. From an upstream point of view, the goal is to develop for the least-common-denominator that's supported across the broadest range platforms used by one's target users. You've answered your own question. Currently sysv *is* the least common denominator. From an upstream perspective, increased use of systemd, just makes lives more difficult - once can no longer count on simply including a set of sysvinit scripts with confidence that they'll just work. At a minimum, they have to start worrying about incompatibilities between their init scripts and systemd's implementation of sysvinit. Assuming there are any. Beyond that, they have to either rely on packagers, or start including systemd service files. That just strikes me as a less desirable situation - more things to go wrong, more people and steps in the delivery chain. Service files are incredibly easy to write *and* they already provide a sysvinit script, so it's not like their software is unusable on systemd unless they provide one. As packages in Debian will gain .service files (in addition to sysvinit scripts) I expect at least a large portion of these to be submitted upstream, as any diligent Debian package maintainer should do, so you'll see more and more of them, at least for active upstream/packager combinations. Why do the work when the distributions can do it for you? ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
[OT] xy? [was: Re: init scripts [was: If Not Systemd, then What?]]
Scott Ferguson wrote: On 19/11/14 15:12, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 23:14, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 15:06, Miles Fidelman wrote: snipped Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. ummm that's awfully cryptic Not if you are a programmer, or read this list often. http://mywiki.wooledge.org/XyProblem Can't say that I've ever come across it used on this list. https://www.google.com/search?q=+xy+problem+site%3Ahttps%3A%2F%2Flists.debian.org 36 total hits - I'd say that's obscure And while I can't claim to be much of a programmer, at least these days, I've managed and worked with an awful lot of programmers, and I can honestly say that I've never come across the term in general usage. Odd - it's commonly employed on stack exchange and various programming lists. I'll take your word for it. Just saying that I personally have not come across it. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546c9ddd.9020...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
Andrei POPESCU wrote: On Ma, 18 nov 14, 23:12:48, Miles Fidelman wrote: I still don't think I'm seeing your point. Mail servers, and servers in general need to be initialized, usually rely on the o/s init system, and generally come packaged with a collection of init and utility scripts. To date, every single major server we rely on, for a relatively standard collection of web, mail, list, and database servers comes stock with ONLY sysvinit scripts. To me, that's caring about the init system. Can you elaborate on what you mean by don't care? ... Again, this seems like a backwards perspective. When I put on my product manager's hat (which I've done at one time in my life), from a developer's point of view, one generally tries to develop for cross-platform compatibility. Having to package, or be packaged for a specific environment is a major inconvenience - especially when said packaging relies on human beings. From an upstream point of view, the goal is to develop for the least-common-denominator that's supported across the broadest range platforms used by one's target users. You've answered your own question. Currently sysv *is* the least common denominator. From an upstream perspective, increased use of systemd, just makes lives more difficult - once can no longer count on simply including a set of sysvinit scripts with confidence that they'll just work. At a minimum, they have to start worrying about incompatibilities between their init scripts and systemd's implementation of sysvinit. Assuming there are any. If you believe in any kind of qa, pro-active design review, and/or testing, you now have one more thing to worry about. And if you provide any install time regression tests, you have to be concerned about a new class of bugs. Beyond that, they have to either rely on packagers, or start including systemd service files. That just strikes me as a less desirable situation - more things to go wrong, more people and steps in the delivery chain. Service files are incredibly easy to write *and* they already provide a sysvinit script, so it's not like their software is unusable on systemd unless they provide one. As packages in Debian will gain .service files (in addition to sysvinit scripts) I expect at least a large portion of these to be submitted upstream, as any diligent Debian package maintainer should do, so you'll see more and more of them, at least for active upstream/packager combinations. Why do the work when the distributions can do it for you? ;) Trusting one more group of people, mostly volunteers, to do the right thing, in a timely manner. It's not like all packages are well-maintained, in a timely fashion. I'd rather rely on cross-platform development tools and not rely on packagers at all. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546ca010.2050...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
On 18/11/14 15:06, Miles Fidelman wrote: Please don't top post - it's not hard to move the mouse. Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. However - I don't 'believe' it's a relevant point. A. Mail servers don't care about init systems. Quite the reverse. B. systemd's ain't systemd's (e.g. what constitutes systemd varies according to release and distro). (i.e. ~/.bashrc from debian isn't identical to upstreams). To ensure I wasn't falling into the trap of confirmation bias - before checking upstream for init support I'd be asking myself if it was necessary (cart before horse?). e.g. Why *should* sendmail ship *a* systemd .session file? After all sendmail developers have to support a wide range of systems and apportion resources according to their definition of needs. 1. Compared to configuring sendmail correctly it's trivial to create one to suit the usecase. 2. Like sendmail itself there is no one-size-all session/timer configuration. 3. If the user installs from a distro repostitory they get a default .session file to match the distro. (If the distro is going to do the work why should upstream do it?) They ship sysvinit scripts, period. Which is my point. I suspect the logic you base the point upon is flawed. Major upstream application developers do not seem to be jumping on systemd. More important than trying to find evidence of a negative 'might' be determining whether there is a need. If there is none[*1] then the absence of proof has little value. [*1]you mention sendmail, which is widely deployed on distros that use systemd *despite* upstream not distributing systemd support - because upstream support for systemd is redundant. Do you have something less fuzzy than major upstream application developers?? It's puzzling as this is Debian and most of us use the *Debian packaged* version of upstream so the relevance is difficult to dissern. If anything, what I'm seeing are oh sht, I guess we should develop systemd service units at some point. Can you point to some upstream references for this please? (my Google-fu fails me). Miles Fidelman Did you try Google? https://www.google.com/search?q=systemd+%2B%22sendmail.service%22ie=utf-8oe=utf-8aq=tchannel=sb What do they know? I'm sorry, I can't answer empty rhetoric questions. Was that intentional? Could you rephrase the question so it makes sense please? Miles Fidelman e.g. sendmail.service:- [Unit] Description=Sendmail Mail Transport Agent After=syslog.target network.target [Service] Environment=QUEUE=1h EnvironmentFile=/etc/sysconfig/sendmail Type=forking ExecStart=/usr/sbin/sendmail -bd -q $QUEUE $SENDMAIL_OPTARG [Install] WantedBy=multi-user.target Useful Refs:- https://wiki.archlinux.org/index.php/sendmail#Start_on_boot https://wiki.archlinux.org/index.php/Systemd/Timers http://0pointer.de/blog/projects/systemd-for-admins-2.html https://www.lisenet.com/2014/create-a-systemd-service-to-send-automatic-emails-when-arch-linux-restarts/ Kind regards -- Turns out you can't back a winner in the Gish Gallop ~ disappointed punter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546afc6c.70...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 08:54:16PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. False, how? the whole part that you erased showed there is a few upstreams that care about integration with systemd at the source code level. Ie, using features of systemd ( journald, socket activation ), rather than just providing a .service file. No... my point is that NONE of the major upstream projects that I use on our servers, bother to produce systemd service files, but all of them produce sysvinit files. so you select only the upstream you want, on the point you want. And erase when someone point the problem. And I'll note that those are precisely some of the most used, most mature packages, that you'll find on practically every production server in the world (well, ok, I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). What do they know? Show us where Debian is using the file shipped by upstream. Then, tell me, is Debian wrong to not use them, or are the script shipped upstream deficient ? In fact, you show they are shipping initscript, but tell me, how many of them are proper initscript, following lsb ? http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html As you didn't gave any link to source code, you place extra burden on the one trying to be critics about your argument. Maybe that's what you want, maybe not. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141118090718.ga18...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
Scott Ferguson wrote: On 18/11/14 15:06, Miles Fidelman wrote: Please don't top post - it's not hard to move the mouse. Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. ummm that's awfully cryptic However - I don't 'believe' it's a relevant point. A. Mail servers don't care about init systems. Quite the reverse. B. systemd's ain't systemd's (e.g. what constitutes systemd varies according to release and distro). (i.e. ~/.bashrc from debian isn't identical to upstreams). Are you kidding me? Mail servers generally start up automatically as system services, and need to get restarted if they die. How does that not involve the init system? Same again for pretty much any server. To ensure I wasn't falling into the trap of confirmation bias - before checking upstream for init support I'd be asking myself if it was necessary (cart before horse?). e.g. Why *should* sendmail ship *a* systemd .session file? After all sendmail developers have to support a wide range of systems and apportion resources according to their definition of needs. 1. Compared to configuring sendmail correctly it's trivial to create one to suit the usecase. 2. Like sendmail itself there is no one-size-all session/timer configuration. 3. If the user installs from a distro repostitory they get a default .session file to match the distro. (If the distro is going to do the work why should upstream do it?) They ship sysvinit scripts, period. Which is my point. I suspect the logic you base the point upon is flawed. ./configure make; make test; make install pretty much works for pretty much any major server application - which includes installing init scripts from upstream that just work packaging adds some convenience in handling dependencies and managing system configuration, usually at the expense of running well behind what comes from upstream (and checkinstall makes it pretty easy to integrate upstream source into package management) generally, I can rely on upstream code to just work - and usually, but not always, packaged versions are reasonably current and just work but... when upstream provides sysvinit scripts, that adds complexity and/or extra code: - either the packager has to write systemd init info (one more thing to go wrong and that should be regression tested), or, - systemd has to handle the init script properly - again one more thing to go wrong, particularly if the upstream script runs afoul of one of the documented (or undocumented) incompatibilities in systemd's handling of init scripts (and why should upstream have to worry about that when they code?) Major upstream application developers do not seem to be jumping on systemd. More important than trying to find evidence of a negative 'might' be determining whether there is a need. If there is none[*1] then the absence of proof has little value. [*1]you mention sendmail, which is widely deployed on distros that use systemd *despite* upstream not distributing systemd support - because upstream support for systemd is redundant. Do you have something less fuzzy than major upstream application developers?? It's puzzling as this is Debian and most of us use the *Debian packaged* version of upstream so the relevance is difficult to dissern. If anything, what I'm seeing are oh sht, I guess we should develop systemd service units at some point. Can you point to some upstream references for this please? (my Google-fu fails me). Don't really have a lot of time to retrace my steps, but I came across comments to this effect on at least two (I think three) dev lists for programs on the list of major server apps that you clipped from this thread. But you could start here: http://search.gmane.org/?query=systemdgroup=gmane.comp.db.postgresql.devel.general Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b3811.4060...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 08:54:16PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. False, how? the whole part that you erased showed there is a few upstreams that care about integration with systemd at the source code level. Ie, using features of systemd ( journald, socket activation ), rather than just providing a .service file. No... my point is that NONE of the major upstream projects that I use on our servers, bother to produce systemd service files, but all of them produce sysvinit files. so you select only the upstream you want, on the point you want. And erase when someone point the problem. No... I selected the upstreams that I run on our servers, and then since a few of them are less common, I added the more common equivalents: - I run postfix, added sendmail - I run sympa, added mailman - I run mysql, added mariadb and postgres And I'll note that those are precisely some of the most used, most mature packages, that you'll find on practically every production server in the world (well, ok, I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). What do they know? Show us where Debian is using the file shipped by upstream. ummm... as the start for packaging and I expect a lot of people install from upstream source when packaged versions get stale (as they do, for example, with sympa) - I know I do Then, tell me, is Debian wrong to not use them, or are the script shipped upstream deficient ? In fact, you show they are shipping initscript, but tell me, how many of them are proper initscript, following lsb ? http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html You know, I really don't care. They work, with mature sysvinit init systems. As you didn't gave any link to source code, you place extra burden on the one trying to be critics about your argument. Maybe that's what you want, maybe not. Tough. Particularly in that I don't really care about arguing with anyone who really has his mind made up. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b3ab0.5020...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
Am 18.11.2014 um 10:07 schrieb Ludovic Meyer ludo.v.me...@gmail.com: Show us where Debian is using the file shipped by upstream. Maybe drbd? Then, tell me, is Debian wrong to not use them, or are the script shipped upstream deficient ? In fact, you show they are shipping initscript, but tell me, how many of them are proper initscript, following lsb ? http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html The init script of drbd should conform to LSB because I checked it against LSB around 2007 and it was patched afterwards. But who knows what happend in the meantime. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0110cb02-da99-4118-9ca8-4ee40ec9c...@fixpunkt.de
Re: init scripts [was: If Not Systemd, then What?]
Show us where Debian is using the file shipped by upstream. dpkg -l | grep xymon ii xymon-client 4.3.17-4 amd64client for the Xymon network monitor 17:25:35 weezer:~/src/xymon-4.3.17$ diff /etc/init.d/xymon-client debian/xymon-client.init 3,4c3,4 # xymon-clientThis shell script takes care of starting and stopping # the xymon client. --- # xymonclientThis shell script takes care of starting and stopping #the Xymon client. 19c19 NAME=xymon-client --- NAME=xymonclient 29c29 # Include xymon-client defaults if available --- # Include xymonclient defaults if available 43,48d42 if test $TMPFSSIZE test -e /proc/mounts ! grep -q /var/lib/xymon/tmp /proc/mounts; then echo Mounting tmpfs on /var/lib/xymon/tmp rm -f /var/lib/xymon/tmp/* mount -t tmpfs -osize=$TMPFSSIZE,mode=755,uid=$(id -u xymon) tmpfs /var/lib/xymon/tmp fi wc -l /etc/init.d/xymon-client 109 /etc/init.d/xymon-client So the xymon-client package uses the init script from upstream, with some modifications (naturally). Cheers Iain -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fadafb58a04c262ef88414af24d4c...@thargoid.co.uk
Re: init scripts [was: If Not Systemd, then What?]
Le dimanche, 16 novembre 2014, 11.50:25 Miles Fidelman a écrit : Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. Let's take the inverse view: which of these use the upstream sysvinit scripts directly ? The answer, as demonstrated below, is: none. bind9 http://sources.debian.net/src/bind9/1:9.9.5.dfsg-5/debian/bind9.init/ apache http://sources.debian.net/src/apache2/2.4.10-7/debian/apache2.init/ sympa http://sources.debian.net/src/sympa/6.1.23~dfsg-1/debian/sympa.init/ mailman http://sources.debian.net/src/mailman/1:2.1.18-1/debian/mailman.init/ mysql http://sources.debian.net/src/mysql-5.5/5.5.39-1/debian/mysql-server-5.5.mysql.init/ mariadb http://sources.debian.net/src/mariadb-10.0/10.0.14-3/debian/mariadb-server-10.0.mysql.init/ postgres http://sources.debian.net/src/postgresql-common/163/debian/postgresql-common.postgresql.init/ postfix http://sources.debian.net/src/postfix/2.11.3-1/debian/init.d/ spamassassin http://sources.debian.net/src/spamassassin/3.4.0-3/debian/spamassassin.init/ amavisd http://sources.debian.net/src/amavisd-new/1:2.10.1-1/debian/amavisd-new.amavis.init/ clamav http://sources.debian.net/src/clamav/0.98.5~rc1%2Bdfsg-4/debian/clamav-daemon.init.in/ (I've only looked at current sid versions and checked in the debian/ directory. Feel free to run your own investigations using the fantastic sources.debian.net.) Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file The above IMHO demonstrates quite clearly one of the advantages of systemd over sysvinit: for all of the examples you took, Debian is currently using a Debian-specific sysvinit script (I haven't investigated the reasons though), all of which are quite redundant. They are not shared across distributions at all. So, the upstream examples you chose actually demonstrate that these were not targeting Debian enough for the Debian maintainers to use the provided init scripts (if these were even provided). (Note, I'm not claiming Debian will not need to modify the eventual systemd configuration files either, even if I think it's less probable.) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2240015.XzS36MAbdC@gyllingar
Re: init scripts [was: If Not Systemd, then What?]
Hallo, * Miles Fidelman [Sun, Nov 16 2014, 02:41:14PM]: Andrei POPESCU wrote: On Du, 16 nov 14, 11:50:25, Miles Fidelman wrote: So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared I don't see any item that would matter on a Debian system, care to elaborate? It's very simple. I have a bunch of stuff running on my system that I compiled from upstream code, including init scripts that work just fine. Now I have to worry that some of those scripts are incompatible with systemd. You have already opened the Pandora box when you started relying on self-compiled software which is installed aside of any knowlege of dpkg. Now you hope to reduce your own efforts on upgrading by holding back any progress. Is this fair? I don't think so. If you don't see what I mean, think about all the other packages where Debian does not promise backwards compatibility (Perl/Python/... modules, etc, i.e. all that beasts that make a transition in big clusters). You already have to read the release notes now, why should we make an exception here for startup related parts? Apart from that, have ever read those init scripts from upstream packages or is this all this aversion just lazyness and fear / panic to not touch a running system (but do a system upgrade, ha, ha, ha)? Regards, Eduard. signature.asc Description: Digital signature
Re: init scripts [was: If Not Systemd, then What?]
On 18/11/14 23:14, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 15:06, Miles Fidelman wrote: snipped Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. ummm that's awfully cryptic Not if you are a programmer, or read this list often. http://mywiki.wooledge.org/XyProblem However - I don't 'believe' it's a relevant point. A. Mail servers don't care about init systems. Quite the reverse. B. systemd's ain't systemd's (e.g. what constitutes systemd varies according to release and distro). (i.e. ~/.bashrc from debian isn't identical to upstreams). Are you kidding me? No. Mail servers generally start up automatically as system services, and need to get restarted if they die. How does that not involve the init system? Please read again. I never said mail servers do not involve the init system - I said mail servers don't care about the init system. They simply need to be initiated, and, depending on the admins desires, monitored - typically by a daemon. Whether started by /etc/rc.local, cron/acron, or *any* init system - mail servers don't care. snipped To ensure I wasn't falling into the trap of confirmation bias - before checking upstream for init support I'd be asking myself if it was necessary (cart before horse?). e.g. Why *should* sendmail ship *a* systemd .session file? After all sendmail developers have to support a wide range of systems and apportion resources according to their definition of needs. 1. Compared to configuring sendmail correctly it's trivial to create one to suit the usecase. 2. Like sendmail itself there is no one-size-all session/timer configuration. 3. If the user installs from a distro repostitory they get a default .session file to match the distro. (If the distro is going to do the work why should upstream do it?) They ship sysvinit scripts, period. Which is my point. I suspect the logic you base the point upon is flawed. ./configure make; make test; make install Apropos of what??!! pretty much works for pretty much any major server application It pretty much works to *build* any package; test the build, and then (crudely) install it. - which includes installing init scripts from upstream that just work Pretty much i.e. sometimes. IMO it's too generic to apply a process that's designed to work in non-specific situations to *specific* situations - in this case, Debian. packaging adds some convenience in handling dependencies and managing system configuration, usually at the expense of running well behind what comes from upstream (and checkinstall makes it pretty easy to integrate upstream source into package management) Agreed. But, huh?? You talk of a need for stability then choose bleeding edge corner cases. Current upstream version of sendmail is 8.14.9 which:- ;just works with Jessie or Wheezy when systemd is installed using the Debian packaged systemd session configs for sendmail ; 8.14.8-1 from RC installs on Debian just fine. generally, I can rely on upstream code to just work - and usually, but not always, packaged versions are reasonably current and just work Agreed. Though the Debian way isn't always what upstream supports - and often I've found their Debian package is actually Ubuntu packaging, so I've had to tweak things (likewise checkinstall and rpm conversions don't always work). That's the price of choosing the bleeding edge don't you think? but... when upstream provides sysvinit scripts, that adds complexity and/or extra code: Yes, though:- ;I don't expect upstream to support all distros and releases ;I had many LSB errors from upstream sysvinit scripts - so as a rule I expect problems when installing packages from upstream. Lack of support for downstream *is to be expected*. - either the packager has to write systemd init info (one more thing to go wrong and that should be regression tested), or, - systemd has to handle the init script properly - again one more thing to go wrong, particularly if the upstream script runs afoul of one of the documented (or undocumented) incompatibilities in systemd's handling of init scripts (and why should upstream have to worry about that when they code?) Agreed pretty much. Lack of support for downstream *is to be expected*. If you have a problem with that take it upstream. Major upstream application developers do not seem to be jumping on systemd. More important than trying to find evidence of a negative 'might' be determining whether there is a need. If there is none[*1] then the absence of proof has little value. [*1]you mention sendmail, which is widely deployed on distros that use systemd *despite* upstream not distributing systemd support - because
Re: init scripts [was: If Not Systemd, then What?]
Didier 'OdyX' Raboud wrote: Le dimanche, 16 novembre 2014, 11.50:25 Miles Fidelman a écrit : Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. Let's take the inverse view: which of these use the upstream sysvinit scripts directly ? The answer, as demonstrated below, is: none. Out of curiosity, how are you comparing these to the init scripts that are generated by making the upstream source? At the very least, would not the appropriate references be bind9 http://sources.debian.net/src/bind9/1:9.9.5.dfsg-5/debian/bind9.init/ http://sources.debian.net/src/bind9/1:9.9.5.dfsg-5/debian/changelog - look for references to init apache http://sources.debian.net/src/apache2/2.4.10-7/debian/apache2.init/ http://sources.debian.net/src/apache2/2.4.10-7/debian/changelog etc. or a diff between the upstream source and the script in the Debian package sympa http://sources.debian.net/src/sympa/6.1.23~dfsg-1/debian/sympa.init/ mailman http://sources.debian.net/src/mailman/1:2.1.18-1/debian/mailman.init/ mysql http://sources.debian.net/src/mysql-5.5/5.5.39-1/debian/mysql-server-5.5.mysql.init/ mariadb http://sources.debian.net/src/mariadb-10.0/10.0.14-3/debian/mariadb-server-10.0.mysql.init/ postgres http://sources.debian.net/src/postgresql-common/163/debian/postgresql-common.postgresql.init/ postfix http://sources.debian.net/src/postfix/2.11.3-1/debian/init.d/ spamassassin http://sources.debian.net/src/spamassassin/3.4.0-3/debian/spamassassin.init/ amavisd http://sources.debian.net/src/amavisd-new/1:2.10.1-1/debian/amavisd-new.amavis.init/ clamav http://sources.debian.net/src/clamav/0.98.5~rc1%2Bdfsg-4/debian/clamav-daemon.init.in/ (I've only looked at current sid versions and checked in the debian/ directory. Feel free to run your own investigations using the fantastic sources.debian.net.) the in depth analysis would be how many additional changes had to be added to accommodate any incompatibilities between sysvinit scripts and systemd's handling of said scripts Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file The above IMHO demonstrates quite clearly one of the advantages of systemd over sysvinit: for all of the examples you took, Debian is currently using a Debian-specific sysvinit script (I haven't investigated the reasons though), all of which are quite redundant. They are not shared across distributions at all. So, the upstream examples you chose actually demonstrate that these were not targeting Debian enough for the Debian maintainers to use the provided init scripts (if these were even provided). (Note, I'm not claiming Debian will not need to modify the eventual systemd configuration files either, even if I think it's less probable.) actually, what my experience tells me is that every one of those packages works equally well when installed from a .deb package, or when built directly from upstream source -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546c0a1e.9020...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
Scott Ferguson wrote: On 18/11/14 23:14, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 15:06, Miles Fidelman wrote: snipped Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. ummm that's awfully cryptic Not if you are a programmer, or read this list often. http://mywiki.wooledge.org/XyProblem Can't say that I've ever come across it used on this list. And while I can't claim to be much of a programmer, at least these days, I've managed and worked with an awful lot of programmers, and I can honestly say that I've never come across the term in general usage. Of course, your mileage may vary. However - I don't 'believe' it's a relevant point. A. Mail servers don't care about init systems. Quite the reverse. B. systemd's ain't systemd's (e.g. what constitutes systemd varies according to release and distro). (i.e. ~/.bashrc from debian isn't identical to upstreams). Are you kidding me? No. Mail servers generally start up automatically as system services, and need to get restarted if they die. How does that not involve the init system? Please read again. I never said mail servers do not involve the init system - I said mail servers don't care about the init system. They simply need to be initiated, and, depending on the admins desires, monitored - typically by a daemon. Whether started by /etc/rc.local, cron/acron, or *any* init system - mail servers don't care. I still don't think I'm seeing your point. Mail servers, and servers in general need to be initialized, usually rely on the o/s init system, and generally come packaged with a collection of init and utility scripts. To date, every single major server we rely on, for a relatively standard collection of web, mail, list, and database servers comes stock with ONLY sysvinit scripts. To me, that's caring about the init system. Can you elaborate on what you mean by don't care? snipped To ensure I wasn't falling into the trap of confirmation bias - before checking upstream for init support I'd be asking myself if it was necessary (cart before horse?). e.g. Why *should* sendmail ship *a* systemd .session file? After all sendmail developers have to support a wide range of systems and apportion resources according to their definition of needs. 1. Compared to configuring sendmail correctly it's trivial to create one to suit the usecase. 2. Like sendmail itself there is no one-size-all session/timer configuration. 3. If the user installs from a distro repostitory they get a default .session file to match the distro. (If the distro is going to do the work why should upstream do it?) They ship sysvinit scripts, period. Which is my point. I suspect the logic you base the point upon is flawed. ./configure make; make test; make install Apropos of what??!! pretty much works for pretty much any major server application It pretty much works to *build* any package; test the build, and then (crudely) install it. - which includes installing init scripts from upstream that just work Pretty much i.e. sometimes. IMO it's too generic to apply a process that's designed to work in non-specific situations to *specific* situations - in this case, Debian. Well, for all of the servers I've installed, I've at various times installed from upstream source, on multiple distros, and BSD, and things just worked. The gnu autotools are pretty clever that way. packaging adds some convenience in handling dependencies and managing system configuration, usually at the expense of running well behind what comes from upstream (and checkinstall makes it pretty easy to integrate upstream source into package management) Agreed. But, huh?? You talk of a need for stability then choose bleeding edge corner cases. At various times, I've found the packaged versions of mission-critical software to lag way behind upstream - particularly in the case of the list management software we use, and at times, antispam and antivirus software. Also, some of the stuff we experiment and develop with (various NoSQL databases, and Erlang). Sometimes waiting for packaging to catch up just doesn't cut it (anti-spam stuff, for example - always looking at new tools there). I worry a lot more about stability in the sense of environment and regression testing. I really don't like it when my platform changes under me. Applications, I expect to change. snip Agreed. Though the Debian way isn't always what upstream supports - and often I've found their Debian package is actually Ubuntu packaging, so I've had to tweak things (likewise checkinstall and rpm conversions don't always work). That's the price of choosing the bleeding edge don't you think? But, to date, the Debian way has
Re: init scripts [was: If Not Systemd, then What?]
On 19/11/14 15:12, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 23:14, Miles Fidelman wrote: Scott Ferguson wrote: On 18/11/14 15:06, Miles Fidelman wrote: snipped Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. Your point was noted - hence the xy? comment. ummm that's awfully cryptic Not if you are a programmer, or read this list often. http://mywiki.wooledge.org/XyProblem Can't say that I've ever come across it used on this list. https://www.google.com/search?q=+xy+problem+site%3Ahttps%3A%2F%2Flists.debian.org And while I can't claim to be much of a programmer, at least these days, I've managed and worked with an awful lot of programmers, and I can honestly say that I've never come across the term in general usage. Odd - it's commonly employed on stack exchange and various programming lists. Of course, your mileage may vary. However - I don't 'believe' it's a relevant point. A. Mail servers don't care about init systems. Quite the reverse. B. systemd's ain't systemd's (e.g. what constitutes systemd varies according to release and distro). (i.e. ~/.bashrc from debian isn't identical to upstreams). Are you kidding me? No. Mail servers generally start up automatically as system services, and need to get restarted if they die. How does that not involve the init system? Please read again. I never said mail servers do not involve the init system - I said mail servers don't care about the init system. They simply need to be initiated, and, depending on the admins desires, monitored - typically by a daemon. Whether started by /etc/rc.local, cron/acron, or *any* init system - mail servers don't care. I still don't think I'm seeing your point. Agreed. As demonstrated in the next two paragraphs. Mail servers, and servers in general need to be initialized, usually rely on the o/s init system, and generally come packaged with a collection of init and utility scripts. To date, every single major server we rely on, for a relatively standard collection of web, mail, list, and database servers comes stock with ONLY sysvinit scripts. Are you saying those apps can't be managed other than by sysvinit? (I hope not). To me, that's caring about the init system. Can you elaborate on what you mean by don't care? Are you deliberately being obtuse? snipped To ensure I wasn't falling into the trap of confirmation bias - before checking upstream for init support I'd be asking myself if it was necessary (cart before horse?). e.g. Why *should* sendmail ship *a* systemd .session file? After all sendmail developers have to support a wide range of systems and apportion resources according to their definition of needs. 1. Compared to configuring sendmail correctly it's trivial to create one to suit the usecase. 2. Like sendmail itself there is no one-size-all session/timer configuration. 3. If the user installs from a distro repostitory they get a default .session file to match the distro. (If the distro is going to do the work why should upstream do it?) They ship sysvinit scripts, period. Which is my point. I suspect the logic you base the point upon is flawed. ./configure make; make test; make install Apropos of what??!! pretty much works for pretty much any major server application It pretty much works to *build* any package; test the build, and then (crudely) install it. - which includes installing init scripts from upstream that just work Pretty much i.e. sometimes. IMO it's too generic to apply a process that's designed to work in non-specific situations to *specific* situations - in this case, Debian. Well, for all of the servers I've installed, I've at various times installed from upstream source, on multiple distros, and BSD, and things just worked. The gnu autotools are pretty clever that way. packaging adds some convenience in handling dependencies and managing system configuration, usually at the expense of running well behind what comes from upstream (and checkinstall makes it pretty easy to integrate upstream source into package management) Agreed. But, huh?? You talk of a need for stability then choose bleeding edge corner cases. At various times, I've found the packaged versions of mission-critical software to lag way behind upstream - particularly in the case of the list management software we use, and at times, antispam and antivirus software. Also, some of the stuff we experiment and develop with (various NoSQL databases, and Erlang). Sometimes waiting for packaging to catch up just doesn't cut it (anti-spam stuff, for example - always looking at new tools there). I worry a lot more about stability in the sense of environment and regression testing. I really
Re: init scripts [was: If Not Systemd, then What?]
Le mardi, 18 novembre 2014, 22.10:22 Miles Fidelman a écrit : Didier 'OdyX' Raboud wrote: Let's take the inverse view: which of these use the upstream sysvinit scripts directly ? The answer, as demonstrated below, is: none. Out of curiosity, how are you comparing these to the init scripts that are generated by making the upstream source? I was not comparing, I was checking which debian/ folders (aka Debian packaging) would contain init scripts, which are then installed in the binary packages as /etc/init.d/package (see dh_installinit). At the very least, would not the appropriate references be (changelogs) (…) or a diff between the upstream source and the script in the Debian package The content of the debian/ directory in an unpacked Debian source package is exactly that (which is what sources.debian.net shows), hence my references. the in depth analysis would be how many additional changes had to be added to accommodate any incompatibilities between sysvinit scripts and systemd's handling of said scripts I'm ready to place a bet that more changes were made in these scripts by the introduction of insserv and mandatory LSB headers than by making sure they work fine when run by systemd. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1904407.p3R537Cgjt@gyllingar
Re: init scripts [was: If Not Systemd, then What?]
On 11/17/2014 01:13 AM, Andrei POPESCU wrote: On Du, 16 nov 14, 13:22:54, Marty wrote: On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Would you please be so kind to point out which bullet point contradicts which Policy section? Kind regards, Andrei Don't they all by definition? Did I miss something? I suspect the workaround in all cases is sysvinit-core, but the warning still applies to anyone who runs the default configuration. For the record, since you omitted my smiley, I don't assume these are not already well known, or that I am planning to file bug reports. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5469ea0c.3050...@ix.netcom.com
Re: init scripts [was: If Not Systemd, then What?]
On Lu, 17 nov 14, 07:29:00, Marty wrote: On 11/17/2014 01:13 AM, Andrei POPESCU wrote: On Du, 16 nov 14, 13:22:54, Marty wrote: On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Would you please be so kind to point out which bullet point contradicts which Policy section? Don't they all by definition? Did I miss something? Others have addressed those bullets one by one, explaining why they are not relevant to Debian. If you disagree you might want to reply to one of those posts with specific concerns. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: init scripts [was: If Not Systemd, then What?]
Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. So tell me again about all the great features that are in such demand, that systemd is a solution for? Where's the demand? Maybe upstream knows something that seems to elude systemd proponents? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546a52e4.4050...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. So tell me again about all the great features that are in such demand, that systemd is a solution for? Most of the features do not requires anything upstream. For example : - being able to autorestart when crashed. Done on the distribution side, and usually, that's a policy left to the admin, not upstream - limiting the service with cgroups. Again, dependent on the installation, so left to the admin. - limiting the access with namespaces. Again, depend on the setup, so left for the admin. - starting on demand, that can be achieved with either xinetd protocol ( ie, reading stdin, writing stdout instead of a socket ), so no need here. - clean environment, that's not a feature that requires any patch upstream - journald integration, again, most software do use syslog, so no special need to have something that work. There is a few feature that requires any upstream patches. 1) socket activation using the systemd way ( ie, not xinetd ) 2) using journald to have more metadata that regular syslog 3) notifcation protocol and automated restart Where's the demand? Maybe upstream knows something that seems to elude systemd proponents? Apache has support as a module in trunk : https://httpd.apache.org/docs/trunk/mod/mod_systemd.html There is support for journal too, see mod_journal. And also see https://github.com/apache/httpd/commit/9e6638622be042eb00af5234a48049f7b5487a15#diff-92a02cae0d4feb2dfea5d1532ba1b977 for support directly in apache. HAProxy do have some support for integration https://github.com/jvehent/haproxy/blob/master/src/haproxy-systemd-wrapper.c Php-fpm does too : http://thanatos.be/2014/04/12/php-fpm-ondemand.html Nodejs has a module for nodejs application: https://savanne.be/articles/deploying-node-js-with-systemd/ Docker has support for it in various place ( socket activation, support in libcontainer ), and I could surely find lots of core stuff and newer code that do have native support. Dovecot have support for it, there is a service file : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/dovecot.service.in There is support for it : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/src/master/service-listen.c There is the upstream of mdadm who even wrote 2 articles on how to do it for nfs : http://lwn.net/Articles/584175/ http://lwn.net/Articles/584176/ Older software are just integrated with xinetd do not need anything. So for example, openssh already support socket activation like it does for xinetd. Had you done your homework and spent 5 minutes double checking your affirmation, you would surely have found the same links as me. just search for HAVE_SYSTEMD on github, bitbucket, etc. And to show there is demand, you can even look on modern configuration tools and you can see they all support to configure systemd : To give the 4 most spoken of at the moment : - ansible https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L396 - chef http://www.rubydoc.info/github/opscode/chef/Chef/Provider/Service/Systemd - puppet https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb - saltstack
Re: init scripts [was: If Not Systemd, then What?]
Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. False, how? I went through the release notes, install instructions, support wikis, source trees, and did some googling for good measure, and all that I found re. systemd scripts for pretty much the most popular server-side programs were a few emails in the Arch users list about how to get these things working w/ systemd. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546a8617.8070...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. False, how? the whole part that you erased showed there is a few upstreams that care about integration with systemd at the source code level. Ie, using features of systemd ( journald, socket activation ), rather than just providing a .service file. I went through the release notes, install instructions, support wikis, source trees, and did some googling for good measure, and all that I found re. systemd scripts for pretty much the most popular server-side programs were a few emails in the Arch users list about how to get these things working w/ systemd. Now, if you really want to see how much do ship a unit file, i suggest using proper tools, like : http://code.openhub.net/ Look for ExecStart= Now, the problem is that the search engine do give around 16 millions of matches, because it also include the result of various distribution, and I guess duplicate and fork, so you would surely have to filter. But looking at the 200 seconds first results, this doesn't seems to be full of completely wrong results. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141118001418.ga16...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: Ludovic Meyer wrote: On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. Interesting, since I posted this, a bunch of people have jumped on my comment that relying on packagers and systemd to support sysvinit scripts seems increasingly risky, but... Not a single person has commented on the observation that upstream developers, at least of core server applications, are thoroughly ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify see, it try to force its way by forcing people to integrate with systemd. Either way, that's gonna be used as a way to criticize. False, how? the whole part that you erased showed there is a few upstreams that care about integration with systemd at the source code level. Ie, using features of systemd ( journald, socket activation ), rather than just providing a .service file. No... my point is that NONE of the major upstream projects that I use on our servers, bother to produce systemd service files, but all of them produce sysvinit files. And I'll note that those are precisely some of the most used, most mature packages, that you'll find on practically every production server in the world (well, ok, I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). What do they know? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546aa6c8.8030...@meetinghouse.net
Re: init scripts [was: If Not Systemd, then What?]
On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Did you try Google? https://www.google.com/search?q=systemd+%2B%22sendmail.service%22ie=utf-8oe=utf-8aq=tchannel=sb What do they know? Miles Fidelman e.g. sendmail.service:- [Unit] Description=Sendmail Mail Transport Agent After=syslog.target network.target [Service] Environment=QUEUE=1h EnvironmentFile=/etc/sysconfig/sendmail Type=forking ExecStart=/usr/sbin/sendmail -bd -q $QUEUE $SENDMAIL_OPTARG [Install] WantedBy=multi-user.target Useful Refs:- https://wiki.archlinux.org/index.php/sendmail#Start_on_boot https://wiki.archlinux.org/index.php/Systemd/Timers http://0pointer.de/blog/projects/systemd-for-admins-2.html https://www.lisenet.com/2014/create-a-systemd-service-to-send-automatic-emails-when-arch-linux-restarts/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546ac051.5050...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
Ummm those are NOT systemd scripts shipped by the upstream sendmail developers. They ship sysvinit scripts, period. Which is my point. Major upstream application developers do not seem to be jumping on systemd. If anything, what I'm seeing are oh sht, I guess we should develop systemd service units at some point. Miles Fidelman Scott Ferguson wrote: On 18/11/14 12:54, Miles Fidelman wrote: snipped I left out sendmail, but I just checked, and guess what, no systemd service file in upstream). xy? Did you try Google? https://www.google.com/search?q=systemd+%2B%22sendmail.service%22ie=utf-8oe=utf-8aq=tchannel=sb What do they know? Miles Fidelman e.g. sendmail.service:- [Unit] Description=Sendmail Mail Transport Agent After=syslog.target network.target [Service] Environment=QUEUE=1h EnvironmentFile=/etc/sysconfig/sendmail Type=forking ExecStart=/usr/sbin/sendmail -bd -q $QUEUE $SENDMAIL_OPTARG [Install] WantedBy=multi-user.target Useful Refs:- https://wiki.archlinux.org/index.php/sendmail#Start_on_boot https://wiki.archlinux.org/index.php/Systemd/Timers http://0pointer.de/blog/projects/systemd-for-admins-2.html https://www.lisenet.com/2014/create-a-systemd-service-to-send-automatic-emails-when-arch-linux-restarts/ -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546ac5c7.9010...@meetinghouse.net
Re: If Not Systemd, then What?
Dne, 21. 10. 2014 04:06:23 je Marty napisal(a): On 10/20/2014 03:45 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Why not? I do not see sysvinit -- or any other legacy init system, for that matter -- as contradicting the following: Whichever one the user wants is the best. The users should decide, individually and collectively. The distro should be the testbed for new ideas, with users trying out and choosing solutions that work best for them. Debian should not make that choice for users. Upstreams should not make that choice for Debian. I'll second that. There has been much gnashing of teeth and talking about forks and pitchforks on this list. Instead of talking of catastrophic upheavals, such as systemd or forking, why not talk of refreshing/refurbishing/maintaining sysvinit and other existing systems? After all, we probably wouldn't be dealing with this hot systemd potato now had sysvinit been maintained intensely, actively, and with adequate manpower through all these years. Instead, it has been left more or less bitrotting on savannah (kudos to the few maintainers working on it despite the hostile stance of the Linux community), and this major upheaval is now the result. This is official Debian Policy but some people seem upset about it. Exactly. Instead of all the ire, sysvinit alternatives are in dire need of some love. Instead of reinventing the square wheel, much of this misguided energy could be directed toward patching up the old wheels which, after all, had been serving us -- and serving us well -- for the last 20 years. I hope this just a misunderstanding that gets cleared up after the dust settles and everyone starts talking again, instead of just yelling at each other. Ditto. I hope some defectors come back to Debian and realize that if they give Debian/upstream packages some work, many bitrotten packages may be reinstated into Debian main, without having to make a blend/fork or whatever. For the benefit of us all. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? We all should be able to propose our ideal solution with a reasonable expectation that if it's a good idea, and somebody does the work, it could be adopted and help other people, without being unduly hindered by a software bundle laying exclusive claim to PID 1. 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. We don't need another Windows, We don't need to know the way /home All we want is life beyond the Thunderdome -- Kinda regards, my beast washes Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix Oozer #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416138037.11318.0@compax
Re: If Not Systemd, then What?
On 2014-11-16 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. +1 for being reasonable and making sense It's an approach that would keep a lot of people happy and, more importantly (at least to me), it gives the user choice instead of taking it away. At least this way each user could choose the loosely-coupled components s/he wanted. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468ac54.6040...@eu.ipp.pt
Re: If Not Systemd, then What?
Hi, Nuno Magalhães nunomagalh...@eu.ipp.pt writes: On 2014-11-16 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. +1 for being reasonable and making sense It's an approach that would keep a lot of people happy and, more importantly (at least to me), it gives the user choice instead of taking it away. At least this way each user could choose the loosely-coupled components s/he wanted. Nobody is stopping anybody from improving sysvinit if they want to. So, have fun hacking on it. ;) Ansgar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761efp6ka@deep-thought.43-1.org
Re: If Not Systemd, then What?
On 11/16/2014 6:40 AM, Klistvud wrote: Dne, 21. 10. 2014 04:06:23 je Marty napisal(a): On 10/20/2014 03:45 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Why not? I do not see sysvinit -- or any other legacy init system, for that matter -- as contradicting the following: Whichever one the user wants is the best. The users should decide, individually and collectively. The distro should be the testbed for new ideas, with users trying out and choosing solutions that work best for them. Debian should not make that choice for users. Upstreams should not make that choice for Debian. I'll second that. There has been much gnashing of teeth and talking about forks and pitchforks on this list. Instead of talking of catastrophic upheavals, such as systemd or forking, why not talk of refreshing/refurbishing/maintaining sysvinit and other existing systems? After all, we probably wouldn't be dealing with this hot systemd potato now had sysvinit been maintained intensely, actively, and with adequate manpower through all these years. Instead, it has been left more or less bitrotting on savannah (kudos to the few maintainers working on it despite the hostile stance of the Linux community), and this major upheaval is now the result. The problem here is lack of time and/or skills. I would love to help, but I already have my plate full. Additionally, I've done device drivers and applications, but never dealt with init systems. There would be a big learning curve. And then there is the politics of being accepted by the DD community. Maybe some people don't think it's too bad - but I get enough politics in real life that I don't want to deal with it in a volunteer position. Most of the qualified people I know are pretty much in the same position. This is official Debian Policy but some people seem upset about it. Exactly. Instead of all the ire, sysvinit alternatives are in dire need of some love. Instead of reinventing the square wheel, much of this misguided energy could be directed toward patching up the old wheels which, after all, had been serving us -- and serving us well -- for the last 20 years. So why, instead of spending all this time on a new init system didn't developers already familiar with sysvinit work on it? Systemd wasn't one person alone. I hope this just a misunderstanding that gets cleared up after the dust settles and everyone starts talking again, instead of just yelling at each other. Ditto. I hope some defectors come back to Debian and realize that if they give Debian/upstream packages some work, many bitrotten packages may be reinstated into Debian main, without having to make a blend/fork or whatever. For the benefit of us all. I don't think this is going to happen. I know a lot of people who are looking at another distro, or even helping with a fork. This includes me. And when I find a distro I like, I won't be coming back. The others feel the same way. I don't change distros very often; it's a lot of work to test new systems before placing in production. And then there is the learning curve. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? We all should be able to propose our ideal solution with a reasonable expectation that if it's a good idea, and somebody does the work, it could be adopted and help other people, without being unduly hindered by a software bundle laying exclusive claim to PID 1. 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. That would be great, but it's not going to happen. The TC has already indicated systemd is going to be the default, and packages are already beginning to require systemd. I predict more and more packages will require systemd as time goes on. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. This would also be great. However, who's going to spend the time building these replacements? Maintaining/upgrading sysvinit is minor compared to this job, and even that couldn't be done. We
Re: If Not Systemd, then What?
Hi, Jerry Stuckle stuckleje...@gmail.com writes: The problem here is lack of time and/or skills. I would love to help, but I already have my plate full. Additionally, I've done device drivers and applications, but never dealt with init systems. There would be a big learning curve. And then there is the politics of being accepted by the DD community. Maybe some people don't think it's too bad - but I get enough politics in real life that I don't want to deal with it in a volunteer position. If you do not have time/skill/motivation to deal with it yourself, there is also the option of hiring someone to do the work for you. See [1] for a list of people offering services for Debian to start with. [1] https://www.debian.org/consultants/ So why, instead of spending all this time on a new init system didn't developers already familiar with sysvinit work on it? Systemd wasn't one person alone. Presumably nobody was interested enough to do so. 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. That would be great, but it's not going to happen. The TC has already indicated systemd is going to be the default, and packages are already beginning to require systemd. I predict more and more packages will require systemd as time goes on. It's not going to happen, because... This would also be great. However, who's going to spend the time building these replacements? Maintaining/upgrading sysvinit is minor compared to this job, and even that couldn't be done. ... nobody wants to work on it (at least not for free). Ansgar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjbrkvtm@deep-thought.43-1.org
Re: If Not Systemd, then What?
On 16/11/14 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. Given the profundity of disagreement about what init systems are supposed to provide, I believe that this would be a Sisyphean task. Positions people hold on the topic include, but: 1. The init daemon should fork exactly once; in the child it should exec another program, while the parent (PID 1) does nothing except reap zombies. 2. As (1), except that if the initially-forked child process exits, PID 1 should repeat the fork and exec-in-child procedure. 3. The init daemon should have a simple integrated service management mechanism akin to sysvinit's /etc/inittab. 4. The init daemon should have a complex integrated service management mechanism, perhaps akin to those of upstart or systemd. 5. The init program should do some basic setup, then exec a service manager daemon *within PID 1*. Moving on from *there*, let's take a look at two of the things you suggest, each of which are quite reasonable in isolation. On the one hand, making them into true, interchangeable drop-in replacements of each other suggests to me that you think they should all have exactly the same set of interfaces and functionality. I don't agree with this position, but it's reasonable, though it's rather stifling (since now you can't add new functionality unless you can persuade all the other init maintainers to add it). On the other, each of them accomplishing at least the common subset of tasks an init system is supposed to provide suggests to me that you think it would be all right for some of them to have extra interfaces and functionality - but as soon as you allow extra interfaces and functionality, you no longer achieve the true, interchangeable drop-in replacements part. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468c4a7.5000...@zen.co.uk
init scripts [was: If Not Systemd, then What?]
Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468d5d1.4010...@meetinghouse.net
Re: If Not Systemd, then What?
Le Sun, 16 Nov 2014 13:53:24 +, Nuno Magalhães nunomagalh...@eu.ipp.pt a écrit : On 2014-11-16 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. +1 for being reasonable and making sense It's an approach that would keep a lot of people happy and, more importantly (at least to me), it gives the user choice instead of taking it away. At least this way each user could choose the loosely-coupled components s/he wanted. Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common standard that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). 2) Again that's exactly what systemd and upstart are doing, they have added extra features to PID1 like socket activation, process tracking or the fact that the daemons are started in a clean environment. And then to that, the systemd project (outside of PID1) has consolidated services (some of them dead upstream for _years_) under the same umbrella project. All of this without preventing the already existing implementations to be used. journald is _not_ preventing a syslog daemon to be used, the .timer unit files are _not_ preventing cron to be used and so on... But then you cannot blame the systemd project for 3rd party software taking advantages of these new functionalities if they think they fit their usecases. Laurent Bigonville -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116183351.3bd37...@fornost.bigon.be
Re: init scripts [was: If Not Systemd, then What?]
On Sun, Nov 16, 2014 at 11:50:25AM -0500, Miles Fidelman wrote: Given all the talk about not being able to influence upstream, it occurred to me to actually take a look at which of the major applications I rely on actually come with native systemd service scripts. I just went through the documentation, and in some cases, the source trees, for the following: bind9 apache sympa mailman mysql mariadb postgres postfix spamassassin amavisd clamav Most come with sysvinit scripts, several come with their own startup scripts (e.g., apachectl) that get dropped into rc.local. Not a one comes with a native systemd service file (even though, when you search through the mysql documentation it tells you that oracle linux has switched to systemd). So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared In practice, what would be broken ? Taking the list : - the fact that direct invocation is deprecated is a good thing, since this was previously broken. Starting stuff directly from the script mean that your environment leak in the daemon environment, which is a source of fun bug ( like sorting in php depending on the locale, and the locale not being always C, something that US people tend to forget ). It also help when you are using SELinux or another MAC, since the domain of the admin do not leak to the daemon, and things are clearly separated. - LSB information have to be correct anyway in Debian, or you would have bug anyway. LSB is also old enough to have no excuse to have transitionned, and is a standard. See https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot - timeout that would block boot are a bug, since this mean that your server could not boot if the timeout was undefinite. Again, i can't see why a correct execution would depend on not booting due to 1 system blocking everything, especially in the list of service you gave. - again, clean env just requires you to make sure that what is needed to be set is present. That's a question of correctness, and I think no one will advocate that being correct is a regression. - none of the script you gave seems interactive, and that's kinda already causing issue anyway ( for example, when automating restart accross a cluster with a tool like ansible, or when you are not near the keyboard when the server reboot and the script start at boot ). - additional verbs are supported on service binary, not on the script level, at least on Centos. If that's misisng, I am sure that can be done on Debian as well, if that's not done already. - stopping non running service seems again a weird things to do. I do not see anything that would depend on this behavior to be correct, as that's more we stop something that said to be stopped, but wasn't. None of the service you gave rely on this behavior, and I would be interested into getting precise details on what service would need this. - run levels support is limited, but it still exist. Again, explain what is your usecase, so we can see if that's broken or not ( because you do not test and do not give details ). Migration to target is likely not hard ( just different directory to make symlinks ), so i do not see why you would fear it. - chkconfig is already returning misleading information, due to a complete lack of standard on the return code of the initscript, despites LSB trying to clean that mess. Again, it will just be broken in a different way. At least, mediating the interaction with systemd make script more reliable once they use it, because there is no local variation in return code. - next one is again on runlevels. Please tell what local variation you have, then people can judge if that's a reason to fear or not. Otherwise, that's just spreading FUD since most people do not have complex runlevels systems, as running/not running is enough for most cases I did see. - early boot scripts would be the biggest challenge for your setup I guess. While you didn't gave any details , you seems to use some customs script instead of Debian, so you would have to change that integration. Yet, without giving the usecase, no one know and maybe I am wrong. If your setup cannot be handled by Debian regular script, maybe the Debian developpers would be interested to fix that use case. And last: - no real time privs. No service you gave use that, but then there is workaround. At most 1 line to add and a reboot. That's not what I would qualify as a cause of fear. Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. What is the risk ? before, you were on your own, now, you would be on your own. Differences, before, you had to write a
Re: If Not Systemd, then What?
On 16/11/14 17:33, Laurent Bigonville wrote: Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common standard that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). Well. They're (mostly) a drop-in replacement for sysvrc and its supporting tools. They're certainly not a *drop-in* replacement for *sysvinit*, because they don't support all of sysvinit's interfaces; specifically, they don't support /etc/inittab. Luckily (for some values of lucky), /etc/inittab was such a terrible interface (it's unpleasantly reminiscent of Angband's monster, item, etc. databases) that it seems even most people who prefer sysvinit to systemd or upstart were using a factory-default /etc/inittab. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468e830.30...@zen.co.uk
Re: init scripts [was: If Not Systemd, then What?]
On Du, 16 nov 14, 11:50:25, Miles Fidelman wrote: So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared I don't see any item that would matter on a Debian system, care to elaborate? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: If Not Systemd, then What?
On 11/16/2014 at 12:33 PM, Laurent Bigonville wrote: Le Sun, 16 Nov 2014 13:53:24 +, Nuno Magalhães nunomagalh...@eu.ipp.pt a écrit : On 2014-11-16 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. 2. Complementing them with existing or new tools (again, drop-in interchangeable replacements of each other) which build on them and provide the next layer. For example, the kernel autofs facility provides very nice automounting and could be deployed to the majority of desktop installs (instead of being just an optional package, as it is now), thus making the various automount daemons of the various desktop environments/file managers virtually superfluous. As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. +1 for being reasonable and making sense It's an approach that would keep a lot of people happy and, more importantly (at least to me), it gives the user choice instead of taking it away. At least this way each user could choose the loosely-coupled components s/he wanted. Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common standard that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). Not a full drop-in replacement; with systemd replacing sysvinit, unless you change configuration settings elsewhere, you will see behavior changes that aren't unambiguous 100% improvements. A drop-in replacement must, at minimum, Just Work in all of the same environments and with all of the same configurations where the thing being replaced already worked. systemd mostly does that, but not entirely - fstab-related boot failures (lack of noauto / nofail leading to a boot failure with systemd, where with sysvinit it would not), issues with booting on/from/to encrypted filesystems, et cetera. A drop-in replacement should, theoretically and ideally, work *exactly the same way* as the thing being replaced, when presented the exact same configuration, except possibly when it can work in a way which is obviously and incontrovertibly better. There are cases in which systemd does not do that - consider the quiet kernel command-line option, for example. Now, there may be good reason to have systemd prefer to not behave in the same way as sysvinit in these regards, and there's certainly nothing saying that it can't or shouldn't do so in its own configuration. But to the extent that it does not do so *by default*, in a configuration inherited from a sysvinit machine, it is not a full drop-in replacement for sysvinit. But then you cannot blame the systemd project for 3rd party software taking advantages of these new functionalities if they think they fit their usecases. I can, however, blame the systemd project for having implemented these new functionalities in a way which only works in the presence of functionality which is only provided by their own init system. But that's a mostly separate argument, which I don't really care to rehash at present. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: If Not Systemd, then What?
On Sun, 16 Nov 2014, Klistvud wrote: Dne, 21. 10. 2014 04:06:23 je Marty napisal(a): On 10/20/2014 03:45 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Why not? I do not see sysvinit -- or any other legacy init system, for that matter -- as contradicting the following: Systemd is intended as a modern replacement for sysvinit. I wanted to know if not systemd, what init others would choose to replace sysvinit. Simple question. Difficult to answer. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116102221.3...@debian7.boseck208.net
Re: init scripts [was: If Not Systemd, then What?]
On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. We have been exhorted to report bugs instead of complain on the mailing lists, nice of Freedesktop people to list them for us. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468eb7e.3050...@ix.netcom.com
Re: init scripts [was: If Not Systemd, then What?]
Le Sun, 16 Nov 2014 11:50:25 -0500, Miles Fidelman mfidel...@meetinghouse.net a écrit : [...] So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Do you have any bug reports at hand that show that there are issues with the initscripts that are shipped in the debian archive? Or are you spreading FUD again? Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. That's indeed true, but usually 3rd party vendors of (commercial) software are certifying their software for a limited set of distributions/version anyway. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116193635.242fc...@fornost.bigon.be
Re: If Not Systemd, then What?
Le Sun, 16 Nov 2014 18:08:48 +, Martin Read zen75...@zen.co.uk a écrit : On 16/11/14 17:33, Laurent Bigonville wrote: Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common standard that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). Well. They're (mostly) a drop-in replacement for sysvrc and its supporting tools. They're certainly not a *drop-in* replacement for *sysvinit*, because they don't support all of sysvinit's interfaces; specifically, they don't support /etc/inittab. Luckily (for some values of lucky), /etc/inittab was such a terrible interface (it's unpleasantly reminiscent of Angband's monster, item, etc. databases) that it seems even most people who prefer sysvinit to systemd or upstart were using a factory-default /etc/inittab. Note that there were plans to either abort systemd-sysv installation or at least display a big fat warning in case /etc/inittab was modified on the machine. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116194032.38ec5...@fornost.bigon.be
Re: If Not Systemd, then What?
Le 16/11/2014 19:22, Patrick Bartek a écrit : On Sun, 16 Nov 2014, Klistvud wrote: Dne, 21. 10. 2014 04:06:23 je Marty napisal(a): On 10/20/2014 03:45 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Why not? I do not see sysvinit -- or any other legacy init system, for that matter -- as contradicting the following: Systemd is intended as a modern replacement for sysvinit. I wanted to know if not systemd, what init others would choose to replace sysvinit. Simple question. Difficult to answer. B Please define modern. And no, new is not equivalent of better. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468efc7.4020...@rail.eu.org
Re: If Not Systemd, then What?
On Sun, Nov 16, 2014 at 06:08:48PM +, Martin Read wrote: On 16/11/14 17:33, Laurent Bigonville wrote: Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common standard that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). Well. They're (mostly) a drop-in replacement for sysvrc and its supporting tools. They're certainly not a *drop-in* replacement for *sysvinit*, because they don't support all of sysvinit's interfaces; specifically, they don't support /etc/inittab. Luckily (for some values of lucky), /etc/inittab was such a terrible interface (it's unpleasantly reminiscent of Angband's monster, item, etc. databases) that it seems even most people who prefer sysvinit to systemd or upstart were using a factory-default /etc/inittab. Writing a generator would be trivial. http://www.freedesktop.org/wiki/Software/systemd/Generators/ No one seemed to care enough for writing one however, but reading the file and generating a unit file ( with the automated restart behavior ) is easy to do. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116192021.ge25...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
Andrei POPESCU wrote: On Du, 16 nov 14, 11:50:25, Miles Fidelman wrote: So... with systemd, one has to: - rely on packagers to generate systemd service files, and/or, - rely on systemd's support for sysvinit scripts, which In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared I don't see any item that would matter on a Debian system, care to elaborate? It's very simple. I have a bunch of stuff running on my system that I compiled from upstream code, including init scripts that work just fine. Now I have to worry that some of those scripts are incompatible with systemd. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468fdda.8010...@meetinghouse.net
Re: If Not Systemd, then What?
On 11/16/2014 6:40 AM, Klistvud klist...@gmail.com wrote: As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. Is eudev in the debian sources? Or do you mean another fork? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546903b1.7060...@libertytrek.org
Re: If Not Systemd, then What?
On 11/16/2014 10:29 AM, Ansgar Burchardt wrote: Hi, Jerry Stuckle stuckleje...@gmail.com writes: The problem here is lack of time and/or skills. I would love to help, but I already have my plate full. Additionally, I've done device drivers and applications, but never dealt with init systems. There would be a big learning curve. And then there is the politics of being accepted by the DD community. Maybe some people don't think it's too bad - but I get enough politics in real life that I don't want to deal with it in a volunteer position. If you do not have time/skill/motivation to deal with it yourself, there is also the option of hiring someone to do the work for you. If I had the money to hire someone, I wouldn't need to work so hard. See [1] for a list of people offering services for Debian to start with. [1] https://www.debian.org/consultants/ So why, instead of spending all this time on a new init system didn't developers already familiar with sysvinit work on it? Systemd wasn't one person alone. Presumably nobody was interested enough to do so. Maybe someone SHOULD have had enough interest. 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. That would be great, but it's not going to happen. The TC has already indicated systemd is going to be the default, and packages are already beginning to require systemd. I predict more and more packages will require systemd as time goes on. It's not going to happen, because... For the reason I stated. This would also be great. However, who's going to spend the time building these replacements? Maintaining/upgrading sysvinit is minor compared to this job, and even that couldn't be done. ... nobody wants to work on it (at least not for free). Ansgar So why don't YOU work on it? Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54690ca9.1040...@gmail.com
Re: If Not Systemd, then What?
Dne, 16. 11. 2014 21:06:09 je Tanstaafl napisal(a): On 11/16/2014 6:40 AM, Klistvud klist...@gmail.com wrote: As a further example, the former udev (prior to being merged into systemd) has already been forked and could/will serve us well for years to come. And so on. Is eudev in the debian sources? Or do you mean another fork? I meant eudev, I am not aware of any other forks. -- Kinda regards, my beast washes Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix Oozer #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416178461.11318.1@compax
Re: If Not Systemd, then What?
Hi, Jerry Stuckle stuckleje...@gmail.com writes: On 11/16/2014 10:29 AM, Ansgar Burchardt wrote: Jerry Stuckle stuckleje...@gmail.com writes: So why, instead of spending all this time on a new init system didn't developers already familiar with sysvinit work on it? Systemd wasn't one person alone. Presumably nobody was interested enough to do so. Maybe someone SHOULD have had enough interest. Which doesn't change the fact that nobody was... I can write long lists of what SHOULD be done in my opinion, but that won't make any of it happen. 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. [...] It's not going to happen, because... ... nobody wants to work on it (at least not for free). So why don't YOU work on it? Oh, that's easy to answer. There is no motivation for me to do so: I don't care about support for sysvinit. I care even less thanks to the behavior of some people who write angry mails (no, really: why should I waste my free time to do something for them?). Ansgar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjbq7laq@deep-thought.43-1.org
Re: init scripts [was: If Not Systemd, then What?]
On Du, 16 nov 14, 13:22:54, Marty wrote: On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Would you please be so kind to point out which bullet point contradicts which Policy section? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: If Not Systemd, then What?
On Saturday 08 November 2014 15:31:02 Jonathan de Boyne Pollard wrote: Andrei Popescu: Upstart was the only realcontender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. Tanstaafl: And why was OPenRC not acontender? Jonathan de Boyne Pollard: Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. Andrei Popescu: Quote from above, with added emphasis: Upstart was the only *real* contender to systemd *at the time* of the evaluation for the Technical Committee, [...] Yes, that's exactly where you were dismissive. It ill behove you, and you were wrong. No, the final vote was between upstart and systemd. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201411131553.06894.lisi.re...@gmail.com
Re: If Not Systemd, then What?
On 11/13/2014 10:53 AM, Lisi Reisz lisi.re...@gmail.com wrote: On Saturday 08 November 2014 15:31:02 Jonathan de Boyne Pollard wrote: Andrei Popescu: Quote from above, with added emphasis: Upstart was the only *real* contender to systemd *at the time* of the evaluation for the Technical Committee, [...] Yes, that's exactly where you were dismissive. It ill behove you, and you were wrong. No, the final vote was between upstart and systemd. Yes, apparently because someone actively sabotaged any possibility of OpenRC being considered by giving improper bad information on how to use it... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464dc49.20...@libertytrek.org
Re: If Not Systemd, then What?
On Jo, 13 nov 14, 11:28:57, Tanstaafl wrote: Yes, apparently because someone actively sabotaged any possibility of OpenRC being considered by giving improper bad information on how to use it... OpenRC was represented by its Maintainer in the init debate (Thomas Goirand). Are you saying he intentionally sabotaged it to not be considered? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: If Not Systemd, then What?
On 11/13/2014 3:42 PM, Andrei POPESCU andreimpope...@gmail.com wrote: On Jo, 13 nov 14, 11:28:57, Tanstaafl wrote: Yes, apparently because someone actively sabotaged any possibility of OpenRC being considered by giving improper bad information on how to use it... OpenRC was represented by its Maintainer in the init debate (Thomas Goirand). Are you saying he intentionally sabotaged it to not be considered? I'm not, but that seemed to be what someone else said - although when I asked for clarification, none was forthcoming: On 10/24/2014 7:07 AM, Tanstaafl tansta...@libertytrek.org wrote: On 10/24/2014 4:49 AM, Jonathan de Boyne Pollard j.deboynepollard-newsgro...@ntlworld.com wrote: Tanstaafl: And why was OpenRC not a contender? Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. I actually do remember reading a fleeting mention of it somewhere in the vast sea of stuff I read when trying to catch up on this issue... Contrastingly, the people who were propounding OpenRC at the time provided a good example of how NOT to go about doing so. Their several mistakes are worth learning from. Not sure I understand what you are saying here... Are you saying that some of the people who suggested OpenRC actually provided BAD examples - meaning, examples that were destined to result in problems - of how to use it in Debian? If so, maybe that was on purpose, to decrease the chances of OpenRC being a real contender? The fact is, OpenRC has been the default init system on gentoo since I don't know when, and I have *never* had an init problem on any of my gentoo systems - although I admittedly never use unstable/testing for system-critical packages either... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54652207.7050...@libertytrek.org
Re: If Not Systemd, then What?
Jonathan de Boyne Pollard: Contrastingly, the people who were propounding OpenRC at the time provided a good example of how NOT to go about doing so. Their several mistakes are worth learning from. Tanstaafl: Not sure I understand what you are saying here... Are you saying that some of the people who suggested OpenRC actually provided BAD examples - meaning, examples that were destined to result in problems - of how to use it in Debian? No; it was more an entirely bungled presentation. For example: They reacted badly and disproportionately to being told about simple problems, like the fact that what they had presented didn't have any doco at all. That's a mistake worth learning from. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545e370d.8040...@ntlworld.com
Re: If Not Systemd, then What?
Andrei Popescu: Upstart was the only realcontender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. Tanstaafl: And why was OPenRC not acontender? Jonathan de Boyne Pollard: Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. Andrei Popescu: Quote from above, with added emphasis: Upstart was the only *real* contender to systemd *at the time* of the evaluation for the Technical Committee, [...] Yes, that's exactly where you were dismissive. It ill behove you, and you were wrong. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545e3736.4010...@ntlworld.com
Re: Re: If Not Systemd, then What?
On Vi, 24 oct 14, 09:49:46, Jonathan de Boyne Pollard wrote: Andrei Popescu: Upstart was the only real contender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. Tanstaafl: And why was OPenRC not a contender? Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Quote from above, with added emphasis: Upstart was the only *real* contender to systemd *at the time* of the evaluation for the Technical Committee, [...] Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. In my opinion that was more a formality, it was quite clear that OpenRC would be beaten by both systemd and upstart. It did reach quorum though (i.e. better than Further Discussion), which SysV did not. https://lists.debian.org/debian-ctte/2014/02/msg00402.html Contrastingly, the people who were propounding OpenRC at the time provided a good example of how NOT to go about doing so. Their several mistakes are worth learning from. Fully agreed. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Re: If Not Systemd, then What?
Andrei Popescu: Upstart was the only real contender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. Tanstaafl: And why was OPenRC not a contender? Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. Contrastingly, the people who were propounding OpenRC at the time provided a good example of how NOT to go about doing so. Their several mistakes are worth learning from. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a12aa.10...@ntlworld.com
Re: If Not Systemd, then What?
On 10/23/2014 4:10 PM, koanhead koanh...@riseup.net wrote: I propose OpenRC, having recently tried it. So far I'm liking how it works, and it solves most of the problems I had with sysvinit. It's not a replacement for PID1, and is supposed to be compatible with arbitrary PID1 programs (sysvinit, sytemd, runit, etc.) I expect to test it with other PID1 programs at some point, but for now I'm still learning it. There's also runit, which I haven't tried yet but about which I've heard good things; and daemontools, which has already been talked up on this list. All these are already in Debian's repositories. Seconded... OpenRC has also been the default init system for gentoo for as long as I can remember knowing what init system I was running on my gentoo server (I had help setting up the first one ten years ago, so I don't know if it was the default then)... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a2f86.2070...@libertytrek.org
Re: If Not Systemd, then What?
On 10/24/2014 4:49 AM, Jonathan de Boyne Pollard j.deboynepollard-newsgro...@ntlworld.com wrote: Tanstaafl: And why was OPenRC not a contender? Your question takes a falsehood as its premise. It actually was, contrary to what M. Popescu dismissively stated. Several members of the technical committee took it and tried to use it themselves, just as they did the other systems; and it was included on the formal ballots and in the votes. I actually do remember reading a fleeting mention of it somewhere in the vast sea of stuff I read when trying to catch up on this issue... Contrastingly, the people who were propounding OpenRC at the time provided a good example of how NOT to go about doing so. Their several mistakes are worth learning from. Not sure I understand what you are saying here... Are you saying that some of the people who suggested OpenRC actually provided BAD examples - meaning, examples that were destined to result in problems - of how to use it in Debian? If so, maybe that was on purpose, to decrease the chances of OpenRC being a real contender? The fact is, OpenRC has been the default init system on gentoo since I don't know when, and I have *never* had an init problem on any of my gentoo systems - although I admittedly never use unstable/testing for system-critical packages either... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a32ef.3090...@libertytrek.org
Re: If Not Systemd, then What?
On Wed, Oct 22, 2014 at 05:27:45AM -0400, Miles Fidelman wrote: Ok, let's start with: - it's the rare desktop that has a fiber channel interface snip It's a rare server, too. Nearly all of our physical servers are VM hosts, onto which we fit around 100 VMs. Physical servers are at best 5% of all our servers, and the traits of physical servers are therefore relatively scarce. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023064941.gc20...@chew.redmars.org
Re: If Not Systemd, then What?
On 10/20/2014 04:00 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? I propose OpenRC, having recently tried it. So far I'm liking how it works, and it solves most of the problems I had with sysvinit. It's not a replacement for PID1, and is supposed to be compatible with arbitrary PID1 programs (sysvinit, sytemd, runit, etc.) I expect to test it with other PID1 programs at some point, but for now I'm still learning it. There's also runit, which I haven't tried yet but about which I've heard good things; and daemontools, which has already been talked up on this list. All these are already in Debian's repositories. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2bnc3$vh0$1...@news.albasani.net
Re: If Not Systemd, then What?
On Thu, 23 Oct 2014, koanhead wrote: On 10/20/2014 04:00 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? I propose OpenRC, having recently tried it. So far I'm liking how it works, and it solves most of the problems I had with sysvinit. It's not a replacement for PID1, and is supposed to be compatible with arbitrary PID1 programs (sysvinit, sytemd, runit, etc.) I expect to test it with other PID1 programs at some point, but for now I'm still learning it. There's also runit, which I haven't tried yet but about which I've heard good things; and daemontools, which has already been talked up on this list. All these are already in Debian's repositories. I myself have been looking at runit for a just-for-fun try at replacing systemd in Jessie running in a VM. One of the reasons for considering runit is it purports to be a drop-in replacement for sysvinit, either in part or wholly. I've heard of OpenRC, but haven't really researched it much. I'll take a more lengthy look at it. Thanks for the reply. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023153145.26cb5...@debian7.boseck208.net
Re: If Not Systemd, then What?
On Tue, 21 Oct 2014 18:41:21 -0700 Patrick Bartek nemomm...@gmail.com wrote: On Mon, 20 Oct 2014, Steve Litt wrote: On Mon, 20 Oct 2014 12:45:11 -0700 Patrick Bartek nemomm...@gmail.com wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? * Nosh * Runit * Upstart * S6 * Probably more I don't know about. OpenRC, God, and another one -- I can't recall the name -- come to mind. Been studying them all. Runit as a partial or full drop-in replacement for sysvinit seems promising. And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged Nobody's arguing for sysvinit as a long term solution, for the exact reasons you post above. Those of us who appeared to favor sysvinit were saying let's wait until we have something good. We also pointed out the false choice of prematurely narrowing it to systemd, Upstart or sysvinit. This I realize, but for some something good is never ever good enough to replace the old, the familiar, the comfortable. I spoze. But there's little good about systemd, and a whole lot of bad. Like I listed near the beginning of this thread, there are plenty of something goods that I'd gladly replace sysvinit with. But systemd is a catastrophe if you want a computer controlled by you and not Red Hat. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022020458.55d17...@mydesq2.domain.cxm
Re: If Not Systemd, then What?
On Wed, 22 Oct 2014 13:04:26 +1100 Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote: P.S. I have been told that one major distro does (or is attempting to do) just that - separate into a 'server' and a 'desktop' distribution. What, like Windows? I think that really is the point that is being made, that Windows has always made the distinction, with the server OS being very expensive and requiring access licences for machines or people making use of it. Microsoft server software, such as DNS and the full web server is only available on the server OS, with a few cut-down versions on workstations. With Linux, it is (so far) only usage which determines the category, e.g. with few exceptions, servers are continuously powered, don't have monitors, many don't have X, etc. There is no software which is *only* installable on a server, though there is some which isn't really practical on an intermittently-powered machine. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022090545.0702a...@jresid.jretrading.com
Re: If Not Systemd, then What?
Scott Ferguson wrote: On 21/10/14 15:10, Miles Fidelman wrote: Scott Ferguson wrote: Good question Patrick - top posted as I'm referring to the Subject. On 21/10/14 06:45, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? One of the difficulties is that there is no clear distinction between a desktop and a server - just degrees. Um, yes, there is. Typically different hardware (headless for starters), storage area networks, clusters, high availability, as well as different role, and so forth. Miles With respect, you're just repeating your claim that there is a clear distinction between server and desktop - not proving it, which doesn't advance the discussion. Ok, let's start with: - it's the rare desktop that has a fiber channel interface - it's the rare desktop that has an interface for dual-ported disk drives - it's the rare desktop configuration that splits processing and storage (e.g., blade servers + storage servers) - in servers, large RAID arrays are common, desktops might have a pair of mirrored disks, never seen anybody set up a desktop for RAID5,6,10 - these days, servers are generally run in clusters, with cluster file systems, and environments like openstack on top of them - when it comes to performance, desktops generally emphasize graphics performance (e.g., for gaming, video editing, and such); servers are designed more for how many virtual machines they can run - high-availability clustering is a big data center concern, not a desktop concern (anybody run DRBD, or Corosync on a dekstop?) - when it comes to virtualization, on desktops its mostly for running programs in other environments; for servers its mostly about supporting lots of independent users and services - when's the last time you saw a desktop or laptop with an IPMI BMC (or for that matter, had a BMC infected by a virus - not pretty) (note: if you don't know what BMC stands for, then go away and learn something about serious data centers, before weighing in on the distinctions between desktops and servers) - scalability, optimization for transaction processing, high-volume mail processing, etc., etc., etc. - not issues that one worries about on the desktop Samba is a server, as is NFS, and apache. If you run them on a desktop is it still *just* a desktop? Can you not run a desktop on server hardware? Generally not - except remotely - given that most servers are headless and don't have graphics boards. Yeah, one can X- into a server, if you install the software. Many (most?) don't - CLI and various management tools is plenty good for server admin (along with lots of bash scripts - one of the reasons that a lot of sysadmins don't like systemd). Can you not run a server on desktop hardware? Not if you're supporting a serious load - unless you're clustering lots of machines (but once you cluster a few hundred motherboards, you're talking a desktop machine, you're talking a cluster). I don't believe you've thought this through... : I'll leave pulseaudio out, just to make things simpler (and acknowledge that simple is a synonym for dumb). I don't believe you have any knowledge whatsoever about data centers or real servers - and are talking through your hat. That you even mention audio in the same conversation as servers says you're in a different universe. Kind regards P.S. I have been told that one major distro does (or is attempting to do) just that - separate into a 'server' and a 'desktop' distribution. Let's see: - IBM doesn't do desktops - Windows has very separate desktop and server-side editions - MacOS comes in separate flavors - BSDs are primarily server oriented - Until recently, most Linux distros were server oriented - particularly Debian, I might add -- Linux on the desktop is a new phenomenon - Solaris is mostly a server side o/s (workstations are small servers, not large desktops) - In the Linux world Ubuntu comes in desktop, server, and cloud varieties - RHEL is almost entirely server oriented (can you say Enterprise, Gluster, JBoss, ?) - SUSE has desktop, server, and cloud varieties Again - if you didn't know that, then you're talking out of ignorance. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https
Re: If Not Systemd, then What?
Hi. On Wed, Oct 22, 2014 at 05:27:45AM -0400, Miles Fidelman wrote: Scott Ferguson wrote: - when's the last time you saw a desktop or laptop with an IPMI BMC (or for that matter, had a BMC infected by a virus - not pretty) (note: if you don't know what BMC stands for, then go away and learn something about serious data centers, before weighing in on the distinctions between desktops and servers) A minor nitpick - there's Intel AMT which specifically targets desktops to provide capabilities similar to BMC. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022095110.GA23107@x101h
Re: If Not Systemd, then What?
On Wednesday, October 22, 2014 3:20:05 PM UTC+5:30, Miles Fidelman wrote: Scott Ferguson wrote: On 21/10/14 15:10, Miles Fidelman wrote: Scott Ferguson wrote: Good question Patrick - top posted as I'm referring to the Subject. On 21/10/14 06:45, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? One of the difficulties is that there is no clear distinction between a desktop and a server - just degrees. Um, yes, there is. Typically different hardware (headless for starters), storage area networks, clusters, high availability, as well as different role, and so forth. Miles With respect, you're just repeating your claim that there is a clear distinction between server and desktop - not proving it, which doesn't advance the discussion. Ok, let's start with: - it's the rare desktop that has a fiber channel interface - it's the rare desktop that has an interface for dual-ported disk drives - it's the rare desktop configuration that splits processing and storage (e.g., blade servers + storage servers) - in servers, large RAID arrays are common, desktops might have a pair of mirrored disks, never seen anybody set up a desktop for RAID5,6,10 - these days, servers are generally run in clusters, with cluster file systems, and environments like openstack on top of them - when it comes to performance, desktops generally emphasize graphics performance (e.g., for gaming, video editing, and such); servers are designed more for how many virtual machines they can run - high-availability clustering is a big data center concern, not a desktop concern (anybody run DRBD, or Corosync on a dekstop?) - when it comes to virtualization, on desktops its mostly for running programs in other environments; for servers its mostly about supporting lots of independent users and services - when's the last time you saw a desktop or laptop with an IPMI BMC (or for that matter, had a BMC infected by a virus - not pretty) (note: if you don't know what BMC stands for, then go away and learn something about serious data centers, before weighing in on the distinctions between desktops and servers) - scalability, optimization for transaction processing, high-volume mail processing, etc., etc., etc. - not issues that one worries about on the desktop Samba is a server, as is NFS, and apache. If you run them on a desktop is it still *just* a desktop? Can you not run a desktop on server hardware? Generally not - except remotely - given that most servers are headless and don't have graphics boards. Yeah, one can X- into a server, if you install the software. Many (most?) don't - CLI and various management tools is plenty good for server admin (along with lots of bash scripts - one of the reasons that a lot of sysadmins don't like systemd). Can you not run a server on desktop hardware? Not if you're supporting a serious load - unless you're clustering lots of machines (but once you cluster a few hundred motherboards, you're talking a desktop machine, you're talking a cluster). I don't believe you've thought this through... : I'll leave pulseaudio out, just to make things simpler (and acknowledge that simple is a synonym for dumb). I don't believe you have any knowledge whatsoever about data centers or real servers - and are talking through your hat. That you even mention audio in the same conversation as servers says you're in a different universe. Are you guys just having fun talking past each other? Or seriously dont know the two meanings of 'server'? First two here: http://whatis.techtarget.com/definition/server -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b38ccdfc-09a1-4b17-865e-d6f3bdf85...@googlegroups.com
Re: If Not Systemd, then What?
On 21/10/14 21:08, Miles Fidelman wrote: Steve Litt wrote: On Tue, 21 Oct 2014 10:18:49 +0200 Raffaele Morelli raffaele.more...@gmail.com wrote: Using systemd since 2014-08-09 with no issues. Good for you. Let's see if you have no issues 2016-08-09, if Red Hat wins its war against Linux. Not quite sure I'd go that far - personally, this seems more like Poettering on a mission to reshape Linux in his image, and is taking Red Hat along for the ride. But I could be wrong. I hope you're not, because the only other explanations I can think of would be far more frightening. In one of the links Steve provided (http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html), Mr. Pid Eins (= Pid One) tries to talk *all* Linux distributions into adopting his reinvention how distributions work [sic] as part of the systemd project. Who would be interested in such a unification of all Linux distributions? Red Hat? Under normal circumstances, no corporation could possibly be interested in seeing its excellent ideas and its unique selling point being copied by all competitors. A corporation would want its competitors to adopt *bad* ideas - and then step back and watch the competitors dismantle themselves. And if we start thinking about who else would certainly benefit from such a homogenous landscape of highly opaque systems as that proposed by Mr. Pid Eins, we'll quickly enter the realm of what user or developer John Doe would call conspiracy theories. p. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m288an$c20$1...@ger.gmane.org
Re: If Not Systemd, then What?
On 10/21/2014 4:21 PM, Andrei POPESCU andreimpope...@gmail.com wrote: Upstart was the only real contender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. And why was OPenRC not a contender? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447a692.1060...@libertytrek.org
Re: If Not Systemd, then What?
Peter Nieman wrote: On 21/10/14 21:08, Miles Fidelman wrote: Steve Litt wrote: On Tue, 21 Oct 2014 10:18:49 +0200 Raffaele Morelli raffaele.more...@gmail.com wrote: Using systemd since 2014-08-09 with no issues. Good for you. Let's see if you have no issues 2016-08-09, if Red Hat wins its war against Linux. Not quite sure I'd go that far - personally, this seems more like Poettering on a mission to reshape Linux in his image, and is taking Red Hat along for the ride. But I could be wrong. I hope you're not, because the only other explanations I can think of would be far more frightening. In one of the links Steve provided (http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html), Mr. Pid Eins (= Pid One) tries to talk *all* Linux distributions into adopting his reinvention how distributions work [sic] as part of the systemd project. Who would be interested in such a unification of all Linux distributions? Red Hat? Under normal circumstances, no corporation could possibly be interested in seeing its excellent ideas and its unique selling point being copied by all competitors. A corporation would want its competitors to adopt *bad* ideas - and then step back and watch the competitors dismantle themselves. And if we start thinking about who else would certainly benefit from such a homogenous landscape of highly opaque systems as that proposed by Mr. Pid Eins, we'll quickly enter the realm of what user or developer John Doe would call conspiracy theories. It occurs to me to wonder if anyone in the BSD or Illumos ecosystems might want to see Linux die (at least for server-side use). ;-) -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447b0a9.5050...@meetinghouse.net
Re: If Not Systemd, then What?
Martin Steigerwald wrote: Am Montag, 20. Oktober 2014, 19:49:43 schrieb Jimmy Johnson: So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? Just wondering. See above and unless you are a tester or developer you may want to roll-back to Squeeze. Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to work with sysvinit as well. Hi Martin, Something I did not know at the time you asked the question: Why Squeeze?. Is that Wheezy was used by Debian to test systemd and even though I did not know this at that time I did not feel comfortable using Wheezy as my main desktop and now knowing that Wheezy is capable of installing systemd it will not be my main desktop until systemd is proven to be safe to use, I need to know more than words from a blog or a wiki to feel comfortable. I have been able to customize Squeeze to do all and behave as good as Wheeze but probably a little faster and once again I feel like a Happy Debian User. :) -- Jimmy Johnson Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447d88c@gmail.com
Re: If Not Systemd, then What?
Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. snip And it still works and is completely customizable. Wow! Just maybe I can get by using it for a couple more years. -- Jimmy Johnson Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447da97.8080...@gmail.com
Re: If Not Systemd, then What?
Hi Jimmy, Am Mittwoch, 22. Oktober 2014, 09:17:16 schrieb Jimmy Johnson: Martin Steigerwald wrote: Am Montag, 20. Oktober 2014, 19:49:43 schrieb Jimmy Johnson: So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? Just wondering. See above and unless you are a tester or developer you may want to roll-back to Squeeze. Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to work with sysvinit as well. Hi Martin, Something I did not know at the time you asked the question: Why Squeeze?. Is that Wheezy was used by Debian to test systemd and even though I did not know this at that time I did not feel comfortable using Wheezy as my main desktop and now knowing that Wheezy is capable of installing systemd it will not be my main desktop until systemd is proven to be safe to use, I need to know more than words from a blog or a wiki to feel comfortable. I have been able to customize Squeeze to do all and behave as good as Wheeze but probably a little faster and once again I feel like a Happy Debian User. :) While Wheezy has systemd packages and it somewhat works, but also had lots of issues in my testing with really systemd packages, its optional. So as long as you do not install it, you will have sysvinit just as with Squeeze. So systemd is not a reason to delay an update from Squeeze to Wheezy. Its Jessie/Sid that are under some circumstances difficult to use without systemd. As to my current knowledge one of the circumstances is an installed GNOME desktop. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13094961.CDQsp2eu1D@merkaba
Re: If Not Systemd, then What?
Martin Steigerwald wrote: Hi Jimmy, Am Mittwoch, 22. Oktober 2014, 09:17:16 schrieb Jimmy Johnson: Martin Steigerwald wrote: Am Montag, 20. Oktober 2014, 19:49:43 schrieb Jimmy Johnson: So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? Just wondering. See above and unless you are a tester or developer you may want to roll-back to Squeeze. Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to work with sysvinit as well. Hi Martin, Something I did not know at the time you asked the question: Why Squeeze?. Is that Wheezy was used by Debian to test systemd and even though I did not know this at that time I did not feel comfortable using Wheezy as my main desktop and now knowing that Wheezy is capable of installing systemd it will not be my main desktop until systemd is proven to be safe to use, I need to know more than words from a blog or a wiki to feel comfortable. I have been able to customize Squeeze to do all and behave as good as Wheeze but probably a little faster and once again I feel like a Happy Debian User. :) While Wheezy has systemd packages and it somewhat works, but also had lots of issues in my testing with really systemd packages, its optional. So as long as you do not install it, you will have sysvinit just as with Squeeze. So systemd is not a reason to delay an update from Squeeze to Wheezy. As I have posted elsewhere, I have more than a few installs of Wheezy, I also have testing and unstable installed too, they will remain as always until I no longer have an interest in Debian and that will be a sad day if and when it happens. Its Jessie/Sid that are under some circumstances difficult to use without systemd. As to my current knowledge one of the circumstances is an installed GNOME desktop. I install using the Debian-Live-KDE-iso(another project I have helped with) and will continue my testing and upgrading of Debian systems for as long as Debian fits my needs. Upon the first sign of a backdoor and/or keylogger being installed and used in Debian by default it will begone and mentally ripped to shreds. -- Jimmy Johnson Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447f97f.4010...@gmail.com
Re: If Not Systemd, then What?
On Mi, 22 oct 14, 08:44:02, Tanstaafl wrote: On 10/21/2014 4:21 PM, Andrei POPESCU andreimpope...@gmail.com wrote: Upstart was the only real contender to systemd at the time of the evaluation by the Technical Committee, but it has or is being replaced by systemd everywhere. And why was OPenRC not a contender? It's all in the debate, but from the top of my head: not ready, lack of documentation, not much gain compared to the migration costs, could have been more. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: If Not Systemd, then What?
Martin Steigerwald wrote: Am Mittwoch, 22. Oktober 2014, 11:37:51 schrieben Sie: Its Jessie/Sid that are under some circumstances difficult to use without systemd. As to my current knowledge one of the circumstances is an installed GNOME desktop. I install using the Debian-Live-KDE-iso(another project I have helped with) and will continue my testing and upgrading of Debian systems for as long as Debian fits my needs. Upon the first sign of a backdoor and/or keylogger being installed and used in Debian by default it will begone and mentally ripped to shreds. Huh? Where does your fear of that come from? Martin, fear..I have no fear..but I'm not naive ether and taking this subject any further on list I will not do, but you are welcome to contact me off list. -- Jimmy Johnson Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544806b8.9080...@gmail.com
Re: If Not Systemd, then What?
On 10/22/2014 12:17 PM, Jimmy Johnson wrote: Martin Steigerwald wrote: Am Montag, 20. Oktober 2014, 19:49:43 schrieb Jimmy Johnson: So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? Just wondering. See above and unless you are a tester or developer you may want to roll-back to Squeeze. Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to work with sysvinit as well. Hi Martin, Something I did not know at the time you asked the question: Why Squeeze?. Is that Wheezy was used by Debian to test systemd and even though I did not know this at that time I did not feel comfortable using Wheezy as my main desktop and now knowing that Wheezy is capable of installing systemd it will not be my main desktop until systemd is proven to be safe to use, I need to know more than words from a blog or a wiki to feel comfortable. I have been able to customize Squeeze to do all and behave as good as Wheeze but probably a little faster and once again I feel like a Happy Debian User. :) You have to make a concerted effort to enable systemd to Wheezy. I mean, you really have to try hard. :) Ric -- My father, Victor Moore (Vic) used to say: There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome. R.I.P. Dad. Linux user# 44256 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544808ee.5020...@gmail.com
Re: If Not Systemd, then What?
Am Mittwoch, 22. Oktober 2014, 12:34:16 schrieb Jimmy Johnson: Martin Steigerwald wrote: Am Mittwoch, 22. Oktober 2014, 11:37:51 schrieben Sie: Its Jessie/Sid that are under some circumstances difficult to use without systemd. As to my current knowledge one of the circumstances is an installed GNOME desktop. I install using the Debian-Live-KDE-iso(another project I have helped with) and will continue my testing and upgrading of Debian systems for as long as Debian fits my needs. Upon the first sign of a backdoor and/or keylogger being installed and used in Debian by default it will begone and mentally ripped to shreds. Huh? Where does your fear of that come from? Martin, fear..I have no fear..but I'm not naive ether and taking this subject any further on list I will not do, but you are welcome to contact me off list. Jimmy, I wrote to you off list, and you put my personal reply on the list. Please don´t do that. I mean personal replies as personal replies. I think I am not interested into digging into this topic further anyway. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3337305.afCvyX72Cr@merkaba
Re: If Not Systemd, then What?
Martin Steigerwald wrote: Jimmy, I wrote to you off list, and you put my personal reply on the list. Please don�t do that. I mean personal replies as personal replies. I think I am not interested into digging into this topic further anyway. No problem and sorry as I did not realize you where posting off list. -- Jimmy Johnson Debian Squeeze - KDE 4.4.5 - AMD64 - EXT4 at sda11 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5448105b.9080...@gmail.com
Re: If Not Systemd, then What?
On 22/10/14 19:05, Joe wrote: On Wed, 22 Oct 2014 13:04:26 +1100 Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote: P.S. I have been told that one major distro does (or is attempting to do) just that - separate into a 'server' and a 'desktop' distribution. What, like Windows? No. A Linux distro. SUSE. I think that really is the point that is being made, that Windows has always made the distinction, with the server OS being very expensive and requiring access licences for machines or people making use of it. Microsoft server software, such as DNS and the full web server is only available on the server OS, with a few cut-down versions on workstations. With Linux, it is (so far) only usage which determines the category, e.g. with few exceptions, servers are continuously powered, don't have monitors, many don't have X, etc. There is no software which is *only* installable on a server, though there is some which isn't really practical on an intermittently-powered machine. Kind regards. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54481b6a.9000...@gmail.com
Re: If Not Systemd, then What?
On 22/10/14 20:27, Miles Fidelman wrote: Scott Ferguson wrote: On 21/10/14 15:10, Miles Fidelman wrote: Scott Ferguson wrote: Good question Patrick - top posted as I'm referring to the Subject. On 21/10/14 06:45, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? One of the difficulties is that there is no clear distinction between a desktop and a server - just degrees. Um, yes, there is. Typically different hardware (headless for starters), storage area networks, clusters, high availability, as well as different role, and so forth. Miles With respect, you're just repeating your claim that there is a clear distinction between server and desktop - not proving it, which doesn't advance the discussion. Ok, let's start with: - it's the rare desktop that has a fiber channel interface - it's the rare desktop that has an interface for dual-ported disk drives - it's the rare desktop configuration that splits processing and storage (e.g., blade servers + storage servers) - in servers, large RAID arrays are common, desktops might have a pair of mirrored disks, never seen anybody set up a desktop for RAID5,6,10 - these days, servers are generally run in clusters, with cluster file systems, and environments like openstack on top of them - when it comes to performance, desktops generally emphasize graphics performance (e.g., for gaming, video editing, and such); servers are designed more for how many virtual machines they can run - high-availability clustering is a big data center concern, not a desktop concern (anybody run DRBD, or Corosync on a dekstop?) - when it comes to virtualization, on desktops its mostly for running programs in other environments; for servers its mostly about supporting lots of independent users and services - when's the last time you saw a desktop or laptop with an IPMI BMC (or for that matter, had a BMC infected by a virus - not pretty) (note: if you don't know what BMC stands for, then go away and learn something about serious data centers, before weighing in on the distinctions between desktops and servers) - scalability, optimization for transaction processing, high-volume mail processing, etc., etc., etc. - not issues that one worries about on the desktop I don't disagree with any of the above. Respectfully, I repeat:- ; there is no *clear* distinction between server and desktop. ; you have not advanced the discussion (expand and/or tangent != advance) Samba is a server, as is NFS, and apache. If you run them on a desktop is it still *just* a desktop? Can you not run a desktop on server hardware? Generally not - except remotely - given that most servers are headless and don't have graphics boards. Please, you're a smart guy and have no need to stoop to advancing selective cases as evidence of *clear* distinctions. Yeah, one can X- into a server, if you install the software. Many (most?) don't - CLI and various management tools is plenty good for server admin Agreed. snipped one of the reasons that a lot of sysadmins don't like systemd). Opinions vary - not that a lot is *not* case, but that a lot constitutes a significant percentage - or a majority. Of the sysadmin I've spoken to - the majority (a slight majority) hold an opinion similar to mine:- we don't have one[*1], we are *very* wary of popular opinion (lowest common denominator?), we are primarily technicians and engineers not writers and have a strong preference for demonstrated facts (in the course of extensive testing). [*1] as a result of considering two opposing opinions Can you not run a server on desktop hardware? Not if you're supporting a serious load - unless you're clustering lots of machines (but once you cluster a few hundred motherboards, you're talking a desktop machine, you're talking a cluster). Again, selective instances. *Not* clear cut distinctions. I don't believe you've thought this through... : I'll leave pulseaudio out, just to make things simpler (and acknowledge that simple is a synonym for dumb). I don't believe you have any knowledge whatsoever about data centers or real servers - and are talking through your hat. That's the problem with beliefs - they can be the core of confirmation bias - as to the insults, I'd normally associate that with a lack of argument. Neither of which I expect of you. That you even mention audio in the same conversation as servers says you're in a different universe
Re: If Not Systemd, then What?
On 22/10/14 20:51, Reco wrote: Hi. On Wed, Oct 22, 2014 at 05:27:45AM -0400, Miles Fidelman wrote: Scott Ferguson wrote: - when's the last time you saw a desktop or laptop with an IPMI BMC (or for that matter, had a BMC infected by a virus - not pretty) (note: if you don't know what BMC stands for, then go away and learn something about serious data centers, before weighing in on the distinctions between desktops and servers) A minor nitpick - there's Intel AMT which specifically targets desktops to provide capabilities similar to BMC. Reco And (the old) HP Kayak range also, both Desktops and Servers. I'm now struggling to see how this directly relates to Debian. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5448214e.1030...@gmail.com
Re: If Not Systemd, then What?
On 22/10/14 21:23, Rusi Mody wrote: On Wednesday, October 22, 2014 3:20:05 PM UTC+5:30, Miles Fidelman wrote: Scott Ferguson wrote: On 21/10/14 15:10, Miles Fidelman wrote: Scott Ferguson wrote: snipped Are you guys just having fun talking past each other? I can only speak for myself - no. I doubt Miles is having fun either. And as it's apparent not a discussion I don't intend to pursue it. I'm sure Miles does have some good points - and is a knowledgeable guy, but he doesn't appear to be deploying a logic schema upon which to base a technical discussion instead of continual goal shifting in an attempt to substantiate an opinion based mostly on emotion (fear). I 'can' understand: why he feels so emotional about it ; how that emotion can affect thinking/writing. Or seriously dont know the two meanings of 'server'? No. I was aware of both. Three actually - to 'some' people, who have an annoying habit of differentiating between server and desktop on the basis of case style or location. First two here: http://whatis.techtarget.com/definition/server Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5448241f.8030...@gmail.com
Re: If Not Systemd, then What?
On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote: On Mon, 20 Oct 2014 12:45:11 -0700 Patrick Bartek nemomm...@gmail.com wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? * Nosh So this one is fun, it is just a direct copy of the systemd service format. Guess the proof that's at least a feature that people do want, dropping shell. And of course, not only the format is copied, it took the set of systemd services and copied them like this. I am sure ftp-masters wouldn't accept a GPL violation ( as the .service file are likely not un the BSD ). * Runit was non free for a long time, not sure if developped anymore, especially since last post on one of the ml date back to June 2013. * Upstart no longer developped, and suffer from several bugs, go read the tech-ctte debate. * S6 likely the same as runit when it come to be alive. * Probably more I don't know about. You could add openrc, the only serious contender. And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged Nobody's arguing for sysvinit as a long term solution, for the exact reasons you post above. Those of us who appeared to favor sysvinit were saying let's wait until we have something good. We also pointed out the false choice of prematurely narrowing it to systemd, Upstart or sysvinit. You mean let's do like we did since 20 years, wait, in case if something will happen. None of the alternatives you propose have been widely adopted by anyone except upstart. And that's mostly because no one cared about them up to the point to even propose them. Now of course, the systemd cabal will argue that we can't wait any longer. My question to them is, why was sysvinit not a dire emergency until Red Hat's systemd juggernaut came along, and then all of a sudden we just couldn't wait? You mean that after waiting several years, the solution is to wait again, because no one cared before, and when 1 group came and changed, the solution is to refuse and go back doing nothing ? -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021061217.ga29...@gmail.com
Re: If Not Systemd, then What?
On Tue, 21 Oct 2014 08:12:17 +0200 Ludovic Meyer ludo.v.me...@gmail.com wrote: On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote: On Mon, 20 Oct 2014 12:45:11 -0700 Patrick Bartek nemomm...@gmail.com wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? * Nosh So this one is fun, it is just a direct copy of the systemd service format. Guess the proof that's at least a feature that people do want, dropping shell. I think you meant a direct copy of daemontools, didn't you? http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html It's not a direct copy, it's an enhanced superset of daemontools, kind of. Daemontools preceded systemd by several years, and I sincerely doubt daemontools and systemd have anything in common. And of course, not only the format is copied, it took the set of systemd services and copied them like this. I am sure ftp-masters wouldn't accept a GPL violation ( as the .service file are likely not un the BSD ). Daemontools wasn't GPL'ed, it was Public Domained, so anyone can do absolutely anything with it. * Runit was non free for a long time, not sure if developped anymore, especially since last post on one of the ml date back to June 2013. Funtoo is using it, and I seriously doubt they'd be using something not developed anymore. * Upstart no longer developped, and suffer from several bugs, go read the tech-ctte debate. I read it, and if Upstart problems were the most distressing thing in that debate, I'd be a happy man. If Upstart is no longer under development, the reason would be that the Debian CTTE decided on systemd, so Cannonical reluctantly followed suit. * S6 likely the same as runit when it come to be alive. * Probably more I don't know about. You could add openrc, the only serious contender. Thanks. I hereby add openrc, assuming it's ready now. And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged Nobody's arguing for sysvinit as a long term solution, for the exact reasons you post above. Those of us who appeared to favor sysvinit were saying let's wait until we have something good. We also pointed out the false choice of prematurely narrowing it to systemd, Upstart or sysvinit. You mean let's do like we did since 20 years, wait, in case if something will happen. None of the alternatives you propose have been widely adopted by anyone except upstart. And that's mostly because no one cared about them up to the point to even propose them. The reason nobody paid attention to them yet is the alternative wasn't systemd until now. systemd is a mighty motivator, I'll say that for it. Now of course, the systemd cabal will argue that we can't wait any longer. My question to them is, why was sysvinit not a dire emergency until Red Hat's systemd juggernaut came along, and then all of a sudden we just couldn't wait? You mean that after waiting several years, the solution is to wait again, because no one cared before, That is *exactly* what I mean. Don't move to a worse position, and if this had really been life or death, systemd would have been gone a few years ago. and when 1 group came and changed, the solution is to refuse and go back doing nothing ? Now that, I didn't say. Go back and read the quoted text. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021024646.04540...@mydesq2.domain.cxm
Re: If Not Systemd, then What?
On Tue, Oct 21, 2014 at 12:36:52AM -0200, Martinx - ジェームズ wrote: 2- Start testing uselessd; You missed 'package uselessd' for Debian - not yet done. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021065822.gc28...@chew.redmars.org
Re: If Not Systemd, then What?
On Tuesday, October 21, 2014 12:00:01 PM UTC+5:30, Ludovic Meyer wrote: On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote: On Mon, 20 Oct 2014 12:45:11 -0700 Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? * Nosh So this one is fun, it is just a direct copy of the systemd service format. Guess the proof that's at least a feature that people do want, dropping shell. And of course, not only the format is copied, it took the set of systemd services and copied them like this. I am sure ftp-masters wouldn't accept a GPL violation ( as the .service file are likely not un the BSD ). * Runit was non free for a long time, not sure if developped anymore, especially since last post on one of the ml date back to June 2013. * Upstart no longer developped, and suffer from several bugs, go read the tech-ctte debate. * S6 likely the same as runit when it come to be alive. * Probably more I don't know about. You could add openrc, the only serious contender. And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged Nobody's arguing for sysvinit as a long term solution, for the exact reasons you post above. Those of us who appeared to favor sysvinit were saying let's wait until we have something good. We also pointed out the false choice of prematurely narrowing it to systemd, Upstart or sysvinit. You mean let's do like we did since 20 years, wait, in case if something will happen. None of the alternatives you propose have been widely adopted by anyone except upstart. And that's mostly because no one cared about them up to the point to even propose them. Now of course, the systemd cabal will argue that we can't wait any longer. My question to them is, why was sysvinit not a dire emergency until Red Hat's systemd juggernaut came along, and then all of a sudden we just couldn't wait? You mean that after waiting several years, the solution is to wait again, because no one cared before, and when 1 group came and changed, the solution is to refuse and go back doing nothing ? Fallacy of False Dilemma: http://en.wikipedia.org/wiki/False_dilemma There are other choices to - do nothing as weve done for 20 years - do it now In particular, one can take a holistic view: not just Stable - Jessie, but rather Stable - Jessie - Jessie+1 and work out the least disruptive, most generally acceptable solution in that +1ed widened frame -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a0e8993f-d150-42d4-b31e-3b44c2fe8...@googlegroups.com
Re: If Not Systemd, then What?
That's true... Can't wait to try it! If uselessd provides ONLY a new init, based on CGroups and lots of cool ideas from systemd itself, then, it worth trying it! Just for fun... Systemd will be still around, acting only as udev, I know... But, then, it will be more easy to live without it. If that becomes true, I mean, if uselessd can act as systemd to mange/supervise process in a new fashion (i.e. no init scripts), then, it will be doing what systemd was supposed to be doing (in Debian) in first place! Sorry about my poor English. - Thiago On 21 October 2014 04:58, Jonathan Dowland j...@debian.org wrote: On Tue, Oct 21, 2014 at 12:36:52AM -0200, Martinx - ジェームズ wrote: 2- Start testing uselessd; You missed 'package uselessd' for Debian - not yet done. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021065822.gc28...@chew.redmars.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJSM8J3KX+BpG_EovV0d-P+KVKDmQQ=9pj_-RstF=_nx5em...@mail.gmail.com
Re: If Not Systemd, then What?
Am Montag, 20. Oktober 2014, 19:49:43 schrieb Jimmy Johnson: So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? Just wondering. See above and unless you are a tester or developer you may want to roll-back to Squeeze. Why Squeeze? Wheezy has sysvinit just fine… and so or so I expect Jessie to work with sysvinit as well. Squeeze has security support through the LTS initiative that only provides this support for a reduced set of packages. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/282804258.gtEqSjICmt@merkaba
Re: If Not Systemd, then What?
Hi, Please do not top-post. On Tue, Oct 21, 2014 at 05:27:34AM -0200, Martinx - ジェームズ wrote: If uselessd provides ONLY a new init, based on CGroups and lots of cool ideas from systemd itself, then, it worth trying it! Just for fun... I think it's an interesting project and I might contribute towards the packaging, so long as it's a team effort, but currently nobody has taken ownership of the 'request for package' bug, so there is almost no chance of uselessd being a part of jessie. (it would have to be packaged, uploaded and pass NEW in under 2 weeks.) Systemd will be still around, acting only as udev, I know... But, then, it will be more easy to live without it. udev and systemd are not the same things. Their source co-exists in the same version control repository, and they are developed in concert, but they are (currently) independent, and will certainly be independent for jessie. (whether they remain independent in the future is another question.) Sorry about my poor English. No need to apologise! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021081132.ga28...@chew.redmars.org
Re: If Not Systemd, then What?
Here are some interesting things one should be aware of before http://0pointer.de/blog/projects/the-biggest-myths.html Read enough about but still haven't read something really valuable against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link) I believe the main issue with systemd and the community mainly the badass-ness of the guys in this init system war or whatever you prefer to address at. Using systemd since 2014-08-09 with no issues. -- « Nunc est bibendum, nunc pede libero pulsanda tellus » -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021081847.gb1...@gmail.com
Re: If Not Systemd, then What?
On Tue, Oct 21, 2014 at 10:18:49AM +0200, Raffaele Morelli wrote: Here are some interesting things one should be aware of before http://0pointer.de/blog/projects/the-biggest-myths.html Read enough about but still haven't read something really valuable against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link) Please don't, because that isn't on topic for this mailing list. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021084152.gf28...@chew.redmars.org
Re: If Not Systemd, then What?
On Ma, 21 oct 14, 00:10:27, Miles Fidelman wrote: Um, yes, there is. Typically different hardware (headless for starters), storage area networks, clusters, high availability, as well as different role, and so forth. I have a Raspberry Pi serving my domain (DNS + WWW). As far as I'm concerned that's *my* server. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: If Not Systemd, then What?
Hi Raffaele, Am Dienstag, 21. Oktober 2014, 10:18:49 schrieb Raffaele Morelli: Here are some interesting things one should be aware of before http://0pointer.de/blog/projects/the-biggest-myths.html Read enough about but still haven't read something really valuable against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link) I believe the main issue with systemd and the community mainly the badass-ness of the guys in this init system war or whatever you prefer to address at. Using systemd since 2014-08-09 with no issues. I think this is certainly a good read for background. I also suggest to revisit [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance http://lists.freedesktop.org/archives/systemd-devel/2014-September/023290.html Rob from this list voiced some concern there. And I added hints about debianfork.org and also raised some issues here now. This is where upstream really gets to see the feedback. So I again suggest you voice your concerns there. Politely and in enough detail. Or as some of you do, work on the alternatives. Lets see what comes out of the GR: I hope it goes for restricting dependencies to PID 1 tightly. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5729685.ll3milQcNW@merkaba
Re: If Not Systemd, then What?
On 21/10/14 at 09:41am, Jonathan Dowland wrote: On Tue, Oct 21, 2014 at 10:18:49AM +0200, Raffaele Morelli wrote: Here are some interesting things one should be aware of before http://0pointer.de/blog/projects/the-biggest-myths.html Read enough about but still haven't read something really valuable against systemd from eg. Torvalds, Eric Steven Raymond, etc... (if you do, post the link) Please don't, because that isn't on topic for this mailing list. you know, it's been months that this systemd thing is going on and I thought it was tolerated (though I learned to use ^D in mutt :-) ) I apologize -- « Nunc est bibendum, nunc pede libero pulsanda tellus » -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021094833.gg1...@gmail.com
Re: If Not Systemd, then What?
On 10/20/2014 3:45 PM, Patrick Bartek nemomm...@gmail.com wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? OpenRC has been working just fine on my Gentoo server for many years. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54463621.3010...@libertytrek.org
Re: If Not Systemd, then What?
On 10/20/2014 10:36 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: 1- Fork udev (out from systemd's tree or before it got merged / engulfed); Maybe Gentoo's eudev would be a good place to start with that. I also don't see why OpenRC isn't on the list of obvious choices. It is the default in Gentoo and has been for ages, and it 'just works'. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544638ab.4010...@libertytrek.org
Re: If Not Systemd, then What?
Steve Litt wrote: On Tue, 21 Oct 2014 08:12:17 +0200 Ludovic Meyer ludo.v.me...@gmail.com wrote: snip * Upstart no longer developped, and suffer from several bugs, go read the tech-ctte debate. I read it, and if Upstart problems were the most distressing thing in that debate, I'd be a happy man. If Upstart is no longer under development, the reason would be that the Debian CTTE decided on systemd, so Cannonical reluctantly followed suit. And this is where the Tech. Committee decision really hurt the Linux community as a whole. Essentially, this came down to giving in to blackmail (if you want GNOME you have to take systemd) - and yes, I read all the email about the decision, but that's really what it comes down to (IMHO). And in doing so, basically led to a general decline in the overall Linux ecosystem. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544661b5.7010...@meetinghouse.net
Re: If Not Systemd, then What?
- Original Message - From: Jonathan Dowland j...@debian.org On Tue, Oct 21, 2014 at 05:27:34AM -0200, Martinx - ジェームズ wrote: If uselessd provides ONLY a new init, based on CGroups and lots of cool ideas from systemd itself, then, it worth trying it! Just for fun... I think it's an interesting project and I might contribute towards the packaging, so long as it's a team effort, but currently nobody has taken ownership of the 'request for package' bug, so there is almost no chance of uselessd being a part of jessie. (it would have to be packaged, uploaded and pass NEW in under 2 weeks.) Jonathan, I'm not sure what is meant by nobody has taken ownership of the 'request for package' bug. If that's something that needs to be done, tell me what is required and I'll see if I can do it. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/812307098.111494.1413900021175.javamail.zim...@ptd.net
