From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Elisp addiction not as bad in light of Linux forkoholism Date: Sun, 30 Nov 2014 15:51:40 +0100 Organization: Aioe.org NNTP Server Message-ID: <87k32cwxkz.fsf@debian.uxu> References: <873891sgaw.fsf@debian.uxu> <87oarp9sk4.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417359337 27907 80.91.229.3 (30 Nov 2014 14:55:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2014 14:55:37 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 30 15:55:31 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xv5uL-0002XW-P2 for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Nov 2014 15:55:29 +0100 Original-Received: from localhost ([::1]:50642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv5uL-00057F-ER for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Nov 2014 09:55:29 -0500 Original-Path: usenet.stanford.edu!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 110 Original-NNTP-Posting-Host: feB02bRejf23rfBm51Mt7Q.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:bjEJDSKmcjch4ymj88m96Od5es0= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:209034 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:101313 Archived-At: "Pascal J. Bourguignon" writes: >> init is, I think, a remnant of AT&T's UNIX System >> V. init has been around on Unix systems a long >> time, including Linux systems. init is functional >> but very heavy-handed and hackish in style - for >> example, running system userspace startup (and >> exit) processes - and in what order - relies on the >> file*names* of scripts! > > You call it hackish, but I find it is an essential > unixism. Using the file system as a database for > unix administration data, keeping other unix > adminstration data in simple text file tables > (instead of more sophisticated, but also much more > brittle databases (think for example, the various > versions of Sun NIS (Yellow Pages), NeXT/Apple > NetInfo, and now Directory Services (how long will > it last!?)). > > This is essential to keep unix administration data > in simple text files, and possibly in structured > directories (ie. with file names encoding things > like order of loading or others), because this is > what gives unix its discoverability and ease of > administration (and ease of writing administrative > tools). > > On the other hand, I don't mind people developping > non-unix systems, using a unix kernel and adding > layers, such as Android. But that should not trample > upon a true unix system. Don't even true unix systems have to change? But I don't think init is bad. The script name solution isn't what we expect today when we hope to just add or remove stuff regardless of what is already there, but I have mucked around with that myself and it was straightforward with the runlevels as directories and "services" (?) as scripts. (Yes, that is a very Unix solution.) >> So because of some child-diseases and other >> obstacles that were to be expected, there has been >> a constant ruckus and never-ending hullabaloo where >> many people - including those that should probably >> focus on their stuff - have expressed dislike in >> unpleasant ways. > > I've not looked at systemd too closely, but AFAICS, > the problem is not child-diseases, but more that > it's not enough unixy. It's kind of like launchd on > MacOSX, and, while I must admit that launchd finally > seems to work satisfactorily, I wouldn't say that it > plays nice from a unix point of view. I got systemd to work almost instantly the way init did, but it was more complicated than init as I had to wade through scripts with code that I didn't understand, and then add a couple of lines. It worked, but init is more clear for my purposes. But I would suspect systemd brings something to the table for those who does this more often and thus take the time to understand the new system. Actually it is enough for me that Debian opted for it: I trust them. >> And now, classy old Debian has forked again! > > Ubuntu forked from Debian and it's not a bad thing > (arguably). Forking is not a bad thing conceptually, it is rather it should be done when an all-but undividable piece of software is at a crossroad and people want to take different roads. For example, let's say there is code for a basic calculator. Some people want to keep it simple (keep it as it is), some people wants to do a GUI and make it a plotter as well, and some third people want to stick with CLI but extend it into a scientific calculator with e and powers and all. Now, what I would do is: do *all* of that, and then have it configurable! But OK, a fork is a good option as well because then the basic code can be reused. On the other hand, when I am against forking (as an opinion, of course I'm not saying it should be hindered in practice) - when I am against forking is when the fork is on some big system, but is due to a small software component that should be all modular already. So forking systemd to do a different systemd (let's call it systemd2) is OK, but not to fork Debian because some people prefer systemd to systemd2. Why not just make it optional? Forking OSs (distros) involves so much overhead it is much better to put that time into (modular) software. That would get us better software and people would be more inclined to compose their own systems *within* a system. So instead of distro hopper we would have better computer users as well. -- underground experts united