Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thad Floryan Newsgroups: comp.os.linux.misc Subject: Re: What distros *don't* use systemd ? Date: Sun, 07 Sep 2014 23:08:57 -0700 Organization: ThadLABS Lines: 95 Message-ID: <540D47F9.5080601@thadlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Injection-Info: mx05.eternal-september.org; posting-host="8c9e5db8d01ced79e92159efa406567d"; logging-data="12442"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19i7htQvLDHbUPW9u/s6XwRpUdWnOIWwsI=" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) In-Reply-To: Cancel-Lock: sha1:gMeJ2nwom9FAN5YL1kFDWP/0RnI= Xref: csiph.com comp.os.linux.misc:12009 On 9/7/2014 6:50 PM, Keith Keller wrote: > On 2014-09-08, Rich wrote: >> As far as I can tell, the only point to the symlink forrest was that it >> made it easier to impliment a gui to hide the details of how to >> configure one's system from the sysadmin. > > That is of course completely inaccurate; the point of SysV init was to > be able to provide many different runlevels (init itself provides this; > even Slackware uses SysV init) and a directory per runlevel--this is > where the "symlink forest" comes from, but in this context the symlink > forest actually makes a lot of sense, because otherwise you'd have to > have separate files in each runlevel, which risks having the script for > a service in one runlevel being different from that of another runlevel. > > I wouldn't disagree that SysV style init scripts and their corresponding > runlevel directories never really caught on--people change runlevels > seldom enough, and even less seldom between levels other than 0, 1, 6, > and the default, that the effort to maintain the symlink forest seems > not worth it. But trying to claim that the ''point'' to SysV style was > to hide admin details is simply FUD (especially since any competent > sysadmin could work out the details in about five minutes). Hi Keith, That's 100% correct. I still have 3 SysV systems (3B1, UNIXpc, PC7300) in my home garage that still function perfectly and run a full SysV with 4 MB (megabyte) RAM, 67MB HD and a "measly" Motorola MC68010 at 10MHz that boots fairly quickly, supports full Ethernet and StarLAN, drives the VoicePower expansion card for a complete home PBX with voice mail, etc., and having an expansion chassis to support multiple QIC tapes for backups and data interchange. See: http://en.wikipedia.org/wiki/AT%26T_Unix_PC You can see part of my home network using 3B1s in 1985 in this 4-page excerpted PDF from the O'Reilly "Managing uucp and Usenet" book here (which is now out of print and I cannot find a full PDF of it): http://thadlabs.com/FILES/OR_Mng_uucp+Usenet.pdf 165kB During the last several years of the West Coast Computer Faire that was held annually in San Francisco , I'd demo two of my 3B1 systems in the [original] AT&T booth with one running emacs, gcc and spacewar all at the same time as seen on the builtin tilt'n'swivel monitor, and the other system was used to demo networking and program development and I let people "play" with it hands-on. These had great keyboards and 3-button mice back then, too. The systems were easy to manage, and editing rc.* files or creating new ones (e.g., rc.local) was trivial because all configs were plain ASCII files. FWIW, I ran the AT&T Silicon Valley UNIX Users' Group for the entirety of its existence until AT&T abandoned UNIX and I lost the use of the huge AT&T building that was in Sunnyvale CA (and is now the AMD HQ) for the user meetings. AT&T was a very gracious host and also provided us free food (sandwiches, drinks, fruit) for each meeting. I also submitted many of my programs to the comp.sources.unix group and many other archives (e.g., UUnet, Simtel, etc.). One of the most popular programs was tprobe (for which I still receive thanks today, 22+ years later); the shortest URL to an archive of it used to be here: http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe but that's now an aerospace site. A shell archive ('man 1 shar') is here: http://thadlabs.com/FILES/tprobe.shar.txt 46kB and a PDF of its man page created using groff is here: http://thadlabs.com/FILES/tprobe.pdf 13kB and a copy of the source file of that man page from the shar file is here: http://thadlabs.com/FILES/tprobe.man.txt 9kB and a description about tprobe is here: http://www.drdobbs.com/on-the-networks/184402700?_requestid=139511 The original purpose of tprobe was to determine why boot tapes could not be easily duplicated -- the reason was variable-length records hence the name tprobe for "tape probe". tprobe would analyze any given boot tape and could duplicate it on the current system, a remote system, or between two remote systems depending where the tape drive(s) were located with the current system in control, and not consuming RAM or disk space to do the duplication which is why it was very popular. Heh, it took longer to write the man page than it took to design the program, implement it, and test it. Writing UNIX-style man pages is a real pain which is why we see such poor or non-existent man pages for most linux distros nowadays. Thad