On Mon, Jan 16, 2012 at 02:28:09PM -0800, John Kozubik wrote:
>
> Friends,
>
> I was disappointed to see that 8.3-RELEASE is now slated to come out in
> March of 2012. This will be ~13 months since 8.2-RELEASE and is typical
> of a trend towards longer gaps between minor releases.
>
> I also see that undercutting the current release before wide deployment
> and maturity is continuing. 7.0 came (barely) after 6.3, which was bad
> enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.
>
> Finally, the culture of "that's fixed in CURRENT" or "we built those
> changes into (insert next major release)" continues to get worse. It's
> difficult to escape the notion that FreeBSD is becoming an operating
> system by, and for, FreeBSD developers.
>
Hello John,
With my sysadmin hat on i can echo your feelings, but i guess that your
proposals are more focused on a company environment than a collaborative
environment.
First i would like to remember the last stage of FreeBSD 4.x for those
people (not you) who are arguing in the thread about long "stable" releases.
Those of us who used FreeBSD 4.x on the late release cycle will remember
a few of this problems:
- New hardware didn't work because no ACPI support was in 4.x until
4.11 or 4.12 (can't remember). Even then, it was considered a bad
idea to backport it because it was a huge change for a -STABLE branch.
- Because SMPng project involved a lot of changes, it was not easy to
backport drivers.
- SMP performance was horrible. As libc_r was the only option on 4.x
you got various performance and stability problems with apps designed
for a better threading model. A good example is MySQL performance. At
that time started the whole "mysql performance issues of FreeBSD vs
linux"
that last until today.
- Porting some new apps was troublesome because a lot of libraries
had missing bits pending the big SMPng changes on 5.x. Mostly related
to thread libs.
- 5.x was a huge change relating to POLA. Eg: init scripts changed to
new rc.d
framework (iirc imported or based on NetBSD work).
At that time you had two options:
- Use rock solid FreeBSD 4.x and be unable to run more or less recent
apps and hardware
without huge problems.
- Use FreeBSD 5.x which was unstable and slow compared to 4.x
Because of this problems some people migrated to Linux, a fork of FreeBSD with
the idea
of an easier SMP model was created, etc.
FreeBSD project learnt a good lesson: If you wait too much for great features
to came
to a reality instead of releasing often, you will not have features or
stability. Ie:
The stable release is unusable because backporting drivers and libs is harder
and you end with
unsupported new hardware as time passes, apps are harder to port because
missing APIs,
etc. And the new "current" release is unusable because there are too many
things in testing
and breaks in a lot of places.
At that time (maybe 6.x? can't remember for sure, maybe someone else will
remember better)
the FreeBSD project announced a new way of doing releases. Release Timely
instead of
release based on features. If you don't have a feature ready when it's time for
releases, just skip
until next one instead of waiting.
Now a few years later as sysadmins we find that there are too many releases
that don't last
too much. We waste a lot of time testing upgrades and once they're in
production releases
don't last often enough for the effort to be worthwile. Hence, John mail.
I agree with John on the problems, but i disagree on solutions and the causes.
No solution
is going to work if you expect volunteers to do anything for a long time that's
boring. You lost
interest and stop working on that.
What i really think it's the problem:
If you try to maintain a few servers without much resources you end replicating
half FreeBSD's
project release infraestructure:
- You find a bug, report, get a patch and apply. After that, you lost
forever the option
of using freebsd-update. You need to reinstall the system to get
freebsd-update again
- You want binary updates with custom kernel or patches? -> Your only
option is cutting your
own releases or forget about freebsd-update.
- You want to track packages on various machines? -> create your
tinderbox because binary package upgrades
is a no-op with standard packages distributed by the project.
- You want to apply a security update to a custom kernel? -> no binary
option
- Do you want to apply just one security update but no other to a
standard kernel? -> no option
freebsd-update will just allow you all patches or none.
- Performance problems? Usually involves recompiling with different
compiler or kernel/userland options.
Again: no easy binary upgrade path.
As you can see, if you want to change something, you end doing half the release
process yourself for
easy things like patch handling, package upgrades or binary upgrading. And
what's worse:
You can't easily change from custom-built system to standard system once bugs
are fixed and get to
mainstream.
If you're a small FreeBSD user with 10-300 servers it will hurt a lot to do
most of release engenieering
yourself to just get a little flexibility.
We're half binary, half source.
I think that the best thing for improving sysadmin experiencie is to lower the
entry of useful
tools that allow to easily administer lots of different servers.
It's not hard to get a patch from a developer for a small driver update. It's
not even that expensive
to pay someone for a backport. I've done various myself in the years i've been
using FreeBSD. What's
really expensive is maintaining the infraestructure needed for just one patch.
The difference of a standard RELEASE install vs standard release with a small
re(4) patch is that now
i suddenly need to build releases, create freebsd-update servers etc.
Thinking on how other projects get the same thing done you can look at Debian
project. If you need
to patch any util, as you have system packages, you just patch a .deb and post
it to a custom FTP server.
Now all servers could easily update from that package. Once the patches are in
mainstream version, you
just need to forget about your package and system will use the newer official
version without problems.
This also gets for free community involvement: Eg debian backports[1] for
stable releases. People interested
in getting long support cycles for releases can collaborate. Now try to do that
with backports for RELEASES
on FreeBSD.
What we lack, IMO is flexibility for binary updates/upgrades and some way of
having system packages.
Of course if noone is interested in wasting his time on writing all of this,
nothing will get done of this talk,
but i just wanted to offer a different solution that shouldn't be that hard to
implement or sponsor and
could make developers and big companies happy without any of them having to do
long-time work.
I hope you've been able to understand me because english is not my native
language.
Have a nice day.
Victor.
[1]: http://backports-master.debian.org/
--
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
