FreeBSD installers and future direction

[Bruce Cran]

I heard there was some discussion at BSDCan about the direction of a 
future FreeBSD installer.  Considering we currently have bsdinstall, 
pc-sysinstall, and an effort to revive sysinstall, I'd be interested to 
know what was decided (if anything) and whether I could help make 
progress towards getting a single really good installer/frontend - 
instead of the current situation with several, none of which have a 
much-needed UI for setting up an installation on ZFS.


--
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Matt Olander]

On Sat, May 25, 2013 at 8:43 AM, Bruce Cran  wrote:
>
> I heard there was some discussion at BSDCan about the direction of a future 
> FreeBSD installer.  Considering we currently have bsdinstall, pc-sysinstall, 
> and an effort to revive sysinstall, I'd be interested to know what was 
> decided (if anything) and whether I could help make progress towards getting 
> a single really good installer/frontend - instead of the current situation 
> with several, none of which have a much-needed UI for setting up an 
> installation on ZFS.

Hey Bruce,

>From my vague recollection, we discussed improving bsdinstall by tying
it in with pc-sysinstall, which we've been threatening to do for at
least a year. Also, there was much discussion about Devin's bsdconfig
perhaps tying in with a Google SoC Project.

I think Devin was nominated for most of the work, since he was unable
to defend himself :P

Cheers,
-matt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 25/05/2013 17:15, Matt Olander wrote:

 From my vague recollection, we discussed improving bsdinstall by tying
it in with pc-sysinstall, which we've been threatening to do for at
least a year. Also, there was much discussion about Devin's bsdconfig
perhaps tying in with a Google SoC Project.

I think Devin was nominated for most of the work, since he was unable
to defend himself :P


Thanks. From previous discussions with Devin I think he has other plans 
for the installer that don't involve pc-sysinstall. But since it seems 
the future is all sh(1) code, I won't be able to contribute.


https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with 
pc-sysinstall - are these being fixed?


--
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Nathan Whitehorn]

On 05/25/13 13:26, Bruce Cran wrote:

On 25/05/2013 17:15, Matt Olander wrote:

 From my vague recollection, we discussed improving bsdinstall by tying
it in with pc-sysinstall, which we've been threatening to do for at
least a year. Also, there was much discussion about Devin's bsdconfig
perhaps tying in with a Google SoC Project.

I think Devin was nominated for most of the work, since he was unable
to defend himself :P


Thanks. From previous discussions with Devin I think he has other 
plans for the installer that don't involve pc-sysinstall. But since it 
seems the future is all sh(1) code, I won't be able to contribute.


https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations 
with pc-sysinstall - are these being fixed?




I'm not aware of any movement there (on either side of the table). I'd 
personally be very suspicious of an all-sh(1) future -- by far the 
cleanest parts of bsdinstall are in C -- and this is especially true for 
interacting with geom. That said, since I've lost nearly all of my free 
time and ability to work on bsdinstall, I won't get in the way of anyone 
else working on things

-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Dirk Engling]

On 26.05.13 01:07, Nathan Whitehorn wrote:

> I'm not aware of any movement there (on either side of the table). I'd
> personally be very suspicious of an all-sh(1) future -- by far the
> cleanest parts of bsdinstall are in C -- and this is especially true for
> interacting with geom. That said, since I've lost nearly all of my free
> time and ability to work on bsdinstall, I won't get in the way of anyone
> else working on things

As discussed at BSDCan, I'd be willing to participate in the development
and at least implement setting up zpools/zfs and geli/gbde providers. I
have done similar things in sh in my ezjail tools and think I can glue
the rest together.

Scanning through the pc-sysinstall code, I find nothing too fancy there
regarding either interaction with zfs nor geom tools. I do not think it
is necessary as a back end just for these features.

Nathan, is there any design rationale available for the scripts, e.g. on
why you chose sh versus C and were you provided with some kind of wish
list/requirements in the first place? Any particular mail thread to scan
through beforehand?

Regards,

  erdgeist
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Super Bisquit]

Please don't turn this into an architecture dependent mess. PCBSD is i386 &
AMD64 only.


On Sat, May 25, 2013 at 9:01 PM, Dirk Engling  wrote:

> On 26.05.13 01:07, Nathan Whitehorn wrote:
>
> > I'm not aware of any movement there (on either side of the table). I'd
> > personally be very suspicious of an all-sh(1) future -- by far the
> > cleanest parts of bsdinstall are in C -- and this is especially true for
> > interacting with geom. That said, since I've lost nearly all of my free
> > time and ability to work on bsdinstall, I won't get in the way of anyone
> > else working on things
>
> As discussed at BSDCan, I'd be willing to participate in the development
> and at least implement setting up zpools/zfs and geli/gbde providers. I
> have done similar things in sh in my ezjail tools and think I can glue
> the rest together.
>
> Scanning through the pc-sysinstall code, I find nothing too fancy there
> regarding either interaction with zfs nor geom tools. I do not think it
> is necessary as a back end just for these features.
>
> Nathan, is there any design rationale available for the scripts, e.g. on
> why you chose sh versus C and were you provided with some kind of wish
> list/requirements in the first place? Any particular mail thread to scan
> through beforehand?
>
> Regards,
>
>   erdgeist
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 9:15 AM, Matt Olander wrote:

> On Sat, May 25, 2013 at 8:43 AM, Bruce Cran  wrote:
>> 
>> I heard there was some discussion at BSDCan about the direction of a future 
>> FreeBSD installer.  Considering we currently have bsdinstall, pc-sysinstall, 
>> and an effort to revive sysinstall, I'd be interested to know what was 
>> decided (if anything) and whether I could help make progress towards getting 
>> a single really good installer/frontend - instead of the current situation 
>> with several, none of which have a much-needed UI for setting up an 
>> installation on ZFS.
> 
> Hey Bruce,
> 
> From my vague recollection, we discussed improving bsdinstall by tying
> it in with pc-sysinstall, which we've been threatening to do for at
> least a year. Also, there was much discussion about Devin's bsdconfig
> perhaps tying in with a Google SoC Project.
> 

There is indeed a GSoC project to address the situation w/regard to installers.

The GSoC project is one submitted by Harsh Bhatt and I've submitted that I wish 
to Mentor. The project is titled:

"Making pc-sysinstall FreeBSD ready by porting it to multiple architectures"

The project is designed as such to increase possibilities w/respect to 
installers. To elaborate…

Integrating bsdinstall with pc-sysinstall would introduce a regression because 
bsdinstall currently supports all platforms, whereas pc-sysinstall has 
hard-coded assumptions specific to the x86 platform (i386 and amd64 included). 
If bsdinstall was ever going to be programmed to use pc-sysinstall as a 
back-end, pc-sysinstall would have to be cleaned up.

I'm in no way pushing to integrate bsdinstall with pc-sysinstall… but I *am* 
saying this is a GSoC project to look out for. The goal of the project is to 
see if it is even possible to remedy any possibility that tying bsdinstall to 
pc-sysinstall would introduce a regression in platform support. If the project 
is successful, PC-BSD should be able to immediately benefit from the fruits 
thereof (as -- correct me if I'm wrong -- the graphical PC-BSD installer uses 
pc-sysinstall as a back-end).

