Re: FreeBSD Installer Roadmap

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).
>> 
>> 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.
> 
> pc-sysinstall has been used as the PC-BSD installer for quite a while now, and 
> has done a lot of installs on a lot of different hardware platforms.  I'll 
> wager that the compatibility of the shell command gpart is a better bet than 
> the "stick your thumbs in you ears and yell nananana while you scribble 1's 
> and 0's to a disk and voila, there's a disklabel" approach that sysinstall 
> 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. From 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).


> 
> That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT 
> labeling, installing to ZFS, or gmirror, using geli, all require you to boot 
> to a shell and do an install by hand. I'm sure more people can chime in to 
> 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).


> 
> So my question is: Given that everyone involved is very conscious of locking 
> out FreeBSD from hardware platforms due to installer compatibility, wouldn't a 
> better use of your time be investing in the future and ensuring that it works 
> on legacy platforms as opposed to putting sysinstall on life support when it 
> already has some fairly serious missing functionality, that is only likely to 
> 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.


> 
> -- 
> Thanks,
> 
> 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_at_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 <-