Upcoming Releases Schedule...
a134qaed at gmail.com
Thu Sep 18 16:12:16 UTC 2008
On Thu, Sep 18, 2008 at 12:25 AM, Jo Rhett <jrhett at netconsonance.com> wrote:
> I understand what you mean, but the statement is blatantly false as stated.
> Anyone selling software to the US Government *must* specify (or meet,
> depending) a minimum support period, and must also specify a cost the agency
> can pay to extend the support period.
> Not relevant to FreeBSD -- just qualifying the statement as it stands. For
> the obvious comparison, Solaris versions have well-published release and
> support periods, usually upwards of 8 years. Obviously they have more
> resources to do this, I'm just pointing out that the statement you made is
> incorrect as stated.
>> and I'm not sure you could do it differently -- no one plans to ship a
>> lemon, but once in a while you discover that things don't go as planned.
> I am amazed at the preposterously large elephant in the room that none of
> you are willing to address. Watching each of you dance around it would be
> terribly funny if it didn't affect my job so badly. (and if I wasn't going
> to have to bail on FreeBSD and go to some crap form of Linux because the
> FreeBSD developers appear to be unwilling to consider the idea of getting
> more help)
My opinion on this matter may be considered radical, but I do think it
should be at least recorded, if not impartially considered. While this
problem can't be solved just by extending time with the hope that the
resources will be allocated (no offense to your character, but that
promise is made by a lot of people, and it doesn't always work out
that way; particularly in environments with ingrained and blind
politics where the money flows can change based on pride and/or sheer
ignorance), it may be advantageous to treat the root causes.
One of the biggest (and most prominent, though not obviously so)
issues is the lack of concurrency with regards to releases. With the
default system, having multiple freebsd releases side by side (both
different versions, and different architectures) is infeasible. This
makes the choice more critical, while hindering flexibility. The
necessity of long support schedules is one of the symptoms.
The fact that you have to choose, and then to change the choice you
must clean up, back up, and create a new environment in order to test
on a different release/architecture (release in this context includes
kernel, a chroot is incomplete for testing), has two major effects: it
hinders users from being able to selectively test newer releases with
their software stack/hardware selection, with no adverse (within
reason; obviously bugs like disk corruption will still happen) changes
that will prevent them from reverting.
While it may not please the accountants, cleaning up the namespace and
allowing safe concurrency of releases will increase the /legitmate/
feasibility of using FreeBSD on a large scale. Oh, I forgot to
mention, this is far from a pipe dream. I have a working environment
with this capability, and I use it whenever I am able.
This isn't to say it is the only cause, it is one of many, and I would
never even claim it was a magic bullet. But it is my opinion that this
problem is best solved not by arguing how to work around the symptoms,
but to analyze and solve the parent problems that may not be so
There's my two cents on the matter.
More information about the freebsd-stable