Re: Init system deba{te|cle}
On Mon, 04 Nov 2013 11:06:25 +0100 berenger.mo...@neutralite.org wrote: Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. I'm interested. Do you have a document explaining that you need to use shell scripts with systemd? systemd supports shell scripts, but it's not because it have to, it is because it's authors wants and easy integration of existing stuff, AFAIK. I didn't write it quite well. I meant about non-standard configuration. -- http://mr.flossdaily.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131108121251.5ac42...@eunet.rs
Re: Init system deba{te|cle}
Le 08.11.2013 12:12, Marko Randjelovic a écrit : On Mon, 04 Nov 2013 11:06:25 +0100 berenger.mo...@neutralite.org wrote: Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. I'm interested. Do you have a document explaining that you need to use shell scripts with systemd? systemd supports shell scripts, but it's not because it have to, it is because it's authors wants and easy integration of existing stuff, AFAIK. I didn't write it quite well. I meant about non-standard configuration. -- http://mr.flossdaily.org So your argument is that things are more complex when they are not standard than when they are standard with systemd, while the complexity is the same ( modulo the script's complexity itself ) with sysvinit? My opinion on that point is that it's a good thing, because systemd's standard situations are far simpler to configure than sysvinit, while the non-standard ones are as complex as the sysvinit's ones (and so as sysvinit standards ones, too, still modulo the script complexity itself). This sounds fair enough for me. Note that I actually do not intend to use systemd, but it is only because there are people doing things for me with sysvinit, and that systemd does too many things according to my tastes (since I want the lightest system possible, without having to sacrifice any feature. This works quite well, but could be better if dbus and especially gstreamer were not required by so many applications, so I won't add a systemd in it if I can delay... ). If systemd had not as many features, I would be using it from months. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ebfa806b2b907d990f60c0d0364f5...@neutralite.org
Re: Init system deba{te|cle}
On Sun, 3 Nov 2013 14:33:27 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? It depends, but if you could do it then I don't see why couldn't you do anything that is needed later. Besides, configuration files can also change, just like init scripts. A don't have a feeling that upstart/systemd configuration is so simple (not so much about syntax, I was looking at their documentation and there are things such as 'events' and such things have to be properly defined), so it can also make problems, not just change in init scripts. There is nothing more standard/portable in Unix-like systems then POSIX shell. …which wasn't fully supported on Solaris 9 so you had to use a subset (e.g. no $(subshell) syntax). Writing truly portable shell scripts across multiple UNIX families was a terrible pain and one could not simply rely on the POSIX feature-set. I know this from bitter experience. I suspect C89 is/was more portable in practice, but the point OP is making here isn't the scripting language, for portability, it's the fact init scripts do little to abstract the differences between OSes, so portable init scripts are very hard to achieve. E.g. Debian uses /etc/default for overrides, Redhat-esque systems use various schemes under /etc/sysconfig; We are talking about Debian init system. init scripts do not need to support Red Hat because they are on systemd and Solaris is not a Linux distro and it's not realistic to expect scripts could be portable between Debian and Solaris. various init scripts are written with the assumption sh → bash which required a lot of fixing up when Debian and Ubuntu moved to a different default sh; and on and on. We already moved to a different default shell. Such OS layout specifics being baked into init scripts also make it much harder to make changes, since you break a load of init scripts when the assumptions they rely on change. It's because scripts are not correctly done. All scripts that use the same resource should not reference that resource directly, but instead by a common function. That way, when resource location change, you need to change only relevant function. We could just correct such errors, and make other corrections/improvements/enhancements instead of going into vendor lock-in. If Debian wants to take care about it's init scripts, I would really be motivated to be involved. That's why I am not sure makers of alternative init systems really very much care about users' real benefit. They could add additional features as additional software, not replacement software. Or they could work to improve existing sysvinit. E.g. they could extend start-stop-daemon to return only when service is ready, or if timeout exceeds to return with error status. I'm sure it would be much simpler than making all that. I primarily mean about systemd and upstart, I didn't have enough time to learn about OpenRC, but at first glance it looks to me significantly better. If it's development continues in good direction, Debian could take OpenRC as replacement for sysvinit, so the worst mistake would be if we now, without enough vision about eventual consequences, take systemd or upstart as default init system. This is why it's not just systemd that is trying to replace shell scripts: nearly all the next-gen init systems do (launchd, upstart, openrc… even smf with its XML). I do not see 'start daemons when they are first used' is quite an important benefit and start in parallel is already supported by sysvinit (startpar). Some people like socket activation a lot (which is why inetd was used to achieve this in the past) Then it's again a lack of feature in server software (lack of initd support), and not init system. I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. It's a principle near and dear to much of the rest of our F/OSS stack, however. The Linux kernel is monolithic (and enormous) rather than a microkernel. GLibc is enormous rather than a family of smaller libraries. And so on. I agree with it, but it's because people choose to join existing projects instead of to start a new one. We are lacking entrepreneur spirit :) . --
Re: Init system deba{te|cle}
On Mon, 04 Nov 2013 10:44:23 -0600 Conrad Nelson y...@marupa.net wrote: Not everyone is a programmer, but a lot of non-programmers are still admins but are not interested in working with shell scripts if they don't have to. We already have: skeleton, /etc/default. I agree it's poor, but as I said, and at least for me, the right way is to extend existing software: (1) add new features to sysvinit (2) add new software in addition to sysvinit (3) make init scripts more correct (abstraction) (4) extend configurability (more options in /etc/default/*) (3) makes (4) easily possible And if sysvinit is in accord with UNIX philosophy, and as they say it is, than I don't see why (1) and (2) would not be possible, too, and with not to much effort. About what they say as disadvantages of sysvinit (lack of features), is not really to blame sysvinit, because it does one thing and do it right[1]. Other features could be implemented as additional software. On the other hand, what actually was done was writing new software that make old software obsolete and that do *many* things, which is not in accord with UNIX philosophy (and is in accord with authoritarian philosophy). Further, shell scripts can have any number of bugs in them that are harder to find than unit files which rarely have more than a dozen lines in them. Every complex software has bugs, including complex init system. [1] https://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy rule 2 -- http://mr.flossdaily.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131108134841.71563...@eunet.rs
Re: Init system deba{te|cle}
Le 08.11.2013 12:55, Marko Randjelovic a écrit : On Sun, 3 Nov 2013 14:33:27 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? It depends, but if you could do it then I don't see why couldn't you do anything that is needed later. Besides, configuration files can also change, just like init scripts. A don't have a feeling that upstart/systemd configuration is so simple (not so much about syntax, I was looking at their documentation and there are things such as 'events' and such things have to be properly defined), so it can also make problems, not just change in init scripts. The point here was probably that maintaining a patch-fork implies lot of work ( by patch-fork I mean that you try to stay as close as possible to upstream's versions but you keep a set of patches ) when time goes on, because those patches becomes harder and harder to maintain, since upstream's code changes might imply reworking your patch set, piece after piece. There is nothing more standard/portable in Unix-like systems then POSIX shell. …which wasn't fully supported on Solaris 9 so you had to use a subset (e.g. no $(subshell) syntax). Writing truly portable shell scripts across multiple UNIX families was a terrible pain and one could not simply rely on the POSIX feature-set. I know this from bitter experience. I suspect C89 is/was more portable in practice, but the point OP is making here isn't the scripting language, for portability, it's the fact init scripts do little to abstract the differences between OSes, so portable init scripts are very hard to achieve. E.g. Debian uses /etc/default for overrides, Redhat-esque systems use various schemes under /etc/sysconfig; We are talking about Debian init system. init scripts do not need to support Red Hat because they are on systemd But if it was possible, it would be nice, do not you think so? Not reinventing the wheel without reasons is a noble objective for me. ( Learning how to do the wheel, or trying to make it lighter or faster are two good reasons to reinvent the wheel anyway, but they are not the most frequent ones ) That's what systemd offers. and Solaris is not a Linux distro and it's not realistic to expect scripts could be portable between Debian and Solaris. Debian is not only a linux distribution, it is a free software operating systems which can use the linux kernel. So, having script compatible across kernels ( you said solaris is not a linux distribution, so I thought you only mean it does not uses the linux kernel, nothing less and nothing more ) would be useful. And I think it is doable, if those scripts are really specialized in doing one and only one thing, relying on script libraries to do lower level things. Another thing needed to make something portable is to remove hard-coded data from the main program, being by moving them in other, specialized scripts, or in configuration files. Unfortunately, doing so makes things slower to have something which really works (but easier to maintain indeed) so it is rarely done. And I do think that script writers does it more rarely than software writers ( in the average, of course, and I have no data other than my feeling on that topic ). I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. It's a principle near and dear to much of the rest of our F/OSS stack, however. The Linux kernel is monolithic (and enormous) rather than a microkernel. GLibc is enormous rather than a family of smaller libraries. And so on. I agree with it, but it's because people choose to join existing projects instead of to start a new one. We are lacking entrepreneur spirit :) . I do not think so. My opinion is that the problem is the lack of fixed and clear objectives, so new features are added which are in the vague borders. Doing so often extends those vague borders. You probably already have seen a pretty good software becoming a memory black hole by time when features where added one after the other: that's what I am talking about, and it is not a open-source-only issue. There is also the problem that current developers usually likes to use only one library to do everything ( calling it a
Re: Init system deba{te|cle}
Le 08.11.2013 13:48, Marko Randjelovic a écrit : On Mon, 04 Nov 2013 10:44:23 -0600 Conrad Nelson y...@marupa.net wrote: Not everyone is a programmer, but a lot of non-programmers are still admins but are not interested in working with shell scripts if they don't have to. We already have: skeleton, /etc/default. I agree it's poor, but as I said, and at least for me, the right way is to extend existing software: (1) add new features to sysvinit (2) add new software in addition to sysvinit (3) make init scripts more correct (abstraction) (4) extend configurability (more options in /etc/default/*) (3) makes (4) easily possible And if sysvinit is in accord with UNIX philosophy, and as they say it is, than I don't see why (1) and (2) would not be possible, too, and with not to much effort. About what they say as disadvantages of sysvinit (lack of features), is not really to blame sysvinit, because it does one thing and do it right[1]. Other features could be implemented as additional software. On the other hand, what actually was done was writing new software that make old software obsolete and that do *many* things, which is not in accord with UNIX philosophy (and is in accord with authoritarian philosophy). Further, shell scripts can have any number of bugs in them that are harder to find than unit files which rarely have more than a dozen lines in them. Every complex software has bugs, including complex init system. [1] https://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy rule 2 -- http://mr.flossdaily.org While I tend to agree on most of your words here, you made a little mistake: what actually was done was writing new software that make old software. Systemd is compatible with sysvinit ( sysvinit's scripts can be used by systemd, it is why you can install systemd on Debian and remove sysvinit, without changing any sysvinit script and things will still work. I tried it 1-2 years ago). It's sysvinit which is not compatible (it does not supports the systemd's configuration files) but since systemd is meant to be an evolution, it's normal. Sometimes, making older softwares not able to understand latest ones is mandatory. Or we would have to write everything in a XML way to avoid it... But it this happens, it will probably trigger Ragnarök. Now, your words are also interesting on a point. Since sysvinit does only one thing and does it correctly, which allows to write programs to extends it, I wonder if a program could be made to make systemd's script understandable by sysvinit? Of course, it would depends on, or rather recommend in Debian's terminology, other tools to achieve feature completeness of systemd. Such a translator would indeed be an interesting thing, because it would allow using systemd's configurations which are way easier in lot of people's mind on sysvinit, and that would remove the main argument for switching to systemd. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e0664fe7fc71567d44d28281f637f...@neutralite.org
Re: Init system deba{te|cle}
Le 05.11.2013 15:32, Jonathan Dowland a écrit : On Tue, Nov 05, 2013 at 03:10:31PM +0100, berenger.mo...@neutralite.org wrote: As simple Debian users, we indeed do not mind about portability stuff. But for Debian's maintainers, using systemd as default means that they'll have to maintain other systems for Debian Hurd and Debian KFreeBSD. Debian Hurd is not a release architecture so the project is not hobbled by its requirements (yet). That's certainly the case for KFreeBSD, so long as it remains a release architecture for jessie. Quite separately from the init discussion, I believe some of my fellow developers have concerns regarding its readiness (and did so for wheezy too). But, indeed, almost nobody mind about that, because linux is probably the most used kernel in free software world, and not with a small difference. Linux is like the windows of free software world (in term of adoption, not about other aspects). Yes, in Debian the amd64 variant of the Linux kernel is more popular than the two KFreeBSD variants combined by a very large margin. To be very honest, I have no idea about differences between the kernels from end-user point of view. Except that it seem you can use windows' drivers natively, of course (but that single point really sounds interesting in itself). The lack of informations about those differences is the only one thing which made me not switching, and I do not know how longer my prudence will refrain my curiosity. And since I really trust Debian developers for doing quality work, I do not have a lot of concerns about it being ready. From the developer point of view, the fact that FreeBSD can be compiled with other compilers than GCC is a strong argument for switching. My opinion is that being able to compile something with more than one compiler is a proof of quality. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bd9689067fc456c28e209477c1701...@neutralite.org
Re: Init system deba{te|cle}
On Mon, Nov 04, 2013 at 04:16:39PM +, Tom H wrote: On Sun, Nov 3, 2013 at 9:33 AM, Marko Randjelovic marko...@eunet.rs wrote: Decisions like changing such an essential part of OS should not be made in rush. It's not being done in a rush. This has been discussed at length on debian-devel a number of times in the last two years. …and the next release is a long time off, so if a change is made in sid now, there's a long time to make sure that whatever is new is robust and integrated. In other words now is exactly the right time to be doing it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105094713.gc28...@bryant.redmars.org
Re: Init system deba{te|cle}
Le 04.11.2013 17:44, Conrad Nelson a écrit : LXDE, on the other hand, would be a better choice for a UNIX philosophy fan (better, not perfect, since UNIX philosophy imply that softwares discuss between them by text only, which can not really be easily done when you come to GUIs. I think that raw UNIX philosophy is not adapted to modern graphical uses, but this is a personal opinion which can be changed rather easily since I want to be wrong). I do not think UNIX philosophy is not wrong, I think users are wrong. Users want false impression of power and that only makes them dependent on the software that makes them such an illusion, similar to effect of narcotics. Look what RMS says about companies want to control their users with software. Users are not wrong: they do not want to have to write pieces of programs to use their system. I do not want to have to plug cables inside my car neither. Instead, I want to push a button and have the system replying to my request. Without me needing to alter it. Couldn't agree more. I said in a different reply on this threat that managing services is probably better handled in a declarative style (Configuration) than an imperative (Programming) one. I am also a programmer and I think shell scripts are a poor way of managing services when simply declaring dependencies and what binaries to use is more efficient. And if you need some wrapper systemd supports shall scripts just fine. Also, being portable has never been a goal for systemd, so I'm not really sure that's criticism-worthy. As simple Debian users, we indeed do not mind about portability stuff. But for Debian's maintainers, using systemd as default means that they'll have to maintain other systems for Debian Hurd and Debian KFreeBSD. But, indeed, almost nobody mind about that, because linux is probably the most used kernel in free software world, and not with a small difference. Linux is like the windows of free software world (in term of adoption, not about other aspects). Not everyone is a programmer, but a lot of non-programmers are still admins but are not interested in working with shell scripts if they don't have to. Further, shell scripts can have any number of bugs in them that are harder to find than unit files which rarely have more than a dozen lines in them. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b0e60fcf47e911f4c9feddc074606...@neutralite.org
Re: Init system deba{te|cle}
On Tue, Nov 05, 2013 at 03:10:31PM +0100, berenger.mo...@neutralite.org wrote: As simple Debian users, we indeed do not mind about portability stuff. But for Debian's maintainers, using systemd as default means that they'll have to maintain other systems for Debian Hurd and Debian KFreeBSD. Debian Hurd is not a release architecture so the project is not hobbled by its requirements (yet). That's certainly the case for KFreeBSD, so long as it remains a release architecture for jessie. Quite separately from the init discussion, I believe some of my fellow developers have concerns regarding its readiness (and did so for wheezy too). But, indeed, almost nobody mind about that, because linux is probably the most used kernel in free software world, and not with a small difference. Linux is like the windows of free software world (in term of adoption, not about other aspects). Yes, in Debian the amd64 variant of the Linux kernel is more popular than the two KFreeBSD variants combined by a very large margin. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105143210.ge28...@bryant.redmars.org
Re: Init system deba{te|cle}
Le 03.11.2013 10:23, Marko Randjelovic a écrit : On Sat, 02 Nov 2013 15:58:45 +0100 berenger.mo...@neutralite.org wrote: _ sysvinit scripts are scripts. Scripts needs programming skills, and the sh language does not have an easy to read syntax. I would in fact call it rather obscure compared to various other languages I used. Systemd configuration files are, real configuration files. Plain-text, no XML (this point is important for me), no script (this one too). Just some key-value associations. I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, Being a programmer does not imply to thinks as programming as an easy thing. I am also a programmer, and, I have no shame to say that I am not able to use all languages. For example, I can not use prolog effectively. Programming is more error-prone than real configuration files. A single typo can generate hard to debug problems, especially in non compiled languages, not to speak about lacks of strong typing. _ systemd configuration files can be shared between distributions more easily than sysvinit scripts. Thus, it is more portable across linux distributions. The work being centralized, it makes the package's maintainers needed to do less work. There is nothing more standard/portable in Unix-like systems then POSIX shell. Other have replied this better than I could. Another advantage it have, is that it is able to parallelize the start of daemons, and to only start daemons when they are first used. It is not an important feature on a server, but for desktops or laptops which are computers you can start lot of times in a day, it can save time. On that particular point, my opinion is that it is not the good solution: the good solution is to only start daemons you really need. I do not see 'start daemons when they are first used' is quite an important benefit Makes it faster to have a system you can use. There are probably other advantages like security: less things started, less security flaws. Not sure how this apply to systemd however. Portability have a cost, and it is often the lack of features or the need to reinvent the wheel on some targets but not on all. WxWidgets knows the problem I am talking about. I'd say the problem is in the lack of real effort to solve programming problems in an abstract way. Portability imply to limit yourself to the greatest common factor, or to implement lacking features on targets yourself. A non implemented feature can not be abstracted. And the last problem I can think about, is that it does things that are not only system initialization. It means that, by itself, it might become hard to maintain. I said might, because I never looked at sysvinit source code (since it is old, it could bet not so clean, having be maintained by lot of different people) not systemd's one (good software designs can make things damn easy to maintain, even when they do not do only one thing). and so, which would imply duplicate work. If Debian was a normal Linux distribution, then portability would not have been a problem. I don't see why Debian is not a normal Linux distibution and how is it related to portability Because it's not limited to linux kernel. There would still be the lack of UNIX philosophy, but, be honest: any distribution using Gnome, KDE or even XFCE as the default DE is already damn far from the UNIX philosophy. I have nothing against that, do not take me wrong, it is a choice. But using those DEs as defaults DE proves that this philosophy is not so important. I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. I can not agree more, however my point is that there are currently no DE implementing it. The closer to it I know about is LXDE, which still have small issues in this regard. Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. I'm interested. Do you have a document explaining that you need to use shell scripts with systemd? systemd supports shell scripts, but it's not because it have to, it is because it's authors wants and easy integration of existing stuff, AFAIK. LXDE, on the other hand, would be a better choice for a UNIX philosophy fan (better, not perfect, since UNIX philosophy imply that softwares discuss between them by text only, which can not really be easily done when you come to GUIs. I think that raw UNIX philosophy is not adapted to modern graphical uses, but this is a personal opinion which can be changed rather easily since I want to be wrong). I do not think UNIX philosophy is not wrong, I think users are wrong. Users want false impression of power and that only makes them
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 9:45 PM, Reco recovery...@gmail.com wrote: On Sat, 2 Nov 2013 21:23:01 + Tom H tomh0...@gmail.com wrote: On Sat, Nov 2, 2013 at 2:16 PM, Reco recovery...@gmail.com wrote: I don't trust this guy. He's generally very abrasive and very aggressive. He joined or started a debian-devel thread on init systems and tried to convince people that openrc was the solution to Debian's prayers. It was the sales pitch from hell! He's especially unreliable when it comes to systemd. Well, whoever he is, he raises some valid questions. Such as - what logind are supposed to do? Why bother keeping unrelated projects in systemd git? He's a Gentoo developer who might be involved in OpenRC development (he's not its Gentoo maintainer). logind is a replacement of ConsoleKit, which is now dead upstream (and has been for one or two years). On my (Ubuntu) laptop: [root@lenovo15]# loginctl list-sessions SESSIONUID USER SEAT c1124 dirmngr seat0 c2 1000 th seat0 2 sessions listed. [root@lenovo15]# loginctl list-users UID USER 124 dirmngr 1000 th 2 users listed. [root@lenovo15]# loginctl list-seats SEAT seat0 1 seats listed. Its role is the tracking and management of user sessions. That somehow extends into power management and the first dependency of GNOME on systemd (that I know of) was of the power module of gnome-settings-daemon in GNOME 3.8. If the Ubuntu developers who've already split logind from systemd up to v204 throw up their hands and say it can't be done for v205+, then I'll believe it... Not that I'm in hurry too :) You might not be in a hurry but I'm sure that there are Debian users and developers who'd like to see GNOME depend on logind rather than on systemd. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=swryorwnmctceb65us9hcubjsmydtuqukkupubheab...@mail.gmail.com
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 10:06 PM, Reco recovery...@gmail.com wrote:
On Sat, 2 Nov 2013 21:08:29 +
Tom H tomh0...@gmail.com wrote:
Misrepresenting what systemd is and the reasons for its existence
doesn't make sense:
http://0pointer.de/blog/projects/systemd.html
OS X and Solaris switched to launchd and smf respectively in 2005 and,
to borrow an expression from Asterix and Obelix, the sky didn't fall
on their heads. Modern nix systems need a more sophisticated
/sbin/init and associated executables and they need (and have needed
for a long time) something more reliable and maintainable than a bunch
of dash/bash scripts to bring the system up.
I've never seen (nor intend to) launchd, but I'm familiar with smf.
And while in Solaris the sky didn't fall on their heads indeed, smf
uses ksh scripts for actual launch, check and re-start services like no
tomorrow. And Solaris's svc.startd is actually started by /sbin/init.
Whenever the result is more reliable ('forgetting' to start sshd on a
failed local non-root filesystem mount is one of 'features' of new
Solaris), or maintainable (yes, I always wanted to describe service
dependencies in xml) is subjective, of course.
And smf doesn't provide 'one true API' for service launch nor requires
services to be written in a specific way.
smf uses manifests to manage the ksh scripts, which are far more
simple that the pre-smf rc scripts; often just a case,start/stop/...
mini-script.
So the entire management and supervision of the scripts is done
through the manifests, which are new to smf. The fact that these
manifests are in xml sucks. This is where Scott and Lennart have
improved on both launchd and smf (by not using xml) and on smf (by
combining the control of the scripts and the scripts themselves with
exec or script,end script in an upstart config file and with
ExecStart=... in a service file.
Furthermore, the fact that Solaris uses /sbin/init doesn't mean that
it's using that of sysvinit. On Ubuntu, upstart uses its very own
/sbin/init.
Linux is playing catch-up
in this field and I'm glad that upstart and systemd are dragging it
out of the dark ages, even if it's kicking and screaming irrationally.
Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if
using good ol' sysvinit. So, Lennart fixed what wasn't broken in the
first place.
How can you say that sysvinit isn't broken? Did Scott and Lennart both
think sysvinit is perfect but I'm nonetheless going to develop
upstart/systemd; my employer won't mind my wasting my time on such a
project my distro in a more constructive way? Both upstart and
systemd were developed in order to improve on sysvinit.
From a user perspective: with sysvinit, you can't be sure when you
stop a daemon that it actually stops.
From a developer (and to a certain extent user/admin) perspective: the
following is taken from [1].
begin
I think it's painfully obvious if you compare an init script to an upstart
or systemd configuration file for a simple daemon like, say, my lbcd
package.
For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle). Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration. (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)
/end
[1] http://lists.debian.org/debian-devel/2013/10/msg01099.html
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOdo=sw_tj6uqq-dnaxlc3bf5wwnoj3bg1d0_+4r-ax4jha...@mail.gmail.com
Re: Init system deba{te|cle}
On Sun, Nov 3, 2013 at 9:23 AM, Marko Randjelovic marko...@eunet.rs wrote: On Sat, 02 Nov 2013 15:58:45 +0100 berenger.mo...@neutralite.org wrote: _ sysvinit scripts are scripts. Scripts needs programming skills, and the sh language does not have an easy to read syntax. I would in fact call it rather obscure compared to various other languages I used. Systemd configuration files are, real configuration files. Plain-text, no XML (this point is important for me), no script (this one too). Just some key-value associations. I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. System init scripts are not an admin task, they're a system task. Anyway, writing an upstart job or a systemd service is far simpler than writing a dash init script. Furthermore, if you want to do more than /path/to/executable parameters using either upstart or systemd, you can. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szcqoxevan6wtxrenp6mnp4jgz2purybzjto0bdnj2...@mail.gmail.com
Re: Init system deba{te|cle}
On Sun, Nov 3, 2013 at 9:33 AM, Marko Randjelovic marko...@eunet.rs wrote: On Tue, 29 Oct 2013 16:55:44 -0400 John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Decisions like changing such an essential part of OS should not be made in rush. It's not being done in a rush. This has been discussed at length on debian-devel a number of times in the last two years. SysVInit simply works. Symbolic links are a simple and natural way to control system startup. We have update-rc.d. And LSB tags provide protection for order of services. When you run systemctl enable sshd.service, symlinks to sshd.service are created in /etc/systemd/system/multi-user.target.wants/ so your simple and natural way to control system startup is still in effect in systemd. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Szx0YH2VR9ji48F5QG9_csGtOz_=kt8xtnzkyafty6...@mail.gmail.com
Re: Init system deba{te|cle}
On Sun, Nov 3, 2013 at 2:33 PM, Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? Also how many init scripts are admins editing or is this theoretical? And if it's to fix lacunas in the scripts shipped by Debian, are bug reports being filed for these scripts to be patched? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sw0mw2ddqo4vq54v97un4zkol1x6qc2drnkm80n8gb...@mail.gmail.com
Re: Init system deba{te|cle}
On 11/03/2013 10:41 AM, Reco wrote: On Sun, 3 Nov 2013 14:21:40 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if using good ol' sysvinit. So, Lennart fixed what wasn't broken in the first place. If that were so, why are people adopting it? I don't know why people adopting it. I only have an option about why distributions adapting systemd. IMO: Well, there are some nice features in systemd. It's easier to work with unit files over shell scripts. It's nice to write out how you want the system to manage services in a declarative style over an imperative one. Also, teh dependency/concurrency-based startup makes a properly set up systemd boot up a Linux system very fast. What's maybe not so nice is the journal. It's great to be able to search it, but I rather like not having my logs stored in a binary format for a feature that, while nice, might not see much use on my system. :/ I'd still rather be able to just open logs in a text editor and parse through myself. Fortunately systemd has no qualms about passing system events to stuff like syslog (And adds a few useful things to the logs to boot.) Fedora - because RedHat needs something enterprisey for their RHEL, and apparently upstart in RHEL6 doesn't cut it (being pet Canonical project and all that). Upstart has the right idea but the wrong implementation. You'd be hard set to see anyone care to use it outside of Ubuntuland and it's not just purely for the fact it's got ties to Canonical. I think the most classical example used is its dependency approach. Rather than bring up a service if another service calls for it, it brings up a service, then brings up EVERY LAST SERVICE IMAGINABLE THAT USES IT. Imagine what it's like to launch your network service and see sshd, httpd, telnetd, and a Minecraft server all launch because their configuration states they use the network service (Unless you disabled it.). That's how Upstart approaches dependency launching. Systemd is about trying to keep the number of services minimal to save memory and CPU for the user(s), not to mention minimizing boot times. Systemd works much the same way as launchd on OS X (That's what OS X's init is called, isn't it?). OpenSUSE - because Novell (assuming, of course, there's anybody left to make decisions after their sellover) needs something enterprisey for SLES, and their homegrown sysvinit doesn't cut it for some reason. I can't comment on their init. I used SLED for a time and found it unnecessarily cumbersome. ArchLinux - because they like to ship upstream projects unmodified and like to change things frequently. They ship GNOME - GNOME says 'use systemd' - they ship systemd. Nah. That's not why they did it. They actually went over the reasons on their forums and GNOME didn't really come up all that much. Primarily it was because sysvinit is not really all that nice. Its entire functionality relied on well-written shell scripts, and lots of them. Even the upstream maintainer, from what I understand, is not crazy about sysvinit anymore. Thing is, sysvinit, while it works and it is simple and tried and true, is a real dinosaur and, like X11, was designed for a different day with different needs. Being able to use an init system that's a lot more smart is a real plus. One goal that I definitely can appreciate is that systemd is meant to allow upstream developers of services to create units for it so that distribution maintainers don't have to do much extra work packaging them or someone building a service from source won't have to write scripts for it. This is not to say systemd doesn't have its issues. Unless you have a distribution that fully supports it, it's not going to be fun to use as you'll end up spending most your post-install time writing your own units for it as the distro might not have any (Or much.). Systemd is also large and complex. And some people also view the fact that Lennart Poettering is the guy behind it as a real negative (Not fans of Pulseaudio and Avahi, usually.). As I mentioned before, the journal is not readable outside of its tools which I don't like (The admin in me would rather things like configuration and logs be in plain text, which is one reason why I hate Windows.) Lots and lots of people were less than thrilled also with the udev merge (Gentoo developers seemed downright angry about it and are, last I checked (Though a while ago.) they were making their own udev fork.). Maybe one major downside is systemd uses very Linux kernel-specific features, which is what this thread was about, I think. systemd isn't really portable which to a lot of Linux fans is almost sacrilege. I personally don't have a problem with it since there are so few projects I know of that actually make specific use of Linux-exclusive functionality. Maybe they do so indirectly through
Re: Init system deba{te|cle}
On 11/04/2013 04:06 AM, berenger.mo...@neutralite.org wrote: Le 03.11.2013 10:23, Marko Randjelovic a écrit : On Sat, 02 Nov 2013 15:58:45 +0100 berenger.mo...@neutralite.org wrote: _ sysvinit scripts are scripts. Scripts needs programming skills, and the sh language does not have an easy to read syntax. I would in fact call it rather obscure compared to various other languages I used. Systemd configuration files are, real configuration files. Plain-text, no XML (this point is important for me), no script (this one too). Just some key-value associations. I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, Being a programmer does not imply to thinks as programming as an easy thing. I am also a programmer, and, I have no shame to say that I am not able to use all languages. For example, I can not use prolog effectively. Programming is more error-prone than real configuration files. A single typo can generate hard to debug problems, especially in non compiled languages, not to speak about lacks of strong typing. _ systemd configuration files can be shared between distributions more easily than sysvinit scripts. Thus, it is more portable across linux distributions. The work being centralized, it makes the package's maintainers needed to do less work. There is nothing more standard/portable in Unix-like systems then POSIX shell. Other have replied this better than I could. Another advantage it have, is that it is able to parallelize the start of daemons, and to only start daemons when they are first used. It is not an important feature on a server, but for desktops or laptops which are computers you can start lot of times in a day, it can save time. On that particular point, my opinion is that it is not the good solution: the good solution is to only start daemons you really need. I do not see 'start daemons when they are first used' is quite an important benefit Makes it faster to have a system you can use. There are probably other advantages like security: less things started, less security flaws. Not sure how this apply to systemd however. Portability have a cost, and it is often the lack of features or the need to reinvent the wheel on some targets but not on all. WxWidgets knows the problem I am talking about. I'd say the problem is in the lack of real effort to solve programming problems in an abstract way. Portability imply to limit yourself to the greatest common factor, or to implement lacking features on targets yourself. A non implemented feature can not be abstracted. And the last problem I can think about, is that it does things that are not only system initialization. It means that, by itself, it might become hard to maintain. I said might, because I never looked at sysvinit source code (since it is old, it could bet not so clean, having be maintained by lot of different people) not systemd's one (good software designs can make things damn easy to maintain, even when they do not do only one thing). and so, which would imply duplicate work. If Debian was a normal Linux distribution, then portability would not have been a problem. I don't see why Debian is not a normal Linux distibution and how is it related to portability Because it's not limited to linux kernel. There would still be the lack of UNIX philosophy, but, be honest: any distribution using Gnome, KDE or even XFCE as the default DE is already damn far from the UNIX philosophy. I have nothing against that, do not take me wrong, it is a choice. But using those DEs as defaults DE proves that this philosophy is not so important. I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. I can not agree more, however my point is that there are currently no DE implementing it. The closer to it I know about is LXDE, which still have small issues in this regard. Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. I'm interested. Do you have a document explaining that you need to use shell scripts with systemd? systemd supports shell scripts, but it's not because it have to, it is because it's authors wants and easy integration of existing stuff, AFAIK. LXDE, on the other hand, would be a better choice for a UNIX philosophy fan (better, not perfect, since UNIX philosophy imply that softwares discuss between them by text only, which can not really be easily done when you come to GUIs. I think that raw UNIX philosophy is not adapted to modern graphical uses, but this is a personal opinion which can be changed rather easily since I want to be wrong). I do not think UNIX philosophy is not wrong, I think users are wrong. Users want false impression of
Re: Init system deba{te|cle}
On 11/04/2013 10:22 AM, Tom H wrote: On Sun, Nov 3, 2013 at 2:33 PM, Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? Also how many init scripts are admins editing or is this theoretical? And if it's to fix lacunas in the scripts shipped by Debian, are bug reports being filed for these scripts to be patched? If they are talking about your work being overwritten by a change of the config file upstream,. I think just about every package manager under the sun actually alerts the user and tries to get them to resolve the change if they detect user modifications to the config. The argument seems specious to me. Admins make changes to system configs all the time, it's part of what they do. And package managers usually can tell if they are putting out configs that'd change what the admin made and (often) just save it to a side file and call attention to it. There's no reason they wouldn't do the same for unit files. Conrad -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5277d05a.5020...@marupa.net
Re: Init system deba{te|cle}
On Mon, 4 Nov 2013 15:43:36 + Tom H tomh0...@gmail.com wrote: smf uses manifests to manage the ksh scripts, which are far more simple that the pre-smf rc scripts; often just a case,start/stop/... mini-script. Solaris 11.1, more or less default non-X install. There're 17 scripts exceeding 10k in /lib/svc/method. Smallest script is 248 bytes, largest one is 41627 bytes. They must've put entire Shakespeare poetry in Solaris 9 in init scripts if they reduced them in Solaris 10. RHEL 5.9, non-X install. There're 2 scripts exceeding 10k in /etc/rc.d/init.d. Smallest script is 128 bytes, largest one is 14793 bytes. Debian 7.1, X install. There're 2 scripts exceeding 10k in /etc/init.d. Smallest script is 117 bytes, largest one is 18483 bytes. So the entire management and supervision of the scripts is done through the manifests, which are new to smf. The fact that these manifests are in xml sucks. This is where I agree with you. This is where Scott and Lennart have improved on both launchd and smf (by not using xml) and on smf (by combining the control of the scripts and the scripts themselves with exec or script,end script in an upstart config file and with ExecStart=... in a service file. Ok, good. But there's noticeable difference between ksh scripts smf uses and forking and execing binaries like system does. That difference is troubleshooting. Furthermore, the fact that Solaris uses /sbin/init doesn't mean that it's using that of sysvinit. On Ubuntu, upstart uses its very own /sbin/init. Smf respects /etc/inittab, systemd does not. If it takes to write /sbin/init replacement for such compatibility - I'm fine with that. If certain init does not respect this configuration file - that's bad. Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if using good ol' sysvinit. So, Lennart fixed what wasn't broken in the first place. How can you say that sysvinit isn't broken? Let me think… Because it's works most of the time? You know, it allows booting, starting and stopping services. It may be broken, but it's good enough. Did Scott and Lennart both think sysvinit is perfect but I'm nonetheless going to develop upstart/systemd; my employer won't mind my wasting my time on such a project my distro in a more constructive way? Yet their corresponding employers could view such 'time wasting' as an excellent opportunity to play a little vendor lock-in game. Both upstart and systemd were developed in order to improve on sysvinit. Their developers surely say so. I would be surprised if they'd say otherwise. Still, they must be correct in the case of RHEL sysvinit. That thing is a real mess imo. From a user perspective: with sysvinit, you can't be sure when you stop a daemon that it actually stops. True. But tell me, can systemd kill processes in the 'uninterruptable sleep' state (aka D-state)? Or, quickly unmount NFS filesystem mounted with 'hard' option even if NFS server is down? Can upstart do these wonders? From a developer (and to a certain extent user/admin) perspective: the following is taken from [1]. begin skipped rant about 'writing a script is hard' /end [1] http://lists.debian.org/debian-devel/2013/10/msg01099.html If that's the only problem, they could adopt, say, [2] without breaking anything else. [2] http://thomas.goirand.fr/blog/?p=147 Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131104205633.4488e176412ab96b3e823...@gmail.com
Re: Init system deba{te|cle}
On Sun, Nov 3, 2013 at 4:41 PM, Reco recovery...@gmail.com wrote: On Sun, 3 Nov 2013 14:21:40 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: I don't know why people adopting it. I only have an option about why distributions adapting systemd. IMO: Fedora - because RedHat needs something enterprisey for their RHEL, and apparently upstart in RHEL6 doesn't cut it (being pet Canonical project and all that). Fedora 9 switched to upstart and Fedora 15 switched to systemd. RHEL 6 is based on Fedora 12/13... RHEL 6 (as well as Fedora 9-14) use upstart's /sbin/init and a few upstart jobs. AFAIR, there are native jobs for setting up the ttys, launching plymouth, and parsing /proc/cmdline in order to run telinit runlevel and that's about it. sysvinit scripts launch everything else, via upstart. The only reason that I remember having seen for not switching more comprehensively to native upstart jobs is that if you have sysvinit script that depends on another sysvinit script and the latter's ported to an upstart job, the dependency breaks. Lennart gave a talk at this summer's DebConf. Two reasons for systemd stand out from that talk. 1) He described systemd as completely open source more than once, in a clear dig at Canonical's copyright-assignment-come-contributor-agreement for upstart. 2) He said (not his exact words) that we spoke to upstart upstream about some changes and they were rejected. ArchLinux - because they like to ship upstream projects unmodified and like to change things frequently. They ship GNOME - GNOME says 'use systemd' - they ship systemd. Arch decided that systemd was better than its implementation of sysvinit and rc. PS Not that I have anything against systemd. By the time I'll get my hands on it (be it next Debian stable, or RHEL7) they'll sure stabilize it somehow, write distribution-specific documentation and all that. There's no need for distribution-specific documentation. One of the goals of systemd is distribution-neutral system and service manager, with service files shipped by the various upstreams providing daemons. He even got some stick from some Red-Hatters/Fedorans for adopting Debian's /etc/hostname. :) The only documentation that you need are the man pages and Lennart's systemd for administrators blog series. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=syah93pjccpjndtaaolafm8klwkwfdvkahzywydohf...@mail.gmail.com
Re: Init system deba{te|cle}
On Mon, Nov 4, 2013 at 4:37 PM, Conrad Nelson y...@marupa.net wrote: On 11/03/2013 10:41 AM, Reco wrote: On Sun, 3 Nov 2013 14:21:40 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: Well, there are some nice features in systemd. It's easier to work with unit files over shell scripts. It's nice to write out how you want the system to manage services in a declarative style over an imperative one. Also, teh dependency/concurrency-based startup makes a properly set up systemd boot up a Linux system very fast. What's maybe not so nice is the journal. It's great to be able to search it, but I rather like not having my logs stored in a binary format for a feature that, while nice, might not see much use on my system. :/ I'd still rather be able to just open logs in a text editor and parse through myself. Fortunately systemd has no qualms about passing system events to stuff like syslog (And adds a few useful things to the logs to boot.) I agree with the last sentence. All you have to do is pay a visit to /etc/systemd/journald.conf and set Storage=none and ForwardToSyslog=yes (and have rsyslog running!). But journalctl is a wonderful tool (at least in IMO). Upstart has the right idea but the wrong implementation. You'd be hard set to see anyone care to use it outside of Ubuntuland and it's not just purely for the fact it's got ties to Canonical. I think the most classical example used is its dependency approach. Rather than bring up a service if another service calls for it, it brings up a service, then brings up EVERY LAST SERVICE IMAGINABLE THAT USES IT. Imagine what it's like to launch your network service and see sshd, httpd, telnetd, and a Minecraft server all launch because their configuration states they use the network service (Unless you disabled it.). That's the whole point of upstart events. If you don't want a network daemon to start when the network comes up, change it to manual with echo manual /etc/init/daemon.override. Aren't all these daemons brought up at boot (perhaps not simultaneoulsy) when you're using sysvinit unless you disable them? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szftsu_a61btnzy6yxuhiioqnys_a6azvbndgytrzx...@mail.gmail.com
Re: Init system deba{te|cle}
On Mon, Nov 4, 2013 at 4:50 PM, Conrad Nelson y...@marupa.net wrote: On 11/04/2013 10:22 AM, Tom H wrote: On Sun, Nov 3, 2013 at 2:33 PM, Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? Also how many init scripts are admins editing or is this theoretical? And if it's to fix lacunas in the scripts shipped by Debian, are bug reports being filed for these scripts to be patched? The argument seems specious to me. Admins make changes to system configs all the time, it's part of what they do. I've written (or helped a developer write) sysvinit scripts for home-grown apps but I'd be sacked if I made a change to a sysvinit script without showing that there's a technical problem with that script and without filing a bug report. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SyXbx4ZnrUUNePKDCxBtMf7_pwLKEPECNueUn0fkH=w...@mail.gmail.com
Re: Init system deba{te|cle}
On 11/04/2013 12:22 PM, Tom H wrote: On Mon, Nov 4, 2013 at 4:37 PM, Conrad Nelson y...@marupa.net wrote: On 11/03/2013 10:41 AM, Reco wrote: On Sun, 3 Nov 2013 14:21:40 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: Well, there are some nice features in systemd. It's easier to work with unit files over shell scripts. It's nice to write out how you want the system to manage services in a declarative style over an imperative one. Also, teh dependency/concurrency-based startup makes a properly set up systemd boot up a Linux system very fast. What's maybe not so nice is the journal. It's great to be able to search it, but I rather like not having my logs stored in a binary format for a feature that, while nice, might not see much use on my system. :/ I'd still rather be able to just open logs in a text editor and parse through myself. Fortunately systemd has no qualms about passing system events to stuff like syslog (And adds a few useful things to the logs to boot.) I agree with the last sentence. All you have to do is pay a visit to /etc/systemd/journald.conf and set Storage=none and ForwardToSyslog=yes (and have rsyslog running!). But journalctl is a wonderful tool (at least in IMO). Oh, it is. I think a better way to put what I mean is journalctl is great as long as it's still letting things like syslogd have a copy. Which is great because journalctl makes it pretty trivial to do exactly that. This way I can use whatever I want to look at logs, which is handy in a rescue situation. Unfortunately I don't have a lot of need to use jornalctl's nicer features. Upstart has the right idea but the wrong implementation. You'd be hard set to see anyone care to use it outside of Ubuntuland and it's not just purely for the fact it's got ties to Canonical. I think the most classical example used is its dependency approach. Rather than bring up a service if another service calls for it, it brings up a service, then brings up EVERY LAST SERVICE IMAGINABLE THAT USES IT. Imagine what it's like to launch your network service and see sshd, httpd, telnetd, and a Minecraft server all launch because their configuration states they use the network service (Unless you disabled it.). That's the whole point of upstart events. If you don't want a network daemon to start when the network comes up, change it to manual with echo manual /etc/init/daemon.override. Aren't all these daemons brought up at boot (perhaps not simultaneoulsy) when you're using sysvinit unless you disable them? In systemd, this would not be necessary, though. Systemd approaches it in the reverse way. It simply says, X service is required by Y service, therefore I'll start Y so X can use it. Once X is done, I'll go ahead and shut down Y to save memory and CPU time. Upstart, by default, says, X has been started. Since Y, Z, A, B, and C can use it, I'll go ahead and start those regardless of performance/memory impact or actual need for those services. And I don't think I'll bother shutting any of these down unless explicitly directed. Yes, you can change the configuration for those services, but the point is that it shouldn't be necessary to do so. A smart init shouldn't think that because a service is available EVERYTHING ELSE that depends on it needs to be run by default. This is why I think systemd is great and upstart is not. Upstart has the concept (Dependency-based event-driven service management.), but the execution of the concept is lacking. Sysvinit is worse, though, since its reliant on shell scripts to do virtually everything you'd think init should probably handle itself. There is perhaps a loss of flexibility in setting up a system configuration with systemd, but looking back at my time with Arch I realize that flexibility isn't really essential and the downsides weigh down sysvinit. Conrad -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5277ebfe.20...@marupa.net
Re: Init system deba{te|cle}
On Mon, 04 Nov 2013 10:37:51 -0600 Conrad Nelson y...@marupa.net wrote: Well, there are some nice features in systemd. It's easier to work with unit files over shell scripts. It's nice to write out how you want the system to manage services in a declarative style over an imperative one. Also, teh dependency/concurrency-based startup makes a properly set up systemd boot up a Linux system very fast. Good ol' chkconfig - that's easy. And its' replacement in systemd is called? Startup speed is irrelevant for me. I don't reboot servers that often (and when I do, 90% of the time it is the hardware initialize itself), and on desktops I use hibernate. What's maybe not so nice is the journal. It's great to be able to search it, but I rather like not having my logs stored in a binary format for a feature that, while nice, might not see much use on my system. :/ I'd still rather be able to just open logs in a text editor and parse through myself. Fortunately systemd has no qualms about passing system events to stuff like syslog (And adds a few useful things to the logs to boot.) And what about removing this journal thing? I mean, if it inferior to rsyslog, why bother keeping it (or installing it in the first place)? Fedora - because RedHat needs something enterprisey for their RHEL, and apparently upstart in RHEL6 doesn't cut it (being pet Canonical project and all that). Upstart has the right idea but the wrong implementation. You'd be hard set to see anyone care to use it outside of Ubuntuland and it's not just purely for the fact it's got ties to Canonical. Um. RHEL6, OEL6, CentOS6, Scientific Linux 6. I think the most classical example used is its dependency approach. Rather than bring up a service if another service calls for it, it brings up a service, then brings up EVERY LAST SERVICE IMAGINABLE THAT USES IT. Imagine what it's like to launch your network service and see sshd, httpd, telnetd, and a Minecraft server all launch because their configuration states they use the network service (Unless you disabled it.). That's how Upstart approaches dependency launching. That's simply terrible. Systemd is about trying to keep the number of services minimal to save memory and CPU for the user(s), not to mention minimizing boot times. Systemd works much the same way as launchd on OS X (That's what OS X's init is called, isn't it?). So, they're reverting to good ol' inetd days. Hardly an innovation, but may be useful to someone. OpenSUSE - because Novell (assuming, of course, there's anybody left to make decisions after their sellover) needs something enterprisey for SLES, and their homegrown sysvinit doesn't cut it for some reason. I can't comment on their init. I used SLED for a time and found it unnecessarily cumbersome. Basically these guys came with the idea of parallel dependency-based boot (Debian started to use the same approach couple of years later), and managed not to break sysvinit THAT much by implementing that idea. ArchLinux - because they like to ship upstream projects unmodified and like to change things frequently. They ship GNOME - GNOME says 'use systemd' - they ship systemd. Nah. That's not why they did it. They actually went over the reasons on their forums and GNOME didn't really come up all that much. Primarily it was because sysvinit is not really all that nice. Its entire functionality relied on well-written shell scripts, and lots of them. I still fail to understand why sysvinit shell-scripts are bad, yet, when used by systemd they suddenly became good. Even the upstream maintainer, from what I understand, is not crazy about sysvinit anymore. Thing is, sysvinit, while it works and it is simple and tried and true, is a real dinosaur and, like X11, was designed for a different day with different needs. And working drop-in replacement for X is …? And unless it cannot run that Motif app written 15 years ago it doesn't count. And if it has problems with Java's Swing it doesn't count too. Being able to use an init system that's a lot more smart is a real plus. One goal that I definitely can appreciate is that systemd is meant to allow upstream developers of services to create units for it so that distribution maintainers don't have to do much extra work packaging them or someone building a service from source won't have to write scripts for it. Wait. Upstream developer writes a daemon, yet somehow it never occurs to him (or her, irrelevant) that such daemon needs to be actually started. The very existence of systemd somehow tells this guy 'hey, you'll need to write systemd unit'. Does not compute. Either developer writes something that allows daemon to be started (be it script, upstart job or systemd unit), or not. This is not to say systemd doesn't have its issues. Unless you have a distribution that fully supports it, it's not going to be fun to use as you'll
Re: Init system deba{te|cle}
On Mon, 4 Nov 2013 17:21:48 + Tom H tomh0...@gmail.com wrote: RHEL 6 (as well as Fedora 9-14) use upstart's /sbin/init and a few upstart jobs. AFAIR, there are native jobs for setting up the ttys, launching plymouth, and parsing /proc/cmdline in order to run telinit runlevel and that's about it. sysvinit scripts launch everything else, via upstart. And that's a good thing. Changing things way too much scares customers. Lennart gave a talk at this summer's DebConf. Two reasons for systemd stand out from that talk. 1) He described systemd as completely open source more than once, in a clear dig at Canonical's copyright-assignment-come-contributor-agreement for upstart. Meaning 'you can watch, but you cannot touch'? Thanks, I prefer free software to opensource one. 2) He said (not his exact words) that we spoke to upstart upstream about some changes and they were rejected. This can mean anything. Unless said changes were described, of course. ArchLinux - because they like to ship upstream projects unmodified and like to change things frequently. They ship GNOME - GNOME says 'use systemd' - they ship systemd. Arch decided that systemd was better than its implementation of sysvinit and rc. True. And what was the reason for this 'better'? PS Not that I have anything against systemd. By the time I'll get my hands on it (be it next Debian stable, or RHEL7) they'll sure stabilize it somehow, write distribution-specific documentation and all that. There's no need for distribution-specific documentation. One of the goals of systemd is distribution-neutral system and service manager, with service files shipped by the various upstreams providing daemons. He even got some stick from some Red-Hatters/Fedorans for adopting Debian's /etc/hostname. :) OOPS. Wrong. I use ifupdown. How exactly transition to systemd affects me? I have these nice entries in /etc/fstab. How exactly transition to systemd affects me? I have these tested-and-verified values in /etc/sysctl.conf. How exactly transition to systemd affects me? I have this rsyslog that sends syslog messages to the central server. How exactly transition to systemd affects me? Now, of course, it can be done Fedora-style: we break things twice a year and cannot hear your screams. It can be done ArchLinux-style: we change things every day, don't update unless you've read our wiki. But in Debian stable they usually write release notes and document all things that changed since the last stable release. The only documentation that you need are the man pages and Lennart's systemd for administrators blog series. Man pages describe intended behaviour usually, not implementation restrictions. How many systemd releases came since this 'Lennart's systemd for administrators blog series' was published? Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105011548.8f1a1e35736d06415099b...@gmail.com
Re: Init system deba{te|cle}
On Mon, 4 Nov 2013 15:06:50 + Tom H tomh0...@gmail.com wrote: Well, whoever he is, he raises some valid questions. Such as - what logind are supposed to do? Why bother keeping unrelated projects in systemd git? He's a Gentoo developer who might be involved in OpenRC development (he's not its Gentoo maintainer). logind is a replacement of ConsoleKit, which is now dead upstream (and has been for one or two years). OK. And why does one needed to use ConsoleKit? Seriously, I've never installed it and may miss something. On my (Ubuntu) laptop: [root@lenovo15]# loginctl list-sessions SESSIONUID USER SEAT c1124 dirmngr seat0 c2 1000 th seat0 2 sessions listed. [root@lenovo15]# loginctl list-users UID USER 124 dirmngr 1000 th 2 users listed. [root@lenovo15]# loginctl list-seats SEAT seat0 1 seats listed. Neat, but I can do the same and more with good old 'w'. Its role is the tracking and management of user sessions. Now it gets better. How do I, say, kill a user session with systemd? Or logind tools for that matter? What about ssh logins? That somehow extends into power management and the first dependency of GNOME on systemd (that I know of) was of the power module of gnome-settings-daemon in GNOME 3.8. And what does that 'power module' do? Does it changes CPU frequency (that's kernel job btw, no userspace required)? Does it put a laptop to sleep (handled by acpid without external assistance usually)? If the Ubuntu developers who've already split logind from systemd up to v204 throw up their hands and say it can't be done for v205+, then I'll believe it... Not that I'm in hurry too :) You might not be in a hurry but I'm sure that there are Debian users and developers who'd like to see GNOME depend on logind rather than on systemd. If that's means there will be less dependencies for GNOME, count me in. But I meant something different: I'm just a Debian user, not a DM or DD. I can replace init with anything they put in Debian archive, but on my hosts only. I cannot decide what will be put in the Debian archive, or what users will get by default. So, I wait till next Debian stable comes out, and then I'll see what they put there. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105013206.22f2bca4798da1f108312...@gmail.com
Re: Init system deba{te|cle}
On Sat, 02 Nov 2013 15:58:45 +0100 berenger.mo...@neutralite.org wrote: _ sysvinit scripts are scripts. Scripts needs programming skills, and the sh language does not have an easy to read syntax. I would in fact call it rather obscure compared to various other languages I used. Systemd configuration files are, real configuration files. Plain-text, no XML (this point is important for me), no script (this one too). Just some key-value associations. I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. _ systemd configuration files can be shared between distributions more easily than sysvinit scripts. Thus, it is more portable across linux distributions. The work being centralized, it makes the package's maintainers needed to do less work. There is nothing more standard/portable in Unix-like systems then POSIX shell. Another advantage it have, is that it is able to parallelize the start of daemons, and to only start daemons when they are first used. It is not an important feature on a server, but for desktops or laptops which are computers you can start lot of times in a day, it can save time. On that particular point, my opinion is that it is not the good solution: the good solution is to only start daemons you really need. I do not see 'start daemons when they are first used' is quite an important benefit and start in parallel is already supported by sysvinit (startpar). Portability have a cost, and it is often the lack of features or the need to reinvent the wheel on some targets but not on all. WxWidgets knows the problem I am talking about. I'd say the problem is in the lack of real effort to solve programming problems in an abstract way. And the last problem I can think about, is that it does things that are not only system initialization. It means that, by itself, it might become hard to maintain. I said might, because I never looked at sysvinit source code (since it is old, it could bet not so clean, having be maintained by lot of different people) not systemd's one (good software designs can make things damn easy to maintain, even when they do not do only one thing). and so, which would imply duplicate work. If Debian was a normal Linux distribution, then portability would not have been a problem. I don't see why Debian is not a normal Linux distibution and how is it related to portability There would still be the lack of UNIX philosophy, but, be honest: any distribution using Gnome, KDE or even XFCE as the default DE is already damn far from the UNIX philosophy. I have nothing against that, do not take me wrong, it is a choice. But using those DEs as defaults DE proves that this philosophy is not so important. I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. This will make many people unable to solve their system startup problems and force them pay money to big companies, which is in essence what big companies want. Debian should not put interests of big companies above interests of its users. LXDE, on the other hand, would be a better choice for a UNIX philosophy fan (better, not perfect, since UNIX philosophy imply that softwares discuss between them by text only, which can not really be easily done when you come to GUIs. I think that raw UNIX philosophy is not adapted to modern graphical uses, but this is a personal opinion which can be changed rather easily since I want to be wrong). I do not think UNIX philosophy is not wrong, I think users are wrong. Users want false impression of power and that only makes them dependent on the software that makes them such an illusion, similar to effect of narcotics. Look what RMS says about companies want to control their users with software. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103102302.42493...@eunet.rs
Re: Init system deba{te|cle}
On Tue, 29 Oct 2013 16:55:44 -0400 John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? I am sure this is not urgent, Gnome should not be default DE and even they could easily just make two (or more) DE options in installer. XFCE4 is on Wheezy DVD-1. Decisions like changing such an essential part of OS should not be made in rush. With systemd, your system cannot start without DBus to coordinate processes. This makes early system startup to complicated. You cannot start your system w/o DBus installed and working. This can also make problems to small/embedded systems because of increased storage/memory consumption. SysVInit simply works. Symbolic links are a simple and natural way to control system startup. We have update-rc.d. And LSB tags provide protection for order of services. We should just improve our startup scripts, instead of adapting everything to systemd. We would have to learn syntax and way of usage of systemd, and for additional flexibility we would have to use shell scripts anyway. I do not see enough reasons for Gnome to depend on systemd, other than forcing us to switch to systemd for interests of big corporations. -- http://mr.flossdaily.org signature.asc Description: PGP signature
Re: Init system deba{te|cle}
On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if using good ol' sysvinit. So, Lennart fixed what wasn't broken in the first place. If that were so, why are people adopting it? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103142140.ga19...@bryant.redmars.org
Re: Init system deba{te|cle}
On Sun, 03 Nov 2013, Marko Randjelovic wrote: and so, which would imply duplicate work. If Debian was a normal Linux distribution, then portability would not have been a problem. I don't see why Debian is not a normal Linux distibution and how is it related to portability Debian is not just a Linux distribution anymore due to Debian GNU/kFreeBSD, and FreeBSD support *is* a big deal re. portability issues. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103142847.ga5...@khazad-dum.debian.net
Re: Init system deba{te|cle}
On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote: I find shell scripts the most efficient way to automate system adin tasks. It could be because I am a programmer, but at least init scripts are already provided, and small modifications should not be a problem even for non-programmers. For new scripts you have 'skeleton' file that can be easily adjusted for a particular work. Amongst other problems, how do you (or the package system) reconcile when you have made a local modification to an init script and the upstream package has made another in an update? There is nothing more standard/portable in Unix-like systems then POSIX shell. …which wasn't fully supported on Solaris 9 so you had to use a subset (e.g. no $(subshell) syntax). Writing truly portable shell scripts across multiple UNIX families was a terrible pain and one could not simply rely on the POSIX feature-set. I know this from bitter experience. I suspect C89 is/was more portable in practice, but the point OP is making here isn't the scripting language, for portability, it's the fact init scripts do little to abstract the differences between OSes, so portable init scripts are very hard to achieve. E.g. Debian uses /etc/default for overrides, Redhat-esque systems use various schemes under /etc/sysconfig; various init scripts are written with the assumption sh → bash which required a lot of fixing up when Debian and Ubuntu moved to a different default sh; and on and on. Such OS layout specifics being baked into init scripts also make it much harder to make changes, since you break a load of init scripts when the assumptions they rely on change. This is why it's not just systemd that is trying to replace shell scripts: nearly all the next-gen init systems do (launchd, upstart, openrc… even smf with its XML). I do not see 'start daemons when they are first used' is quite an important benefit and start in parallel is already supported by sysvinit (startpar). Some people like socket activation a lot (which is why inetd was used to achieve this in the past) I don't think UNIX philosophy is not so important. First of all, the principle of all-might is by nature authoritarian. All-in-one solutions are a characteristic of big companies that want to impress their users, while not giving them enough real benefit. It's a principle near and dear to much of the rest of our F/OSS stack, however. The Linux kernel is monolithic (and enormous) rather than a microkernel. GLibc is enormous rather than a family of smaller libraries. And so on. Systemd makes system startup more complicated and you need to know not only shell scripts but also systemd syntax. This will make many people unable to solve their system startup problems If you are considering the hypothetical novice user above (I think you are, correct me if I'm wrong), then in the systemd world such a user does not need to understand shell scripts to tweak or resolve system startup problems, only the systemd syntax. and force them pay money to big companies, which is in essence what big companies want. Debian should not put interests of big companies above interests of its users. Which big company will accept my money to fix a startup problem for me? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103143327.gb19...@bryant.redmars.org
Re: Init system deba{te|cle}
On 03.Nov.2013, at 10:33, Marko Randjelovic wrote: On Tue, 29 Oct 2013 16:55:44 -0400 John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? I am sure this is not urgent, Gnome should not be default DE and even they could easily just make two (or more) DE options in installer. XFCE4 is on Wheezy DVD-1. Decisions like changing such an essential part of OS should not be made in rush. This is wise. Put in other words: If you do not know what to do, do nothing. I do not see enough reasons for Gnome to depend on systemd, other than forcing us to switch to systemd for interests of big corporations. Who knows? http://en.wikipedia.org/wiki/Lennart_Poettering (the one that wrote systemd) tells us Poettering is a long term contributor of the GNOME project, a GNOME Foundation member and... -- Markus -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1d5d8055-d172-47c3-a9d5-6f8c49cca...@gmail.com
Re: Init system deba{te|cle}
On Sun, 3 Nov 2013 14:21:40 + Jonathan Dowland j...@debian.org wrote: On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote: Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if using good ol' sysvinit. So, Lennart fixed what wasn't broken in the first place. If that were so, why are people adopting it? I don't know why people adopting it. I only have an option about why distributions adapting systemd. IMO: Fedora - because RedHat needs something enterprisey for their RHEL, and apparently upstart in RHEL6 doesn't cut it (being pet Canonical project and all that). OpenSUSE - because Novell (assuming, of course, there's anybody left to make decisions after their sellover) needs something enterprisey for SLES, and their homegrown sysvinit doesn't cut it for some reason. ArchLinux - because they like to ship upstream projects unmodified and like to change things frequently. They ship GNOME - GNOME says 'use systemd' - they ship systemd. Did I miss some more-or-less important distribution that already moved to systemd? PS Not that I have anything against systemd. By the time I'll get my hands on it (be it next Debian stable, or RHEL7) they'll sure stabilize it somehow, write distribution-specific documentation and all that. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103204113.8b66aaf8740e7fc6127cc...@gmail.com
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 1:42 AM, berenger.mo...@neutralite.org wrote: Le 01.11.2013 20:01, Tom H a écrit : On Thu, Oct 31, 2013 at 8:58 PM, berenger.mo...@neutralite.org wrote: Le 31.10.2013 21:06, André Nunes Batista a écrit : On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. If it's the Debian's GNOME maintainers' choice, how come GNOME depends on systemd in Gentoo? It seems I was wrong, but if I were not, then, it could be because it's simpler with that choice. As I said up-thread, it's a question of decoupling logind from systemd. The Gentoo GNOME developers decided that it was simpler for them not to do so. Given its attachment to upstart, Ubuntu must be planning to keep on doing so; but Lennart and co might make it increasingly difficult (not necessarily - and most likely not - through malice!) so it may not be the best long-term strategy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szgm45ihx4imoaa-yub5f2_r-f-n5xe2ep_xvps0dk...@mail.gmail.com
Re: Init system deba{te|cle}
On Wed, Oct 30, 2013 at 5:55 AM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Probably not. At least, it seems incomprehensible to me why there should even be a debate. Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? I don't even think that has much to do with it. Couldn't we just make XFCE the temporary default and stay with sysvinit until the technical dust has settled and we have a clearer view of the long-term merits of openrc, systemd, and upstart? Lots of reasons to take Gnome's default deskstop status away, but the gratuitous dependency on systemd is a good one. I'm not close to DD status, so reluctant to ask on -devel. I don't fit any of the categories of that debate: I find your description of the beligerents interesting. 1) systemd advocates with few reservations about forcing their way, 2) near-adolescent emotional responses to anything that looks like forcing. Luckily there have been a few posts by 3) sensible and emotionally moderate folks; it's reassuring to see how many of them also hold office in Debian. But still, I'd like to understand. Me, too, although I have some observations. If you haven't been reading -devel, an overview can be found here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 and here https://wiki.debian.org/Debate/initsystem. -- johnrchamp...@wowway.com GPG key 1024D/99421A63 2005-01-05 EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63 gpg --keyserver subkeys.pgp.net --recv-keys 99421A63 I'm a former Fedora user. Got my start on MkLinux and openBSD, but the companies I worked for seemed to think the commercial support approach from Red Hat was more in line with what they needed, so I shifted to Red Hat and followed that line to Fedora. Around Fedora 11 or 13 I became aware of the talk about upstart, then suddenly there was this announcement, around Fedora 14: Rawhide had switched to systemd. No one seemed to think it necessary to bother with setting up a parallel track and isolate the community from the bumps. Lennart's way or the highway. Good engineers don't do that. When you rip out a piece like the init system and replace it with something highly experimental like systemd, you set up a parallel track. Unless you don't care what happens to your community. I did a small bit of research, started wondering if there was something hidden that might involve certain parties who think they have reason to attempt to submarine the Linux community. Took my concerns and technical questions to the dev list over there and got put on the moderator's list. Anything even slightly controversial that I try to ask over there just doesn't even make it to the list. Did get one or two replies that my posts were waiting moderation. And no good technical reasons, just that the traditional system was too complicated. Shutdown -h becomes systemctl halt or some such. apachectl stop/start/graceful, etc.? Now arcane parameters to the systemctl stop/start/? service-something-or-other. Arcane parameters to systemctl's new, undocumented (man pages way behind) commands and parameters. The only way to find out was to guess or ask on the list and hope someone who know was hanging around, or read the current code. I'm repeating myself, but good engineers don't do that. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43inkc56czeq84tbm8n+yuot9wtbrl1ofkzk_afanvbp...@mail.gmail.com
Re: Init system deba{te|cle}
Hi. On Sat, 2 Nov 2013 12:09:51 + Tom H tomh0...@gmail.com wrote: As I said up-thread, it's a question of decoupling logind from systemd. The Gentoo GNOME developers decided that it was simpler for them not to do so. Given its attachment to upstart, Ubuntu must be planning to keep on doing so; but Lennart and co might make it increasingly difficult (not necessarily - and most likely not - through malice!) so it may not be the best long-term strategy. According to this man pulling out logind from systemd is not valid strategy. Writing independent logind is not a valid strategy too: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131102181657.fbb0428ef863d39604fd9...@gmail.com
Re: Init system deba{te|cle}
Le 02.11.2013 13:09, Tom H a écrit : On Sat, Nov 2, 2013 at 1:42 AM, berenger.mo...@neutralite.org wrote: Le 01.11.2013 20:01, Tom H a écrit : On Thu, Oct 31, 2013 at 8:58 PM, berenger.mo...@neutralite.org wrote: Le 31.10.2013 21:06, André Nunes Batista a écrit : On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. If it's the Debian's GNOME maintainers' choice, how come GNOME depends on systemd in Gentoo? It seems I was wrong, but if I were not, then, it could be because it's simpler with that choice. As I said up-thread, it's a question of decoupling logind from systemd. The Gentoo GNOME developers decided that it was simpler for them not to do so. Given its attachment to upstart, Ubuntu must be planning to keep on doing so; but Lennart and co might make it increasingly difficult (not necessarily - and most likely not - through malice!) so it may not be the best long-term strategy. Yes, I agree on the wrong long-term strategy. Now, I wonder. Gnome was said portable, am I wrong? If they now have a hard dependency on systemd, they can no longer be considered portable, since systemd is itself only targeting linux kernels (and this is fine, since they do not claim to be portable)? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5f8f39d36377af92146bb141a09ac...@neutralite.org
Re: Init system deba{te|cle}
Le 02.11.2013 13:23, Joel Rees a écrit : On Wed, Oct 30, 2013 at 5:55 AM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Probably not. At least, it seems incomprehensible to me why there should even be a debate. Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? I don't even think that has much to do with it. Couldn't we just make XFCE the temporary default and stay with sysvinit until the technical dust has settled and we have a clearer view of the long-term merits of openrc, systemd, and upstart? Lots of reasons to take Gnome's default deskstop status away, but the gratuitous dependency on systemd is a good one. I'm not close to DD status, so reluctant to ask on -devel. I don't fit any of the categories of that debate: I find your description of the beligerents interesting. 1) systemd advocates with few reservations about forcing their way, 2) near-adolescent emotional responses to anything that looks like forcing. Luckily there have been a few posts by 3) sensible and emotionally moderate folks; it's reassuring to see how many of them also hold office in Debian. But still, I'd like to understand. Me, too, although I have some observations. If you haven't been reading -devel, an overview can be found here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 and here https://wiki.debian.org/Debate/initsystem. -- johnrchamp...@wowway.com GPG key 1024D/99421A63 2005-01-05 EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63 gpg --keyserver subkeys.pgp.net --recv-keys 99421A63 I'm a former Fedora user. Got my start on MkLinux and openBSD, but the companies I worked for seemed to think the commercial support approach from Red Hat was more in line with what they needed, so I shifted to Red Hat and followed that line to Fedora. Around Fedora 11 or 13 I became aware of the talk about upstart, then suddenly there was this announcement, around Fedora 14: Rawhide had switched to systemd. No one seemed to think it necessary to bother with setting up a parallel track and isolate the community from the bumps. Lennart's way or the highway. Good engineers don't do that. When you rip out a piece like the init system and replace it with something highly experimental like systemd, you set up a parallel track. Unless you don't care what happens to your community. I did a small bit of research, started wondering if there was something hidden that might involve certain parties who think they have reason to attempt to submarine the Linux community. Took my concerns and technical questions to the dev list over there and got put on the moderator's list. Anything even slightly controversial that I try to ask over there just doesn't even make it to the list. Did get one or two replies that my posts were waiting moderation. And no good technical reasons, just that the traditional system was too complicated. Shutdown -h becomes systemctl halt or some such. apachectl stop/start/graceful, etc.? Now arcane parameters to the systemctl stop/start/? service-something-or-other. Arcane parameters to systemctl's new, undocumented (man pages way behind) commands and parameters. The only way to find out was to guess or ask on the list and hope someone who know was hanging around, or read the current code. I'm repeating myself, but good engineers don't do that. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. I do not know all technical advantages of systemd, but the less complex you deny have more deep that using it from commandline. It is less complex for maintainers: _ sysvinit scripts are scripts. Scripts needs programming skills, and the sh language does not have an easy to read syntax. I would in fact call it rather obscure compared to various other languages I used. Systemd configuration files are, real configuration files. Plain-text, no XML (this point is important for me), no script (this one too). Just some key-value associations. _ systemd configuration files can be shared between distributions more easily than sysvinit scripts. Thus, it is more portable across linux distributions. The work being centralized, it makes the package's maintainers needed to do less work. Another advantage it have, is that it is able to parallelize the start of daemons, and to only start daemons when they are first used. It is not an important feature on a server, but for desktops or laptops which are computers you can start lot of times in a day, it can save time. On that particular point, my opinion is that it is not the good solution: the good solution is to only start daemons you really need. Now, it have it's problems: it is not portable, because it depends on certain linux specific
Re: Init system deba{te|cle}
On Saturday, November 02, 2013 08:23:45 AM Joel Rees wrote: I'm repeating myself, but good engineers don't do that. No, they don't. They prepare new footings and pour a new foundation before moving the house to the new location. It's nice to know I haven't misperceived the situation. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201311021228.39675.neal.p.mur...@alum.wpi.edu
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 12:23 PM, Joel Rees joel.r...@gmail.com wrote: I'm a former Fedora user. Got my start on MkLinux and openBSD, but the companies I worked for seemed to think the commercial support approach from Red Hat was more in line with what they needed, so I shifted to Red Hat and followed that line to Fedora. Around Fedora 11 or 13 I became aware of the talk about upstart, then suddenly there was this announcement, around Fedora 14: Rawhide had switched to systemd. No one seemed to think it necessary to bother with setting up a parallel track and isolate the community from the bumps. Lennart's way or the highway. This is nonsense. Fedora 14 was slated to default to systemd but at the last minute, FESCO decided not to go ahead with systemd and the init system change was reverted; to upstart not to sysvinit. So there was a fallback... Fedora prides itself on being a bleeding-edge distribution and it takes risks. Sometimes the risks that it takes are too much of a gamble. Fedora 18 was about two months late because the anaconda developers chose to change both the frontend and the backend of the installer without a fallback to the Fedora 17 installer (because they didn't have the resources to maintain both the old and the new code). Good engineers don't do that. When you rip out a piece like the init system and replace it with something highly experimental like systemd, you set up a parallel track. Unless you don't care what happens to your community. I did a small bit of research, started wondering if there was something hidden that might involve certain parties who think they have reason to attempt to submarine the Linux community. Took my concerns and technical questions to the dev list over there and got put on the moderator's list. Anything even slightly controversial that I try to ask over there just doesn't even make it to the list. Did get one or two replies that my posts were waiting moderation. And no good technical reasons, just that the traditional system was too complicated. Misrepresenting what systemd is and the reasons for its existence doesn't make sense: http://0pointer.de/blog/projects/systemd.html OS X and Solaris switched to launchd and smf respectively in 2005 and, to borrow an expression from Asterix and Obelix, the sky didn't fall on their heads. Modern nix systems need a more sophisticated /sbin/init and associated executables and they need (and have needed for a long time) something more reliable and maintainable than a bunch of dash/bash scripts to bring the system up. Linux is playing catch-up in this field and I'm glad that upstart and systemd are dragging it out of the dark ages, even if it's kicking and screaming irrationally. Shutdown -h becomes systemctl halt or some such. apachectl stop/start/graceful, etc.? Now arcane parameters to the systemctl stop/start/? service-something-or-other. Arcane parameters to systemctl's new, undocumented (man pages way behind) commands and parameters. The only way to find out was to guess or ask on the list and hope someone who know was hanging around, or read the current code. I'm repeating myself, but good engineers don't do that. You can use shutdown ... and systemctl halt/systemctl poweroff, as well as apachectl There was a problem in the run-up to Fedora 14 in that the systemd-supplied shutdown didn't understand traditional switches and it was patched within a few days of a bug report being filed. I don't understand your complaint about documentation because systemd/systemctl are unusually well documented; and were so from the very beginning. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=syu9zu8zevvdmc6+4ad9dvsjqyrasi67n+dtxa7q5i...@mail.gmail.com
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 2:16 PM, Reco recovery...@gmail.com wrote: On Sat, 2 Nov 2013 12:09:51 + Tom H tomh0...@gmail.com wrote: As I said up-thread, it's a question of decoupling logind from systemd. The Gentoo GNOME developers decided that it was simpler for them not to do so. Given its attachment to upstart, Ubuntu must be planning to keep on doing so; but Lennart and co might make it increasingly difficult (not necessarily - and most likely not - through malice!) so it may not be the best long-term strategy. According to this man pulling out logind from systemd is not valid strategy. Writing independent logind is not a valid strategy too: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt I don't trust this guy. He's generally very abrasive and very aggressive. He joined or started a debian-devel thread on init systems and tried to convince people that openrc was the solution to Debian's prayers. It was the sales pitch from hell! He's especially unreliable when it comes to systemd. If the Ubuntu developers who've already split logind from systemd up to v204 throw up their hands and say it can't be done for v205+, then I'll believe it... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sydzcvlmzufmq82t0qqgsw_tot1w3vhiz5ykmddehz...@mail.gmail.com
Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 2:30 PM, berenger.mo...@neutralite.org wrote: Now, I wonder. Gnome was said portable, am I wrong? If they now have a hard dependency on systemd, they can no longer be considered portable, since systemd is itself only targeting linux kernels (and this is fine, since they do not claim to be portable)? GNOME is portable because there are porters willing to do the work. If they quit because the work's too time-comsuming or impossible, it'll stop being portable. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwyP65ptY1krbMJsW1m-4L=kvcrtljykfhhtxox9x3...@mail.gmail.com
Re: Init system deba{te|cle}
On Sat, 2 Nov 2013 21:23:01 + Tom H tomh0...@gmail.com wrote: On Sat, Nov 2, 2013 at 2:16 PM, Reco recovery...@gmail.com wrote: I don't trust this guy. He's generally very abrasive and very aggressive. He joined or started a debian-devel thread on init systems and tried to convince people that openrc was the solution to Debian's prayers. It was the sales pitch from hell! He's especially unreliable when it comes to systemd. Well, whoever he is, he raises some valid questions. Such as - what logind are supposed to do? Why bother keeping unrelated projects in systemd git? If the Ubuntu developers who've already split logind from systemd up to v204 throw up their hands and say it can't be done for v205+, then I'll believe it... Not that I'm in hurry too :) Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131103014538.0db7c798e736077f2adc2...@gmail.com
Re: Init system deba{te|cle}
On Sat, 2 Nov 2013 21:08:29 +
Tom H tomh0...@gmail.com wrote:
Misrepresenting what systemd is and the reasons for its existence
doesn't make sense:
http://0pointer.de/blog/projects/systemd.html
OS X and Solaris switched to launchd and smf respectively in 2005 and,
to borrow an expression from Asterix and Obelix, the sky didn't fall
on their heads. Modern nix systems need a more sophisticated
/sbin/init and associated executables and they need (and have needed
for a long time) something more reliable and maintainable than a bunch
of dash/bash scripts to bring the system up.
I've never seen (nor intend to) launchd, but I'm familiar with smf.
And while in Solaris the sky didn't fall on their heads indeed, smf
uses ksh scripts for actual launch, check and re-start services like no
tomorrow. And Solaris's svc.startd is actually started by /sbin/init.
Whenever the result is more reliable ('forgetting' to start sshd on a
failed local non-root filesystem mount is one of 'features' of new
Solaris), or maintainable (yes, I always wanted to describe service
dependencies in xml) is subjective, of course.
And smf doesn't provide 'one true API' for service launch nor requires
services to be written in a specific way.
Linux is playing catch-up
in this field and I'm glad that upstart and systemd are dragging it
out of the dark ages, even if it's kicking and screaming irrationally.
Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if
using good ol' sysvinit. So, Lennart fixed what wasn't broken in the
first place.
Reco
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131103020606.0e3c3157645ebc412abe5...@gmail.com
Re: Init system deba{te|cle}
Hi. On Fri, 01 Nov 2013 15:35:40 +0100 berenger.mo...@neutralite.org wrote: Le 01.11.2013 10:23, Reco a écrit : On Thu, Oct 31, 2013 at 09:58:26PM +0100, berenger.mo...@neutralite.org wrote: That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. One of GNOME developers says that: http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that. Which means that GDM under OpenRC would leave lingering processes around, making it impossible to restart/shutdown GDM properly. Debian GNOME packagers are planning the same AFAIK; they rather just rely on systemd … So, Debian maintainers had a choice: make systemd an dependency to GDM. Or, ship GDM that behaves funny. So the problem is that only systemd which is able to manage daemon's lives? I mean, if another tools was able (maybe upstart or any other, I have no idea if one does the same thing) to control daemons' lives, it could be used instead of systemd without any problem? For this specific daemon - yes, it's can be managed correctly by systemd only. At least, the man says so. The reason is (the way I see it) - GDM is now designed with systemd in mind, it does nothing to cleanup after itself. You use anything other than systemd to start GDM, try to stop GDM - it leaves gdm* processes. No other daemon known to me behaves like that. PS: was it intended to send that reply only to me and not to the list? OOPS. No, it was intended for the list. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131101200725.fb57b47135652659a072a...@gmail.com
Re: Init system deba{te|cle}
On Thu, Oct 31, 2013 at 8:06 PM, André Nunes Batista andrenbati...@gmail.com wrote: On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? It's not a question of need; some people like/prefer GNOME. Part of the discussion and a possbile solution is ensure that a DE doesn't depend on a se=pecific init. It's silly to dismiss GNOME-Shell and Unity as tablet-targeted interfaces when Apple's been using essentially the same interface for 13 years, long before iPads, iPhones, and touch iPods. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sxbkfjjtzlgb1pzesztdb2kzmhuzvw5qamnqwygwvj...@mail.gmail.com
Re: Init system deba{te|cle}
On Thu, Oct 31, 2013 at 8:58 PM, berenger.mo...@neutralite.org wrote: Le 31.10.2013 21:06, André Nunes Batista a écrit : On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. If it's the Debian's GNOME maintainers' choice, how come GNOME depends on systemd in Gentoo? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SxjUygj1y2HKXgDFX4eunn7SwWiHtScbyx=0w_g4up...@mail.gmail.com
Re: Init system deba{te|cle}
Le 01.11.2013 17:07, Reco a écrit : Hi. On Fri, 01 Nov 2013 15:35:40 +0100 berenger.mo...@neutralite.org wrote: Le 01.11.2013 10:23, Reco a écrit : On Thu, Oct 31, 2013 at 09:58:26PM +0100, berenger.mo...@neutralite.org wrote: That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. One of GNOME developers says that: http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that. Which means that GDM under OpenRC would leave lingering processes around, making it impossible to restart/shutdown GDM properly. Debian GNOME packagers are planning the same AFAIK; they rather just rely on systemd … So, Debian maintainers had a choice: make systemd an dependency to GDM. Or, ship GDM that behaves funny. So the problem is that only systemd which is able to manage daemon's lives? I mean, if another tools was able (maybe upstart or any other, I have no idea if one does the same thing) to control daemons' lives, it could be used instead of systemd without any problem? For this specific daemon - yes, it's can be managed correctly by systemd only. At least, the man says so. The reason is (the way I see it) - GDM is now designed with systemd in mind, it does nothing to cleanup after itself. You use anything other than systemd to start GDM, try to stop GDM - it leaves gdm* processes. No other daemon known to me behaves like that. Ok, thanks for the info. I have always thought that gnome have a bad design (needing to install so many tools when you only need a small part of the DE is not what I call a good design. Just my opinion, and it might also be outdated, of course), and it seems it becomes worse. BTW, if they love GC at this point, they should rewrite everything in Java! PS: was it intended to send that reply only to me and not to the list? OOPS. No, it was intended for the list. Reco No problem, I was surprised so I kept it private, just in case. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/adb07d9c4a1b6d8e6e99ff2c275b1...@neutralite.org
Re: Init system deba{te|cle}
Le 01.11.2013 20:01, Tom H a écrit : On Thu, Oct 31, 2013 at 8:58 PM, berenger.mo...@neutralite.org wrote: Le 31.10.2013 21:06, André Nunes Batista a écrit : On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. If it's the Debian's GNOME maintainers' choice, how come GNOME depends on systemd in Gentoo? It seems I was wrong, but if I were not, then, it could be because it's simpler with that choice. Or people could share some opinion. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508e854e10fe2fafaedad43359e72...@neutralite.org
Re: Init system deba{te|cle}
On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? -- André N. Batista GNUPG/PGP KEY: 6722CF80 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1383250011.6245.65.camel@tagesuhu-pc
Re: Init system deba{te|cle}
Le 31.10.2013 21:06, André Nunes Batista a écrit : On Wed, 2013-10-30 at 14:22 +, Tom H wrote: On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. And does one really needs Gnome? Based on the level of user dissatisfaction I'd say Gnome shouldn't interfere with boot process. Especially one that tries to bundle everything... maybe gnome-devs are trying hard to address smarts, tablets and gadgets only? That's not gnome which changes the boot process. It's systemd. It simply happens that gnome depends on systemd in Debian build. Since AFAIK gnome is still available on platforms not based on linux kernel, unlike systemd, I really think that it's gnome maintainer's choice to have this hard dependency. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6ea3dfddb58113163c02e91eb646b...@neutralite.org
Re: Init system deba{te|cle}
Le 29.10.2013 23:25, Neal Murphy a écrit : On Tuesday, October 29, 2013 05:48:20 PM Jonathan Dowland wrote: On Tue, Oct 29, 2013 at 04:55:44PM -0400, John wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? I think it's largely driven by frustration over how bipartisan the discussion is and how long it has been going on (it has been repeating over and over for years), combined with a desire on the part of most folks for Debian to move to *some* modern init system (the debate being, which). I imagine part of the debate includes the fact that systemd integrates all kinds of systems and subsystems in an attempt to become the do-all and end-all of services control. This effort moves far away from the old UNIX concept of 'do one thing and do it well'. Were I to be unkind, I would opine that systemd is an attempt to make Linux more like Windows, where everything has tentacles everywhere. I agree that I do not like various things in systemd. It's sad, because the configuration files are far better that init scripts. I think a 'next-gen' sysvinit could be developed--from sysvinit--that would satisfy most requirements of a services monitor, and continue to do what sysvinit was intended to do in the first place: start daemons and keep them running as best as possible without creating all manner of interdependencies. http://xkcd.com/927/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/73fc964091e337324a7dcaaa52166...@neutralite.org
Re: Init system deba{te|cle}
Le 29.10.2013 21:55, John a écrit : Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Couldn't we just make XFCE the temporary default and stay with sysvinit until the technical dust has settled and we have a clearer view of the long-term merits of openrc, systemd, and upstart? I agree that considering recent debates about gnome3, gnome3 should no longer be the default DE in debian. Do not take me wrong here: I do not even use a DE, so I just do not care about which one is the default one. I simply have read lot of things, being on the mailing list or the whole Internet (it includes lot of trolls) and it seems that most gnome2's users just hate the 3rd major version, for various reasons. Since I think gnome2 was the default because the most used by Debian's users, then it does not makes sense to use gnome3 as the default. And my opinion is reinforced by the fact that gnome's softwares have dependencies on some systemd parts, when gnome should be a simple DE and so, should not have hard dependencies about system utilities. On the other hand, those applications already had dependencies on softwares that were not mandatory, like policykit. Those are simply replaced by the systemd-based variant, so does it really adds a problem? There were bloated soft using *kit as dependencies and are now bloated with systemd-* dependencies instead. I honestly do not mind that much. The day I'll really want to get rid of those dependencies, I'll hack their source code myself for that. For now, if I really like the soft, I can do with design choices that I think wrong. Now, since there is a popularity contest for packages installed, why not simply use it to choose the default DE? It would avoid flame wars to use those numbers, since it will show what users prefers, in the users which want to contribute their package list. I'm not close to DD status, so reluctant to ask on -devel. I think it have it's place on devel- ml, because in Debian, the rulers are the devs :) I mean, Debian is a meritocracy, if I am not wrong. We, as simple users, can have opinions, but when only using Debian, we know that our opinions may, or may not, be listened. On devel ml, you will find lot of people with more merit, and so more weight, than us, simple users. I don't fit any of the categories of that debate: 1) systemd advocates with few reservations about forcing their way, 2) near-adolescent emotional responses to anything that looks like forcing. Luckily there have been a few posts by 3) sensible and emotionally moderate folks; it's reassuring to see how many of them also hold office in Debian. As I. I can only remember about 3 valid arguments in the systemd debates: _ easier to maintain configuration files ( simple configuration files for systemd versus shell scripts with lot of cross references for sysVinit ) _ tools which should do only one thing depends on some of it's module when it is not needed ( I guess I could use the dbus / libsystemd-login0 example ) _ it uses linux special features, and so, is not portable. The 1st one is a pro, the 2nd one a con (at least for me), and the 3rd one is neutral: using kernel features can be a good thing, but compatibility is always a good thing too. About the 2nd argument, I think that the problem is not from systemd itself, but from tools which depends on it. In my example, it's dbus' developers' choice which is questionable, not systemd itself. When a programmer use a tool, it is his job to choose it carefully, not the tool's author's job. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c1855af9bdd94b2bea2c71f85556a...@neutralite.org
Re: Init system deba{te|cle}
On Tue, Oct 29, 2013 at 8:55 PM, John johnrchamp...@wowway.com wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? Is it provoked by systemd's effort to be adopted having at least found a home with gnome, made urgent by gnome's status as our default? Although this isn't the first debian-devel systemd-slugfest, there's more of a sense of urgency and finality this time because GNOME 3.8 depends on logind, and, other than on Ubuntu for systemd =204, that means that GNOME 3.8 depends on systemd-as-pid-1. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szw0powzbkxv13cz9gk-+qogxnme-gwq3n9rej9_ba...@mail.gmail.com
Re: Init system deba{te|cle}
On Tue, Oct 29, 2013 at 04:55:44PM -0400, John wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? I think it's largely driven by frustration over how bipartisan the discussion is and how long it has been going on (it has been repeating over and over for years), combined with a desire on the part of most folks for Debian to move to *some* modern init system (the debate being, which). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131029214820.ga12...@bryant.redmars.org
Re: Init system deba{te|cle}
On Tuesday, October 29, 2013 05:48:20 PM Jonathan Dowland wrote: On Tue, Oct 29, 2013 at 04:55:44PM -0400, John wrote: Could someone who has been following the giant fuss on -devel over init systems explain why there's such a sense of dire urgency? I think it's largely driven by frustration over how bipartisan the discussion is and how long it has been going on (it has been repeating over and over for years), combined with a desire on the part of most folks for Debian to move to *some* modern init system (the debate being, which). I imagine part of the debate includes the fact that systemd integrates all kinds of systems and subsystems in an attempt to become the do-all and end-all of services control. This effort moves far away from the old UNIX concept of 'do one thing and do it well'. Were I to be unkind, I would opine that systemd is an attempt to make Linux more like Windows, where everything has tentacles everywhere. I think a 'next-gen' sysvinit could be developed--from sysvinit--that would satisfy most requirements of a services monitor, and continue to do what sysvinit was intended to do in the first place: start daemons and keep them running as best as possible without creating all manner of interdependencies. Were one to look, on would see that init is really only used for two purposes today: (1) to restart gettys and (2) to inherit processes and reap zombies. It isn't used to start, maintain and stop daemons; when a daemon dies, it can be days before its absence is noticed. So who is up to extend sysvinit to 16-32 run levels with an 'init tree' (or trees) instead of the current 'init table'? Extend it to follow its original purpose: start, stop and maintain daemons and services. Allow daemons to be started in parallel (up to the count of available CPUs), but add checkpoints to the tree that pause until pending parallel startups are complete before continuing to spawn more daemons (i.e., handle startup dependencies). And design it so that the tree is human-readable, so that it doesn't require a whole new suite of incomprehensible programs to (re)start and stop daemons. Design this 'next-gen' init to use the existing start/stop scripts in /etc/init.d. It's possible. It's doable. It would require learning a 'new way' but would be far less invasive than current alternatives. N -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201310291825.02817.neal.p.mur...@alum.wpi.edu
Re: Init system deba{te|cle}
Neal writes: I think a 'next-gen' sysvinit could be developed--from sysvinit--that would satisfy most requirements of a services monitor http://wiki.gentoo.org/wiki/Comparison_of_init_systems http://smarden.org/runit/ https://bbs.archlinux.org/viewtopic.php?id=148747 wikipedia.org/wiki/OpenRC -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uxbfxxd@thumper.dhh.gt.org
