From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D09171384B4 for ; Wed, 25 Nov 2015 16:28:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CD04921C083; Wed, 25 Nov 2015 16:28:28 +0000 (UTC) Received: from acheron.yagibdah.de (acheron.yagibdah.de [185.55.75.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9139B21C00B for ; Wed, 25 Nov 2015 16:28:27 +0000 (UTC) Received: from br-dmz-ip.yagibdah.de ([192.168.1.1] helo=heimdali.yagibdah.de) by acheron.yagibdah.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.85) (envelope-from ) id 1a1cvf-0002np-Sp for gentoo-user@lists.gentoo.org; Wed, 25 Nov 2015 17:28:24 +0100 Received: from lee by heimdali.yagibdah.de with local (Exim 4.85) (envelope-from ) id 1a1cvf-0003yL-Qu for gentoo-user@lists.gentoo.org; Wed, 25 Nov 2015 17:28:23 +0100 From: lee To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] https://wiki.gentoo.org/wiki/Traffic_shaping In-Reply-To: <56537B67.2040902@gmail.com> (Alan McKinnon's message of "Mon, 23 Nov 2015 22:47:35 +0200") Date: Wed, 25 Nov 2015 17:28:14 +0100 Organization: my virtual residence Message-ID: <87a8q2cach.fsf@heimdali.yagibdah.de> References: <87r3jmhwgp.fsf@heimdali.yagibdah.de> <87fuzxgdi1.fsf@heimdali.yagibdah.de> <1782051.edZZWJELC6@wstn> <1527343.MWBo1Tue37@wstn> <20151123133009.GU3539@ns1.bonedaddy.net> <87si3we9zz.fsf@heimdali.yagibdah.de> <56537B67.2040902@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Mail-Followup-To: gentoo-user@lists.gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 2ba37e26-a26f-43eb-bcbd-235f4a49de1c X-Archives-Hash: eb2f158183ed4a865f4a36f843c831cd Alan McKinnon writes: > On 23/11/2015 22:31, lee wrote: >> Todd Goodman writes: >> >>> * Peter Humphrey [151123 07:15]: >>>> On Monday 23 November 2015 12:11:36 Peter Humphrey wrote: >>>>> On Monday 23 November 2015 12:29:42 lee wrote: >>>>>> Neil Bothwick writes: >>>>>>> Grepping .config proves nothing. If a requirement of the option is not >>>>>>> set, the option may not appear in .config. The only reliable test is >>>>>>> the >>>>>>> search facility in make *config. >>>>>> >>>>>> Search facility? >>>>>> >>>>>> I only use menuconfig and often times, it's difficult to find a >>>>>> particular option I'm looking for. >>>>> >>>>> Touch the / key, then enter the option name minus the CONFIG_ prefix. Case >>>>> is not sensitive. >>>> >>>> I forgot to add that if more than one result is returned, they're numbered. >>>> Then if you hit the number key of the one you want, you go straight to it. >>> >>> And when you exit from reading that selection you get back to the >>> results list. >>> >>> It's pretty slick and sure beats looking where I "think" it should be or >>> grepping KConfig files. >> >> Wow, that might save me a lot of time :) >> >> And qdisc is extremely well hidden, I'd never have found that. It >> doesn't show up unless other options are enabled: You have to know >> exactly what you want to enable before even knowing that it's there. >> >> How are we supposed to be able to configure a kernel when we can't even >> see the available options anymore? >> > > > By using a tool that *does* show you the options and how to make them > available. Which tool is that? > The kernel devs have no desire to hold anyone's hand; they assume > (correctly IMNSHO) that anyone configuring a kernel knows what they are > doing and knows the tools to use. With that approach, sometimes the user > runs into things they can't find, and it's an acceptable price to pay. Assuming that when someone wants to do something they already know what they are doing and not allowing them to learn by hiding what there is to know leads to nobody being able to do anything. Ask around: How many people do know exactly what they are doing when they are configuring a kernel? You only need to find one who doesn't to prove the supposed assumption of the kernel developers wrong. And I never really knew what I was doing when I configured a kernel. Do you? Who does?