Fanbois huh? vi or emacs? I'm going to be critical here - it is rare that you have personal choice over the tools your system uses. Do the job in front of you. If that means you support windows ME as a security portal(!), that's what you do... at least until you find a better job. On Thu, Sep 29, 2016 at 12:21 PM, Russell Coker via luv-main < luv-main@luv.asn.au> wrote:

On Thursday, 29 September 2016 11:08:00 AM AEST Tim Connors via luv-main wrote:

...

Stop using it! And that part is easy, just run

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

in a while 1 loop as an ordinary user.

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

(user_t:SystemLow-s0:c0.c100)root@play:~# NOTIFY_SOCKET=/run/systemd/ notify systemd-notify "" -bash: systemd-notify: command not found (user_t:SystemLow-s0:c0.c100)root@play:~# ls -l /bin/systemd-notify ls: cannot access /bin/systemd-notify: Permission denied (user_t:SystemLow-s0:c0.c100)root@play:~#

The Jessie SE Linux policy doesn't permit this. So my SE Linux Play Machine would be resistant to this attack even if it had a /run/systemd/notify socket.

A system configured as a test Play Machine running Debian/Unstable has /run/ systemd/notify but unprivileged users (even as root) are not permitted to access it. So even if a hostile user compiled their own systemd-notify program or copied it in from another system it still wouldn't do any good.

The "targeted" policy (the default) would permit this though.

-- 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

-- Dr Paul van den Bergen

On 29/09/16 16:12, Rick Moen via luv-main wrote:

ftp://linuxmafia.com/pub/humour/ed-is-the-standard-text-editor

I miss TECO. Oh no, wait, no I don't. Cheers, Andrew

On 29/09/16 17:12, Rick Moen via luv-main wrote:

On 29/09/16 16:12, Rick Moen via luv-main wrote: But what does your _name_ do in TECO? ;->

It makes me glad emacs and vi were created! :P Cheers, Andrew

On 30/09/16 08:29, Chris Samuel via luv-main wrote:

On Thursday, 29 September 2016 5:00:39 PM AEST Andrew Pam wrote:

...

I miss TECO. Oh no, wait, no I don't.

Grin, I think I missed that one, instead having to use FRED on a Honeywell L66 running GCOS-3 (from memory). That was a pure line editor, because the L66 only had a line input mode as there was a front end system between you and the main machine that only passed on input/output when hit hit enter. :-)

https://www.thinkage.ca/english/gcos/expl/fred/expl.html

Um, late 60's, some sed-like variant. It really was a _stream_ editor - you prepared a paper tape of edit commands and ran it against the original file paper tape to create the new file on paper tape. The output tape ran at 400 chars/sec, the input was optically read at faster than that.

Quoting russell@coker.com.au (russell@coker.com.au):

People who have chosen systemd have spent a lot of time making it work better and solving some real problems that other init systems have had for many years. People who want to choose SysVInit have spent a lot of time flaming people who write the code.

I continue to like OpenRC a great deal, as the init system. I'm still looking around for the most conservatively written, narrowly scoped PID1 process. (OpenRC doesn't handle being PID1.) I've written a description of how to (very easily) convert Debian 8 'Jessie' over to OpenRC -- or to runit, sysvinit, or upstart, all of those available packaged in Debian 8 -- and make that architecture decision persist. It turned out to be very easy. Actually I wrote the basic details on this mailing list, in response to a question about that. Later, I fleshed out the topic for my Web site: http://linuxmafia.com/faq/Debian/openrc-conversion.html

We had a "debate" about the relative merits of the various init systems on this list some time ago. It turned out that only one of the people who were criticising systemd had actually used it, and that person wasn't making the more extreme criticisms.

https://etbe.coker.com.au/2015/04/26/anti-systemd-people/

Both on this mailing list and on your blog, you seem obsessed with, in effect, calling some set of unnamed but broadly scoped critics names, e.g., that they're just flamers, misogynistic, homophobic, and driven by hostility and hate. I'm sure you're aware that this variety of rhetoric suffers a rather serious 'if so, so what?' problem (residing somewhere among the subvarieties of non-sequitur appeal). But anyway, I generally find it a great deal more interesting to discuss technology, than to detail at length how awful are the tribe on the other side of the figurative river. In your more _charitable_ moments, you've been known to dismiss being fond of something other than systemd as mere conservatism -- relying on, among other things, the false assumption that anything else is backwards. A point I'll get to in a moment. However, I did want to stop here and praise the 'mere conservatism' rhetoric as at least not the total non-sequitur fallacy that the name-calling is. ;->

It's quite likely that I have contributed more patches for init systems than anyone else on this list. The attitude of SysVInit fans doesn't make me inclined to spend any more effort patching that init system.

