Date: Sun, 14 Jul 2002 18:51:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Thomas Seck <tmseck-lists@netcologne.de>, freebsd-arch@FreeBSD.ORG Subject: Re: Package system flaws? Message-ID: <3D322AB8.4CCD1A63@mindspring.com> References: <p05111700b953ed16c118@[128.113.24.47]> <p05111701b953f38542f8@[128.113.24.47]> <20020712121427.GD3678@lummux.tchpc.tcd.ie> <20020712144854.GA756@laurel.tmseck.homedns.org> <20020713054141.A26277@misty.eyesbeyond.com> <20020713011750.GA755@laurel.tmseck.homedns.org> <20020714042237.GD931@lizzy.catnook.com> <20020714042623.GB95460@squall.waterspout.com> <20020714095939.GA588@laurel.tmseck.homedns.org> <200207141333.g6EDXj0L031673@whizzo.transsys.com> <20020714155728.GA4237@laurel.tmseck.homedns.org> <200207141624.g6EGOa0L033175@whizzo.transsys.com> <3D31F81E.290289FD@mindspring.com> <200207142347.g6ENla0L039627@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Louis A. Mamakos" wrote:
> I think of two classes of users of the FreeBSD system. They are:
>
> A) Those that install releases from a CDROM from time-to-time.
>
> 2) Those that follow FreeBSD development on an on-going basis (e.g.,
> bleeding edge -CURRENT or production -STABLE users).
>
> The "A" class of users don't need a package management system to
> maintain their systems as part of the FreeBSD base system. E.g., they
> use tools like sysinstall which isn't even built by "make buildworld",
> but is available on the distribution CDROM they booted.
>
> The "2" class of users use tools like cvsup which isn't part of the
> base system to keep their source code/repositories up to date. They
> manage to do this by using a tool in the ports/packages system. Many
> of them also choose to use tools like portupgrade, also in ports/packages.
I respectfully disagree (and not just with your numbering not
being from a single canonical ordinal set ;^)). I think the
majority of FreeBSD users fall into an excluded middle:
iii) Those that follow -stable or -security, and *ignore* FreeBSD
developement on an ongoing basis.
The "iii" class of users, I would argue, represents the *vast*
majority of FreeBSD users, and I'm not just talking "by volume"
because of Yahoo and the thousands of InterJet users, I'm talking
*by user*.
FreeBSD tries very hard to avoid getting into the desktop domain
and competing there, for fear that it would lose. That's where I
would say the vast majority of your "A" users live: they take
what you give them, and they live with it. FreeBSD has consistently
shyed away from serving this user base, any time it had a choice.
Your "2" class of users are developers, who, by the nature of the
inherent biases in the project processes and management, end up
doing all their work on -current, so that the work product is used
by the project, rather than being discarded.
I think you've fused a number of axis', without providing justification,
and the space is more than the two values one dimensional line that
you paint it as. Here's your picture:
Creators ("us") Consumers ("them")
o o
- uses CVSup - uses CDROM
- subscribes to hackers/current/arch - subscrives to questions
etc. etc.
I think this is a very narrow view. I think that there is *at least*
three major axis', and I don't pretend that my idea of "major" matches
everyone elses, but I don't have to for the model to be more valid than
the "us/them" model:
FreeBSD as a Platform
^
| _. General Purpose
| /|
| /
Consumers | / Creators
<-----------------*--------------->
/ |
/ |
|/ |
Embedded `- |
v
FreeBSD as an ends in itself
That's 8 distinct sectors for any given user to be measured into, in
order to categorize them; e.g. numbering clockwise fr0m the upper left,
and from back to front, option base 0, PicoBSD is somewhere in sector
#5:
PicoBSD
- Embedded
- Creators
- FreeBSD as a Platform
FreeBSD on a CDROM is much less localized; it's a potato shaped
region with most of it's mass in sector 3. It's not incredibly
useful for developers, ecept as a bootstrapping tool, and it's
not incredibly useful as a platform, because the configuration
you git with a naieve install is not really safe to run as a
hardened server in a rack mount system... and most rack boxes
for embedded uses don't have a CDROM drive, anyway, because it
takes away front panel space, etc..
> So why is it the package management infrastructure is required to be
> in the base system, when to a large extent it's not today?
That's exactly it: because, to a large extent, it's not today.
And that fails to adequately serve the user base, as a result.
> What's it mean to be part of the "base system" when everything
> turns into optional components?
It means "the pieces fit together". You wouldn't put a left
front quarter panel from a Chevy Nova on a Honda Civic. A
package system is only intended to mean that, when you install
components via one, that they will work together, as expected.
If you have a Honda Civic (FreeBSD 4.6) and you select "install
new left front quarter panel" (e.g. KDE 3.0), you don't end up
with something that was intended for a Chevy Nova (FreeBSD 5.0).
Things need to fit.
Several times in this discussion, I've beaten around the bush of
the fact that one of the major goals of modification of the package
system must be to ensure that one of the emergent properties of
developement going forward is project cohesiveness.
Right now, there is significant work that happens in the PicoBSD
realm (the "freebsd-small" mailing list), e.g. with Soekris boxes
(as one example), and the ability to build small system images
for use in special purpose situations. In other words, the
ability to delegate a box to a particular role. None of this
work is being captured in the main line FreeBSD; it is duplicated,
or it is lost, as the main line FreeBSD moves forward.
Another place that's very obvious on this is that every place I
have ever worked that was a "FreeBSD shop" ended up having to
roll its own developement environment to mirror that of the end
product they intended to build. These places did not use FreeBSD
CDROMs, or, if they did, it was merely as a starting point... and
once past that, there was substantial effort to cross the gap
between the CDROM, as distributed, and the target environment.
Most of these places ended up building their own CDROM ISO images,
burning them, and installing from those images instead any FreeBSD
release CDROM, as released by the FreeBSD project.
If the FreeBSD project doesn't *learn* how to capture this work,
then it will either *continue* to be lost, or it will eventually
fork the project, when the value of the work is too high for it
to be duplicated easily, or allowed to be lost. PicoBSD is
slowly but surely turning itself into a seperate project with a
shared repository and mailing list server.
Rather than trusting people with this, I would like to see the
ability to learn institutionalized in the project and the tools,
so that when individuals responsible leave, either voluntarily,
or by getting hit by a bus, that the learning is not lost.
One of the biggest mistakes a company can make is outsourcing
its intellectual property to third party contractors, because as
soon as the contract is up, unless there were well-thought-out
systems in place, the institutional learning disappears with the
people who embody it.
The only fix for this -- allowing the use of contractors -- is a
systemic fix. In the limit, and once you're past the founders,
*everyone* in an Open Source project is effectively a contractor.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D322AB8.4CCD1A63>