From owner-freebsd-sysinstall@FreeBSD.ORG Wed Apr 23 18:14:01 2014 Return-Path: Delivered-To: freebsd-sysinstall@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FF7887D; Wed, 23 Apr 2014 18:14:01 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B34511647; Wed, 23 Apr 2014 18:14:00 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id s3NIDoFb015722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 13:13:50 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Wed, 23 Apr 2014 13:13:49 -0500 From: Sender: Devin Teske To: "'Randi Harper'" , "'Allen Landsidel'" References: <201404151630.s3FGU0Zg026166@freefall.freebsd.org> In-Reply-To: Subject: RE: bin/164281: bsdinstall(8): please allow sysinstall as installer option Date: Wed, 23 Apr 2014 11:13:46 -0700 Message-ID: <012501cf5f1f$c5e7c740$51b755c0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE32P3QXoWz5+qxC3gplvlAD8ngjAFpa3p5nEM7bpA= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-23_04:2014-04-23,2014-04-23,1970-01-01 signatures=0 Cc: freebsd-sysinstall@freebsd.org X-BeenThere: freebsd-sysinstall@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Sysinstall Work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:14:01 -0000 > -----Original Message----- > From: Randi Harper [mailto:randi@freebsd.org] > Sent: Thursday, April 17, 2014 2:33 PM > To: Allen Landsidel > Cc: freebsd-sysinstall@freebsd.org > Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as installer > option > > YOU HAVE MY AXE. > > -- randi > > > On Tue, Apr 15, 2014 at 9:30 AM, Allen Landsidel > wrote: > > > The following reply was made to PR bin/164281; it has been noted by > GNATS. > > > > From: Allen Landsidel > > To: bug-followup@FreeBSD.org, cederom@tlen.pl, > > devin.teske@fisglobal.com > > Cc: > > Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as > > installer option > > Date: Tue, 15 Apr 2014 12:22:52 -0400 > > > > Any movement on your project, Devin? > > > > Many of us that have been using FreeBSD for years ('96 here) would > > love to see sysinstall return. Whatever sysinstall's failings, > > bsdinstall is far, far worse. Making bsdinstall better than sysinstall is possible. Making sysinstall better than bsdinstall is possible (if revived to some branch where it won't be insta-nuked). The issues with reviving sysinstall are as follows with commentary: 1. To run sysinstall, it has to be ported to new libdialog Ok, so that's not hard. That's trivial in-fact. Just a lot of mundane repetitive analysis of each invocation of each widget and changing the arguments to match the new API. Maybe occasionally modifying the code to call some more-appropriate widget that may be smarter than the limited selection of widgets provided by the old libdialog. 2. sysinstall doesn't support GEOM There's good news here. I'm just finishing up code on bsdconfig (which *cough* is modeled after sysinstall) to not only add GEOM support but drop all legacy methods of device inquiry (GEOM is the sole basis for device scanning; aside from ifconfig to get get the network interfaces which are not represented by GEOM). Since the bsdconfig sh(1) code is literally converted C code from legacy sysinstall(1), that opens the door for a reverse migration to teach sysinstall about GEOM (read: bsdconfig's sh(1) code simulates structs, arrays, and sundry so converting back to C code is trivial). === So recap of what it looks like... sysinstall was forced into deprecation because of a new libdailog and a need to migrate to GEOM. Nobody solved those things so it was ultimately axed and we started over. After years of toiling in a silo, I'm adding those things (but so much more), and I can see in retrospect that those things were not trivial. But here's the question... As I continue the lay the ground-work for a bsdinstall that is superior to sysinstall, do I split my time amongst that task and provision a new task of migrating sysinstall toward resurrection with the afore- mentioned fixes? That's a hard question to ask. I still have many thousands of lines of uncommitted code to work toward the end of making bsdinstall better than sysinstall, and bringing those uncommitted lines to the point of commit is still more work. Partitioning the time I spend on that megalithic load to resurrect sysinstall steals time from making it across the finish-line without legacy tools (old libdialog and old device probing that doesn't recognize GEOM). So to help answer the question of prioritization (given that demand still exists for sysinstall), I think the best way to guide us is a Wiki. I recommend that we develop a f.o Wiki that we can all edit to contain our partiticular misgiving of bsdinstall versus sysinstall. I have quite a few in-mind and they guide my work on both bsdconfig and bsdinstall (a note to those that don't understand the relationship between the two: bsdconfig receives functionality first and then later bsdinstall inherits from bsdconfig -- example: zfsboot which uses the bsdconfig API heavily). I suspect others that have taken the time to run bsdinstall that still want sysinstall will have many more nits to add to such a Wiki. The Wiki can tell me which things in bsdinstall need focus so I can focus on things that are "more broken" than others. While at the same time, I can see how much further we have to go until we can say that sysinstall is no longer needed by any workflow. That being said... with respect to the actual PR of bringing back sysinstall as an option... I'm not against it. In fact, seeing that someone posted on the PR to check-up on me, I think it's time (once 9.3 comes out) to roll a new Druid disk. For those that don't know... I serve sysinstall based media from druidbsd.sf.net for 9.x releases (albeit I haven't cut one since 9.0). I'll make sure to cut one for 9.3 so that people wanting sysinstall can not only have it, but can have the one I developed for $work which has many MANY enhancements -- *cough* including the ability to install from a USB thumb drive *cough*. (smiles) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.