You know, I just remembered what this 'systemd must always be compared to SysVInit and nothing else' trope reminds me of: djbware fans would always characteristically compare qmail only with Sendmail, and djbdns only with BIND. This behaviour persisted _long_ after Postfix, Exim, and Courier-MTA emerged as competitors to qmail, and long after NSD/Unbound, PowerDNS, and MaraDNS/Deadwood emerged as competitors to djbdns. A cynic might imagine these worthies to be unwilling to compare against _modern_ alternatives to Prof. Bernstein's eccentric creations. Anyway, thank heavens, Unix open source offers a smorgasbord of worthwhile options in the software categories in question. Here is a partial list: init systems: systemd, Upstart, Epoch, finit, SysVinit, initng, runit, s6, OpenRC, BSD init, nosh. inits (PID1): BusyBox, SysVinit, ninit, sinit, minit, systemd, BSD init, Upstart, finit, runit, Epoch, nosh, uinit. service managers: OpenRC, finit, runit, daemontools / daemontools-encore, systemd, s6-rc, initng, Epoch, nosh, anopa, supervisord. 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. Because, really, building big feature sets into PID1? I rather think not. It should catch signals and reparent orphan processes (reap zombies), and collect their return status. Processing poweroff and reboot is nice (as part of catching signals). All else including the rest of process handling (the 'init systems' bit), such as process supervision, dependency management, daemon start/stop, libdbus interface, handling /dev changes, monitoring mount points / files / sockets / timers, parsing of various files / messages / strings, and all the rest, need not be in PID1, so I'd rather it _not_ be in such a sensitive and vital place. Yes, having process supervision in PID1 is the only way for total process control to be possible, but I don't have any use-cases where that is actually needed. And socket activation is actually a big dumb bad idea as we know from initd/xinetd, but available with sundry toolkits if you actually want it. Please notice that I don't call either systemd or its acolytes names. I merely say 'I'm glad you like it' to the latter and 'No thanks for now, but I'll bear you in mind' to the former. (And if I'm a misogynist, you'll need to account for my N.O.W. card, http://now.org/ , being older than you are. Do you want to start claiming I'm not a feminist, again? Because that was really funny the last time, so I'd love to do it again.) If I ever actually have a need for the cgroups (control groups) kernel feature, I'll look around for best of breed toolsets. Of course, LXC/OpenVZ do that, but is rather more than just simple management of control groups, and might be excessive. LXC's CGManager is that system's cgroup-wranging tool, and can be used without the rest of LXC if one wishes. And I read that OpenRC includes cgroup management, but I've not pursued that. [1] Or possibly sinit.

Quoting russell@coker.com.au (russell@coker.com.au):

Yes, you can do that. It's much easier than creating a new web site for a new "distribution" which seems to be Debian with a few packages changed.

Indeed, some of the Devuan people were rather upset with me. ;-> (A bunch of them had quite a fit over my expressed view that the desired objective could have been achieved without a distribution fork. Refreshingly, the project leader was not among those, and recognised that I merely politely hold an opinion differing from that of their project.) (I note with appreciation your having addressed this very point in your blog post: 'The sensible option would be to just maintain a separate repository of modified packages as has been done many times before.' I entirely agree.) You'll note that I carefully document on my page what _cannot_ be easily achieved with my approach, at least without supplementing Debian 8 using third-party package repos. The main thing is, of course, GNOME as a whole (but the lion's share of GNOME apps are within easy reach).

It's what I see.

Nothing wrong with your saying so. (I don't like flamers, misogynists, and homophobes, either.) I merely note that this entirely fails to to address the technical substance -- and acts as if there were nothing to discuss about that. And it seems more than a little suspicious that you spent pretty much all your time viewing with alarm the aforementioned deplorable people, with nothing I recall about other non-systemd people with dramatically different attitudes. You know some of those, of course, and did when you wrote your blog post. Their absence from your wall of anti-deplorables text seems... convenient.

I am happy for people to document how to not use systemd and I don't flame anyone for doing so. Why do they flame me and others for describing how to use systemd?

Because the existence of 7.2 billion homo saps guarantees a significant number of very odd people on the Internet? And because of John Gabriel's 'Greater Internet F***wad Theory'? ;-> (Warning: crude language, but in context not gratuitous) https://photos.smugmug.com/photos/i-mHzvgPv/2/O/i-mHzvgPv.jpg

...

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.

I think you're (probably) missing the point. Your blog post flogs the point that some bunch of unidentified (except for one notorious example) bunch of people expressing anti-systemd views behaved badly. But if so, so what? This not only says absolutely nothing about the software (to be fair, your blog intro says it won't really address the software), but also nothing about non-systemd users who aren't going around screaming and shouting, aren't cursing D-Ds in bug reports, and otherwise aren't abusing volunteers or spewing ugly antisocial behaviour. It pretends as if those (including yr. humble servant, I hope) don't exist. Worse, it attempts to slur us by association, e.g.: 'Decent people don’t want to be associated with people like MikeeUSA, the fact that the anti-systemd people seem happy to associate with him isn’t going to help their cause.'

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. Why go to the effort of supporting software if there is a better alternative that has the added benefit of avoiding assholes?

