Date: Thu, 29 Aug 2002 17:30:37 -0700 From: Rich Morin <rdm@cfcl.com> To: freebsd-chat@freebsd.org Subject: Re: What can FreeBSD learn from Mac OS X? Message-ID: <p05111b0eb9944f21ee6f@[192.168.254.205]>
next in thread | raw e-mail | index | archive | help
EA> What do you mean by "productizing"? Do you mean marketing? Why
EA> don't you start the wave, and lead the sheep? I'd also love to
EA> see FreeBSD get into more places, but it takes time, and money,
EA> to "market" the OS. Time I have, money, well, spent elsewhere.
No, I don't just mean marketing. The Cylogistics / Daemon News folks
are already doing good work in that direction; if I have any marketing
aspirations/energy, I'll just give them a hand.
What I mean by "productizing" is something like the distinction made by
Fred Brooks ("The Mythical Man-month": required reading! :-) between
"programs" and "program products". FreeBSD has come a long way on this
particular path, but I think it needs to come further. For example:
* Each FreeBSD release is, in essence, a new install. The user is
given a bit of help with /etc and such, but is required to figure
out more than a few things for him/herself.
There is no reason why each release shouldn't have detailed notes
(and, preferably, conversion scripts) to assist the administrator
in making the needed adjustments.
* Mac OS X has specifically opted to put as much as possible into
dynamic shared libraries. This lets them upgrade the behavior of
the entire system, simply by upgrading the code in the libraries.
* Each FreeBSD release completely supplants the one(s) before it. By
the time a release is a year old, it's toast: no patches, no support.
I don't see the FreeBSD Project being able to use the same methods as
as Apple does; its goals and market are too different. There may be a way,
however, to get some of the benefits without buying the whole package.
What I would _like_ is a situation where an administrator can be safe in
using a given version of FreeBSD, plus occasional binary patches, for a
year or even longer. In order for this to work, however, there would
need to be multiple, overlapping streams of releases, as:
2002.09 4.7 the "official" release
2002.10 4.7.1 4.7 + early bug fixes
2002.11 4.7.2 4.7.1 + later, critical bug fixes
2002.12 4.8 the "official" release
2003.01 4.8.1 4.8 + early bug fixes
2003.01 4.7.3 4.7.2 + later, critical bug fixes
2003.03 4.8.2 4.8.1 + later, critical bug fixes
2003.03 4.9 the "official" release
2003.04 4.9.1 4.9 + early bug fixes
2003.05 4.7.4 4.7.3 + late, really critical bug fixes
2003.06 4.9.2 4.9.1 + early bug fixes
2003.07 4.8.3 4.8.2 + later, critical bug fixes
2003.10 4.9.3 4.9.2 + later, critical bug fixes
...
I don't know what the exact schedule for the dotdot releases should be,
but my guess is that .1 could come after a month, .2 could show up a
couple months after that, and following fixes would be issued whenever
a truly _horrendous_ security hole was discovered. So, several months
might elapse after .3 and up.
In summary, dotdot releases would ONLY be used for issues of stability
and security (ie, no enhancements and _nothing_ that would affect
system configuration files). Further, the "bar" for inclusion would be
raised for the later dotdot releases.
Unfortunately, we can't _quite_ assume exponential decay for the dotdot
releases; new security holes keep showing up every few months and they
affect all existing releases. Here is a chart that shows the additional
work that my scheme would entail, if we assume a release "lifetime" of
24 months and inter-release gaps of 1, 2, 4, 4, ... months:
MM 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 #
== === === === ==== ==== ==== ==== ==== ==== ==== ==== =
1 -- 1
2 .1 1
3 0
4 .2 -- 1
5 .1 1
6 0
7 .2 -- 1
8 .3 .1 2
9 0
10 .2 -- 1
11 .3 .1 2
12 .4 1
13 .2 -- 1
14 .3 .1 2
15 .4 1
16 .5 .2 -- 2
17 .3 .1 2
18 .4 1
19 .5 .2 -- 2
20 .6 .3 .1 3
21 .4 1
22 .5 .2 -- 2
23 .6 .3 .1 3
24 .7 .4 3
25 .5 .2 -- 2
26 .6 .3 .1 3
27 .7 .4 3
28 .5 .2 -- 2
29 .6 .3 .1 3
30 .7 .4 2
31 .5 .2 -- 2
32 .6 .3 .1 3
33 .7 .4 3
34 .5 .2 3
35 .6 .3 2
36 .7 .4 2
...
It appears that the number of dotdot release per month, under this scheme,
would creep up to an average of about 2.5. Because only critical bug
fixes would be included, the amount of work to prepare each patch should
be relatively small (as compared, say, to a "dot" release :-).
Anyway, that's one suggestion... Now for a question: would anyone pay
Real Money (TM) for these sorts of dotdot releases? It wouldn't have to
be a lot, just enough to pay for the work involved. If so, Daemon News
or some other party might have a business opportunity...
-r
--
email: rdm@cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com/rdm - my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05111b0eb9944f21ee6f>