FreeBSD has serious problems with focus, longevity, and lifecycle
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. The Problems: Between JohnCompanies and rsync.net, we have nearly one thousand full blown FreeBSD systems running on three continents. We've been deploying these systems since 2001 and since the rift[1] have been increasingly subject to the following major issues, listed from most general to most specific: 1) A widening gap of understanding between the developers and the end users. Not everyone has a fantastic tool chain and build environment that allows them to jump around from one snapshot to the next, cost free. We've got a thousand of these things, and not only are we going to run RELEASE software ONLY, but we're going to do everything we can to match that environment up across as large of an installed base as possible. The daily chatter on the lists about getting stable and getting current, or moving to the next major release reflects a complete disconnect between developers and end users. 2) Having two simultaneous production releases draws focus away from both of them, and keeps any release from ever truly maturing. In January of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0. Instead, each release gets perhaps two years of focused development before every new fix is applied only to the upcoming release, and any kind of support or enthusiasm from the community just disappears. This means that any serious or wide deployment gets stuck with a bad choice every two years - keep running something that's already essentially abandoned, or spend all of that time and money on QA, testing, documentation, shipping, etc., all over again, just like they did two years ago. Of course the retort will be: we added ZFS and ULE, etc., and those warranted a full release - and maybe that's true, but since ZFS is only now, circa 8.3 (god willing) ready for any kind of prime time deployment[2], it would have been just fine to release it today, in 7.0. 3) Having two simultaneous production releases draws investment away from FreeBSD, because the relevance and longevity of those fixes are unknown. I am sure we are not the only organization that either needs new features, or needs fixes, that just aren't on others' priority lists. In the past, we've donated time and money[3][4] to try to push some of these things forward, but it makes less and less sense when the lifespan of any particular fixes are limited to the shorter and shorter lifespans of the releases. Why pay to get this fixed today when it's either already fixed in CURRENT or is already irrelevant ? Meanwhile, end users that don't have the option to hire contract coders just lose out. 4) New code and fixes that people NEED TODAY just sits on the shelf for 8 or 10 or (nowadays) 13 months while end users wait for new minor releases. Not only does this hurt end users, but it also hurts downstream projects, like pfsense and FreeNAS. Here's a good example: somewhere around 2007, a great many PCMCIA network cards (of interest to pfsense users, like me) just quit working.[5] I found that this was still the case in 2010. I asked Warner about it, it got MFC'd, and I donated some hardware towards keeping these devices maintained. So far so good. But this was in June of 2011 which means that 8 months later this still isn't released and certainly isn't in pfsense. Ok, fine - if I'm fiddling with PCMCIA cards in 2011, then perhaps get CURRENT is a reasonable response ... but be honest, do you have a build environment that allows you to take FreeBSD CURRENT and generate a new pfsense build from that ? Do any pfsense end users have that ? I don't. More frequent minor releases would be a boon here. 5) New code and fixes that people NEED TODAY often get pushed into the next major release, since that's what people are working on anyway. A few years ago we were dying for new em(4) and twa(4) drivers in FreeBSD 6, but they were applied only to 7 and beyond, since that was the new production release (as opposed to the old production release). It's the same bad choice again: make major investments in testing and people and processes every two years, or just limp along with old, buggy drivers and no support. Suggestions: Here are the specific actions that I think would dramatically improve the focus
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. I also have several FreeBSD installations spread across different development/production systems and it is not feasible to always upgrade to the latest and greatest. Part of why FreeBSD is difficult to adopt into more of the commercial/government sectors is because of this fast paced release cycle and most of the important patches/fixes are not backported far enough. This is why most of my customers decide to use Solaris or RedHat and not FreeBSD. (Not looking to start a flame war about the OS choice/etc just pointing out the Release cycle model). I would love to push FreeBSD harder but it is becoming increasingly difficult as of late. We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? -Will On Mon, 2012-01-16 at 14:28 -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. The Problems: Between JohnCompanies and rsync.net, we have nearly one thousand full blown FreeBSD systems running on three continents. We've been deploying these systems since 2001 and since the rift[1] have been increasingly subject to the following major issues, listed from most general to most specific: 1) A widening gap of understanding between the developers and the end users. Not everyone has a fantastic tool chain and build environment that allows them to jump around from one snapshot to the next, cost free. We've got a thousand of these things, and not only are we going to run RELEASE software ONLY, but we're going to do everything we can to match that environment up across as large of an installed base as possible. The daily chatter on the lists about getting stable and getting current, or moving to the next major release reflects a complete disconnect between developers and end users. 2) Having two simultaneous production releases draws focus away from both of them, and keeps any release from ever truly maturing. In January of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0. Instead, each release gets perhaps two years of focused development before every new fix is applied only to the upcoming release, and any kind of support or enthusiasm from the community just disappears. This means that any serious or wide deployment gets stuck with a bad choice every two years - keep running something that's already essentially abandoned, or spend all of that time and money on QA, testing, documentation, shipping, etc., all over again, just like they did two years ago. Of course the retort will be: we added ZFS and ULE, etc., and those warranted a full release - and maybe that's true, but since ZFS is only now, circa 8.3 (god willing) ready for any kind of prime time deployment[2], it would have been just fine to release it today, in 7.0. 3) Having two simultaneous production releases draws investment away from FreeBSD, because the relevance and longevity of those fixes are unknown. I am sure we are not the only organization that either needs new features, or needs fixes, that just aren't on others' priority lists. In the past, we've donated time and money[3][4] to try to push some of these things forward, but it makes less and less sense when the lifespan of any particular fixes are limited to the shorter and shorter lifespans of the releases. Why pay to get this fixed today when it's either already fixed in CURRENT or is already irrelevant ? Meanwhile, end users that don't have the option to hire contract coders just lose out. 4) New code and fixes that people NEED TODAY just sits on the shelf for 8 or 10 or (nowadays) 13 months while end users wait for new minor releases. Not only does this hurt end users, but it also hurts downstream projects, like pfsense and FreeNAS. Here's a good example: somewhere around 2007, a great many PCMCIA network cards (of interest to pfsense users, like me) just quit working.[5] I found that this was still the case in 2010. I asked Warner about it, it got
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 3:32 PM, William Bentley wrote: I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. [...] We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? -Will It pretty much boils down to one thing.. man power.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Mon, Jan 16, 2012 at 3:32 PM, William Bentley will...@futurecis.com wrote: I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. I also have several FreeBSD installations spread across different development/production systems and it is not feasible to always upgrade to the latest and greatest. Part of why FreeBSD is difficult to adopt into more of the commercial/government sectors is because of this fast paced release cycle and most of the important patches/fixes are not backported far enough. This is why most of my customers decide to use Solaris or RedHat and not FreeBSD. (Not looking to start a flame war about the OS choice/etc just pointing out the Release cycle model). I would love to push FreeBSD harder but it is becoming increasingly difficult as of late. We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? You aren't. There are other people like Devin Teske's group that feel the same (they're upgrading from 4.x to 8.2! Brave man.. and godspeed to him), along with some development organizations that depend on long release cycles (IronPort, Isilon, etc). That being said. More people, more likelihood to succeed with what you need, like julian@ suggests. I like long release cycles too for stuff that I find critical and in production, like my router. My fileserver is a slightly different story, but I just got off the CURRENT bandwagon off on to the 9-STABLE bandwagon :). Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Julian, On Mon, 16 Jan 2012, Julian Elischer wrote: It pretty much boils down to one thing.. man power.. Wouldn't there be more manpower available for more frequent minor releases if the project were not undertaking two simultaneous production releases ? Specifically, wouldn't it have been feasible to be at 8.4 right now if much of 2011 had not been spent breaking ground on 9.0 ? Further, isn't the lack of focus, or polish of the current release also impacted by these decisions ? Of course there is a limited amount of manpower, but for the points I raised that was a symptom, not a cause... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
- Original Message - From: John Kozubik j...@kozubik.com To: freebsd-hackers@freebsd.org Sent: Monday, January 16, 2012 10:28 PM Subject: FreeBSD has serious problems with focus, longevity, and lifecycle 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 must say as a small company that runs ~200 machines on FreeBSD I do see where John is coming from, as it is very time consuming to keep things up to date and new is not always better e.g. we still have boxes stuck on 6.x as issues introduced in the Linux compat after that caused problems. That said I'm in two minds as the features that have been brought in by the more rapid dev cycle like ZFS have been great. Where I do see an issue is where it feels like we've just got to a solid 8.2 release with p6 and some addition patches we see things like em driver updates required to run newer hardware only in 9. While we might like to push everything to 9 it brings with it a large amount of untested changes like the HPN patches to core ssh which we have seen problems with under openssh-portable when tested. So this puts us in a dilemma, push to 9 and keep up to date or stick with 8.2 with custom patches while we wait for 8.3 which we know is good and assuming it has the patches need included in it? The correct answer for us is currently unknown and is still being debated, but in the mean time we are going to keep with 8.2 until we've had the chance to fully evaluate what 9 has to offer. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
thanks john. i've been a long-time (10+ years) freeBSD user (desktops, laptops, servers, and anywhere else i can run it) and advocate (encouraging others to at least check it out) and also a long-time satisfied johnco customer. my freeBSD days seem to be coming to an end. i bought myself a LENOVO T510 when it first came out, around early 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i STILL can't run xorg properly with it. linux has run fine with it since i opened the box. last i checked, freeBSD will be support this GPU in R9... or maybe R10...? i really like freeBSD's robustness, especially compared to linux, among other things. i like that freeBSD is genetically a real unix... what's the real difference between BSD and linux? BSD was developed by unix hackers porting the OS to PC hardware; linux was developed by PC hackers trying to make their own version of unix. these origins are still very apparent, if one knows where to look. i like that i can set up a freeBSD bare-bones (eg secure) mail-server or web-server in an afternoon. but none of that matters if the damn thing just doesn't work. over the last two years, and it pains me to say this, i've been running linux on that T510. but it gets worse... i've been finding that i'm simply more productive on that machine, and spending more time in front of it, and more time getting useful things done. i understand that it's ultimately a matter of manpower and resources, and linux seems to have more momentum and sex appeal, but i'm finding myself in a real crisis of faith... the OS that i've been using and loving for 10+ years seems to be dying, from any real usability perspective. and for now, i'm slowly and reluctantly migrating towards linux. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - We will, in fact, be greeted as liberators. -- Dick Cheney, 16 March 2003 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 16/01/12 16:13 -0800, John Kozubik wrote: Julian, On Mon, 16 Jan 2012, Julian Elischer wrote: It pretty much boils down to one thing.. man power.. Wouldn't there be more manpower available for more frequent minor releases if the project were not undertaking two simultaneous production releases ? Specifically, wouldn't it have been feasible to be at 8.4 right now if much of 2011 had not been spent breaking ground on 9.0 ? Further, isn't the lack of focus, or polish of the current release also impacted by these decisions ? Of course there is a limited amount of manpower, but for the points I raised that was a symptom, not a cause... This would be a different argument if all the devs were paid a salary. In many instances the devs in question wouldn't have the motivation to work on the maintenence release, in others the work is sponsored but is moving in a direction that is fundamentally incompatible with the 8.x release. I'm not trying to refute your input, just offering some insight about how it may not be strictly accurate. -- richo || Today's excuse: Please excuse me, I have to circuit an AC line through my head to get this database working. http://blog.psych0tik.net signature.asc Description: Digital signature
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17/01/12 02:21 +, Igor Mozolevsky wrote: On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer Potentially, but it doesn't invalidate it, imo. I'm very aware that the code I produce for $WORK is very different to code I write in my own time. Code for $WORK is wrapped in test cases, clean, neat and well documented. code I write in my own time tends to be hackish, incomplete totally undocumented and ludicrously easy to break because I'm intrigued by implementing a single interesting figure that has my attention, or to see whether or not a concept is technically feasible. This is a shortcoming of mine that I should work to overcome, but I feel that the same thing would likely extend to other developers, though in most cases to a lesser degree. Without some other motivation most people naturally gravitate towards newer cool features, rather than doing the relatively boring maintenence and backporting. Note though, that recognising this highlights my respect for the people who take the time to do it, even though it may not be as cool as working on the latest and greatest new feature. -- richo || Today's excuse: emissions from GSM-phones http://blog.psych0tik.net signature.asc Description: Digital signature
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 02:25, richo ri...@psych0tik.net wrote: On 17/01/12 02:21 +, Igor Mozolevsky wrote: On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer Potentially, but it doesn't invalidate it, imo. I'm very aware that the code I produce for $WORK is very different to code I write in my own time. Code for $WORK is wrapped in test cases, clean, neat and well documented. code I write in my own time tends to be hackish, incomplete totally undocumented and ludicrously easy to break because I'm intrigued by implementing a single interesting figure that has my attention, or to see whether or not a concept is technically feasible. This is a shortcoming of mine that I should work to overcome, but I feel that the same thing would likely extend to other developers, though in most cases to a lesser degree. Without some other motivation most people naturally gravitate towards newer cool features, rather than doing the relatively boring maintenence and backporting. Are you not making a case for long and thin release cycle vs short and fat then? It's absolutely fine to have a branch (let's call that development) that is cool-and-funky and breaks in 70% of the cases so long as there is another branch (let's call it release) that is not-so-cool-and-funky, but only breaks in 1% of the cases, but is well documented, tested, c and have the developer satisfaction of not only having implemented something cool, but knowing that once that cool is stable enough, that feature is used in environments where stability and dependability matters? A cool feature that nobody can rely on is, quite frankly, junk; is it not? To be realistic, I think any serious developer should expect to spend 70% of their development time on maintenance, for a simple reason that if the software is not maintained to the standard that end-users find usable, they will simply switch, and the user-base to test your latest cool-and-funky gets smaller and smaller... Of course, one way to avoid the 70% being spent on maintenance is to write flawless software, but good luck with that! ;-) This goes back to one of the points that John K. made: who is the system for, the developers or the end users? A system for the latter will quite happily give enough playground for the former, but a system for the former, will never work for the latter. Which, I suppose, is why your $WORK demands a certain quality of code---one way or another their livelihood depends on it!.. -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/16/2012 17:03, Atom Smasher wrote: i bought myself a LENOVO T510 when it first came out, around early 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i STILL can't run xorg properly with it. linux has run fine with it since i opened the box. last i checked, freeBSD will be support this GPU in R9... or maybe R10...? The usual explanation for this is that FreeBSD is the server OS and doesn't need to worry about desktop-only hardware. (Not that I agree with such position.) I noticed that FreeBSD overall isn't too good for laptops (correct me if I am wrong). Even if Arrandale GPU worked, there is no working network manager in kde or gnome, able to find and setup WiFi networks without user typing anything. Also FreeBSD isn't able to enter (and come back from) the sleep mode. Also it can't stop the hard drives when the system is idle (last time I tried I got system crash). These make it very difficult to use FreeBSD on the laptops. Major usability issues. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/16/2012 16:02, Julian Elischer wrote: It pretty much boils down to one thing.. man power.. If the basic design of the system is wrong, it doesn't matter how many person-hours you throw at it (or don't). -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, richo wrote: I'm very aware that the code I produce for $WORK is very different to code I write in my own time. Code for $WORK is wrapped in test cases, clean, neat and well documented. code I write in my own time tends to be hackish, incomplete totally undocumented and ludicrously easy to break because I'm intrigued by implementing a single interesting figure that has my attention, or to see whether or not a concept is technically feasible. code i write for work is (typically) under pressure of time and money. sometimes good documentation is more important than good code, sometimes documentation is irrelevant. at work i've been complimented for getting things done on time and under budget, but NEVER for getting it done right. code i write in my own time is art. i wouldn't write a sloppy song in my spare time, and i don't write sloppy code in my spare time. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - A student asked his old Sufi Master if he should tie up his camel for the night, so that it wouldn't wander away while they were sleeping or if doing so was an insult to God. Should he leave the camel untied to show his trust in God that the camel wouldn't run away? The Master replied Trust God AND tie up your camel. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012, Steven Hartland wrote: 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 must say as a small company that runs ~200 machines on FreeBSD I do see where John is coming from, as it is very time consuming to keep things up to date and new is not always better e.g. we still have boxes stuck on 6.x as issues introduced in the Linux compat after that caused problems. That said I'm in two minds as the features that have been brought in by the more rapid dev cycle like ZFS have been great. The features are great - nobody doesn't want the features! Like I said in the original post, as wonderful as ZFS on FreeBSD is (and we are deploying it this year) it is only now (well, in March) with 8.3 that I feel it is finally safe and stable enough to bet the farm on. I'm not the only one that feels this way. If that's the case, then, ZFS could have been developed just as it has, in a development branch, and not been used as justification for (mutiple) major releases and all of their disruption. As I said in the original post - we should be on 6.12 right now, and bringing out 7.0, with ZFS v28. Where I do see an issue is where it feels like we've just got to a solid 8.2 release with p6 and some addition patches we see things like em driver updates required to run newer hardware only in 9. That's a few releases in a row now where legacy gets locked out of new motherboards because of em(4). But I digress... While we might like to push everything to 9 it brings with it a large amount of untested changes like the HPN patches to core ssh which we have seen problems with under openssh-portable when tested. So this puts us in a dilemma, push to 9 and keep up to date or stick with 8.2 with custom patches while we wait for 8.3 which we know is good and assuming it has the patches need included in it? Exactly. We're in the same boat. Longer, dedicated lifecycle, extended legacy support, and more frequent minor releases were my original suggestions. Why not take the newer production release (or whatever 9.0 is) and rename it development ? Why couldn't this change happen today, specifically with 8.x and 9.x ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Just a note before everyone goes off on wonderful things were with FreeBSD 4.x going all the way to 4.11: 4.x is an anomoly in the history of FreeBSD major versions, being the only release with more than 4? 5? minor releases. There were only a couple minor versions of 1.x; there were only a couple of minor versions of 2.x; there were only a couple minor versions of 3.x; and so on through to 8.x. IOW, the 'glory days before 5.0' is really no different than the days since 5.0. Looking at the complete history of FreeBSD releases, 4.x is the outlier that needs to be discarded for the stats to make sense. (Or something like that, I've failed stats 3 times now.) :) When I started with FreeBSD, there were two production releases available: 2.2.something and 3.1. They even came in the same box set from Walnut Creek? Forget where I ordered them online now. Shortly after, 4.0 was released, but 3.x was stil developped. The only difference between pre-5 and post-5 is the switch from feature-based releases that could take years to develop, to time-based releases that ship at mostly-regular times, with whatever features are ready. The latter is actually more useful, as you can plan ahead of time as you know the general timeframes between major versions. So, let's keep a little perspective in the discussion, and not ignore the past history of FreeBSD releases. Cheers, Freddie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