_Again_ with the comparison to _just_ SysVInit, as if OpenRC, Runit, and Upstart weren't also maintained packages in Debian-main, and as if nosh weren't available in a compatible .deb from a third-party repo, and as if s6, perp, nosh, ninit, sinit, minit, finit, Epoch, and uinit were not available in source and easy to build. Anyway, I have a difficult time believing DDs are helpless to use killfiles.

There's nothing wrong with being a bit "conservative" in the dictionary sense (IE not the Trump or Abbott sense). Being conservative in such ways is why we have had SysVInit for so long.

This is of course changing the subject, as this is not what I meant by 'mere conservatism'.

Upstart is no longer the default for Ubuntu, I guess it's future isn't that good.

I've never liked Upstart myself -- but it's open source and able to be maintained if anyone continues to care.

If you want a tiny minimal init then having one that is linked with cp, mv, etc probably isn't the way to go.

Busybox isn't exactly 'linked with' those. The code in the Busybox binary able to fulfill those functions isn't used when invoked as /sbin/init, I'm pretty sure. However, yes, it's certainly not ideal. The likes of the s6 PID1 init are probably a lot better.

The PID1 program could reap processes and then inform the supervision process about it.

Yes, but this introduces complexity that's just not really worth the benefit. Supervisors work just fine without coordinating with PID1. At $WORK, a large Internet business, we use supervisord with great success, and the theoretical holes in it from lack of coordination with PID1 really don't matter in the real world.

...

And socket activation is actually a big dumb bad idea as we know from initd/xinetd, but available with sundry toolkits if you actually want it.

Why? inetd always worked well for what it did.

