X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 33302DC11C7 for ; Sun, 22 Nov 2015 03:46:24 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id F2583DC0076 for ; Sun, 22 Nov 2015 03:46:23 +0000 (UTC) Received: by padhx2 with SMTP id hx2so156580238pad.1 for ; Sat, 21 Nov 2015 19:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0iwdoBlHjVzevauZ0qgdVfvY3IHFhYg5DH5wg8Mo/o8=; b=AZoTHzzJs4q3ywrZ6UxUF3YxL3ycKvt4yz4W8SWzh/z2eeF3mBkqfnIOV/6trcMto9 GD/YhsNzxnFhcy5w7+nPC0hD6MeR/qXdF0fOfgw/hOJa6UtEBVHEFxk1kgWLYkiz1O1O NNeZQOgqoJ6fPD9TPaz/zVvccqQ+CcqG5784BBKJ1MNVH+1+hP+k+6Y5FRcYjvF5oIWI IxYJGmNvaR+V+xaucS0c6pbLSTKgywCg0QKfW4F3N/5m8Dtw4PaA6Jk4qvg0z72BPDjA /f1Dlizy6tBc3ozmWTvKs8uQjnjq3+s636rAS5u3TIKcUetoJzy/g7QmAFJt7RKbpmT7 AWIw== X-Received: by 10.98.70.141 with SMTP id o13mr8730861pfi.44.1448163982326; Sat, 21 Nov 2015 19:46:22 -0800 (PST) Received: from newbook ([50.0.225.136]) by smtp.gmail.com with ESMTPSA id ez1sm5236011pab.6.2015.11.21.19.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Nov 2015 19:46:21 -0800 (PST) Date: Sat, 21 Nov 2015 19:46:16 -0800 From: Isaac Dunham To: Christie Taylor Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] Default DHCP server on Alpine Linux v3.3 Message-ID: <20151122034615.GA8248@newbook> References: X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: ClamAV using ClamSMTP On Sat, Nov 21, 2015 at 01:56:35PM +0100, Christie Taylor wrote: > ISC DHCP is maintained by a team that focuses on DHCP and has been tested over and over on giant networks and is pretty solid. > > BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be (in > my opinion) coupled with BusyBox. It looks like they try to do everything > on what should be just the coreutilities. Bite off more than can chew. Booting a system takes more than coreutils. It takes init, a shell, coreutils, linux-utils, some networking programs... > What do you think about ISC DHCP? Maybe that v3.3 is coming soon, this could be another great change to come with it. > > https://www.isc.org/downloads/dhcp/ ISC dhcp is probably some of the most reliable code from ISC, but that isn't saying much. I always found dhclient to hang shutdown on my Debian Squeeze laptop, due to it persistently trying to release the lease after the wireless interface went down (and retrying repeatedly...). > I think the more Alpine distances from BusyBox the better. A single > binary doing all these things, from coreutilities to device manager > and dhcp server?! Crazy. Programs should be separate. For coreutilities > I recommend sbase and for the dhcp server, I think ISC DHCP is the best > out there. Try morpheus, then. http://morpheus.2f30.org/ Other than using the suckless dhcp client, it sounds more like what you want. It seems you fundamentally reject the concept of Busybox. Alpine was built around exploiting it. But if you're actually curious about what the justification for a multi-call binary like Busybox is, here are some. - shared code: Almost every program out there has a standard routine for parsing arguments. A lot of programs need to read files and convert them into numbers. A lot of programs need to write a buffer in full. There are pretty standard formats for writing errors... In summary, the bulk of most small *nix programs have a pattern that could be factored out into shared code. - total binary size: Code can be shared a lot of ways, including static and shared libraries as well as multicall binaries. Static libraries and compile-time tricks with #include only share it at the source level. If you use shared libraries, they share the same implementation. But every binary that you have has a standard ELF header, taking up a bit of space. You can only avoid this by sharing the header, which requires a single binary. (Shared libraries have their own headers, so using them is sharing code at the expense of increasing the number of headers.) - simple, atomic upgrades: Frequently, one program will rely on a specific version of another. With Busybox, you can just drop one new binary in, and you don't need to worry about whether (for example) your new ifup requires a newer version of ip, or if it uses ifconfig... And if the new binary is properly copied, you don't need to worry about what happens when an upgrade gets interrupted by a reboot. - easily portable binary: Besides not depending on external programs that might not be on every system, it's easier to just copy a single binary over. Now, I will say that Busybox does have some tools that perhaps shouldn't be there. For example: -pscan: you don't need a port scanner for most uses -dnsd: while a DNS server can be useful for small network devices that often use Busybox, this one is essentially useless without dnsmasq or similar tools, which make it redundant. -fbsplash: a timed PPM display on a framebuffer doesn't need to happen in Busybox; you'll need another file anyhow, and PPM more than makes up for any savings in space... Thanks, Isaac --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---