ASIDE: For what it's worth, it's somewhat convenient to think that in a simple 
world -- because pc-sysinstall is already the backend of the PC-BSD GUI 
installer -- FreeBSD would have bsdinstall as the TUI front-end to the same 
back-end. But however, I'm not naïve and can't imagine that as being clean or 
elegant unless we can clean up pc-sysinstall. Cleaning up the code is a another 
major focal-point of the aforementioned GSoC project.

With respect to my bsdconfig… (how it relates to installers)

Just as there were blockers preventing pc-sysinstall from being integrated into 
bsdinstall.

There are blockers that prevent bsdinstall from being integrated into the 
larger bsdconfig framework.

In the case of pc-sysinstall integrating to bsdinstall, pc-sysinstall doesn't 
support all the target architectures that bsdinstall does. Meanwhile, in the 
case of bsdinstall integrating into bsdconfig, bsdinstall doesn't support all 
the features of bsdconfig.

Luckily, introduction of most features to bring bsdinstall on-par with 
bsdconfig will be easy as we can just make bsdinstall use the subroutine 
includes from bsdconfig. However, there are other things that just can't be 
done without plain sweat and labor…

For example, making bsdinstall i18n-ready (as bsdconfig is). I expect this to 
take (with a medium effort) a week or two, aided by the fact that the dialog(1) 
abstraction API offered by bsdconfig makes most of that transparent (for 
example, you don't have to worry about whether the "Yes" button says "Ja", 
"Oui", or "Yes" -- you just call f_dialog_yesno() and it worried about how to 
call dialog(1) to form the proper i18n-compatible prompt).

Another big change to bsdinstall would be to make it *more* modular and rewrite 
the C components to be in sh.


> I think Devin was nominated for most of the work, since he was unable
> to defend himself :P
> 

I don't mind being volunteered. In earnest, I figure the code I'm working on is 
volunteering enough.
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 11:26 AM, Bruce Cran wrote:

> On 25/05/2013 17:15, Matt Olander wrote:
>> From my vague recollection, we discussed improving bsdinstall by tying
>> it in with pc-sysinstall, which we've been threatening to do for at
>> least a year. Also, there was much discussion about Devin's bsdconfig
>> perhaps tying in with a Google SoC Project.
>> 
>> I think Devin was nominated for most of the work, since he was unable
>> to defend himself :P
> 
> Thanks. From previous discussions with Devin I think he has other plans for 
> the installer that don't involve pc-sysinstall. But since it seems the future 
> is all sh(1) code, I won't be able to contribute.
> 

The future of how these softwares become entangled to produce something better:

+ bsdinstall
+ pc-sysinstall
+ bsdconfig

Is in my mind entirely still open as I work to finish up bsdconfig.

I was thinking…

Perhaps just rewrite bsdinstall from scratch (using the existing code as a 
template).

Have to put pc-sysinstall on the back-burner for any/all considerations until 
the code is cleaned up and actually usable on all architectures (there's a GSoC 
project to do exactly that -- I'm the potential mentor; project is pending 
status).

So unless this GSoC goes through and we are able to (as we plan) clean up that 
mess…

Defacto plan is to just rewrite bsdinstall from scratch (again… using the 
existing code as a template).

In said rewrite… I'd *heavily* leverate usr.sbin/bsdconfig/share/*.subr 
(specifically "dialog.subr" -- the abstraction layer that allows me to have 
nice i18n-ready dialogs and also gracefully handle dialog in a way that makes 
my code look very clean).



> https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with 
> pc-sysinstall - are these being fixed?
> 

I can see if the GSoC student for the "Making pc-sysinstall FreeBSD ready by 
porting it to multiple architectures" project is willing to incorporate any of 
those limitations into his work. But I think the focus of the project should be 
to clean up the code and make it work on at least one other important non-x86 
architecture. Barring that…

You're absolutely right in stating that any/all discussions on merging 
pc-sysinstall with bsdinstall would result in a regression with pc-sysinstall 
in its current state.
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 4:07 PM, Nathan Whitehorn wrote:

> On 05/25/13 13:26, Bruce Cran wrote:
>> On 25/05/2013 17:15, Matt Olander wrote:
>>> From my vague recollection, we discussed improving bsdinstall by tying
>>> it in with pc-sysinstall, which we've been threatening to do for at
>>> least a year. Also, there was much discussion about Devin's bsdconfig
>>> perhaps tying in with a Google SoC Project.
>>> 
>>> I think Devin was nominated for most of the work, since he was unable
>>> to defend himself :P
>> 
>> Thanks. From previous discussions with Devin I think he has other plans for 
>> the installer that don't involve pc-sysinstall. But since it seems the 
>> future is all sh(1) code, I won't be able to contribute.
>> 
>> https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with 
>> pc-sysinstall - are these being fixed?
>> 
> 
> I'm not aware of any movement there (on either side of the table). I'd 
> personally be very suspicious of an all-sh(1) future -- by far the cleanest 
> parts of bsdinstall are in C -- and this is especially true for interacting 
> with geom.

So that I can get a feel for the expectations on quality of product…

You say the cleanest parts of bsdinstall are in C.

What makes the sh parts unclean? Not looking for any particular answer… just 
want your opinion.

I've been working very hard to produce a heavy-lifting "dialog.subr" (see 
base/head/usr.sbin/bsdconfig/share/dialog.subr) which makes dialog(1) work very 
nice and clean in sh(1). However, this may not be your concern, and you may 
instead have some other "cleanliness" insight that I can address in my work.
-- 
Devin


> That said, since I've lost nearly all of my free time and ability to work on 
> bsdinstall, I won't get in the way of anyone else working on things
> -Nathan
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 6:01 PM, Dirk Engling wrote:

> On 26.05.13 01:07, Nathan Whitehorn wrote:
> 
>> I'm not aware of any movement there (on either side of the table). I'd
>> personally be very suspicious of an all-sh(1) future -- by far the
>> cleanest parts of bsdinstall are in C -- and this is especially true for
>> interacting with geom. That said, since I've lost nearly all of my free
>> time and ability to work on bsdinstall, I won't get in the way of anyone
>> else working on things
> 
> As discussed at BSDCan, I'd be willing to participate in the development
> and at least implement setting up zpools/zfs and geli/gbde providers. I
> have done similar things in sh in my ezjail tools and think I can glue
> the rest together.
> 

Very Cool!

I do encourage you to take a peak at bsdconfig either from HEAD or from ports 
(in sysutils)…

However, I'm getting ready to drastically change the API very soon (as 
previously threatened). I'm in the home-stretch and I'm trying to get in all 
the API changes before broaching the idea of taking off the "WITH_BSDCONFIG" 
build-option requirement.


> Scanning through the pc-sysinstall code, I find nothing too fancy there
> regarding either interaction with zfs nor geom tools. I do not think it
> is necessary as a back end just for these features.
> 

I tend to agree.

In fact… the directory structure of pc-sysinstall and even the way it stores 
the subroutines in *.sh files means I would be compelled to restructure the 
thing into proper "includes".