And you might have noticed that it was used only for trivial services and for those unable to open sockets without help. It turned out, the alleged benefit of socket activation really didn't buy you anything. 'You save having a process until the daemon's needed.' Um, are we running out of process identifiers? 'You save RAM by not having the daemon loaded until it's needed.' Um, are we suddenly unable to have inactive processes swapped out? If the process was significant, people found over time that they were better off having the process running and inactive so that it has markedly better startup time, if nothing else. That's why inetd/xinetd got relegated to the likes of in.fingerd, chargen, and svnserve. If you actually need a superserver, there are much better ones, one per service, such as s6-tcpserver (s6 suite) or tcpsvd (Gerrit Pape's tools). Starting those superservers in parallel, as any supervision suite can, will end up being just as fast as trying to open every possible socket early on in process 1. There is really no reason at all why a superserver should be tied to an init system.

...

(And if I'm a misogynist, you'll need to account for my N.O.W. card, http://now.org/ , being older than you are. Do you want to start claiming I'm not a feminist, again? Because that was really funny the last time, so I'd love to do it again.)

https://lists.luv.asn.au/pipermail/luv-talk/2014-April/002582.html

Above is the post by Tim Josling that started the discussion you reference.

Indeed, people who link to returnofkings.com are IMO either trolling, deeply nasty, or both. But the point was that *I* am not a misogynist (and have been a member of the largest feminist organisation for 40 years).

Whenever I see a man claiming to be a feminist it usually seems to be in the context of criticising women or protecting men who do misogynistic things (like Tim Josling posting the Return of Kings article to the luv-talk list).

You want me to send you a copy of my N.O.W. card, and my cancelled cheque from 1976? ;-> I'm hardly 'desperate' to call myself a feminist. It's just something I've been unofficially pretty much my entire conscious life, and officially since I was a teenager -- just a basic attitudinal fact of my existence from an early age. And when some guy in Australia, who at that point had not even met me, tried to tell me I'm not a feminist, I found that deeply amusing. Hardly desperate, then. Satisfied to have been on the right side of history, and to have occasionally done a few small parts for that. And there are also the personal reasons. If your Mum had been suddenly widowed when you were 10, I imagine you'd have become an avowed feminist at age 10, as well. Simple loyalty applies.

Quoting russell@coker.com.au (russell@coker.com.au):

More complex things have been done in Debian before. Getting the full GNOME functionality without systemd might not be possible, but getting the functionality that most people want (IE what has been commonly available before systemd) shouldn't be difficult. Unless of course they alienate most of the people who are capable of doing the coding in question.

Even at that, maintaining compatible repos of components modified to the preferences of a community is something done all the time. I pointed out to the Devuan people that the Siduction and (now-dormant) Aptosid distributions have done exactly this, for many years. (Both of those are installable live-CD distros closely compatible with Debian-unstable with repos to do stabilisation and add some small local improvements.)

Why systemd out of all the things that I have blogged about?

Give me a few milion AUS$, and I'll do a proper sociological study. Short of that, I can speculate: Being angry at SE-Linux maintainers would be the world's lamest and least dramatic way of expressing pique at NSA over data collection. Also, poorly socialised nerds don't perceive NSA as taking their toys away the way (e.g.) entitlement-crazed debian-user subscribers do when faced with the prospect of 1000+ developers not promising to do do exactly what they, the debian-user subscribers, want. I intend the phrase 'taking their toys away' figuratively, but sometimes this can be observed more literally, a spit the dummy instance[1] -- such as when my co-worker Nick Moffitt at VA Linux Systems rashly mentioned on the internal developers' mailing list that one of the tools they were using is proprietary. I told him 'Nick, you shouldn't have been surprised at the screams of outrage. They read your posting as threatening to take their toys away.' Technogeeks do that at the drop of a hat. However, I think it a rather more likely factor that the 8Chan types had already glommed onto the systemd discussion within Debian as being a symbolic 'SJW' issue, hence they jumped in with their characteristic vitriol even though they overwhelmingly have little or no interest in Debian or even Linux. And, if you're referring in particular to your 'anti-systemd-people' blog post, if you didn't set out to flamebait that lot (and, actually, to flamebait anyone who's not an admirer of the systemd suite), you sure did a heck of a job of it without trying in _that_ posting. I mean, if you tell me you weren't aiming for that, I'll believe you, but I've seldom seen something that _is_ that flamebaity, so intended or not. And, of course, that lot are simply the noisiest people around.

Why is systemd the sole technical issue which has resulted in so much abuse? Why are 2 of the 3 topics which get abuse targetted by the same people?

Because you drew spillover from dumb, noisy, emotive culture-warfare habituated by dumb, noisy, emotive people. Obviously. Has nothing really to do with Debian, and nothing even really to do with Linux.

Actually others have been identified. But some of the discussion in question has been on private mailing lists.

I commented (obviously) only on what I saw, which is what you posted here and on your blog.

The options that were most seriously considered for a Debian default were systemd and SysVInit.

I'm of course aware of that, but this seems entirely unresponsive to my point.

Some addresses have been banned from the Debian BTS. But that doesn't scale well and causes some annoyance to people maintaining the packages in question and the Debian sysadmin team. You don't get to just use a killfile if you are part of a project like Debian.

I see nothing in the Social Contract, New Maintainer's Guide, or any other aspect of being a DD that would in any way mitigate against killfiling abusive people. Nor should there be. But on the other had, Joey Hess is a good friend of mine, and I know quite a bit about how his dismay over the whole systemd fiasco lead to his resignation and walking away -- a terrible loss to the project. I might point out that his primary source of alienation was not the flamers but rather the extreme organisational dysfunction revealed to him by the way the project conducted itself. Joey came to the conclusion that the Debian Constitution is toxic, causing dysfunction and pushing away good people as an emergent effect.

True. But the whole process of arguing about systemd has put a lot of people off. Anyone who's not up for an argument is probably giving such packages a wide berth.

As I said, Joey is a good friend of mine -- and in his view the problem was less the outside users' misbehaviour than Debian Project's, itself. (I make no comment on his view. You would have to ask him for any further particulars, so please don't expect me to provide them.)

It is exactly linked with those utilities.

{sigh} Your phrase 'linked to' has multiple meanings, and I thought it would be entirely evident that I was reading your comment as implying some of those broader meanings. _Of course_ I know that Busybox implements its version of cp, mv, ls, etc. via hard links to /usr/bin/busybox. That's the _first thing_ to learn about BusyBox. I had _thought_ my meaning was quite clear. Sometimes, Russell, you are pretty amazingly unable to deal with nuance.

Not that I think such concerns about security should be an issue. I think that PID1 should be simple enough that attacks aren't viable.

It seems wisest to pare it down to the minimal functionality required.

One corner case that socket activation could be good for is daemons that aren't really needed.

Indeed. This is where inetd/xinetd (or s6-tcpserver or tcpsvd) really shine -- on the rare cases where you need them.

...

I'm hardly 'desperate' to call myself a feminist.

Then why are we even discussing it?

Because (some months ago) you went out of your way to deny that I'm one, and I found that _very_ amusing, and because I have an entirely unfair sense of humour such that I'm glad to still needle you over that. ;-> [1] Nobody I know here in California would understand that figure of speech, so call that Oz localisation. Yr. welcome. ;->

Quoting russell@coker.com.au (russell@coker.com.au):

Yet occasionally people do such things.

I see you're back to ignoring my point. Ah well.

...

Also, poorly socialised nerds don't perceive NSA as taking their toys away the way (e.g.) entitlement-crazed debian-user subscribers do when faced with the prospect of 1000+ developers not promising to do do exactly what they, the debian-user subscribers, want.

The Snowden revelations effectively forced the world to use HTTPS. That took a few toys away.

Again, pretty much failing to grasp nuance and context, here. I don't think the intended meaning of 'taking their toys away' was unclear, but you're not really following, and seemingly not actually trying.

...

However, I think it a rather more likely factor that the 8Chan types had already glommed onto the systemd discussion within Debian as being a symbolic 'SJW' issue, hence they jumped in with their characteristic vitriol even though they overwhelmingly have little or no interest in Debian or even Linux.

However would they have got that idea?

Um, because they're pretty much a crazy rage-mob? I mean, you _do_ have some idea what I mean when I say '8chan types', right?

https://etbe.coker.com.au/2015/01/13/systemd-notes/

No, I'm referring to the above blog post which was linked from the anti- systemd-people post.

Then, I'm no wiser, since no comments are displayed there. Perhaps you deleted them (but the archive.org snapshots all have 'Comments are closed' at the bottom, too).

When someone makes malicious bug reports it takes a lot more effort to delete them than simply deleting a message. It is impossible for a regular DD to killfile someone from the BTS, only the sysadmin team can do that.

Welcome to the Internet, I guess. It's 2016, and there are bored net.randoms doing rage-mobbing. (And, again, in all likelihood, I'm betting that many of those were just joy-riding outsiders getting their entertainment from piling fuel on a scrapheap fire.)

Surprising really given all the other toxic stuff that has happened in Debian. Debian is so much better than it used to be!

_I'm_ not surprised. Joey was reacting to some pretty serious internal ugliness within the project's internal affairs to which, as a key developer, he had a front-row seat. And _also_, separately from and in addition to that, IMO the project haplessly being dragged by the GNOME multiseat API, of all the petty things, into bad administrative decisions was pretty pathetic. You think those bad administrative decisions were correct, so you think everything's better and better. We shall therefore politely agree to disagree on this matter.

But it was this issue out of the thousands of issues that have arisen previously that got the involvement of the outside users and demonstrated the problem to a level that Joey couldn't ignore.

I think it very clearly called Joey's attention to pre-existing structural problems that he felt are unfixable. And therefor resigned as a DD and orphaned all of his packages.

No, it's just that I am sticking to the exact meaning of my statement and not allowing you to reinterpret it.

Again, I really don't think my meaning was difficult to grasp, but I do think you have a serious deafness to context and nuance. (This is rather common among computerists, of course.)

I think that when a man is claiming to be a feminist it's strongly correlated to him being a jerk. This is evidence to support that theory.

Well, as they say in the American South, 'Bless your heart.' ;-> Still not interested in that copy of my 1976 cheque to join N.O.W.? And maybe I can throw in some 1980s and 1990s snapshots of my doing escort duty of Planned Parenthood clients, walking them through Operation Rescue picket lines, for good measure.

Quoting russell@coker.com.au (russell@coker.com.au):

I don't approve content-free hate comments. There were no comments about actual issues so none were approved.

I believe you, of course. Yeah, that's genuinely weird. I really have no idea why a bunch of deplorable types (sorry, joke from current USAian national politics) would be set off by that blog post with displays of culture-wars bigotry, as it's just a straightforward and well-written software tutorial.

https://mako.cc/copyrighteous/pledge-to-killfile-andrew-suffield

Hmm, key part of rationale was: However, since responses that quote unecessarily provocative messages are visible by folks who have ignored the sender, blocking email from a person (also known as killfiling) only works if done en-mass. Mistaken rationale. Please see 'Procmail Trollkiller - Filter to autodelete posts from a roster of trolls and all first-level replies unless the mail is addressed to you directly' on http://linuxmafia.com/kb/Mail/ . Further to that: http://linuxmafia.com/~rick/lexicon.html#edwards Edwards's Law "You cannot apply a technological solution to a sociological problem." Nobody seems to know who Edwards was, but pretty much the entire system administrator profession rests on the implicit assumption that he/she was egregiously mistaken. This plausible-sounding but empty-headed dictum is most often referred to as "Edwards' [sic] Law" -— by the depressingly huge mass of semi-literates unable to correctly write possessives of singular nouns ending in "s". (In _no_ way am I expressing opposition to stronger measures, including in particular bannings. I'm just saying that the cited rationale for the case of Suffield rests on the assumption that one is not very good at effective use of killfiling.)

Andrew eventually chose to resign from Debian.

I'm sure Debian Project is better for that. It's better than the usual escalation pattern where people do as much damage as they're permitted before finally flaming out. Which is a second item on my 'lexicon' page. ;-> (http://linuxmafia.com/~rick/lexicon.html#moenslaw-murdersuicide)

Things really have improved. Anyone who doesn't think so probably doesn't know what used to happen.

Glad to hear it. I'm just an interested outsider and a Debian-using sysadmin.

http://www.newyorker.com/humor/daily-shouts/as-a-vocal-male-feminist-im-offe...

I'm not particularly 'vocal' and certainly not offended at anything -- just really amused at being told I'm 'not a feminist' after 40 years' involvement with N.O.W. activities. But you have the same right to redefine words to suit your rhetoric as everyone else on the Internet, I guess.

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, russell@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/

On Monday, 3 October 2016 12:46:06 AM AEDT Craig Sanders via luv-main wrote:

[edited to put the interesting stuff at the top, and the boring stuff at the bottom where it's easily ignored.]

Good idea.

On Sat, Oct 01, 2016 at 08:05:31PM +1000, russell@coker.com.au wrote:

...

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.

yes, but bash does a lot more, and is the lot nicer to use interactively.

True. But for most of the situations where tools like busybox are typically used that isn't much of an issue. Lack of usable find and du commands on Android devices is quite annoying for me, but lack of a good shell isn't such a big deal. While I'm in the small minority of Android users who actually use a shell on an Android device, I'm not in the even tinier minority who use it enough to want a good shell.

the difference between 600K and 1.2MB (or even 2MB or 3MB if a good subset of GNU tar and other GNU tools - the rest of coreutils and find, to start with, maybe sed and awk too) can be made loadable) is minimal, even on small embedded systems these days, most have GBs of storage at least, and hundreds of MB or even a few GB of RAM..

https://www.kogan.com/au/buy/kogan-agora-6/ The most common varient of "embedded" Linux IMHO is Android phones. The cheapest Android phone that Kogan has in stock right now costs $179, has 16G of storage, and 2G of RAM. That compares well to desktop PCs in 2003. https://www.aldimobile.com.au/plans/xlvaluepack/ I just upgraded my Nexus 6P to Android 7, it was about 1G to download. So a few extra meg isn't going to make a lot of difference to that. Also 3G/4G plans are getting pretty cheap nowadays. I'm currently using the AldiMobile "XL" pack that costs $35 per 30 days for 6G of data. I chose that because sticking within a 2G limit was too difficult and it doesn't cost much. I could download a new Android image over 3G and not exceed my monthly quota.

...

The majority of Debian users don't care much which init system is in use.

the majority had no say in it, and probably aren't capable of switching to something else if systemd doesn't meet their needs.

The majority have no say in any Debian decisions apart from moving to Ubuntu or something if they don't like what Debian is doing.

...

...

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

so it's OK to break promises because some (other) people said some mean things somewhere along the line?

right.

i think what actually happened is that they knowingly lied just to get their preferred option approved, and actually had no intention of enabling or even allowing continued support of anything except systemd.

I don't think so. I originally planned to help with such things. But all the flame-wars just drained my energy. Every time I think about such work I end up just playing Warzone 2100 instead. As an aside I helped get the latest version of Warzone 2100 into Unstable, it has some nice new features, if you like RTS games then check it out.

...

and now everyone wants to just forget it.

actively discriminating against other inits is not "forgetting it"

it's fair enough to not make any personal effort to support something you don't use or are not interested in...it's quite another to reject out of hand someone else's contribution to add that support.

and "avoiding arseholes" is not a valid excuse - the areseholes aren't the ones submitting patches or otherwise doing useful work. in fact, deliberately rejecting such patches is likely to piss off some of those arseholes, so it fails even at that.

I don't think that there are many people rejecting patches. Anyway you can of course send patches, NMU packages, create private repositories, etc.

...

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.

that, to put it extremely mildly, is very far from optimal or even reasonable.

Debian is a Universal Operating System. It's not just for those who like particular packages or the most popular packages and "up yours" to everyone else - that attitude, more than anything else, is why I am still resisting the move to systemd.

i've encountered the attitude before, e.g. with djb-ware, and my warnings about the dead-end nature of qmail back then proved to be exactly right.

Qmail wasn't a problem. It worked nicely for what it aimed to do and used the Maildir standard (which was new at the time) which allowed for an easy upgrade path to Postfix.

systemd presents exactly the same kind of one-way conversion danger, once you've switched it will be extremely difficult to switch to anything else

It wasn't difficult to switch away from Qmail for most email setups. The systems that were difficult to switch were the more complicated ones that would be difficult no matter what you did. I don't think that init.d scripts are going to go away. If a decision is made to go back to them they can be retrieved from old repositories and used again.

...

The people like you aren't on "the opposite side".

loons you have to ignore. anything else just ensures you stay on their radar, and then you'll keep wondering why they keep targetting you.

there's really no point in engaging them in any way.

That's not my experience. I wrote a blog post about technical issues related to systemd and got a bunch of nasty comments that I refused to approve. I wrote a blog post about the horrible people who write such comments and got comments discussing the issues in reasonable manner. It seems that when I made it clear that sending me abuse isn't going to get a good result they decided not to send such abuse. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Hi all, Rick Moen wrote

At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream".

https://lwn.net/Articles/511726/

Unfortunately the advocating for/against tools can become a bit questionable too. Russell Coker wrote:

We had a "debate" about the relative merits of the various init systems on this list some time ago. It turned out that only one of the people who were criticising systemd had actually used it, and that person wasn't making the more extreme criticisms.

https://etbe.coker.com.au/2015/04/26/anti-systemd-people/

That is obviously April 2015. I am not sure where other people work but I, at least, cannot avoid to work in environments that are established, and I rarely have a workplace where I could just say: I do not like systemd - so I replace it with something else. So, as a systems administrator I had plenty of opportunities to deal with systemd. But I still do not like it. I also do not like Linux containers. I do not like SELinux. If I say so, it seems to be heresy in some quarters. I do like clean solutions that are easy to work with. They should be reliable. Saying: I have containers but I do not trust them is a bit like saying: I have Windows and it is safer now but I do not trust them, and for that reason better install Antivirus software. It is better to have containers and they separate resources sufficiently so you can trust them. SELinux policies are quite an expensive(in effort) afterthought to try to plug holes in case something "escaped". The policies have to be written and adapted for every application and every Linux distribution, and they are absolute useless under anything but Linux. SELinux is preventing simple solutions to work as expected. A simple link 'ln -s /opt/petros/etc/ntp.conf /etc/ntp.conf' fails without doing additional SELinux adaption. Quite often the fix has to be re-applied after a package update. I have seen many, many times where the "something is wrong" was countered with setting SELinux in permissive mode, and never revisited again.

From estimates, that covers probably 30 to 50% of systems I have encountered [I really make that up, I do not have proper statistics, sorry. So the "measurement" is subjective. Sorry. But it may give you an idea that it is not "once in a while".]

If, after many many years, this is still the case, then it is probably fair to say: This technology is not doing a good job. [Yes, I know my way around SELinux, most of the times. Actually nearly all, I would think. I just need sufficient time. And I also know what a deadline looks like, and I also see what others do around me.] Now, with systemd, it adds another layer of complexity into this ecosystem, entrenching it further. The end of it are systems that are occasionally "misbehaving", and I just hope that it is half-way safe. I would not bet on it. To argue in favour of complex systems and solutions is always amusing. People make mistakes, and with more complexity comes more opportunity to make them. systemd partially tries to solve some problems that are quite irrelevant for many scenarios. It is a good Unix tradition to use it where needed. For that reason it should easily co-exist with other solutions, not aiming to replace them. The team working on it does not seem to be keen to accommodate this. You all probably know what ISO 9001 is about. It judges how well a organisation is structured to produce good quality. I dare to say that the public behaviour of some of the "systemd people" did not foster my confidence that the structure, their decision making, is based on a strong culture which may lead to rational outcomes all of the time. Apologies, that I am not keen to take magnifying glass and scalpel to look after the systemd further in detail. The solution does not have appeal to me, and I rather spend my spare time on nicer things. Unfortunately, to come back to this:

At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream".

https://lwn.net/Articles/511726/

systemd will be harder and harder to get rid of in the Linux world in the future, and that is quite sad. For me, it means that I spend less and less time thinking about traditional Linux distributions, besides of work-related commitments. In general, it might be that some developments in the future make "Linux tomorrow" the "Windows of today", and there are enthusiasts who may create something more simple and better suitable for new products and systems coming along. Regards Peter

On Friday, 30 September 2016 2:54:42 PM AEST Ray via luv-main wrote:

Many thanks for an excellent summing up, I was going to put forward a response but your reply has covered all my points nicely. One thing though I will say is I was quite disturbed about the level of hostility in Russel's post. If systemd's supporters need to resort to this level the obvious conclusion one comes to is systemd cannot be that good.

Wow that's a really bizarre response. In my initial message I linked to my blog post about the abuse I received from anti-systemd people. If "hostility" from advocates implies that a product is deficient then all the homophobic and misogynistic abuse I received in response to a blog post ABOUT TECHNICAL ISSUES OF USING SYSTEMD is surely great evidence of the problems with SysVInit! The "hostility" you accuse me of is merely objecting to being abused by anti- systemd people and having my friends be subject to abuse for their Debian development work. The free sofware you enjoy using is written by many people who spend a lot of their time on it. Time that could be spent doing paid work or in other recreational activities. Fortunately for all of us (including you) the people who were subject to such abuse didn't cease their involvement in free software work (AFAIK) but instead moved to other areas, or in some cases dedicated some time to opposing the abuse. Yes I am spending time writing blog posts and mailing list messages about abuse in the free software community instead of developing free software. Is that REALLY what you want? Can't we just agree that abusing people who develop or support software you don't like is the wrong thing to do? If you want Debian developers to fully support SysVInit what do you think your best strategy is? Do you think that accusing me of "hostility" because I object to profane abuse is going to make me more inclined to support the init system you prefer? Or do you think it might be a better strategy to agree that abusing people who donate their free time to developing software you use for free is a bad thing? PS If you deliberately mis-spelled my name as part of a flame, that's primary- school level. Criticising my "hostile" response towards bullies is high- school level. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On 01.10.16 01:34, Craig Sanders via luv-main wrote:

anyway, systemd's borging of every function it possibly can will inevitably lead to the death of innovation in linux and bring about a software monoculture (nothing will be able to compete with it because in order to do so, a competitor will have to replicate and replace every thing it does, not just be better at one or two things). and moncultures are *always* unhealthy.

In short, the price for systemd's one or two nice (but not unique) features is far too high.

that's my position on systemd anyway, and it seems not an uncommon one.

+1 (Though I'm not sure that systemd's rapacious appetite for monolithic hegemony does a lot more than stultify its own development. In any ecological niche, more agile competitors will tend to gain ascendancy. I look forward to that, and will do what I can to avoid systemd - as I would any unwieldy dinosaur. If that involves avoiding gnome, then that's no loss.) Apropos the editor references upthread, I fell into Vi from CREDIT, capitalised because AFAIR there was no lower case. It was used on Intel 8080-powered "Blue-box" microprocessor development systems with all of _two_ 720k 8" floppy drives, one for the OS, and one for the user stuff. It behaved rather like Vi's ED commands, IIRC. And, of course, Vi is also a dinosaur, displaced by Vim with "nocompatible" set. The coming and passing of systemd will in hindsight be seen as a storm in a teacup, I suspect. (Not comparable with the couple of hours after noon on Sunday, here in the Dandenongs. From my windows I saw three 1m diameter Redgum treetops/branches snap and plunge up to 30m, crashing resoundingly in the gully immediately opposite. The neighbour's house and carport were hit by another three trees, and two others within 200m were partially demolished by trees up to 1.2m in diameter. In all, over 20 trees down along and adjacent to the street. Just as we had half the street cleared with our chainsaws before there was any sight of SES crews, I expect that the Linux community is not wholly dependent on DDs for the preferred init solution(s). Heck, even electricity can be done without for a while, cooking pasta on the wood heater by the light of a row of candles.) Erik

On 11.10.16 21:29, Russell Coker wrote:

On Tuesday, 11 October 2016 8:14:29 PM AEDT Erik Christiansen via luv-main wrote:

...

(Though I'm not sure that systemd's rapacious appetite for monolithic hegemony does a lot more than stultify its own development. In any ecological niche, more agile competitors will tend to gain ascendancy. I look forward to that, and will do what I can to avoid systemd - as I would any unwieldy dinosaur. If that involves avoiding gnome, then that's no loss.)

Did you understand the previous versions of some of the things that systemd replaces like ConsoleKit? Did you avoid them too?

That attempted diversion doesn't fix systemd. As ConsoleKit is no longer supported, it's irrelevant history - a poor diversion from what you're failing to rationally defend. Are you capable of understanding that users can not be bludgeoned into approval of work done "for your own good - so there!", no matter how religiously self-righteous the developers become over its right to replace and fossilise all it can reach? Do you understand that my opposition is not motivated by dislike of DDs or systemd's init performance, but merely by deep-seated opposition to megalomaniacal overreach of whatever colour? The *nix way is for each tool to perform a cohesive set of closely related tasks, not mimic M$, no matter how much that would help corporates monetise Linux. Erik -- (5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. RFC-1925

On 11.10.16 23:09, Russell Coker wrote:

On Tuesday, 11 October 2016 10:49:29 PM AEDT Erik Christiansen via luv-main wrote:

...

That attempted diversion doesn't fix systemd. As ConsoleKit is no longer supported, it's irrelevant history - a poor diversion from what you're failing to rationally defend.

It's no longer supported because it was replaced by systemd.

It's not as if systemd replaced things that were simple and easy to understand. It replaced other things that had already made things complex a couple of versions of Debian ago, and users hadn't complained then.

Modest mission creep would be a lot easier to sell if the logs weren't obfuscated in a deliberate DOS effort aimed at users. However, I'm not convinced that agglomerating additional complex stuff into an init process is a system optimisation. There is the danger that previously discrete processes, merged by the one team, will acquire unnecessary internal linkage, turning the whole into an inseparable monolith. As complexity rises, the inevitable destination is unmaintainability. The effect has led to demise of a UK banking system prior to commissioning, and long delays in commissioning of an airport, due to an inoperable automated baggage handling system. KISS isn't just elegant - it is the essence of survival, in the face of complexity. Erik