[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] 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] 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] 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] Devuan on Raspberry Pi 2B
Hello again, just a hint for the resolute ones among us, as I think this hasn't been mentioned on this list yet: Adding the following lines to e.g. the file /etc/apt/preferences.d/avoid-systemd should make ultimately sure, that libsystemd0 will not be accidentally pulled in by some felted package: Package: libsystemd0 Pin: release o=Debian Pin-Priority: -1 Unfortunately apt does not handle this transparently, when failing to install some distant systemd dependant, but reports an unfixable dependency problem – pointing only at the very next dependency in the chain down to libsystemd0. The complete explained list of possible apt pin-priority categories from <0 to >1000 you can find in the apt_preferences(5) manpage. Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Alexey Rochev 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] 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
On 08/06/2015 11:28 AM, Rainer Weikusat 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. There are additional actions required by [LSB]; out of these I appreciate a "status" action the most - the use of the others is debatable if not questionable, but "status" I find really important. This is usually where init scripts get ugly and try to work around missing commandline interfaces of the services they attempt to manage. As soon a /bin/sleep command appears, it's FUBAR. Thing is, init scripts tend to have problems managing services that do not offer sufficient commandline interfaces as described above; what does SystemD do to address this problem? Regards, T. Links: [LSB] Linux Standard Base Core Specification 3.1. 20.2. Init Script Actions. URL: http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html ___ 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
Hi Joel, On 08/06/2015 11:39 AM, Joel Roth wrote: [...] 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. I appreciate your kind offer of solving my specific technical problems a lot - however, as it stands, I have none *fingers crossed* ;-) What I want to accomplish is sufficiently addressed by my listing of problems a, b (grave defects) and c, d, e, f (various other shortcomings), the intended accomplishment is finding and providing reliable, flexible, and thus, reusable solutions for those problems. Please note that the problems I listed as a, b are not primarily problems of IPC or RPC; they are more related to the configuration language that is powering .asoundrc. Kind regards, T. ___ 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 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. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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 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. - 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. 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 ? 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. Init scripts just don't cut it, no matter where they come from, no matter how simple they are or how complex they are. OpenRC is a step in the right direction, because it provides real support for more things than sysv-rc, but even it doesn't address all the issues of init scripts. What is needed is a *service manager*, a real, full-fledged thing that doesn't only start and stop services, but does it properly, without hacks, with the same environment every time, and can tell you whether a service is alive or not, ready or not, and gives you a unified interface to interact with it in a simple way. (You still have to use daemon-specific interfaces for the more complex ways, because no service manager can unify that.) what does SystemD do to address this problem? It does exactly that. Among the myriad of useless things that systemd does, it does at least one useful thing: it's a proper *service manager*. I'm not saying it's correctly designed - it's not: see for instance http://ewontfix.com/15/ - but it's definitely one of the real, serious advantages that systemd has over its current alternatives, and it is important to acknowledge it. Winning against systemd involves providing better designed alternatives to the useful parts of what it does, and service management is one of those: there is a qualitative jump to do here, and messing around with init scripts is only a quantitative jump and unfortunately isn't going to accomplish anything if not paired with a serious redesign of how booting a machine should be done. That's why I'm currently writing a service manager, and will keep you guys informed when it's out. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
"tilt!" writes:
> On 08/06/2015 11:28 AM, Rainer Weikusat 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.
>
> There are additional actions required by [LSB]; out of these
> I appreciate a "status" action the most - the use of the others
> is debatable if not questionable, but "status" I find really
> important.
Even the restart is already an example of 'cat -v programming' (or
'coral reef design' -- $stuff growing on $other_stuff because $other_stuff
already exists) and 'status' is worse as the semantics are also muddy: What
ever the output happens to be, it contains information which happened to
be accurate at some random point in time in the past and it's neither
known if it's still accurate nor when it was accurate for the last
time. Further, what precisely comprises a useful bit of "status
information" is very program dependent. Eg, the status of a Java
application running on top of JBoss might be 'the JVM got started and
deployment worked, however, because of a typo in some named query,
Hibernate couldn't make sense of it so it isn't really working at the
moment', the status of a ssh server might be "everything's fine but can
we disconnect China as the IPs could be put to a better use than for
scripts trying to break into the system", the status of a long runnning
computation might be "still running, n% completed" and some other task
might just wait for something to do.
Insofar a particular task involves a idempotent process with indefinite
lifetime ('idempotent' here supposed to mean that 'restart in case of
unexpected termination' make sense), "did it terminate despite it wasn't
asked to" would be a useful piece of generic status information but
that's primarily interesting to a program supposed to manage 'daemon
processes' and that's beyond the scope of an start/stop script which
knows nothing about the effects/ purpose of the tasks it's employed to
start or stop.
___
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
I have use OSS4 on a few machine and have been very satisfied, but not a lot with multichannel. I appreciate the separate volume controls for each application, Maybe this could help: http://manuals.opensound.com/developer/multichannel.html Also, here's is some good information for supporting OSS (Although a little old): http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html -Rich ___ 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] Init scripts in packages
Laurent Bercot writes: > 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. That's all nice and dandy but it all boils down to 'the code executed by the init script was deficient in some way'. [...] > 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. 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. Runtime control of a long running process is a task dependent job. And since init scripts are task-agnostic, they cannot (sensibly) provide it. [...] > Init scripts just don't cut it, no matter where they come from, no > matter how simple they are or how complex they are. [...] > What is needed is a *service manager*, a real, full-fledged thing > that doesn't only start and stop services, but does it properly, > without hacks, with the same environment every time, and can tell > you whether a service is alive or not, ready or not, and gives you > a unified interface to interact with it in a simple way. (You still > have to use daemon-specific interfaces for the more complex ways, > because no service manager can unify that.) Service management is a more complex task than [nohup] /usr/sbin/ochsenfrosch >>log 2>&1 & (although this already gets one rather far) and moreover, it's comprised of both generic and task-specific jobs and it's sensible to decouple these two: Let the applications process deal with its problems and handle the generic issues with other code. Further, the runlevel/ init script mechanisms and conventions address only a part of the generic problems services management involves. But "X can't be used" is not something which follows from "I need feature beyond those provided by X". >> what does SystemD do to address this problem? > > It does exactly that. Among the myriad of useless things that systemd > does, it does at least one useful thing: it's a proper *service > manager*. 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? [...] > Winning against systemd involves providing better designed > alternatives to the useful parts of what it does, and service > management is one of those: there is a qualitative jump to do here, > and messing around with init scripts is only a quantitative jump and > unfortunately isn't going to accomplish anything if not paired with a > serious redesign of how booting a machine should be done. '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. And that's only a part of the solution because you'll also have to be on the lookout for senior developers whose surnames
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
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] 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 2>&1 & 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] 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. ___ 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:31, Isaac Dunham wrote: 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. There are tons of those, and you can't fix them all. Stupid example: less. Behaves differently when its stdout is a terminal and when it's not. The only way to ensure reproducible behaviour for a program, no matter what it is, is to start it in a reproducible environment. It took me ... less than a minute to find "pgrep -F". That solves the problem of stale pidfiles. Do you think so? See for yourself: https://gitlab.com/procps-ng/procps/blob/master/pgrep.c It just reads the pid in the pidfile, and does its matching with the read pid. Unless you also give other options to narrow the match, it will have the exact same problem. Now, of course, you can give the executable name, and add even more guards to make sure you don't find the wrong process. At the end of the day, you wrote a nice and complex pgrep command line, you're *almost* 100% sure that it will nail your process and only yours, and you just scanned /proc to send a goddamn signal to a daemon. I'd rather type "s6-svc -d /run/service/my-daemon" and kill my process with absolute certainty, using 10 or 20 times fewer system calls than pgrep and a small fraction of the CPU time. restart means start and stop. reload means reread config file. Ah, thanks. Using a tool dedicated to the purpose is more helpful than any service manager can be For "status" ? Yes, without a doubt. I believe a "status" command should only give the up/down state and readiness state. -- Laurent ___ 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 15:00:20 +0100 Rainer Weikusat wrote: > '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. The day I believe the preceding sentence will be the day I switch to Mac (because presumably BSD will have been kidnapped by a moneybags corporation too). If having a sane init (and sane software architecture in general) requires big money corporate sponsorship, and we get one and overthrow systemd, how long before OUR daddy warbucks does something horrible in order to FUD and EEE away the competition? We're in much the same situation as 1995, when Microsoft was getting a little obnoxious but wasn't quite bad enough to trigger a mass exodus to Linux. By 1999, no-money, no corporation Linux was experiencing huge inward migration on the server, and a noticible inward migration on the desktop. Back then, Redhat was just another distro vendor, and indeed, one of the goodguys. History tells me it can be done without money. 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, 06 Aug 2015 15:00:20 +0100 Rainer Weikusat wrote: > Laurent Bercot writes: > > 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. > > That's all nice and dandy but it all boils down to 'the code executed > by the init script was deficient in some way'. Hi Rainer, I think what Laurent is really saying is that if you choose to manage a daemon via shellscript and PID file, it's very difficult to make your shellscript in a way that *isn't* deficient in some way. 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, 06 Aug 2015 10:28:47 +0100 Rainer Weikusat 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 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
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
Hendrik Boom wrote: > 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? A lot of people do use Linux for live performance. The soundcard DAC/ADC adds some latency. The vanilla kernel is fairly good WRT latency, and depending on your needs you can compile your own kernel (or find an optimized one) for slightly lower latency. Unlike proprietary frameworks, JACK lets different apps play together without fuss. If you're hooking together several components via JACK, each connection adds the latency associated with one buffer (actually it depends on the buffer size times the number of periods, which are command-line arguments to jackd). JACK itself doesn't add latency, and has an API for reporting latencies at different nodes of the audio network, so that it can be compensated. You do need a decent soundcard to be able to do live performance. The authoritative fora for working with these issues are the Linux Audio Users and Linux Audio Developers mailing lists. As the developer of a lightweight DAW with a text interface, I've followed these lists for several years and heard a lot of music produced using Linux. With the incredible flexibility and variety of apps currently available, I would go so far as to say it's a golden age for Linux audio :) cheers, Joel > -- hendrik > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- 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 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. 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. ___ 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] Init scripts in packages
Laurent Bercot 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] multichannel audio i/o management w/o pulse/dbus
On Thu, Aug 06, 2015 at 12:09:33PM +0200, tilt! wrote: > I appreciate your kind offer of solving my specific > technical problems a lot - however, as it stands, I have > none *fingers crossed* ;-) > > What I want to accomplish is sufficiently addressed by my > listing of problems a, b (grave defects) and c, d, e, f > (various other shortcomings), the intended accomplishment > is finding and providing reliable, flexible, and thus, > reusable solutions for those problems. Let me throw in my $0.01 here. I have no problem with others wanting to improve on something that already exists. However, recent history shows that such improvements such as pulseaudio and systemd get forced on all of us, because other packages start to depend on them. So, if someone wants to create an alternative to what already exists, I think that's fine. I for one though don't want to be made to use them if I don't want to, and wouldn't want to suddenly see devuan packages start to depend on these new alternatives. If I'm happy with alsa, I should just need to install alsa. If someone is happy with oss4, they should just need to install oss4. I think this makes sense. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Rainer Weikusat writes: > Laurent Bercot 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] Init scripts in packages
Rainer Weikusat 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
Am 06.08.2015 17:49 schrieb Steve Litt: Laurent Bercot 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, gl&hf. 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
Re: [DNG] Init scripts in packages
Alexey Rochev wrote *Date: *2015-08-05 07:29 -400 *To: *dng *Subject: *[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. It occurs to me that nobody raised the obvious questions: 1. Are we seeing upstream developers shipping systemd scripts, or systemd scripts w/o sysv init scripts? I'm not sure I have. 2. What the heck are Debian developers (packagers, actually), doing removing init scripts? Me, I've been installing key packages from upstream sources for years - avoids having to deal with out-of-date packages and such. (The basic environment is certainly easier to install and maintain via apt - but key production packages, hell no.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