Since I intend to rework bsdinstall to use bsdconfig's libraries (e.g. 
"dialog.subr"), it sounds like a really nice path would be to develop:

base/head/usr.sbin/bsdconfig/share/zfs.subr
base/head/usr.sbin/bsdconfig/share/geom/
base/head/usr.sbin/bsdconfig/share/geom/geli.subr

And then bsdinstall could include those. The reason I tell myself that it would 
be better if they lived in bsdconfig and got imported at runtime by bsdinstall 
(rather than living in bsdinstall) is that I want to move to brand the 
utilities in this way:

bsdinstall is the program designed to install things (bare metal, jails, etc.)
bsdconfig is the program designed to configure things either during 
installation time or post-installation time

bsdinstall would be used on the boot media to install bare metal (but during 
that installation, made use bsdconfig for things like configuring users, boot 
services, networking, etc.). It will also be used after installation and 
running in multi-user land to do things like install jails.

So in other words… anytime something could conceivably be wanted by bsdconfig… 
we should just birth it there and have bsdinstall reach out for it. Seems to 
make sense… a person installs once but configures many times.

Guess I'm saying of course, that there'd be a great use for a zfs and geli 
library to bsdconfig for managing zfs after booting, etc.



> Nathan, is there any design rationale available for the scripts, e.g. on
> why you chose sh versus C and were you provided with some kind of wish
> list/requirements in the first place? Any particular mail thread to scan
> through beforehand?
> 

Can't answer for Nathan (and not sure if you want my opinion), but…

I chose 100% sh for bsdconfig because of a few good reasons…

