From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 5 10:15:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20E8B1065742 for ; Thu, 5 Jul 2012 10:15:48 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF268FC14 for ; Thu, 5 Jul 2012 10:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Message-Id:Content-Type:MIME-Version:Date:Subject:To:From; bh=c/RXrZEsCOGCpLyjfm1WwDk3FVDMhNc9tEBV1Z82zTc=; b=Ptdr4g6TW5Wrh6dAob8+JIqKLf5wbjJ8PY/IKnB5To0T4I/51z0L4/BjEbiHTTJB50pdSTUphkQNm3haFpa+1LGYCvsfHG+RwKhturkdoDDOnBqURgpsVxrvXFajPr3f; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:58516) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Smj69-0009LJ-0l for freebsd-hackers@freebsd.org; Thu, 05 Jul 2012 12:15:45 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Thu, 5 Jul 2012 12:15:44 +0200 User-Agent: KMail/1.9.10 References: <20120705082857.GB37083@server.rulingia.com> <4FF55864.8040807@FreeBSD.org> In-Reply-To: <4FF55864.8040807@FreeBSD.org> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: mail.ru.ac.za (2001:4200:1010:0:250:56ff:fe8d:5) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 10:15:48 -0000 On Thursday 05 July 2012 11:03:32 Doug Barton wrote: > On 07/05/2012 01:28, Peter Jeremy wrote: > > On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown > > > > wrote: > >> As for the idea that Linux refugees need extra help to migrate, > >> that's the sort of thinking that led to things like: > >> > >> alias dir=ls > > > > Whilst we're on the subject, can we please also have #define BEGIN > > { #define END } wired into gcc to help people migrating from Algol > > and Pascal. > > Um, this kind of elitist crap really isn't helpful. It was intended to be a slightly humorous response to your original question: > why would you *not* want a feature that tells you what to > install if you type a command that doesn't exist on the system? rather than ``elitist crap'' (as was the deliberately the over-the-top comparison to Clippy). I don't think suggesting that someone who wants to use a system learn how it works is elitist; and I don't object to optional tools to help them ``settle in'' (but see below). You might also notice that I made a suggestion that might help people migrating - namely some adaptation of the Unix Rosetta Stone in the Handbook so that people who know how to do something in Linux are quickly guided to the best way to do it in FreeBSD (and perhaps vice versa). > If the new feature gets created, and you don't want to use it, turn it > off. No problem. No. I think this is entirely the wrong way round. If the new feature is created and you want it, turn it on. Don't make me turn off something I didn't want in the first place. Given the choice between a system in which I switch on whatever I need, versus one which has absolutely everything switched on where I spend ages switching it all off/deinstalling it all, I know which I prefer - and others have made similar comments. > I haven't seen anything yet that says ``having this feature is a > universally bad idea.'' Several people have pointed out that for minor benefit, this will have the disadvantage of kicking off a subprocess searching a potentially very large database for every typo. I would call that a bad idea; certainly by comparison with a handbook entry or manpage along the lines I suggested. (I'd do it myself if I used Linux more than occasionally). Jonathan