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(a)luv.asn.au&gt; wrote: -- Dr Paul van den Bergen

On 29/09/16 16:12, Rick Moen via luv-main wrote: I miss TECO. Oh no, wait, no I don't. Cheers, Andrew

On 29/09/16 17:12, Rick Moen via luv-main wrote: It makes me glad emacs and vi were created! :P Cheers, Andrew

On 30/09/16 08:29, Chris Samuel via luv-main wrote: 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(a)coker.com.au (russell(a)coker.com.au): 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 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. ;-> 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(a)coker.com.au (russell(a)coker.com.au): 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). 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. 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 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.' _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. This is of course changing the subject, as this is not what I meant by 'mere conservatism'. I've never liked Upstart myself -- but it's open source and able to be maintained if anyone continues to care. 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. 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 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. 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). 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(a)coker.com.au (russell(a)coker.com.au): 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.) 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. 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. I commented (obviously) only on what I saw, which is what you posted here and on your blog. I'm of course aware of that, but this seems entirely unresponsive to my point. 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. 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.) {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. It seems wisest to pare it down to the minimal functionality required. Indeed. This is where inetd/xinetd (or s6-tcpserver or tcpsvd) really shine -- on the rare cases where you need them. 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(a)coker.com.au (russell(a)coker.com.au): I see you're back to ignoring my point. Ah well. 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. 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? 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). 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.) _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. 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. 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.) 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(a)coker.com.au (russell(a)coker.com.au): 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. 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.) 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) Glad to hear it. I'm just an interested outsider and a Debian-using sysadmin. 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: There is no comparison between BLM and init systems. The majority of Debian users don't care much which init system is in use. 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. In this case yes. The people like you aren't on "the opposite side". [...] # 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: Good idea. 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. 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 have no say in any Debian decisions apart from moving to Ubuntu or something if they don't like what Debian is doing. 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. I don't think that there are many people rejecting patches. Anyway you can of course send patches, NMU packages, create private repositories, etc. 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. 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. 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 Unfortunately the advocating for/against tools can become a bit questionable too. Russell Coker wrote: 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. 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: 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: 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: +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: 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: 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