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 28294DC11C7 for ; Sat, 21 Nov 2015 14:23:37 +0000 (UTC) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id C176EDC0076 for ; Sat, 21 Nov 2015 14:23:36 +0000 (UTC) Received: by wmww144 with SMTP id w144so53792374wmw.0 for ; Sat, 21 Nov 2015 06:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nnu7JFacN9SMKhUMWSOPjDLPsQCAfOwkA/tDulF+HdE=; b=SfZVE28J7DjwOP5T5Fy4n+mtUqPssPHIKmuK3NtNyotll8Rxm8X9MlwB/E+q0erGa3 s9O6qJZh4Qu4XrctqAtS/xM9D/kaJYrzEOcnoA83ua05rZb5W/5xI2wNvMrfftQMvMHM YHveqycWb3wgbZAW4KYbs87k8SdkMvG4Isi4hq8w23blCdTrSg99Xx/IkMYwwB4X56ps TS0d2vohHquLFQ3TLz5aeSWXE1h0XUzCQON09hgwfPEjaI5xjcOLYpHRy9QqqI03Pi11 VMHDuCEZ0gVAsECkWHmgWTYxKPQampRq/c0SdrAANIRt9zZaO+W5xWJ+nhP7raGfPkqn wJxw== X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 X-Received: by 10.28.140.136 with SMTP id o130mr6191176wmd.78.1448115815340; Sat, 21 Nov 2015 06:23:35 -0800 (PST) Received: by 10.27.174.66 with HTTP; Sat, 21 Nov 2015 06:23:35 -0800 (PST) In-Reply-To: <5650743F.60108@skarnet.org> References: <5650743F.60108@skarnet.org> Date: Sat, 21 Nov 2015 12:23:35 -0200 Message-ID: Subject: Re: [alpine-devel] Default DHCP server on Alpine Linux v3.3 From: Alan Pillay To: Laurent Bercot Cc: AlpineLinux ML Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: ClamAV using ClamSMTP I have no knowledge on DHCP servers, so I won't comment on that. But I find the argument against Busybox that it tried to "bite off more than they can chew", as you put it a compelling one. Recently suckless developers explained why existing core-utils and linux-utils aren't properly done and why they are working on their own solutions. They specifically mention Busybox and what (from their point of view) is wrong with it. Check it out, it's an awesome watch: http://dl.sta.li/slcon/2015/slcon-2015-01-frign-suckless_core.webm If you are just interested on Busybox/Toybox/Etc problems and the solution (sbase), it's on 11:08. And they do talk about their sdhcp project on the video too, but I didn't look much into it. Best wishes. On Sat, Nov 21, 2015 at 11:40 AM, Laurent Bercot wrote: > On 21/11/2015 13:56, 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. > > > Yeah, yeah. And ISC BIND is maintained by a team that focuses on DNS > and has been tested over and over on giant networks, and is still a > complete piece of crap. > And ISC NTP is maintained by a team that focuses on NTP and has been > tested over and over on giant networks and is a horrible mess. > etc. etc. > > ISC has produced exactly one good thing, and it's the ISC license. > Every piece of software they pump out is a poorly engineered > monolithic piece of spaghetti code, broken both by design *and* by the > amount of bugs still present in it after countless releases. > > udhcpc/udhcpd, on the other hand, do exactly what they are supposed > to do, and nothing more: DHCP client and DHCP server. It's easier to > understand, easier to maintain, and the people who maintain it actually > know their heads from their asses code-wise and engineering-wise. > Don't fall for the sirens of marketing - udhcp is by far the better > product. > > >> BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be >> (in my opinion) coupled with BusyBox. > > > udhcp actually started as a separate project, and was merged into > busybox for convenience. Whether it's a good thing or a bad thing is > a political question; a lot of embedded engineers will swear that it's > a good thing. > > >> It looks like they try to do everything on what should be just the >> coreutilities. Bite off more than can chew. > > > It's a political question, and a good one; I suggest you take it to the > busybox mailing-list. I also tend to think that busybox has overstepped > its initial goal and is now trying to integrate too many utilities. > However, it does not mean that it's a bad project. Technically, the > busybox code is very good, often miles above the projects it reimplements; > and that's the most important thing. > > >> 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. > > > You don't have to use a single binary for all this. You can, if you > so desire, compile a binary named "mdev", a binary named "udhcpc", a > binary named "cp", and so on; the fact all those binaries are part of > the Busybox project should be pretty much invisible to you. Having > everything as a single binary is a choice; historically, that choice > made perfect sense, and when you're trying to use as few resources as > possible, it still makes sense today. > > You can agree or disagree with the way Busybox is organized. I'm not > a fan of the "everything in a single binary" approach, nor of the Kbuild > approach. But the fact remains that Busybox works, is pretty small, and > is very maintainable. If you discover a bug in udhcpc and you report it, > several people (some of them among the Alpine maintainers) can usually > understand what it's about very quickly, and get a fix out in 24 hours, > probably much less. I'm not sure you'd get so quick a reaction time with > ISC dhcp. > > You recommend utilities from the suckless project. That's another > valid approach, and suckless utilities are usually good. However, > "I don't like that Busybox is one project encompassing tons of > different utilities" is not enough of a reason to switch - at least, > not without research: what would be the benefits of switching from busybox > to suckless? > * quality of code-wise (probably a wash) > * maintainability-wise (probably a wash - separate projects doesn't > automatically > mean that the code is more maintainable or that the bug-fixing cycle is > shorter) > * resource-wise (probably a loss - having one binary is good for something) > > But please, no ISC software as the default. I'm all for having ISC DHCP > packaged for people who want it (and as long as I'm not the package > maintainer), > but making it the default would be a major regression. > > -- > Laurent > > > > --- > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > Help: alpine-devel+help@lists.alpinelinux.org > --- > --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---