On Saturday, 1 October 2016 2:09:58 AM AEST Craig Sanders via luv-main wrote: > On Fri, Sep 30, 2016 at 02:38:54PM +1000, russ...@coker.com.au 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"
There is no comparison between BLM and init systems. The majority of Debian users don't care much which init system is in use. > > 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. That's what happens when you have a war about something. A lot of the energy that could be devoted to supporting other init systems is spent on the war and now everyone wants to just forget it. But you have the option to patch things and to run your own repository of patched packages if some DDs don't accept your patches. > > 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? In this case yes. The people like you aren't on "the opposite side". > > 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. [...] > with a few more (including tar, cp, mv, rm, and some others), busybox and > tinybox may soon be obsolete. # du -h /bin/busybox /bin/bash 632K /bin/busybox 1.1M /bin/bash # du -h /lib/x86_64-linux-gnu/libtinfo.so.5.9 /lib/x86_64-linux-gnu/ libdl-2.24.so 168K /lib/x86_64-linux-gnu/libtinfo.so.5.9 16K /lib/x86_64-linux-gnu/libdl-2.24.so Bash is still quite a bit bigger than busybox and links with a couple of libraries that busybox doesn't link with. Systems which run busybox typically run a smaller shell than bash. But hopefully a lot of the installations of busybox will cease having storage space be such a concern. My latest phone is a Nexus 6P with 64G of storage, a recent laptop I got is a Thinkpad X301 ith 64G of storage, and my first laptop had 3.2G of storage. I think we are well past the point where Android installations could have bash and coreutils installed, at least for the Nexus series. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
