On Fri, Sep 30, 2016 at 02:38:54PM +1000, [email protected] wrote: > > I'm sure you're aware that this variety of rhetoric suffers a rather > > serious 'if so, so what?' problem (residing somewhere among the > > It's "if so don't deal with those people" as so many people have done. > There are more than a few DDs who have nothing to do with SysVInit > because of the people who they have to deal with if they choose to do > so.
the dominant majority complaining about how hard done by they are makes me think, "yeah #ALLinitsystemsmatter" > Why go to the effort of supporting software if there is a better > alternative that has the added benefit of avoiding assholes? one of the promises given to soothe those who were concerned about sysvinit etc being ignored or deprecated after the init system vote in debian was that systemd would be the default, but sysvinit and others would continue to be supported. as predicted (but dismissed as needless paranoia at the time), other init systems ARE being deprecated and a few DDs (not many yet, but i don't expect that to last forever) are deliberately dropping sysvinit (etc) support and ignoring or rejecting patches to add such support. > To be fair the haters have had some success in making developers cease is that really what you think "being fair" constitutes? an "acknowledgement" that the opposite side are actually quite good at being evil? > But really we need more features nowadays. features that aren't unique to systemd. > > My current idea of a good system composite is a really tiny, minimal > > PID1 (leaning towards BusyBox[1]) spawning OpenRC as the init > > system. If I ever actually need service supervision, I'd probably > > use runit or supervisord on whatever daemons merit such supervision. > > If you want a tiny minimal init then having one that is linked with > cp, mv, etc probably isn't the way to go. It would be ideal if the > Busybox build system supported splitting some utilities out into > separate binaries. but this is what i really wanted to respond to. bash now supports loadable built-in commands that run without needing to fork an external command (e.g. like the standard built-ins echo, printf, kill, etc), so are fast (avoiding the fork overhead) on the command-line or in a script. the bash-builtins package in debian comes with headers and source examples, and a bunch of loadable built-ins: /usr/lib/bash/basename /usr/lib/bash/dirname /usr/lib/bash/finfo /usr/lib/bash/head /usr/lib/bash/id /usr/lib/bash/ln /usr/lib/bash/logname /usr/lib/bash/mkdir /usr/lib/bash/mypid /usr/lib/bash/pathchk /usr/lib/bash/print /usr/lib/bash/printenv /usr/lib/bash/push /usr/lib/bash/realpath /usr/lib/bash/rmdir /usr/lib/bash/setpgid /usr/lib/bash/sleep /usr/lib/bash/strftime /usr/lib/bash/sync /usr/lib/bash/tee /usr/lib/bash/truefalse /usr/lib/bash/tty /usr/lib/bash/uname /usr/lib/bash/unlink /usr/lib/bash/whoami with a few more (including tar, cp, mv, rm, and some others), busybox and tinybox may soon be obsolete. craig -- craig sanders <[email protected]> _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
