Re: [DNG] Init scripts in packages
Rainer Weikusat rainerweiku...@virginmedia.com writes: [...] I'm going to ignore the remainder of this because - while system startup is a topic of some interest to me - people warring over the right way to replace UNIX(*) because it's broken isn't. Since this is maybe/ likely a bit harsh (and I'm trying to rid myself of this style): If you're convinced that rip and replace is the only viable option then I won't claim that you're wrong because I really don't know. However, until I hit a technical obstacle, I won't be convinced that the existing system can't be fixed (I acknowledge almost all defects you mentioned) and this is based on being familiar (as in 'I wrote the code') with both approaches. A social reason, eg, $someone pays my bills ($someone =~ /hat/) and that's what I did and you will have to eat it aka 'resistance is futile ...' won't do. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Rainer Weikusat rainerweiku...@virginmedia.com writes: Laurent Bercot ska-de...@skarnet.org writes: On 06/08/2015 20:18, Rainer Weikusat wrote: UNIX(*) and therefore, Linux, provides two system calls named fork and exec which can be used to create a new process while inheriting certain parts of the existing environment and to execute a new program in an existing process, keeping most of the environment. This implies that it is possible to write a program which performs a particular 'environment setup task' and then executes another program in the change environment. [...] And that's finally the jboss start script. I have some more tools of this kind because whenever I need a new, generic process management task to be performed, I write a new program doing that which can be used in concert with the existing ones. What you are saying is that your approach is exactly the same as the one found here: http://skarnet.org/software/execline/ No, it's not. This is an interpreter for another programming language sharing some concepts with the Thompson-shell. For the sake of accuracy: While this calls itself an interpreter, it actually isn't. It's a compiler generating threaded code for immediate execution upon call. It's sort-of similar to the Thompson-shell because it relies on separate programs for providing any 'real' functionality, including 'control constructs'. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
On Thu, 2015-08-06 at 06:32 -0500, Nate Bargmann wrote: * On 2015 05 Aug 21:23 -0500, Joel Roth wrote: What dmix doesn't do (and pulseaudio does) is provide a separate volume control for each application. Which is an outstanding feature that I do miss on this desktop that I purged PA from due to extant SysD dependencies. I would just like to see PA installable without the need for bringing in SysD and even Policykit, but the latter may be forgivable but the former is not. Did anybody mention alsamixer? I find it very useful and you don't need any systemd or dbus libraries for that tool. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
tilt! wrote: Hello! [summary of ALSA features snipped] d Since the setup in asoundrc is static in nature, dynamically assigning a multichannel routing, for example through an interactive volume control, to a specific application is something I would not immediately know how to accomplish. ALSA, cannot know how many output or input channels an application will have. Pulse audio support includes exchanging that information using dbus. I think it's a problem on the application side if it won't route to named ALSA PCM device. It's not only ALSA's fault if an application won't let you specify the sound device. But ALSA does offer OSS emulation that many apps use, via device node /dev/dsp. You don't mention what you want to accomplish specifically, or why you were using JACK. It may be easier to solve your specific problems, before trying to generally improve the configuration of the audio services under Devuan. In that case, you would be better off, IMO writing to Linux Audio Users, where you could get authoritative answers. Regards, Joel -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Laurent Bercot ska-de...@skarnet.org writes: On 06/08/2015 20:18, Rainer Weikusat wrote: UNIX(*) and therefore, Linux, provides two system calls named fork and exec which can be used to create a new process while inheriting certain parts of the existing environment and to execute a new program in an existing process, keeping most of the environment. This implies that it is possible to write a program which performs a particular 'environment setup task' and then executes another program in the change environment. [...] And that's finally the jboss start script. I have some more tools of this kind because whenever I need a new, generic process management task to be performed, I write a new program doing that which can be used in concert with the existing ones. What you are saying is that your approach is exactly the same as the one found here: http://skarnet.org/software/execline/ No, it's not. This is an interpreter for another programming language sharing some concepts with the Thompson-shell. What I was describing were additions to an existing scripting environment in order to help with 'process/ services management'. I'm going to ignore the remainder of this because - while system startup is a topic of some interest to me - people warring over the right way to replace UNIX(*) because it's broken isn't. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Am 06.08.2015 17:49 schrieb Steve Litt: Laurent Bercot ska-de...@skarnet.org wrote: I have never said, am not saying, and probably never will say that systemd is any good. It's not, and Lennart and Kay should go back to engineering school, :s/engineering school/kindergarten/ Hell no, that wouldn't be good for the other kids. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On 07/08/2015 00:09, Rainer Weikusat wrote: Since this is maybe/ likely a bit harsh Not harsh, just unwilling to accept that I'm actually your ally and not your enemy. I'm not trying to replace Unix, because Unix is not broken - at least, not as far as system startup is concerned. There *are* broken things in Unix, but that's a whole other enchilada that I won't have time to address in the next 2 or 3 lifetimes. I'm trying to replace *systemd*, with something that embraces Unix much, much more. sysvinit or sysvrc init scripts don't define Unix. Trying to do better than them is not replacing Unix, it's trying to do things right. Now is the time to do things right, because if we don't, systemd is going to take over, for good. I don't want that, and since you're here, I don't think you want that, either. If you're convinced that rip and replace is the only viable option then I won't claim that you're wrong because I really don't know. However, until I hit a technical obstacle, I won't be convinced that the existing system can't be fixed (I acknowledge almost all defects you mentioned) and this is based on being familiar (as in 'I wrote the code') with both approaches. Fine. I'm okay with the burden of proof. Let's take a simple example and see how deep we have to dig to make it work. You have 3 longrun services, A, B and C. A and C can take a long time to start and be ready, because they access some network server that can be slow, or even fail. But they don't depend on anything else than this network server. B depends on A. It does not contact the network server, but it consumes non-negligible resources on the local machine at startup time. Your objective is to reach the state where A, B and C are all up and ready as quickly and reliably as possible. How do you proceed ? Serially ? A start B start ; C start Not good: you add A's and C's latencies. Parallely ? A start B start C start Not good: B can be scheduled to start before A, and will crash. Using a supervision system to make sure all the services will eventually be up ? s6-svc -u /service/A ; s6-svc -u /service/B ; s6-svc -u /service/C Better, but still not optimal: if B crashes because A is not up yet, it will be restarted, and it's annoying because it's hogging important resources every time it attempts to start. You need a dependency manager. rc A+B+C Much better. Except there's no such thing yet. The closest we have is OpenRC, and for now it's serial: you'll eat the added latencies for A and C just like in the naive serial approach. Ouch. ISTR there are plans to make OpenRC go parallel at some point. Let's assume it is parallel already. What do you do if A crashes because the network server is down ? You also need a supervision system, coupled with the dependency manager. The OpenRC folks have realized this, and you can use a flag to have your service auto-restarted. There's also some early support for s6 integration, which I won't deny is flattering, but I still don't think the design is right: for instance, there are early daemons you can't supervise. OK, now, how do you detect that A is ready and that you can start B ? Well, you need readiness notification, assuming A supports it. You need it because you don't want B to crash and restart. And now your rc system must implement some support for it. And I haven't even mentioned logging yet. If you've written init systems, you must have reached that point. I'm interested in knowing how you solved those issues. Now, if you try to implement process supervision, dependency management, readiness notification and state tracking in pure init scripts, well, glhf. That's what sysvrc, with tools like start-stop-daemon or other horrors, has been trying to do for 10 years, without knowing exactly what it was that it was trying to do. The result isn't pretty. Then systemd came and said hey look! I can do just that, and more, and you don't have to bother anymore with those horrible sysvrc scripts! And what did admins say? YES, PLEASE. And they gobbled up the crap because it was coated with the sweet, sweet features. (And, yes, with an unhealthy dose of propaganda and bullshit, but if you dig through the bullshit, you can find a few things of value.) I'm saying the same causes will have the same results, and more tweaking of the init scripts isn't going to accomplish anything without some serious redesign. It's the easy path; I'm all for the easy path when it can be taken, but in this case, it's not the right one. The right path is to provide the sweet, sweet, *needed* features - but to do it the Unix way. A social reason, eg, $someone pays my bills ($someone =~ /hat/) and that's what I did and you will have to eat it aka 'resistance is futile ...' won't do. You are fighting windmills. This is the Lennart way, it's not mine and I don't think it is anyone's here. Even if I wanted to, which I don't and never will, I don't have the power to ram anything
Re: [DNG] Init scripts in packages
Laurent Bercot ska-de...@skarnet.org writes: A leading remark: This is based on an existing system I have implemented (originally for Debian 5) working in the described way. The code is proprietary as I'm one of those evil guys who want to (and do) write code for a living despite the 'free software community' traditionally hates me (not entirely their fault because almost all people handling skills I have at all were acquired by 'trial and error on the internet' and they used to be pretty grueseome [and to a degree, still are]). On 06/08/2015 16:00, Rainer Weikusat wrote: That's all nice and dandy but it all boils down to 'the code executed by the init script was deficient in some way'. Yes, just like root exploits boil down to the code executed by the suid program was deficient in some way. My point is that you shouldn't need to have 40 lines of boilerplate to sanitize your init script before you run it; if it's so fragile, then it's badly designed. UNIX(*) and therefore, Linux, provides two system calls named fork and exec which can be used to create a new process while inheriting certain parts of the existing environment and to execute a new program in an existing process, keeping most of the environment. This implies that it is possible to write a program which performs a particular 'environment setup task' and then executes another program in the change environment. 'nohup' is a well-known example. Because of this, instead of 40 lines of boilerplate in every init script, almost all of which is identical, it's possible to identify common tasks and write programs to handle them which can be chained with other programs handling other tasks, Eg, as a real world example, a command to start a certain Java application I happen to be dealing with looks like this: daemon chdir $DIR monitor -n jboss -g $RUNAS chids -u $RUNAS $JBOSS_HOME/bin/run.sh -b 127.0.0.1 'daemon' creates a daemon process and execvps its arguments in it. 'chdir' changes to a directory passed as first argument and execvps the remaining arguments. 'monitor' forks, performs a few other things (creates a control socket with a well-known name) and execvps its arguments in the new process. As the name might suggests, it works as process monitor/ supervisor. 'chids' changes uid and gid as specified on the command and and execvps its remaining arguments. And that's finally the jboss start script. I have some more tools of this kind because whenever I need a new, generic process management task to be performed, I write a new program doing that which can be used in concert with the existing ones. [...] [systemd] Is it? Or is it an extremely incomplete, ad hoc designed programming language with a service manager and a truckload of other potentially useful stuff attached to it in order to encourage people to swallow the language? [...] Know your enemy. It's easy and tempting to rant for days on systemd's weaknesses; but it's also vital to acknowledge its strengths. sarcasm Considering that SuSE almost adopted updstart, it came just at the right to keep the traditional order of the universe where Fedora guys 'contribute' and moan about Canonical 'not giving back' intact. /scarcasm ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On 06/08/2015 20:18, Rainer Weikusat wrote: UNIX(*) and therefore, Linux, provides two system calls named fork and exec which can be used to create a new process while inheriting certain parts of the existing environment and to execute a new program in an existing process, keeping most of the environment. This implies that it is possible to write a program which performs a particular 'environment setup task' and then executes another program in the change environment. 'nohup' is a well-known example. Because of this, instead of 40 lines of boilerplate in every init script, almost all of which is identical, it's possible to identify common tasks and write programs to handle them which can be chained with other programs handling other tasks Yes. You are describing chain loading. (And the system call is named execve, if you want to be pedantic.) And that's finally the jboss start script. I have some more tools of this kind because whenever I need a new, generic process management task to be performed, I write a new program doing that which can be used in concert with the existing ones. What you are saying is that your approach is exactly the same as the one found here: http://skarnet.org/software/execline/ and here: http://skarnet.org/software/s6/ It's free software, it works, it's maintained, and the author happens to read the dng list, hoping to find technical interlocutors that share his concerns for the future of GNU/whatever/Linux. Are you one of them ? Good. Let's talk. Now, chain loading is great, and all the necessary tools that perform process state changes already exist, but that's not enough to make init scripts safe. When you want to sanitize a process, or when you're doing any kind of security really, you cannot have an allow everything by default and deny specific things approach: fork your process from the user's shell, then sanitize the environment, the fds, the cwd, etc. You *will* forget something at some point; if you don't, the person who writes the next init script will. Instead, you have to use a deny everything by default approach: in the case of init scripts, that means always starting daemons with the same, sanitized, environment. That can only be done with a supervision system, as explained at http://skarnet.org/software/s6/overview.html And a supervision system itself is a great thing, but it's not enough, because it does not handle dependencies between longrun services (i.e. daemons that can be supervised) and oneshot services (i.e. stuff you run once to change the machine state, but that do not leave a long-lived process around). That is where a real service manager is needed. As loath as I am to admit it, systemd *is* both a supervision system and a service manager. It does machine initialization, daemon supervision, and state changes - badly, but it does them. And no amount of mucking with init scripts, no matter how much chain loading you use, is going to accomplish the same. The solution is not in criticizing, it's in doing. I have the supervision system, and I'm working on the service manager. But this will be all for naught if systemd opponents can't be convinced that it is necessary: the admin who wants a service manager will hear sure, systemd does that! on one side, and nah, this is purely systemd propaganda, you don't really need that shit on the other side. Guess what they will choose. The other side should be able to answer sure, you can use *this* piece of software, or *this* other one, to do what you want, and you don't have to put up with all the systemd crap for this. It's the only way we can make it work. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lurking about
.. and what about https://crunchbangplusplus.org/assets/misc/cbpp-1.0-amd64-20150428.iso.torrent instead of BunsenLabs? (= Cheers, __martin__ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
On Thu, Aug 06, 2015 at 10:47:34AM +0200, tilt! wrote: As for problem #1, I personally feel that the lack of user interface (tools and documentation) of the ALSA built-in solutions has been and is the primary motivator for developments like Pulseaudio. The paradigm here is: Package A is unusable because of its documentation. Better write package B which is usable. The problem with this is that often package B is unusable for the same reason. But the reasons this is attractive: I can't write the documentation without knowing what it does. If I can write the documenntation, often the process of reporting clearly what package A does reveals that its design is terrible. and it would be easier to rewrite it to match reasonable documentation than to document all its barnacles. How many audio systems does Linux have now? Does any of them have really low latency -- the kind you need if you are programming the synthesizer inside a live-performance musical instrument? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages.What will Devuan developers do when it happens? We can use sysvinit and Devuan because these init scripts exist. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
Hello! On 08/06/2015 04:22 AM, Joel Roth wrote: [...] What dmix doesn't do (and pulseaudio does) is provide a separate volume control for each application. ... a feature that I use once per year; then it is quite useful. ;-) I find ALSA provides really lots of useful tools, such as: * the plug-in dmix, already mentioned; * the plug-in jack, can divert audio from/to a JACK server; * the loop-back device, constructs a virtual ALSA sound card; * the plug-in route, can up- and down-mix multichannel audio and re-order channels; * the plug-in ladspa, can pass audio through algorithms such as filters, delays or distortions. There are more, but they all have in common these problems: a there are no simplistic configuration tools, actually there are no configuration tools at all, the user interface is the structured text-based configuration file ~/.asoundrc b the configuration file user documentation is badly structured, casually written and limited to few, punctual examples. These problems have existed for ages now; as for problem #2, many unofficial efforts have been made to improve this, there are many tutorials and examples online. Still, I find it undeniable that the official documentation is far from optimal. As for problem #1, I personally feel that the lack of user interface (tools and documentation) of the ALSA built-in solutions has been and is the primary motivator for developments like Pulseaudio. Other problems I feel worth mentioning: c In my experience, setups based on .asoundrc tend to be static, they get written, tinkered with and optimized until they reliably work, then the configuration file is left alone because it just works. d Since the setup in asoundrc is static in nature, dynamically assigning a multichannel routing, for example through an interactive volume control, to a specific application is something I would not immediately know how to accomplish. e Some applications can not use pcm entries defined by plug-ins, they want ALSA playback/capture interfaces (I think ALSA calls these devices). I encountered that problem when trying to route iceweasel output to JACK: with a pcm based on the jack plug-in it refused to accept that as default playback pcm; with a loop device defined as the default (suggested by [1]) it works reliably. f OTOH, working with loop devices (virtual sound cards) for redirection, the number and ordering of these devices is decided at loading time of the snd-aloop kernel module; I am not aware that this could be reconfigured dynamically. Kind regards, T. Links: [1] alsa.opensrc.org. Jack and Loopback device as Alsa-to-Jack bridge. URL: http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Alexey Rochev equ...@gmail.com writes: Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages. This would rid the world of a lot of code of very dubious usefulness most of which should never have been written. One of the justifications for systemd is actually that they idea (orchestrate/ implement system startup based on the filesystem and with code written in the Bourne shell language) must be bad because Can't you see that a horrendous mess they made of it?! (only partially based on the visual effect of seeing a lot of complicated looking code in a language one happens to be almost totally unfamiliar with and all written by different people, ie, in different styles --- even a lot of people who consider themselves highly competent developers can't really cope with that). But a bare-bones init script does really only three things: 1. Execute a command to start something. 2. Execute a command which stops it again. 3. Execute 2) then 1) for a restart. Implementing this needs only marginally more text than this description and the world won't end anytime soon for want of a fifteen (estimate) line program. If anything else fails, I'd be willing to write it for you. Pet peeve: As part of my present job, I've developed a set of relatively small command-line tools supposed to add more 'verbs' suitable for managing services to the shell language (the largest is about 1300 LOC but contains some features which really ought to become independent programs). After experiences with a (simple) process manageing init I wrote for an earlier embedded system, this was an intentional experiment in let's try it with small, independent programs written in C while using the shell as control/ skeleton language for connecting them and see how far I can get with that (I can always try it with a big, complicated program should this fail). After five years, the conclusion is that this worked out beautifully. But this is - of course - all code my employer claims copyright in, hence, it will ultimatively end up getting systemd (or bernsteined or ... insert whatever the name of your favorite init-with-process-manager-ipc-system-and-some-kitchen-sinks written in a real programming language happens to be). life is futile we're all gonna to die in the time between have a coffee ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On Thu, Aug 06, 2015 at 02:21:55PM +0200, Laurent Bercot wrote: On 06/08/2015 11:45, tilt! wrote: Thing is, init scripts tend to have problems managing services that do not offer sufficient commandline interfaces as described above There's a simple reason for that: init scripts aren't managing services. They can more or less start and stop them, that's about it - and they're not even doing the starting and the stopping right. - Starting ? Sure, it's easy to start a service: run the stuff, and if it's a daemon, just fork it. Right ? Wrong. When you just spawn the stuff from your shell, it runs with your shell's environment (open fds, variables, terminals, so many parameters that are *difficult* to clean up and really harden). But when you spawn the stuff at boot time, it runs with the very different environment provided by init. I can't count how many problem reports I've read in support mailing-lists that were really hard to track down, but in the end it was just a config issue because the daemon launching script did not properly sanitize all its environment, so it didn't give the same results when run by the admin or when auto-run at boot time. If differences in environment can cause problems, it's a problem with design. A program that changes what it does just due to differences between the init environment and a login environment is going to be hard to debug. Also, if I'm reading this right, you're implying that execline does clearenv(), sets a new environment, and also closes all fds above 2. - Stopping ? Sure, just find a daemon's pid... oh wait, we need to have it stored somewhere. Hence, .pid files. If you don't know why .pid files are evil, look it up. It took me ... less than a minute to find pgrep -F. That solves the problem of stale pidfiles. And then you have the other functionality. Restarting, sometimes, can be lighter than stop + start: maybe there's a whole lot of config you don't have to do when you're just restarting a daemon - for instance, if restart means read your config file again, some daemons support the convention that receiving a SIGHUP should make them do just that. So restart should simply send a SIGHUP to those, but do stop + start on the others. That's confusing. There's the reload keyword sometimes, but are there any precise semantics ? restart means start and stop. reload means reread config file. And status. This is very service-dependent: since there is no global API, no service manager, scripts will query the daemon's status in a daemon-specific way. More vagueness again, because status doesn't define exactly what you should say, and the lowest common denominator is is it alive? but even for this basic check, daemon-specific interfaces are used. The status command was originally is it running?, but yes, that's barely useful. If you use a pidfile and pgrep -F, that would work. Using a tool dedicated to the purpose is more helpful than any service manager can be (unless your service manager is a hundred-megabyte hog). Think it's hung? strace/ltrace the pid. Wondering what files it has open? Use lsof or look in /proc/$PID/fd/. ... Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lurking about
I have noticed that the chief protagonist of Crunchbang, aka Corenominal, is also a contributing developer on Bunsenlabs- just seems more genuine to me, with Wheezy in LTS 'til 2018, and Devuan still 'tender', I can wait. (thanks to this mailing list for allowing this, not very relevant, thread) Cheers. G.H. -- G.H. gerry.gazu...@gmail.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On 06/08/2015 16:00, Rainer Weikusat wrote: That's all nice and dandy but it all boils down to 'the code executed by the init script was deficient in some way'. Yes, just like root exploits boil down to the code executed by the suid program was deficient in some way. My point is that you shouldn't need to have 40 lines of boilerplate to sanitize your init script before you run it; if it's so fragile, then it's badly designed. But that's something different. Using inetd as simple, well-known example, if I just changed /etc/inetd.conf, I want to daemon to reread it and reconfigure itself accordingly to avoid interrupting unrelated services but in case its on rampage in an endless loop, I want to get rid of the current process and start a new instance. 'SIGHUP' is just a random convention dating back to the times when signals where the only kind of IPC supported by UNIX(*) and the signal was basically hijacked because a 'daemon process' shouldn't ever receive it for some other reason. It's not universally supported and not all daemons are so simple that reread the config file is the only means of controlling them at run time. Eg, someone might want to ask bind to reload a specific zone. All agreed. Service-specific configuration can only be achieved by service-specific tools. Service management is a more complex task than [nohup] /usr/sbin/ochsenfrosch log 21 My point exactly. [systemd] Is it? Or is it an extremely incomplete, ad hoc designed programming language with a service manager and a truckload of other potentially useful stuff attached to it in order to encourage people to swallow the language? I have never said, am not saying, and probably never will say that systemd is any good. It's not, and Lennart and Kay should go back to engineering school, and the people who hired them should go back to HR school. Its Embrace and Extend strategy is as pernicious as Microsoft's in the late 90s / early 2000s. It's technically inept and politically evil. Nevertheless, those guys have understood a few things, and have done a few things better than sysvinit or anything else really. You have to analyze it, cut out the bad parts and keep the good parts. The concept of service management is one of the good parts. They implemented it the systemd way, but they did implement it. Know your enemy. It's easy and tempting to rant for days on systemd's weaknesses; but it's also vital to acknowledge its strengths. 'Winning' against systemd will require getting support of a commerically more potent company than RedHat and SuSE combined and one willing to sink a sizable amount of money into the task. No, I don't think so. You don't fight Goliath with Goliath. You don't fight Microsoft's proprietary-ness by investing into Apple. The last thing we need against systemd is another systemd, as you say yourself in the rest of your paragraph, which I fully agree with. But 'booting the machine' is a much simpler task and it can be solved within the existing framework by incrementally adding the missing bits. Depending on what you mean by adding the missing bits, I may or may not agree. I'm not suggesting doing things the systemd way, but I do believe that a quantum leap is needed. Which, of course, does not preclude maintaining compatibility for some time to ease the transition. Starting from the presumption that this will turn out to be necessary is a guess. You either want to do things right or you don't. If you do, then it's not a guess: starting and maintaining services reliably requires more than the existing framework. There are countless web pages and heartbreaking mails on support mailing-lists to prove it. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On 05/08/15 23:29, Alexey Rochev wrote: Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages. What will Devuan developers do when it happens? We can use sysvinit and Devuan because these init scripts exist. Debian will likely either cease to exist or just have become a rebranded Fedora by the time that happens, so Devuan will likely have forked those packages anyway. Besides, once init-scripts have been written and proven they require very little maintenance so it' unlikely packages will drop the init-scripts soon. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On Thu, 06 Aug 2015 10:28:47 +0100 Rainer Weikusat rainerweiku...@virginmedia.com wrote: But a bare-bones init script does really only three things: 1. Execute a command to start something. 2. Execute a command which stops it again. 3. Execute 2) then 1) for a restart. Those are easy. The tough part is process dependencies. Especially since a lot of daemons aren't ready to do their job when they first get run, and report their readiness only to the systemd communication system. I think the biggest hassle is writing tiny scripts that basically answer the question: Is daemon X now functional? SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On Thu, 6 Aug 2015 16:41:38 +0200 Laurent Bercot ska-de...@skarnet.org wrote: I have never said, am not saying, and probably never will say that systemd is any good. It's not, and Lennart and Kay should go back to engineering school, :s/engineering school/kindergarten/ /* Litt ducks and runs */ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Interesting comment from a kernel developer
Adam Borowski wrote on 23/07/15 07:45: systemd-shim still means systemd. Devuan is supposed to fix this, but in the meantime -- or if you prefer staying with Debian proper -- you can use my repository of deinfested packages: jessie: deb http://angband.pl/debian nosystemd main unstable/stretch: deb http://angband.pl/debian nosystemd-stretch main If some package you want is missing, please let me know -- I deinfest them only when I encounter something that tries to pull systemd into my system, which means I have no exposition to, for example, the Gnome world. Thanks for these, I'll give them a try. Another headache coming up is the migration to gcc-5 for building packages, and all the KDE/Qt related packages that are slowly being rebuilt with gcc-5. Arthur. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
