Date: Mon, 21 Feb 2011 18:38:03 -0800 From: Devin Teske <dteske@vicor.com> To: Josh Paetzel <josh@tcbug.org> Cc: Bruce Cran <bruce@cran.org.uk>, Devin Teske <dteske@vicor.com>, freebsd-current@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org>, freebsd-arch@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap Message-ID: <EA1368DF-9728-4492-B1FC-5F7C2B521DE7@vicor.com> In-Reply-To: <201102211612.51233.josh@tcbug.org> References: <4D35CFFB.3010302@freebsd.org> <61079648-D76C-4699-AC4D-F6EBE64ABFFC@vicor.com> <201102190844.43267.bruce@cran.org.uk> <201102211612.51233.josh@tcbug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 21, 2011, at 2:12 PM, Josh Paetzel wrote: > On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: >> On Saturday 19 February 2011 03:04:39 Devin Teske wrote: >>> There are many reasons for this, and none of them are selfish = (although >>> it remains possible to drum-up some selfish reason, all of the = reasons >>> behind our motivation are in-fact unselfish). Truth-be-told, I = welcome >>> the replacement of sysinstall but am very wary that ANY replacement = will >>> be able to exactly replicate the hardware compatibility that = sysinstall >>> currently enjoys. I do indeed envision a great celebration as = FreeBSD-9 >>> bucks sysinstall but also at the same time have nightmares of = receiving >>> waves of calls from people having trouble (for example) "installing >>> FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a >>> universe far-far-away." (yes, we do have data centers running that = very >>> equipment with uptime in the 1,000's of days). >>=20 >> I think bsdinstall as it currently is is simple enough that there = shouldn't >> be any compatibility issues: it uses gpart for partitioning, runs = tools >> like tzsetup to configure settings etc. so there's far less to go = wrong >> than sysinstall's custom code which for example could crash on the >> "probing devices" screen. >=20 > pc-sysinstall has been used as the PC-BSD installer for quite a while = now, and=20 > has done a lot of installs on a lot of different hardware platforms. = I'll=20 > wager that the compatibility of the shell command gpart is a better = bet than=20 > the "stick your thumbs in you ears and yell nananana while you = scribble 1's=20 > and 0's to a disk and voila, there's a disklabel" approach that = sysinstall=20 > uses. This is a common affront that can be assuaged simply by perusing = sysinstall's code. Unfortunately, I may be truly-alone in my opinion = that sysinstall is elegantly simple (but then again, I also have an = innate understanding of why each/every line of code exists; bourne = in-truth from a decadal melange of knowledge when it comes to ancient = architectures -- that and I routinely read the 15+ years of commit logs = "for fun"). In reality, the _only_ thing, in my honest opinion, that sysinstall = fails-at is its embracement of new technologies such as GPT, ZFS, and = geli (just to name a few; all of which you mention below). However, this = is not the position that I am (or we are, as a business collective) = coming from. =46rom the position at which we stand, sysinstall is not = [yet] deficient and despite your claims, neither does it resort to = black-magic "scribbl[ing] 1's and 0's to a disk and voila, there's a = disklabel" (by comparison standards, might one be able to say -- if = taking the same naive tone -- that gpart "scribble[s] 1's and 0's and = voila, there's a [partition table]"; the only distinction being perhaps = your own bias of MBR versus GPT which if you conversely understood the = limitations of MBR then you might not have such qualms against = disklabels). Just as it was stated by another in this thread that a system with = 1,000+ days uptime may not be a good candidate for upgrade (entirely on = the basis that such a system in its current state has proved its = meddle), we make an argument along the same lines for the install = process -- because sysinstall has served us *so exquisitely well* over = the years (its meddle being proven) we are reluctant to blindly accept = the "new kid on the block" without rigorous recension (note: in = comparison by age, any technology is young when compared to sysinstall). >=20 > That being said, sysinstall holds FreeBSD back in a lot of ways, using = GPT=20 > labeling, installing to ZFS, or gmirror, using geli, all require you = to boot=20 > to a shell and do an install by hand. I'm sure more people can chime = in to=20 > limitations in sysinstall than I can think of off the top of my head. You are absolutely correct in highlighting the most prominent = short-comings of sysinstall, but alas if you don't need those features = then completely swapping out your installer for a new one begins to make = less sense than sticking with what has served (and will continue to = serve) you well. The long and the short of this is, we don't use GPT, we don't (and = wouldn't) use ZFS as a root partition scheme, and have no use for geli = on the root disk (though may venture into using geli as a PCI solution = -- pcisecuritystandards.org -- on secondary media mounted at boot-time). Philosophically, innovation is bourne of necessity -- and we don't need = any of the things that bsdinstall brings us ... so the only thing that = bsdinstall represents is more work for me in migrating thousands upon = thousands of lines of code to the new installer, vetting every aspect of = the new installer in the process (note that we utilize sysinstall in = ways that others could only dream of -- something you'll be able to see = for yourself when I get back from Hong Kong to The States and start = publishing our/my work). That being said, if we _did_ need the features that are provided by = bsdinstall versus what is available today with sysinstall, I assure you = that there would be a concerted effort to start using bsdinstall ... our = hand would simply be forced. However, since we don't need those features = it seems silly to waste any man-hours on migration (by comparison, I can = put sysinstall on life-support with no trouble at all because I = envisaged this day coming and made preparations in the final ahn many = years ago). >=20 > So my question is: Given that everyone involved is very conscious of = locking=20 > out FreeBSD from hardware platforms due to installer compatibility, = wouldn't a=20 > better use of your time be investing in the future and ensuring that = it works=20 > on legacy platforms as opposed to putting sysinstall on life support = when it=20 > already has some fairly serious missing functionality, that is only = likely to=20 > become more of an issue in the future? On the contrary, it takes no effort whatsoever to put sysinstall on = life-support. Rather, it's going to take a very long time to prove that = bsdinstall can do what sysinstall can do. If asked to quantize what = percentage of features we use in sysinstall, I'd have to say 30%, = however the 30% that we do utilize is the underrepresented portion (the = portions that nobody talks about). Also, worth mentioning is that we've = patched sysinstall by 811 lines (by last count) to add even more = features (features that likely won't exist in bsdinstall that will need = to be ported). To make things worse, we're going to also have to completely rewrite all = the programs that generate the scripts that are then fed into = sysinstall's scripting abilities. Those programs weigh in at 3089+ lines = of code (including a mixture of Asm, C, FICL, and sh). It may come to pass that bsdinstall is not up to the task at-hand and = will require patching (just as sysinstall was originally not up to the = task at hand, and so we patched it ... ... _heavily_. Really, the crux of the issue is that our organization is **just now** = migrating off of FreeBSD-4 (yes, it's true... there are over 1,000 = FreeBSD-4.11 machines running in production at this very moment spanning = the entire United States, parts of India, and parts of the Indo-pacific = rim). Worse? We just added yet-another 200+ to those ranks in the past 2 = months. My hat is off to you sir... as I envy your position that you can be so = free-moving. We are encumbered by entrenched methods and do not have the = luxury of trying new things for the sake of change (case in-point, since = bsdinstall brings nothing new to the table that we rely upon, it truly = would be change for the sake of change in our organization). Fin de dialectics. >=20 > --=20 > Thanks, >=20 > Josh Paetzel -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA1368DF-9728-4492-B1FC-5F7C2B521DE7>