LibH pronounced dead, need for a new leadership
The Anarcat
--hHWLQfXTYDoKhP50
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Right. I totally agree with you here Jordan. Maybe the key would be to
try to port successful tools from the linux side. I don't know. One
thing I know is that I have completely departed from developpement on
libh in particular and FreeBSD in general, because of a lack of time,
mainly, but also because of the frustrating experience of maintaining a
low-end (and here I mean 64M of ram :) server with FreeBSD, compared to
other systems.
You mentionned Debian, well that's one thing: I discovered APT. I feel
that working on a package management system is completely futile once
the open source world has such a great tool already tried and true. They
are making APT work with other packaging formats (RPM, for now), and I
don't see why this wouldn't apply to our side. APT could work with the
current FreeBSD package scheme, which itself could be improved upon to
match the capabilities of other packaging systems, as being proven by
the libpkg experiment.
Building an installer is always a bit of the "re-inventing the wheel"
hell. It's already been done, it's never quite right, it's extenuating
and no-one wants to do it anyways.
Maybe claiming the death of libh will bring life to other projects. I'm
thinking of libpkg which kinda sprung to life after all, without libh
mind you, and the binary updates stuff. Both projects are very exciting
and I'm really considering the binary updates stuff for the maintenance
of the FreeBSD boxen I have left.
Maybe all the BSDs need to get together to solve this problem. I can't
believe we can't collectively solve this problem. What I see is multiple
people working on similar or related projects each on their sides:
pkgsrc on NetBSD, libpkg on FreeBSD, a graphical installer (i don't
recall the name) on OpenBSD. We need to focus all those projects
together.
Getting libh out of the way for that is a great move, actually, and
might actually open up the gates for the next step.
I don't nor can lead this one. Someone will have to take care of that,
some people who have their feet deep into the BSDs and are socially
networked in the community.
That is why I CC'd core. Hear our call! FreeBSD needs a new installer!
Let's wake this daemon!
I don't know where or how to announce that, maybe you guys could point
me in the right direction, maybe you guys want to do it yourselves. :)
Anyways, there's surely a debate to open, although I'm not sure it'll
bring anything. This is a highly bikeshed-susceptible material, and what
it needs is work, not opinions or debates.
Long life FreeBSD,
A.
On Sam mai 22, 2004 at 01:19:16 -0700, Jordan Hubbard wrote:
> libh never lived up to its promise, that much is certainly true.
>=20
> The pity of all this is that there's never been the right sort of=20
> project management or even group consensus necessary to come up with=20
> any credible replacement strategy. Libh was never the cause of=20
> FreeBSD's lack of a good replacement installer, merely a symptom of the=
=20
> general lack of desire to deal with this problem space. People just=20
> keep doing (barely) evolutionary hacking on the existing tools and=20
> somehow perceiving this as sufficient and that's just a shame since=20
> it's limited FreeBSD's success (trying, as it has, to be "the=20
> mainstream BSD"). Meanwhile, the SuSE and Red Hats of the world=20
> continue to march on and offer installation and package management=20
> experiences that are at least an order of magnitude more extensive than=
=20
> FreeBSD's. Even Debian, who one could argue is more of a reasonable=20
> comparison to FreeBSD given that it's all been volunteer driven rather=20
> than subsidized by a corporate sugar-daddy, offers a better=20
> installation experience. Not an order of magnitude better, but they've=
=20
> at least put some effort into this area and appear to be continuing to=20
> do so.
>=20
> If libh is finally pronounced dead and buried without ceremony, I hope=20
> that this is announced a little more widely and with at least some=20
> attempt to provoke discussion concerning "if not that, then what? =20
> Nothing? Really??"
>=20
> - Jordan
>=20
>=20
> >>I feel that libh has taken too long the role of a failed promise for=20
> >>the
> >>FreeBSD community and rightly deserves to die now.=20
>=20
--hHWLQfXTYDoKhP50
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAr7rLttcWHAnWiGcRAstxAKCgbeM+Tu/+znhVT3SZ65FBhRUN0wCfc1U0
0gSElD5hLQ4S9HK70mM/RyI=
=ZZdE
-----END PGP SIGNATURE-----
--hHWLQfXTYDoKhP50--
David Johnson
> I don't nor can lead this one. Someone will have to take care of
> that, some people who have their feet deep into the BSDs and are
> socially networked in the community.
I was told not long ago on the -advocacy group to "stop talking about
it, and just go code something." I told them I would.
Unfortunately, I can only code in my spare time, and I have other
software I need to maintain. So I haven't gotten around to coding
anything. And it doesn't look like I'll have time to start coding for
another three months. But I am willing to discuss some ideas.
But this isn't the advocacy list. This is the libh list. SInce libh is
dead, we pretty much have the list to ourselves to talk all we want
about a libh/sysinstall replacement!
--
David Johnson
___________________
http://www.usermode.org
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-libh
To unsubscribe, send any mail to "freebsd-libh...@freebsd.org"
Robert Watson
On Sat, 22 May 2004, The Anarcat wrote:
<snip>
> That is why I CC'd core. Hear our call! FreeBSD needs a new installer!
> Let's wake this daemon!
</snip>
I think most FreeBSD developers recognize that FreeBSD has gone from a
relative leader in the pack in install usability and management to lagging
behind, simply by virtue of having (as jkh pointed out) something that was
just sufficient to keep working with incremental tweaks. I think there's
also a lot of agreement that Something Must Be Done, but that it (as
usual) comes down to a few hard questions:
- How to build a new installer/management environment without bumping into
extensive second system syndrome. There's a nasty temptation to build
from scratch and try to make it all-singing and all-dancing.
- How to get buy-in for the project while its in progress, as well as to
build interest and development support. It's a non-trivial task.
- How to find resources to work on it that are sustained at a high level
for long enough. Again, a non-trivial task.
I agree that software reuse is a big part of the answer -- it's clear we
have been unable to muster what was needed so far, in part because the
FreeBSD Project hasn't become a haven for GUI and user interface types.
We provide a well-defined layer that happens to be a few layers below what
those people tend to be interested in :-).
I would suggest some serious scoping is in order for whoever decides to
take on the task. First, I'd suggest avoiding all-singing and
all-dancing, since it requires a lot of infrastructure investment. Here
are some things not to do:
- GUI installers are cool, but they're a lot of investment. Maybe we
should eschew it and just go for a decent text interface to get the base
system installed. Libdialog was half decent when it was first
integrated into the installer, but I think everyone recognized the state
of the art has moved on a bit. Don't design precluding it, but don't
try to create an optimal architecture for a GUI if the resources aren't
there to follow through, it will just become an obstacle.
- Don't try to solve the package management problem. I know it's hard not
to, since one of the failings of our current install model is that we
don't have a decent package management solution. However I think you'll
find a lot of successful systems don't have a decent package management
solution for the core of the OS, albeit perhaps a smaller core than we
have. Start out building something that just works with tarballs.
- Do focus on the ordering and procedure of the install process:
investigate the requirements for a two-phase process (boot the install
media, splat, boot from the hard disk and finish up). Part of the
complexity in sysinstall is attempting to provide a normal runtime
environment for package install when the configuration is arguably not
normal, so chroot(), libraries, etc, get involved. Splitting into two
distinct environments may help with this, as well as allow the
post-splat phase to take advantage of more tools and capabilities that
today sysinstall can't use (such as a full X install, GUI or third party
libraries, etc).
- Likewise, do focus on how the new installer will build up a description
of an installation to perform before committing, which is something
syinstall doesn't address well (resulting in the incremental changes
just making it worse).
- Do answer the question of how the install mechanism fits into the
FreeBSD development environment. Remember that the FreeBSD Project is
unlikely to want to import vast quantities of libraries and scripting
languages into the base source tree. Can we identify a model by which
the installer becomes an external build and package from the 'src' tree?
Grabbing someone else's solution is certainly possible, but it doesn't
necessarily make all of the above easier. Frankly, my temptation, if I
were going to try and run such a project, would be to spit out a prototype
system that isn't integrated into 'src' as a relative fait accompli over a
period of 4-6 months, and then say "Hey, it works!". I'd add some
abstraction for the base component installing process, but I'd focus more
on the installation model and trying to move away from libdialog. Much of
the nastiness of sysinstall comes out of libdialog offering a poor event
model and state mechanism.
You might consider appealing on a FreeBSD user's list or two looking for
application developers interested in helping. You want FreeBSD developers
involved, but I'm not sure they are reliable for this sort of work: for
one thing, it's pretty far from their areas of expertise so if they lead
the charge, you'll get the common results of that (second system syndrome
and burnout :-). You might want to talk to Scott Long, since I know he's
also given this issue some thought...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Senior Research Scientist, McAfee Research