I ultimately wanted to (and did) make it scriptable. The scripts are actually 
`sourced' shell scripts. So…

Because bsdconfig is sh, and the script is sh, the script has access to all of 
the bsdconfig internals, every API call, every variable, and can do nearly 
anything. There are no frustrating moments where a C aspect doesn't support 
running in a desired mode because that particular aspect was not made 
configurable or tunable. Not that this was (or is) a problem at all currently… 
just that it *was* a problem with sysinstall. For example…

sysinstall had a deviceRescan() function but the dispatch.c system did not make 
*that* particular function available through the system of hard-coded resWords 
(reserved words) that were allowed in a script. So… if you wanted to have a 
sysinstall script that (a) formatted some disks with some slices and (b) then 
formatted those slices with some BSD labels … well… you couldn't (note: this is 
not to say couldn't get sysinstall to write both slices and labels, just that 
if you wanted to do this *OUT* of the context of a full install, you couldn't). 
The problem was that you really needed to call "deviceRescan" after doing the 
slice action on the bare metal so that sysinstall would pick up the "s1" slice 
on which you wanted to later write labels on.

In the case of sysinstall… a one-line change of adding the deviceRescan() 
function to the resWord mapping in dispatch.c would have made that 
functionality available to scripts.

bsdconfig doesn't have that problem because the scripts are actually shell 
scripts and the old sysinstall commands are replicated by shell functions. 
There is never any need to "map" a function before it becomes available

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 7:51 PM, Super Bisquit wrote:

> Please don't turn this into an architecture dependent mess. PCBSD is i386 &
> AMD64 only.
> 

There's a GSoC project (of which I'm potential mentor) to fix that.

However, you are entirely right… we can't in all seriousness even think about 
using pc-sysinstall until it is solid on all architectures as bsdinstall 
already is.

GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple 
architectures"
-- 
Devin



> 
> On Sat, May 25, 2013 at 9:01 PM, Dirk Engling  wrote:
> 
>> On 26.05.13 01:07, Nathan Whitehorn wrote:
>> 
>>> I'm not aware of any movement there (on either side of the table). I'd
>>> personally be very suspicious of an all-sh(1) future -- by far the
>>> cleanest parts of bsdinstall are in C -- and this is especially true for
>>> interacting with geom. That said, since I've lost nearly all of my free
>>> time and ability to work on bsdinstall, I won't get in the way of anyone
>>> else working on things
>> 
>> As discussed at BSDCan, I'd be willing to participate in the development
>> and at least implement setting up zpools/zfs and geli/gbde providers. I
>> have done similar things in sh in my ezjail tools and think I can glue
>> the rest together.
>> 
>> Scanning through the pc-sysinstall code, I find nothing too fancy there
>> regarding either interaction with zfs nor geom tools. I do not think it
>> is necessary as a back end just for these features.
>> 
>> Nathan, is there any design rationale available for the scripts, e.g. on
>> why you chose sh versus C and were you provided with some kind of wish
>> list/requirements in the first place? Any particular mail thread to scan
>> through beforehand?
>> 
>> Regards,
>> 
>>  erdgeist
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Super Bisquit]

May I- and others- see the hyperlink to the project,
please?


On Sat, May 25, 2013 at 11:45 PM, Teske, Devin wrote:

>
> On May 25, 2013, at 7:51 PM, Super Bisquit wrote:
>
> > Please don't turn this into an architecture dependent mess. PCBSD is
> i386 &
> > AMD64 only.
> >
>
> There's a GSoC project (of which I'm potential mentor) to fix that.
>
> However, you are entirely right… we can't in all seriousness even think
> about using pc-sysinstall until it is solid on all architectures as
> bsdinstall already is.
>
> GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to
> multiple architectures"
> --
> Devin
>
>
>
> >
> > On Sat, May 25, 2013 at 9:01 PM, Dirk Engling 
> wrote:
> >
> >> On 26.05.13 01:07, Nathan Whitehorn wrote:
> >>
> >>> I'm not aware of any movement there (on either side of the table). I'd
> >>> personally be very suspicious of an all-sh(1) future -- by far the
> >>> cleanest parts of bsdinstall are in C -- and this is especially true
> for
> >>> interacting with geom. That said, since I've lost nearly all of my free
> >>> time and ability to work on bsdinstall, I won't get in the way of
> anyone
> >>> else working on things
> >>
> >> As discussed at BSDCan, I'd be willing to participate in the development
> >> and at least implement setting up zpools/zfs and geli/gbde providers. I
> >> have done similar things in sh in my ezjail tools and think I can glue
> >> the rest together.
> >>
> >> Scanning through the pc-sysinstall code, I find nothing too fancy there
> >> regarding either interaction with zfs nor geom tools. I do not think it
> >> is necessary as a back end just for these features.
> >>
> >> Nathan, is there any design rationale available for the scripts, e.g. on
> >> why you chose sh versus C and were you provided with some kind of wish
> >> list/requirements in the first place? Any particular mail thread to scan
> >> through beforehand?
> >>
> >> Regards,
> >>
> >>  erdgeist
> >> ___
> >> freebsd-hackers@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> To unsubscribe, send any mail to "
> freebsd-hackers-unsubscr...@freebsd.org"
> >>
> > ___
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hackers-unsubscr...@freebsd.org"
>
> _
> 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.
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Dirk Engling]

On 26.05.13 04:51, Super Bisquit wrote:
> Please don't turn this into an architecture dependent mess. PCBSD is
> i386 & AMD64 only.

Read my email thoroughly and notice that I never seriously considered
using pc-sysinstall after looking into it. Don't worry.

  erdgeist
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 9:58 AM, Super Bisquit wrote:

May I- and others- see the hyperlink to the project,
please?


Absolutely…

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
--
Devin



On Sat, May 25, 2013 at 11:45 PM, Teske, Devin 
mailto:devin.te...@fisglobal.com>> wrote:

On May 25, 2013, at 7:51 PM, Super Bisquit wrote:

> Please don't turn this into an architecture dependent mess. PCBSD is i386 &
> AMD64 only.
>

There's a GSoC project (of which I'm potential mentor) to fix that.

However, you are entirely right… we can't in all seriousness even think about 
using pc-sysinstall until it is solid on all architectures as bsdinstall 
already is.

GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple 
architectures"
--
Devin



>
> On Sat, May 25, 2013 at 9:01 PM, Dirk Engling 
> mailto:erdge...@erdgeist.org>> wrote:
>
>> On 26.05.13 01:07, Nathan Whitehorn wrote:
>>
>>> I'm not aware of any movement there (on either side of the table). I'd
>>> personally be very suspicious of an all-sh(1) future -- by far the
>>> cleanest parts of bsdinstall are in C -- and this is especially true for
>>> interacting with geom. That said, since I've lost nearly all of my free
>>> time and ability to work on bsdinstall, I won't get in the way of anyone
>>> else working on things
>>
>> As discussed at BSDCan, I'd be willing to participate in the development
>> and at least implement setting up zpools/zfs and geli/gbde providers. I
>> have done similar things in sh in my ezjail tools and think I can glue
>> the rest together.
>>
>> Scanning through the pc-sysinstall code, I find nothing too fancy there
>> regarding either interaction with zfs nor geom tools. I do not think it
>> is necessary as a back end just for these features.
>>
>> Nathan, is there any design rationale available for the scripts, e.g. on
>> why you chose sh versus C and were you provided with some kind of wish
>> list/requirements in the first place? Any particular mail thread to scan
>> through beforehand?
>>
>> Regards,
>>
>>  erdgeist
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to 
>> "freebsd-hackers-unsubscr...@freebsd.org"
>>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscr...@freebsd.org"

_
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.


_
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 26/05/2013 18:54, Teske, Devin wrote:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1


"This proposal is not made public, and you are not the student who 
submitted the proposal, nor are you a mentor for the organization it was 
submitted to."


--
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 11:14 AM, Bruce Cran wrote:

> On 26/05/2013 18:54, Teske, Devin wrote:
>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
> 
> "This proposal is not made public, and you are not the student who submitted 
> the proposal, nor are you a mentor for the organization it was submitted to."
> 

So, uh… register?

I can see all private projects and all I did was register with google-melange.

I'm not aware of a way to make it public versus private.
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Dirk Engling]

On 26.05.13 05:42, Teske, Devin wrote:

> I chose 100% sh for bsdconfig because of a few good reasons…

First, the partedit tool makes heavy use of libgeom and the structs
returned from that lib, so I've rather wondered why for some parts C was
preferred, and not the other way around.

Still, thanks for pointing all that out, but I rather wanted to look at
the installer from another angle, as it is supposed to provide everyone
from FreeBSD novices to experts with a comfortable way to do things the
right way and yet be flexible enough to avoid abandoning the tool once
the requirements differ.

So I wonder if there has ever been a best practices document on how to
"properly" set up zpools, when to advice the user against using zfs at
all, whether it makes sense to use geli on the boot device, when it is
better to have multiple zpools and only encrypt the data pool(s). Maybe
the installer should be advocating concepts like manageBE, pre-setting
noexec-flags on /var, setting some default quotas.

The second part, of course, is to find visual concepts on how the user
is guided through the default and expert bsdinstall/bsdconfig screens to
cover the most common scenarios and still offer enough options.

All this doesn't need a developer but a bunch of veteran FreeBSD admins,
a wiki and a lot of bike sheds to paint.

If there's no such document yet, I propose editing one in the wiki.

  erdgeist
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 27/05/2013 00:27, Dirk Engling wrote:

Still, thanks for pointing all that out, but I rather wanted to look at
the installer from another angle, as it is supposed to provide everyone
from FreeBSD novices to experts with a comfortable way to do things the
right way and yet be flexible enough to avoid abandoning the tool once
the requirements differ.


I'd like to see an option of different front-ends for the 
installer/configurator to cater for different users - at least an X11 
application, but there was also an idea of having a http-based 
installation UI.


--
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 4:27 PM, Dirk Engling wrote:

> On 26.05.13 05:42, Teske, Devin wrote:
> 
>> I chose 100% sh for bsdconfig because of a few good reasons…
> 
> First, the partedit tool makes heavy use of libgeom and the structs
> returned from that lib, so I've rather wondered why for some parts C was
> preferred, and not the other way around.
> 

I tend to be of the mind that shell (gpart in this case) would be a better
choice for the installer than tapping into geom… (for the following)

Using gpart makes you exercise both the end-user utilities and the
developer framework (by-way of those utilities) whereas if you stick
to just the developer framework (libgeom in this case) there's a chance
that the installer can do things that can't be done from the command-line.

Just a thought.

If structs are what you want, I have those in bsdconfig:

dte...@scribe9.vicor.com share $ pwd
/home/dteske/src/freebsd_svn/base/head/usr.sbin/bsdconfig/share
dte...@scribe9.vicor.com share $ grep '^# f_' struct.subr 
# f_struct_define $type $member_name1 ...
# f_struct_new $type $name
# f_struct $name
# f_struct $name get $property [$var_to_set]
# f_struct $name set $property $new_value
# f_struct $name unset $property
# f_struct_free $name
# f_struct_copy $from_name $to_name

Naturally, because it's shell, the struct members are loosely typed (so
no need to define their type).

So I think there's great potential to write a very clean "gpart.subr" that
combines the power of the above "struct.subr" with perhaps another
of my modules…

dte...@scribe9.vicor.com share $ grep '^# f_' device.subr 
# f_device_try $name [$i [$var_path]]
# f_device_register $name $desc $devname $type $enabled $init_function \
# f_device_reset
# f_device_get_all
# f_device_name_get $type $name type|desc|max [$var_to_set]
# f_device_name_set $type $name $desc [$max]
# f_device_desc $device_name $device_type [$var_to_set]
# f_device_rescan
# f_device_find $name [$type [$var_to_set]] 
# f_device_init $name
# f_device_get $name $file [$probe]
# f_device_shutdown $name
# f_device_menu $title $prompt $hline $device_type [$helpfile]

NOTE: device.subr already uses struct.subr. For example, $device_type
is actually a struct type, and when you call f_device_get_all() it creates a
series of structs named "device_{name}" (where {name} is something
like "da0") and the struct holds many properties for the device.

I don't think there's any reason why we have to write it in C if we can write
it in sh.



> Still, thanks for pointing all that out, but I rather wanted to look at
> the installer from another angle, as it is supposed to provide everyone
> from FreeBSD novices to experts with a comfortable way to do things the
> right way and yet be flexible enough to avoid abandoning the tool once
> the requirements differ.
> 

I don't see your angle as perpendicular to my own… but rather that I would
like to seek to define in concrete terms what that means.

Working backwards from your list…

Flexibility: I think using a conflated shell namespace (where the entire
installer is sh and is in-turn scriptable by sh) gives the most flexibility. 
Much
more than flexibility, I think this approach also lowers the barrier-to-entry 
for
integration and automation engineers. Open questions: was the fact that
sysinstall was all C with a few forks to external programs a barrier to system-
integration and system-automation engineers trying to automate the install-
and-configure process? Maybe. The BSD-P certification exam requires you
to script sysinstall in FreeBSD-8. If we go all-shell, this would become much
easier IMHO.

Novices to Experts: I'd like to strive to hit a full spectrum between those two
points. I recognize that these are not two discrete ends of a dichotomous
tree, but instead a journey that is traversed (assuming the novice stays with
FreeBSD after trying it out). There are no defined sets of travel along this
line either, some people skip being a novice when they come to FreeBSD
for the first time because they have experience with similar operating systems.
That's why I've taken to developing every aspect of the utility. I want to see
the installer and configurator helpful to all people from developers to grand-
mothers and everybody in-between (that's the modular part… if you don't
like the way something works… the sh(1) nature allows you to simply
override it with your own module).




> So I wonder if there has ever been a best practices document on how to
> "properly" set up zpools, when to advice the user against using zfs at
> all, whether it makes sense to use geli on the boot device, when it is
> better to have multiple zpools and only encrypt the data pool(s). Maybe
> the installer should be advocating concepts like manageBE, pre-setting
> noexec-flags on /var, setting some default quotas.
> 

You'll get no complaints from me here.

The installer is (in my view) not only where we need to provide the most helpful
functionality, but the best place to s

Re: FreeBSD installers and future direction

[Daniel Eischen]

On Mon, 27 May 2013, Teske, Devin wrote:


I don't think there's any reason why we have to write it in C if we can write
it in sh.


I don't really care one way or the other (C or sh), but
I can say that I can understand(*) well structured C a lot
better than well structured sh.  Having something more
strongly typed certainly helps understanding.

(*) Assuming some level of complexity (I know that's
subjective).

--
DE
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/26/13 10:03 AM, Dirk Engling wrote:

On 26.05.13 04:51, Super Bisquit wrote:

Please don't turn this into an architecture dependent mess. PCBSD is
i386 & AMD64 only.

Read my email thoroughly and notice that I never seriously considered
using pc-sysinstall after looking into it. Don't worry.



Why is that exactly?

A number of people are using it successfully to install ZFS based systems.

-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/25/13 8:45 PM, Teske, Devin wrote:

On May 25, 2013, at 7:51 PM, Super Bisquit wrote:


Please don't turn this into an architecture dependent mess. PCBSD is i386 &
AMD64 only.


There's a GSoC project (of which I'm potential mentor) to fix that.

However, you are entirely right… we can't in all seriousness even think about 
using pc-sysinstall until it is solid on all architectures as bsdinstall 
already is.

GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple 
architectures"



Why can we not use in the interim use pc-sysinstall on the platforms 
that it performs best on and use bsdinstall on the others?


It doesn't make sense for us to hold up some platform like this at all.

Maybe no one has thought of this?  Basically use pc-sysinstall on amd64 
and i386 and use bsdinstall on the other platforms until they catch up?


-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Chris Rees]

On 27 May 2013 03:10, "Daniel Eischen"  wrote:
>
> On Mon, 27 May 2013, Teske, Devin wrote:
>>
>>
>> I don't think there's any reason why we have to write it in C if we can
write
>> it in sh.
>
>
> I don't really care one way or the other (C or sh), but
> I can say that I can understand(*) well structured C a lot
> better than well structured sh.  Having something more
> strongly typed certainly helps understanding.
>
> (*) Assuming some level of complexity (I know that's
> subjective).

I think it's all down to familiarity.  I suppose sh is more resistant to
many stupid bugs and handles strings well But it has its own troubles
too of course.

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms 
that it performs best on and use bsdinstall on the others?


Because pc-sysinstall doesn't have a UI - it's only a backend. If we 
update bsdinstall to use it, then it won't work on other platforms.


--
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/27/13 9:56 AM, Bruce Cran wrote:

On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms 
that it performs best on and use bsdinstall on the others?


Because pc-sysinstall doesn't have a UI - it's only a backend. If we 
update bsdinstall to use it, then it won't work on other platforms.


This still doesn't make sense to me.  Why can bsdinstall not 
conditionally use it?


Do we always have to seek the lowest common denominator for our user 
experience?


-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 27/05/2013 19:03, Alfred Perlstein wrote:
Do we always have to seek the lowest common denominator for our user 
experience?


Yes.

--
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 27, 2013, at 11:03 AM, Alfred Perlstein wrote:

> On 5/27/13 9:56 AM, Bruce Cran wrote:
>> On 27/05/2013 16:48, Alfred Perlstein wrote:
>>> Why can we not use in the interim use pc-sysinstall on the platforms that 
>>> it performs best on and use bsdinstall on the others?
>> 
>> Because pc-sysinstall doesn't have a UI - it's only a backend. If we update 
>> bsdinstall to use it, then it won't work on other platforms.
>> 
> This still doesn't make sense to me.  Why can bsdinstall not conditionally 
> use it?
> 

Because, believe it or not, not all programs are split in twain, having a 
front-end and a back-end.

I'm not defending it, and I'm not promoting it, but bsdinstall does things in a 
different way where
pc-sysinstall wants to be just a back-end. bsdinstall would have to go through 
a major revision
to make it use any external back-end. Currently it's one self-enclosed entity.


> Do we always have to seek the lowest common denominator for our user 
> experience?
> 

When the situation*is* that the release engineers can only embrace one 
installer for the release
media of more than just x86 architecture, the answer is… yes (common 
denominator required).

My thoughts are… let me toil on a new installer and then we can think about 
opening the can
of worms that is "how to enable conditional installers."

HINT: I already solved that problem… by modifying the boot loader Forth menu to 
allow the
creation of custom boot menus. Now all we need is another installer to elicit 
the use of that code
to present the choice the user. However… (and this is a big however), unless 
the 2nd choice
installer is as half-as-bad as bsdinstall… I don't see why it wouldn't just 
replace it (therefore
negating the need to invoke that code I put in to allow multiple choice 
installers at beastie menu).
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/27/13 11:40 AM, Bruce Cran wrote:

On 27/05/2013 19:03, Alfred Perlstein wrote:
Do we always have to seek the lowest common denominator for our user 
experience?


Yes.


Is this a joke?

-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Wojciech Puchar]

I heard there was some discussion at BSDCan about the direction of a future 
FreeBSD installer.  Considering we currently have bsdinstall, pc-sysinstall, 
the best would be removing it at all and adding instruction how to install 
by hand.


At least someone that install FreeBSD will know what he/she actually did, 
and what to do then in case of emergency or how to say.. move the system

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Bruce Cran]

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there should be 
a single UI and scripting interface across all platforms. We should try 
and get pc-sysinstall running on all of them first in case there's some 
problem that means it can't be done, in which case we'd need to use a 
different backend.


--
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Nathan Whitehorn]

On 05/27/13 16:23, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there should 
be a single UI and scripting interface across all platforms. We should 
try and get pc-sysinstall running on all of them first in case there's 
some problem that means it can't be done, in which case we'd need to 
use a different backend.




I'd point out that bsdinstall does have a scripting interface now as well.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/27/13 2:23 PM, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there should 
be a single UI and scripting interface across all platforms. We should 
try and get pc-sysinstall running on all of them first in case there's 
some problem that means it can't be done, in which case we'd need to 
use a different backend.




There are just going to be certain platforms that make it EASY to do 
cool things.  We should embrace that!  That's why there are different 
platforms!


Some are great for low power, others are great for graphics, cpu power, 
gpu, networking etc.


If we always go for the lowest common denominator then we are crippling 
all the platforms for no one's benefit.  Even if something CAN be done, 
if it is very difficult, or just never happening, then we can't limit 
everyone's experience based on the more difficult and/or resource 
strapped platforms.


It's just not good business.

-Alfred

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Nathan Whitehorn]

On 05/27/13 20:40, Alfred Perlstein wrote:

On 5/27/13 2:23 PM, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there should 
be a single UI and scripting interface across all platforms. We 
should try and get pc-sysinstall running on all of them first in case 
there's some problem that means it can't be done, in which case we'd 
need to use a different backend.




There are just going to be certain platforms that make it EASY to do 
cool things.  We should embrace that!  That's why there are different 
platforms!


Some are great for low power, others are great for graphics, cpu 
power, gpu, networking etc.


If we always go for the lowest common denominator then we are 
crippling all the platforms for no one's benefit.  Even if something 
CAN be done, if it is very difficult, or just never happening, then we 
can't limit everyone's experience based on the more difficult and/or 
resource strapped platforms.


It's just not good business.


Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup 
support, for instance. Right now we support what we support because it 
is the most feature-complete thing we have, not just on tier-2 platforms 
but also on x86.


To bring this discussion back to the ground, the fact is that we lack an 
installer that has both internal support for ZFS and a UI. One of the 
reasons for this is that making a good expressive UI for ZFS is a 
non-trivial undertaking given its enormous flexibility. The bsdinstall 
partition editor has been written to be extensible for this, and several 
people have started writing code to do it, but no one ended up having 
time to finish. Probably a reasonable thing to do is to start with 
supporting only a minimal set of features. If anyone felt like actually 
writing this code, I'm sure it would be appreciated by all and be more 
productive than email exchanges.

-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 12:37 PM, Teske, Devin wrote:

> 
> On May 26, 2013, at 11:14 AM, Bruce Cran wrote:
> 
>> On 26/05/2013 18:54, Teske, Devin wrote:
>>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
>> 
>> "This proposal is not made public, and you are not the student who submitted 
>> the proposal, nor are you a mentor for the organization it was submitted to."
>> 
> 
> So, uh… register?
> 
> I can see all private projects and all I did was register with google-melange.
> 
> I'm not aware of a way to make it public versus private.

The project was not slotted. :(
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/27/13 6:53 PM, Nathan Whitehorn wrote:

On 05/27/13 20:40, Alfred Perlstein wrote:

On 5/27/13 2:23 PM, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there should 
be a single UI and scripting interface across all platforms. We 
should try and get pc-sysinstall running on all of them first in 
case there's some problem that means it can't be done, in which case 
we'd need to use a different backend.




There are just going to be certain platforms that make it EASY to do 
cool things.  We should embrace that!  That's why there are different 
platforms!


Some are great for low power, others are great for graphics, cpu 
power, gpu, networking etc.


If we always go for the lowest common denominator then we are 
crippling all the platforms for no one's benefit.  Even if something 
CAN be done, if it is very difficult, or just never happening, then 
we can't limit everyone's experience based on the more difficult 
and/or resource strapped platforms.


It's just not good business.


Yes, and all of this cuts both ways: pc-sysinstall has no wireless 
setup support, for instance. Right now we support what we support 
because it is the most feature-complete thing we have, not just on 
tier-2 platforms but also on x86.


To bring this discussion back to the ground, the fact is that we lack 
an installer that has both internal support for ZFS and a UI. One of 
the reasons for this is that making a good expressive UI for ZFS is a 
non-trivial undertaking given its enormous flexibility. The bsdinstall 
partition editor has been written to be extensible for this, and 
several people have started writing code to do it, but no one ended up 
having time to finish. Probably a reasonable thing to do is to start 
with supporting only a minimal set of features. If anyone felt like 
actually writing this code, I'm sure it would be appreciated by all 
and be more productive than email exchanges.

-Nathan


I'm sure if there was a list of reasonable things, such as wireless then 
pc-sysinstall could be augmented.  This is the first I've heard of 
that.  All the other complaints have been based on portability.


Is that all that is required now, wireless?



-Alfred

-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Nathan Whitehorn]

On 05/27/13 23:36, Alfred Perlstein wrote:

On 5/27/13 6:53 PM, Nathan Whitehorn wrote:

On 05/27/13 20:40, Alfred Perlstein wrote:

On 5/27/13 2:23 PM, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there 
should be a single UI and scripting interface across all platforms. 
We should try and get pc-sysinstall running on all of them first in 
case there's some problem that means it can't be done, in which 
case we'd need to use a different backend.




There are just going to be certain platforms that make it EASY to do 
cool things.  We should embrace that!  That's why there are 
different platforms!


Some are great for low power, others are great for graphics, cpu 
power, gpu, networking etc.


If we always go for the lowest common denominator then we are 
crippling all the platforms for no one's benefit.  Even if something 
CAN be done, if it is very difficult, or just never happening, then 
we can't limit everyone's experience based on the more difficult 
and/or resource strapped platforms.


It's just not good business.


Yes, and all of this cuts both ways: pc-sysinstall has no wireless 
setup support, for instance. Right now we support what we support 
because it is the most feature-complete thing we have, not just on 
tier-2 platforms but also on x86.


To bring this discussion back to the ground, the fact is that we lack 
an installer that has both internal support for ZFS and a UI. One of 
the reasons for this is that making a good expressive UI for ZFS is a 
non-trivial undertaking given its enormous flexibility. The 
bsdinstall partition editor has been written to be extensible for 
this, and several people have started writing code to do it, but no 
one ended up having time to finish. Probably a reasonable thing to do 
is to start with supporting only a minimal set of features. If anyone 
felt like actually writing this code, I'm sure it would be 
appreciated by all and be more productive than email exchanges.

-Nathan


I'm sure if there was a list of reasonable things, such as wireless 
then pc-sysinstall could be augmented.  This is the first I've heard 
of that.  All the other complaints have been based on portability.


Is that all that is required now, wireless?


There are more, as well. A partial list of missing features on both 
sides is here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major 
ones are IPv6 (maybe this has changed?) and no jail setup feature. Most 
of the existing disk partitioning code in pc-sysinstall, which is the 
only thing in a FreeBSD installer that is at all complicated, is also 
*extremely* fragile and needs in all likelihood to be entirely replaced. 
The merge effort stalled because of this kind of issue -- doing a 
"merge" rapidly became rewriting both from scratch.

-Nathan

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Alfred Perlstein]

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:

On 05/27/13 23:36, Alfred Perlstein wrote:

On 5/27/13 6:53 PM, Nathan Whitehorn wrote:

On 05/27/13 20:40, Alfred Perlstein wrote:

On 5/27/13 2:23 PM, Bruce Cran wrote:

On 27/05/2013 21:28, Alfred Perlstein wrote:

On 5/27/13 11:40 AM, Bruce Cran wrote:

Yes.

Is this a joke?


It probably /was/ too short a reply. Personally I think there 
should be a single UI and scripting interface across all 
platforms. We should try and get pc-sysinstall running on all of 
them first in case there's some problem that means it can't be 
done, in which case we'd need to use a different backend.




There are just going to be certain platforms that make it EASY to 
do cool things.  We should embrace that!  That's why there are 
different platforms!


Some are great for low power, others are great for graphics, cpu 
power, gpu, networking etc.


If we always go for the lowest common denominator then we are 
crippling all the platforms for no one's benefit.  Even if 
something CAN be done, if it is very difficult, or just never 
happening, then we can't limit everyone's experience based on the 
more difficult and/or resource strapped platforms.


It's just not good business.


Yes, and all of this cuts both ways: pc-sysinstall has no wireless 
setup support, for instance. Right now we support what we support 
because it is the most feature-complete thing we have, not just on 
tier-2 platforms but also on x86.


To bring this discussion back to the ground, the fact is that we 
lack an installer that has both internal support for ZFS and a UI. 
One of the reasons for this is that making a good expressive UI for 
ZFS is a non-trivial undertaking given its enormous flexibility. The 
bsdinstall partition editor has been written to be extensible for 
this, and several people have started writing code to do it, but no 
one ended up having time to finish. Probably a reasonable thing to 
do is to start with supporting only a minimal set of features. If 
anyone felt like actually writing this code, I'm sure it would be 
appreciated by all and be more productive than email exchanges.

-Nathan


I'm sure if there was a list of reasonable things, such as wireless 
then pc-sysinstall could be augmented.  This is the first I've heard 
of that.  All the other complaints have been based on portability.


Is that all that is required now, wireless?


There are more, as well. A partial list of missing features on both 
sides is here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major 
ones are IPv6 (maybe this has changed?) and no jail setup feature. 
Most of the existing disk partitioning code in pc-sysinstall, which is 
the only thing in a FreeBSD installer that is at all complicated, is 
also *extremely* fragile and needs in all likelihood to be entirely 
replaced. The merge effort stalled because of this kind of issue -- 
doing a "merge" rapidly became rewriting both from scratch.

-Nathan


Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.

-Alfred
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?

It probably /was/ too short a reply. Personally I think there should be a 
single UI and scripting interface across all platforms. We should try and get 
pc-sysinstall running on all of them first in case there's some problem that 
means it can't be done, in which case we'd need to use a different backend.


There are just going to be certain platforms that make it EASY to do cool 
things.  We should embrace that!  That's why there are different platforms!

Some are great for low power, others are great for graphics, cpu power, gpu, 
networking etc.

If we always go for the lowest common denominator then we are crippling all the 
platforms for no one's benefit.  Even if something CAN be done, if it is very 
difficult, or just never happening, then we can't limit everyone's experience 
based on the more difficult and/or resource strapped platforms.

It's just not good business.

Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup 
support, for instance. Right now we support what we support because it is the 
most feature-complete thing we have, not just on tier-2 platforms but also on 
x86.

To bring this discussion back to the ground, the fact is that we lack an 
installer that has both internal support for ZFS and a UI. One of the reasons 
for this is that making a good expressive UI for ZFS is a non-trivial 
undertaking given its enormous flexibility. The bsdinstall partition editor has 
been written to be extensible for this, and several people have started writing 
code to do it, but no one ended up having time to finish. Probably a reasonable 
thing to do is to start with supporting only a minimal set of features. If 
anyone felt like actually writing this code, I'm sure it would be appreciated 
by all and be more productive than email exchanges.
-Nathan

I'm sure if there was a list of reasonable things, such as wireless then 
pc-sysinstall could be augmented.  This is the first I've heard of that.  All 
the other complaints have been based on portability.

Is that all that is required now, wireless?

There are more, as well. A partial list of missing features on both sides is 
here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are IPv6 
(maybe this has changed?) and no jail setup feature. Most of the existing disk 
partitioning code in pc-sysinstall, which is the only thing in a FreeBSD 
installer that is at all complicated, is also *extremely* fragile and needs in 
all likelihood to be entirely replaced. The merge effort stalled because of 
this kind of issue -- doing a "merge" rapidly became rewriting both from 
scratch.
-Nathan

Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.


I had my own look at the pc-sysinstall and bsdinstall code and came to the same 
conclusions, plus some.

One of the biggest obstacles I see is actually a high-level issue that I've 
self-identified through extensive work on bsdconfig (which is both a back-end 
and a front-end).

This is the issue of debugging and namespaces.

I've sat down and made lists of other issues… but when I review, I find these 
issues to be secondary to the above-stated larger issues.

Concretely, I'm saying thus:

+ bsdinstall lacks debugging (debugging is different than logging; from what I 
could see BSDINSTALL_LOG -- although utilized by both the sh(1) side and the C 
side -- is only populated during an installation). The ability to have the type 
of debugging that is in bsdconfig would greatly diminish the amount of time 
developing important new features.

+ pc-sysinstall lacks debugging (similar situation… producing a log for some 
action is not the same as being able to have debug statements for the purpose 
of enhancement the program or troubleshooting an enhancement)

+ bsdinstall separates the backend functionality and the front-end 
functionality into two separate namespaces (and in the case of C binaries, a 
third namespace)

+ pc-sysinstall separates one backend into more than one namespace

===

To get an idea of the type of debugging I'm talking about, install 
sysutils/bsdconfig from the ports tree or install it from a HEAD checkout of 
base (it's in usr.sbin) and execute:

bsdconfig -d
# produce debugging statements on stdout collated in realtime with the dialog 
screens

or

bsdconfig -D fooLogfile
# produce debugging statements in "fooLogfile" (debugging statements are hidden 
from stdout)

or

bsdconfig -D +fooLogfile
# produce debugging statements in both "fooLogfile" *and* on stdout (this is 
the same as "-dD fooLogfile")


As this stuff gets more modular and there are back-ends, front

Re: FreeBSD installers and future direction

[Super Bisquit]

In the case of firmware loaded systems, all of them aren't going to work
with a single boot loader.


On Tue, May 28, 2013 at 1:15 PM, Teske, Devin wrote:

>
> On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:
>
> On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
> On 05/27/13 23:36, Alfred Perlstein wrote:
> On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
> On 05/27/13 20:40, Alfred Perlstein wrote:
> On 5/27/13 2:23 PM, Bruce Cran wrote:
> On 27/05/2013 21:28, Alfred Perlstein wrote:
> On 5/27/13 11:40 AM, Bruce Cran wrote:
> Yes.
> Is this a joke?
>
> It probably /was/ too short a reply. Personally I think there should be a
> single UI and scripting interface across all platforms. We should try and
> get pc-sysinstall running on all of them first in case there's some problem
> that means it can't be done, in which case we'd need to use a different
> backend.
>
>
> There are just going to be certain platforms that make it EASY to do cool
> things.  We should embrace that!  That's why there are different platforms!
>
> Some are great for low power, others are great for graphics, cpu power,
> gpu, networking etc.
>
> If we always go for the lowest common denominator then we are crippling
> all the platforms for no one's benefit.  Even if something CAN be done, if
> it is very difficult, or just never happening, then we can't limit
> everyone's experience based on the more difficult and/or resource strapped
> platforms.
>
> It's just not good business.
>
> Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup
> support, for instance. Right now we support what we support because it is
> the most feature-complete thing we have, not just on tier-2 platforms but
> also on x86.
>
> To bring this discussion back to the ground, the fact is that we lack an
> installer that has both internal support for ZFS and a UI. One of the
> reasons for this is that making a good expressive UI for ZFS is a
> non-trivial undertaking given its enormous flexibility. The bsdinstall
> partition editor has been written to be extensible for this, and several
> people have started writing code to do it, but no one ended up having time
> to finish. Probably a reasonable thing to do is to start with supporting
> only a minimal set of features. If anyone felt like actually writing this
> code, I'm sure it would be appreciated by all and be more productive than
> email exchanges.
> -Nathan
>
> I'm sure if there was a list of reasonable things, such as wireless then
> pc-sysinstall could be augmented.  This is the first I've heard of that.
>  All the other complaints have been based on portability.
>
> Is that all that is required now, wireless?
>
> There are more, as well. A partial list of missing features on both sides
> is here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are
> IPv6 (maybe this has changed?) and no jail setup feature. Most of the
> existing disk partitioning code in pc-sysinstall, which is the only thing
> in a FreeBSD installer that is at all complicated, is also *extremely*
> fragile and needs in all likelihood to be entirely replaced. The merge
> effort stalled because of this kind of issue -- doing a "merge" rapidly
> became rewriting both from scratch.
> -Nathan
>
> Ah this is so cool.  I'll bring it up with the PCBSD folks today.
>
> Thank you Nathan.
>
>
> I had my own look at the pc-sysinstall and bsdinstall code and came to the
> same conclusions, plus some.
>
> One of the biggest obstacles I see is actually a high-level issue that
> I've self-identified through extensive work on bsdconfig (which is both a
> back-end and a front-end).
>
> This is the issue of debugging and namespaces.
>
> I've sat down and made lists of other issues… but when I review, I find
> these issues to be secondary to the above-stated larger issues.
>
> Concretely, I'm saying thus:
>
> + bsdinstall lacks debugging (debugging is different than logging; from
> what I could see BSDINSTALL_LOG -- although utilized by both the sh(1) side
> and the C side -- is only populated during an installation). The ability to
> have the type of debugging that is in bsdconfig would greatly diminish the
> amount of time developing important new features.
>
> + pc-sysinstall lacks debugging (similar situation… producing a log for
> some action is not the same as being able to have debug statements for the
> purpose of enhancement the program or troubleshooting an enhancement)
>
> + bsdinstall separates the backend functionality and the front-end
> functionality into two separate namespaces (and in the case of C binaries,
> a third namespace)
>
> + pc-sysinstall separates one backend into more than one namespace
>
> ===
>
> To get an idea of the type of debugging I'm talking about, install
> sysutils/bsdconfig from the ports tree or install it from a HEAD checkout
> of base (it's in usr.sbin) and execute:
>
> bsdconfig -d
> # produce debugging statements on stdout collated in realtime with the
> dialog screens
>
> or
>
> bsdconf

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 28, 2013, at 4:16 PM, Super Bisquit wrote:

In the case of firmware loaded systems, all of them aren't going to work with a 
single boot loader.


Uh…

On the surface, what you're talking about seems to be unrelated to the 
discussion at-hand.

Nobody said anything about unifying the boot loader.

We're talking about the installer… not the boot loader.

*usually* the installer doesn't care about how it got to its installation 
environment.

NOTE: I say *usually* because there *are* specialized situations like cobbler + 
mfsbsd + pc-sysinstall in which case the boot loader needs to provide certain 
information (which is then accessible through kenv(1)). That type of 
installation setup will fail if the specialized boot loader does not boot on 
the desired target installation platform *or* the boot loader that _does_ work 
on said platform doesn't provide the necessary information.

That being said… bsdinstall doesn't require special knowledge from the boot 
loader (to the best of my knowledge).

sysinstall didn't need special info from the boot loader either.

I don't see why talking about a unified installer has to include a discussion 
involving unifying the boot loader (a topic in my mind that is unattainable).
--
Devin






On Tue, May 28, 2013 at 1:15 PM, Teske, Devin 
mailto:devin.te...@fisglobal.com>> wrote:

On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?

It probably /was/ too short a reply. Personally I think there should be a 
single UI and scripting interface across all platforms. We should try and get 
pc-sysinstall running on all of them first in case there's some problem that 
means it can't be done, in which case we'd need to use a different backend.


There are just going to be certain platforms that make it EASY to do cool 
things.  We should embrace that!  That's why there are different platforms!

Some are great for low power, others are great for graphics, cpu power, gpu, 
networking etc.

If we always go for the lowest common denominator then we are crippling all the 
platforms for no one's benefit.  Even if something CAN be done, if it is very 
difficult, or just never happening, then we can't limit everyone's experience 
based on the more difficult and/or resource strapped platforms.

It's just not good business.

Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup 
support, for instance. Right now we support what we support because it is the 
most feature-complete thing we have, not just on tier-2 platforms but also on 
x86.

To bring this discussion back to the ground, the fact is that we lack an 
installer that has both internal support for ZFS and a UI. One of the reasons 
for this is that making a good expressive UI for ZFS is a non-trivial 
undertaking given its enormous flexibility. The bsdinstall partition editor has 
been written to be extensible for this, and several people have started writing 
code to do it, but no one ended up having time to finish. Probably a reasonable 
thing to do is to start with supporting only a minimal set of features. If 
anyone felt like actually writing this code, I'm sure it would be appreciated 
by all and be more productive than email exchanges.
-Nathan

I'm sure if there was a list of reasonable things, such as wireless then 
pc-sysinstall could be augmented.  This is the first I've heard of that.  All 
the other complaints have been based on portability.

Is that all that is required now, wireless?

There are more, as well. A partial list of missing features on both sides is 
here: 
https://wiki.freebsd.org/PCBSDInstallMerge.
 Other major ones are IPv6 (maybe this has changed?) and no jail setup feature. 
Most of the existing disk partitioning code in pc-sysinstall, which is the only 
thing in a FreeBSD installer that is at all complicated, is also *extremely* 
fragile and needs in all likelihood to be entirely replaced. The merge effort 
stalled because of this kind of issue -- doing a "merge" rapidly became 
rewriting both from scratch.
-Nathan

Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.


I had my own look at the pc-sysinstall and bsdinstall code and came to the same 
conclusions, plus some.

One of the biggest obstacles I see is actually a high-level issue that I've 
self-identified through extensive work on bsdconfig (which is both a back-end 
and a front-end).