Date: Tue, 17 Jan 2012 18:10:30 +0100 From: Victor Balada Diaz <victor@bsdes.net> To: John Kozubik <john@kozubik.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <20120117171030.GP39290@equilibrium.bsdes.net> In-Reply-To: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120117171030.GP39290>