Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Thu, 12 Jan 2006 18:15, Jo Rhett wrote: > Before we plan the invasion of Iraq, how about an agreement on what we're > trying to accomplish? Like I said, this topic has always been killed > because "non-newbies can run make buildworld". So if it's going to get > shot down quickly then why bother? You are still fundamentally misunderstanding how FreeBSD works.. You have at least one committer you've said wants to do this, what more do you need? > I've tried to make the point clear, and ignore the insults and try to keep > on topic... but it's pretty much a lost point already. Everyone loves to > say "you're an idiot" or "your ideas [taken out of context] are wrong" etc > and such forth. I think people disagreeing with you is perfectly acceptable.. Calling you an idiot is no, but it seems to be fairly rare (even in this thread) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpM2yxZEunRS.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Thu, 12 Jan 2006 18:07, Jo Rhett wrote: > On Fri, Jan 06, 2006 at 10:20:11PM +1030, Daniel O'Connor wrote: > > I imagine there are a few committers interested, but I'd say you need to > > ask the right way first.. > > As in...? I don't know any personally, but then again I only know about 3 committers which is not a large percentage. > But again, there are lots of people interested in this topic. Colin for > an obvious one. But if Colin can't convince the team to take this on, > where do you start? Colin is a committer. You write the code under his guidance. He commits it. So, there you go, problem solved. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpzQcPCgo49X.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Hej there, Jo Rhett wrote: > On Fri, Jan 06, 2006 at 01:27:18PM +0100, Marian Hettwer wrote: > >>I'm actually wondering how yahoo for instance handles this situation. To >>my knowledge, they have several thousand of FreeBSD based servers. >>Either they are all the same in regards to configuration and version, or >>they have some other cunning way to solve the issue of patching. > > > Yahoo has a very similar implementation to ours from what I grok, but they > aren't happy about releasing their implementation into the wild so I can't > say for sure. > a pity. 'cause I bet there would be some nice ideas. > >>Generally speaking: Your statement is true. You don't start writing code >>without an agreement that the direction choosen is a direction where >>FreeBSD wants to evolve. >>However, you (as in, you as a developer) could come up with a proof of >>concept. Start with an implementation like you would like to have it. >>And even if it's just a piece of paper and some code. > > > Before we plan the invasion of Iraq, how about an agreement on what we're > trying to accomplish? Like I said, this topic has always been killed Please stop with these political statements. They have nothing to do with the topic you're stressing here. Just stop these political statements, please :) > because "non-newbies can run make buildworld". So if it's going to get > shot down quickly then why bother? > Why bother? Because you do see a need for binary updates and you do want to change something. So get started with it. Just write a piece of paper (webpage, whatever), maybe even start coding something. Come up with this paper on freebsd-arch (like stated by someone else) and see wether you can find some agreements. > Frankly, that's pretty much where it has gone. Everyone who cares about > this has privately mailed me saying "it would be nice" but nobody believes > that we can get this accepted for inclusion. > Well, I wouldn't be sure. When perl was removed from base and made optional there was some roaring around too. Nevertheless it was removed from base and is no longer needed to run FreeBSD. > I've tried to make the point clear, and ignore the insults and try to keep > on topic... but it's pretty much a lost point already. Everyone loves to > say "you're an idiot" or "your ideas [taken out of context] are wrong" etc > and such forth. > I was following this thread on -current and frankly, I couldn't see any "you're an idiot" statements. Prove me wrong ( by copy 'n paste of the statement in addition with the sender of that mail ). > >>Then start this thread over again, fine tune the concept and hopefully >>some others will jump aboard and help developing. >>I would like to, but I do lack knowledge in C. Shell and a wee bit of >>Perl is fine. Definitly too few knowledge for a project like that :-/ > > > If it really was a project, just a willingness to test this across a range > of environments and the ability to do-one-thing-at-a-time and read log > files would be great assistance. But given zero interest in the project > expressed so far, this is cart years before horse has evolved. > Then my statement would be again: Yes, I would agree that binary updates could make updating FreeBSD easier. However, there are other ways (apart from using make world). I would think about "make release". This is a way to go. Build your custom releases and roll 'em out. Granted, using own releases is only good if you have like one or two architectures (say i386 and amd64). > >>That statement ain't true. If the code solves your problem, fine. If it >>solves problems of others too, even better. Chances are higher that it >>doesn't get ignored... > > > Code that doesn't solve the problem correctly should be rejected with a > reason. Ignorance advances nothing. No replies/no updates = ignorance. > And no commits means the problem isn't solved. > so far, so true. However, just start your project and ask later on for support. best regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Wed, 2006-Jan-11 23:22:53 -0800, Jo Rhett wrote: >I am deliberately trolling: not to cause grief, but to see if there are any >bites on the topic. So far it's just people insulting my intelligence and >cut&pasting web pages to me. Going out of your way to antagonize FreeBSD developers is not the way to get your ideas adopted. >And yes, I'm using a macro I call '-core' to refer to group of people who >can absolutely kill something like this because they don't like the food >coloring in it. It's a convenience for me. As a convenience for the rest of us, how about using same terminology as the rest of the Project. It makes it much simpler if we all agree on the meanings of the words we use. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Jan 06, 2006 at 01:27:18PM +0100, Marian Hettwer wrote: > I'm actually wondering how yahoo for instance handles this situation. To > my knowledge, they have several thousand of FreeBSD based servers. > Either they are all the same in regards to configuration and version, or > they have some other cunning way to solve the issue of patching. Yahoo has a very similar implementation to ours from what I grok, but they aren't happy about releasing their implementation into the wild so I can't say for sure. > > We need support from the freebsd core developers that this is a worthwhile > > idea, and what kind of solutions would be acceptable to them. Once we have > > a direction to go in, code can be written. > Generally speaking: Your statement is true. You don't start writing code > without an agreement that the direction choosen is a direction where > FreeBSD wants to evolve. > However, you (as in, you as a developer) could come up with a proof of > concept. Start with an implementation like you would like to have it. > And even if it's just a piece of paper and some code. Before we plan the invasion of Iraq, how about an agreement on what we're trying to accomplish? Like I said, this topic has always been killed because "non-newbies can run make buildworld". So if it's going to get shot down quickly then why bother? Frankly, that's pretty much where it has gone. Everyone who cares about this has privately mailed me saying "it would be nice" but nobody believes that we can get this accepted for inclusion. I've tried to make the point clear, and ignore the insults and try to keep on topic... but it's pretty much a lost point already. Everyone loves to say "you're an idiot" or "your ideas [taken out of context] are wrong" etc and such forth. > Then start this thread over again, fine tune the concept and hopefully > some others will jump aboard and help developing. > I would like to, but I do lack knowledge in C. Shell and a wee bit of > Perl is fine. Definitly too few knowledge for a project like that :-/ If it really was a project, just a willingness to test this across a range of environments and the ability to do-one-thing-at-a-time and read log files would be great assistance. But given zero interest in the project expressed so far, this is cart years before horse has evolved. > That statement ain't true. If the code solves your problem, fine. If it > solves problems of others too, even better. Chances are higher that it > doesn't get ignored... Code that doesn't solve the problem correctly should be rejected with a reason. Ignorance advances nothing. No replies/no updates = ignorance. And no commits means the problem isn't solved. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Jan 06, 2006 at 10:20:11PM +1030, Daniel O'Connor wrote: > I imagine there are a few committers interested, but I'd say you need to ask > the right way first.. As in...? But again, there are lots of people interested in this topic. Colin for an obvious one. But if Colin can't convince the team to take this on, where do you start? I tried to start by suggesting to Scott that a faster release schedule means that maybe this should be considered a priority. To see if even a consensus on the *idea* could be reached. Mostly I just get insults. SOP for freebsd. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Jan 06, 2006 at 01:16:36PM -0800, John-Mark Gurney wrote: > You're trying to target to large of an audience... You need to get _A_ > committer interested in your work, and get HIM to guide you and commit > your work... DING! Now we are FINALLY understanding what my goal for this topic was. ARE there any committers who agree that binary updates would be good, and are willing to attempt to acquire enough consensus to get this project started? This topic comes up periodically, and the answer was always no. > stop talking about core... -core makes absolutely no technical decisions > about how FreeBSD is.. it is the developers, and previously there was > a technical review board for settling differences between developers > that were pure "technical" in nature... And if you claim you didn't > know this, then you better read the email you respond to more closely, > since this has been pointed out to you numerous times.. Yes yes this is known. Again, exactly who is at the helm makes no difference if nobody at the helm is interested in the project. I'm not trying to change/restructure/ANYTHING! about the FreeBSD project. I'm bringing up a topic that comes up periodically but gets shot down, to see if there is any new interest in the topic. I am deliberately trolling: not to cause grief, but to see if there are any bites on the topic. So far it's just people insulting my intelligence and cut&pasting web pages to me. Typical FreeBSD: assume the person is stupid and reply as such. > hmmm... you really are choosing to completely ignore what people have > said about core, that at least you did add developers after core, which > makes it appear less likely that you're talking about -core.. but lots > of stuff gets done w/o core developers... I did lots of work on -sparc64, Did your changes to -sparc require changes to the mainline freebsd installation process? If not, then this requires a lot less buy-in from a lot less people. So it's not the same. And yes, I'm using a macro I call '-core' to refer to group of people who can absolutely kill something like this because they don't like the food coloring in it. It's a convenience for me. > As for the whole installation thing, you need to talk with re (release > engineering) as they are the ones to really have final say in what > installation and releases look like... Yes. But back when release engineering was interested in packaging the base installation for exactly the reasons I've listed in other messages, a great uproar was heard and the entire topic was killed off because "freebsd isn't for newbies" and "non-newbies can use make buildworld" without any regard for all of the real issues that production facilities face. In short, there is some group of individuals who can kill projects. This group obviously changes over time, but this issue has repeatedly been killed by some group of people I lazily call "-core" > FreeBSD isn't commercial, so you can't talk about budgets... And most > orgs want some sort of prototypes and feasibility study done before > they'll commit any budget to it... Ah, yes. But that requires conversation to happen and consensus about what kind of results are "feasible" which means that you have to converse first, and write code later. You've made my point for me. > None of this prevents you from getting a basic prototype that works, > but isn't complete with bells and whistles.. Look at what Colin did > with FreeBSD update, I didn't see him demanding anyone in FreeBSD to > sign off on his work... Colin created freebsd-update in spite of not having support for integrating it. And he certainly has commit access. Anyway, Colin (in both freebsd-update and bsdupdates.com) is having to do things the very long way around because of the lack of information provided in the core operating system. Much as we've had to do here, but we structured it inside the cfengine framework. Anyway, the point is that doing it without any chance of integration means going the VERY long way around, which won't help the core installation. Colin could tear out a great deal of his code if the core installation documented versions and checksums at time of installation. Even more code if there was a localized backout ability. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sat, Jan 07, 2006 at 06:44:36AM +1100, Peter Jeremy wrote: > In general, volunteer projects have a surfeit of ideas and a shortage > of real implementations. The Project is never going to agree to import > an idea without some substance. Always true, and I wouldn't expect less. But we've covered the topic of wasting time writing code without buyin. > >consensus that (a) the project has interest and (b) what flavors would be > >acceptable to the existing groups - are both necessary for this project to > >even mumble it's first line of code. > In which case you need to move this thread to freebsd-arch where these > sort of issues are discussed. You need to clearly define your goals > and suggest a design to meet them. If your idea has merit, you'll be > able to convince at least one committer to work with you to implement > your design. Yes, if it even gets that far. But you're putting the cart before the horse. When Scott posted the release schedule, I was not offering to build this for him (although I am interested enough to try/help/etc) I was suggesting that perhaps this issue deserves a priority focus, given the escalation of releases. You're saying "If you want to go to war in Iraq then hire a military" and I'm saying "I was just trying to see if there was agreement that Saddam is a bad guy" and more specifically "I have no desire to rush into Iraq without consensus" ;-) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800: > On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > > I believe core has a policy of never supporting vaporware... There is > > always the chicken and egg problem with arguments like this... I'll > > code this if you agree to support it and maintain it/I will agree to > > support it once you code it... In FreeBSD, and many open source > > projects, no code, no support, how can you support or even agree to > > support something that doesn't exist? And then as soon as FreeBSD > > agrees to support something that doesn't exist, either a) other people who > > were interested in the project stop, even if you end up never producing > > a bit of code, or b) someone else produces better code, drops the > > support for the original, but then the author complains about being > > told they'd support his code, and going with another code base... > > > > Bottom line: Once code exists, then support can be talked about.. > > This is the chicken and egg problem that will kill FreeBSD. I don't And many other open source software projects... FreeBSD isn't unique in this.. I've submitted patches to many other projects just to have them ignored for years too... It's a problem of voluteer orginizations.. > bother writing up patches for FreeBSD because every time I do they sit in a > PR and get ignored for several years. Then someone that does have commit > rights makes their own patch (which often is less useful) but they own it > and the best I've ever succeeded at was convincing them to put some of the > ideas from my patch into their code. > > Note that none of these patches were ever rejected for any technical or > political or any other reason. They just don't get paid attention to. > > Thus, I try to get consensus that the idea has merit. IF freebsd > committers can be bothered to pay attention to the idea, I'll write code > for it. But I'm too old and tired to spend another week writing up > something that will get ignored for X years and then dropped for obsoletion > again. You're trying to target to large of an audience... You need to get _A_ committer interested in your work, and get HIM to guide you and commit your work... > AND there are a lot of opinions and politics around how to version the core > that have nothing to do with code. There's no value in writing code that > will be ignored because it doesn't agree with -core's view of "should be". > I'm a coder, not a politician. If we can get consensus on what type of > implementation would be acceptable to core, then I and many others would be > happy to write code to implement this idea. But this is a considerable > amount of work that will be closely tied to the operation system > installation. It's not something that you can churn out 7 different > implementations of just to see which one fits the current polical > environment. stop talking about core... -core makes absolutely no technical decisions about how FreeBSD is.. it is the developers, and previously there was a technical review board for settling differences between developers that were pure "technical" in nature... And if you claim you didn't know this, then you better read the email you respond to more closely, since this has been pointed out to you numerous times.. and you said in another email: > First, this is obvious and true for all open source projects. But no, > FreeBSD _never_ advances because someone writes code that does something > well. FreeBSD _only_ advances when the core developers agree that this > thing is worthy of their interest. hmmm... you really are choosing to completely ignore what people have said about core, that at least you did add developers after core, which makes it appear less likely that you're talking about -core.. but lots of stuff gets done w/o core developers... I did lots of work on -sparc64, and I'm pretty sure you wouldn't call me a core developer.. and I also got TS-7200 arm support (though it hasn't been committed to cvs due to issues that I haven't resolved with device configuration)... As for the whole installation thing, you need to talk with re (release engineering) as they are the ones to really have final say in what installation and releases look like... > Back to your finale: > > > Bottom line: Once code exists, then support can be talked about.. > > This is bullhockey and you know it. Once the project is done, we'll > authorize a budget for it? Once the season is over we'll know who should FreeBSD isn't commercial, so you can't talk about budgets... And most orgs want some sort of prototypes and feasibility study done before they'll commit any budget to it... > be on the starting team? Yeah, hindsight is sweet. But this isn't a > simple change. It will require very close integration with the installation > and kernel modules at least (and probably more). So having some sort of > consensus that (a) the project has in
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, 2006-Jan-06 03:03:18 -0800, Jo Rhett wrote: >> Bottom line: Once code exists, then support can be talked about.. > >This is bullhockey and you know it. Once the project is done, we'll >authorize a budget for it? Once the season is over we'll know who should >be on the starting team? In general, volunteer projects have a surfeit of ideas and a shortage of real implementations. The Project is never going to agree to import an idea without some substance. > Yeah, hindsight is sweet. But this isn't a >simple change. It will require very close integration with the installation >and kernel modules at least (and probably more). So having some sort of >consensus that (a) the project has interest and (b) what flavors would be >acceptable to the existing groups - are both necessary for this project to >even mumble it's first line of code. In which case you need to move this thread to freebsd-arch where these sort of issues are discussed. You need to clearly define your goals and suggest a design to meet them. If your idea has merit, you'll be able to convince at least one committer to work with you to implement your design. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Hi there, Jo Rhett wrote: > On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: >> >>So, uhh, how would your magical binary upgrade system handle custom kernels? >>Why would it be any different? You still haven't explained how this would >>work.. > > > Versioning of the core package would tell you WHAT you have with a query. > It's trivial to then install the matching patches. Right now every > enterprise has to build a backend database tracking core os, installed > options, compile options, etc for every single installed system. Or build > a checksum database that can be used to derive this information from the > system (if all systems have the CPU/RAM to spare to play this game) > I'm actually wondering how yahoo for instance handles this situation. To my knowledge, they have several thousand of FreeBSD based servers. Either they are all the same in regards to configuration and version, or they have some other cunning way to solve the issue of patching. > > We need support from the freebsd core developers that this is a worthwhile > idea, and what kind of solutions would be acceptable to them. Once we have > a direction to go in, code can be written. > Generally speaking: Your statement is true. You don't start writing code without an agreement that the direction choosen is a direction where FreeBSD wants to evolve. However, you (as in, you as a developer) could come up with a proof of concept. Start with an implementation like you would like to have it. And even if it's just a piece of paper and some code. Then start this thread over again, fine tune the concept and hopefully some others will jump aboard and help developing. I would like to, but I do lack knowledge in C. Shell and a wee bit of Perl is fine. Definitly too few knowledge for a project like that :-/ > >>If you supply a working framework then I think you'll find a lot of support >>materialises. The problem is when you are just proposing vapourware solutions >>everyone steps in and wants it done their way. >> >>Code speaks louder than words :) > > > I've written far too much code for various freebsd problems, and it has > always been ignored. Not rejected, ignored. Unless someone with commit > rights thinks it's a good idea, writing code for freebsd is a waste of > time. > That statement ain't true. If the code solves your problem, fine. If it solves problems of others too, even better. Chances are higher that it doesn't get ignored... regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, 6 Jan 2006 21:53, Jo Rhett wrote: > > you mean? Are you claiming someone from (or claiming to be from core) > > said "Don't do this, we won't allow it"? If so, can you supply proof? > > I used to write a lot of patches to freebsd. I used to submit a lot of bug > reports. I've found over the years that unless you have gotten > pre-agreement from others about the nature of the patch, or agreement to > focus on the problem, neither one amounts to a hill of beans. Installation > problems that existed in 4.4 are still alive and well in the 6.0 installer, > for example. That is not my experience. > How FreeBSD "works" is by getting someone in the core team to care about > the issue. No amount of problem reports, patches or code will generate > even a millimeter of movement otherwise. You are mistaking core@ for [EMAIL PROTECTED] Like I've said before, core is largely irrelevant in FreeBSD when it comes to deciding what stuff gets added. > I've written far too much code for various freebsd problems, and it has > always been ignored. Not rejected, ignored. Unless someone with commit > rights thinks it's a good idea, writing code for freebsd is a waste of > time. Yes.. and those people AREN'T CORE. Please, please stop confusing your terms, it makes the discussion much harder than it needs to be. You ARE right if what you mean is that "We need interested committers to help thrash out a system for making upgrades simpler". I imagine there are a few committers interested, but I'd say you need to ask the right way first.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpW2Ga0PbgcH.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> > I just know that core has either struck it down or been Silent. On Thu, Jan 05, 2006 at 05:32:26PM -0600, Mark Linimon wrote: > The latter is an entirely different case from the former, and you've been > claiming core has done the former. This, and the above, tell me that > you're not interested in checking your facts before making an accusation. > (And, as well, that you do not even understand the role the core plays > in the project. Hint: it is not primarily technical in nature.) I agree with most of what you said here. This was known and understood. Agreement on direction is what I was expecting, er, dreaming about. Not technical issues. Sorry if that surprises you. But I have to take objection to this: > As a final observation, FreeBSD is rarely advanced by postings of the > form 'FreeBSD must do XYZ'. This is primarily because volunteers work on > whatever they feel interested in doing with their free time, rather than > the priorities anyone else sets for them. First, this is obvious and true for all open source projects. But no, FreeBSD _never_ advances because someone writes code that does something well. FreeBSD _only_ advances when the core developers agree that this thing is worthy of their interest. And I'm not even saying this is a bad thing. It just means that writing code without buy-in from the core developers is GUARANTEED to be a waste of time. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: > For NFS mount, read: any network file system. You can also use, say IPSEC to > protect the NFS packets (although I'm not claiming it's a trivial thing to > set up..) IPsec is trivial compared to the amount of code and localized databases we use to manage system versioning information today. > As for restricting the number of writes - that is a totally separate issue > and > isn't very relevant to this discussion. Agreed. > In general core IS silent. > Core isn't some governing body that decides what happens in FreeBSD and plans > in detail what happens. You are showing a fundamental misunderstanding about > how FreeBSD "works". > Also, you just said "... the topic is always struck down ..." - what do you > mean? Are you claiming someone from (or claiming to be from core) said "Don't > do this, we won't allow it"? If so, can you supply proof? I used to write a lot of patches to freebsd. I used to submit a lot of bug reports. I've found over the years that unless you have gotten pre-agreement from others about the nature of the patch, or agreement to focus on the problem, neither one amounts to a hill of beans. Installation problems that existed in 4.4 are still alive and well in the 6.0 installer, for example. How FreeBSD "works" is by getting someone in the core team to care about the issue. No amount of problem reports, patches or code will generate even a millimeter of movement otherwise. So yeah, I take Silence as a negative. I've got zero experience to demonstrate otherwise. > I would *welcome* a more sophisticated method for binary upgrades that was a > lot smarter. I imagine pretty much everyone else would too. Really? I'm about to give up again and bring it up next year. It's become the annual gonzo-thread that never generates anything. > Anyway, so what? Nothing stops you writing such a system, Nothing stops me, but it will become useless without constant maintenance. And core would have no obligation to consider the effects of their changes on this. > and I contend it > isn't necessary to version the base system, or package it specially to do > binary upgrades. Something similar to freebsd-update could do it. I've already spelled out the problems here. Freebsd-update/bsdupdates.com spell out the problems with their approach in their documentation. Many others have written on this issue. That said, if we can actually get a real conversation going about how to handle this then I'd love to hear your input on how to solve all of the problems we've raised without versioning of the core. --but not now, in this thread. This thread appears to be DOA and I'm not going to keep wasting time on this without even a hint that core would be interested in a solution to this problem. (not a blank check, just an expression of interest) > > freebsd-update works "fine" if you run GENERIC with no build options. > > Back to "useful for home computers". > > So, uhh, how would your magical binary upgrade system handle custom kernels? > Why would it be any different? You still haven't explained how this would > work.. Versioning of the core package would tell you WHAT you have with a query. It's trivial to then install the matching patches. Right now every enterprise has to build a backend database tracking core os, installed options, compile options, etc for every single installed system. Or build a checksum database that can be used to derive this information from the system (if all systems have the CPU/RAM to spare to play this game) > > freebsd-update is hampered by the exact problems I'm listing here. > > Difficulty determining "what I have", no method to store "what I did" and > > no effective backout mechanism to speak of. > > Then feel free to expand on it. > This IS an open source project - you can see how everything is written, if > you > want to improve it I would be happy to write code. See my other messages about "waste of time". Without a comittment to the idea from someone with commit access, writing patches or new code just sits in PRs and dies of old age. > > Nobody that I know cares whether or not the solution manifests as core os > > packages, but some sort of core versioning ability has to be developed and > > supported by the core. > > I don't think core is really very relevant here - core is there to mostly > settle disputes. The way forward is to achieve consensus and have working > solutions. Sorry, I was mixing my uses of 'core' here. My bad. The "unpackaged" part of freebsd needs some sort of versioning ability. But yes, you are making my point for me. Without core's agreement that this is a worthwhile project (as in: to be considered - not a blank check) no amount of code will ever amount to anything other than another unsupported freebsd-update style project. We need support from the freebsd core developers that this is a wort
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > I believe core has a policy of never supporting vaporware... There is > always the chicken and egg problem with arguments like this... I'll > code this if you agree to support it and maintain it/I will agree to > support it once you code it... In FreeBSD, and many open source > projects, no code, no support, how can you support or even agree to > support something that doesn't exist? And then as soon as FreeBSD > agrees to support something that doesn't exist, either a) other people who > were interested in the project stop, even if you end up never producing > a bit of code, or b) someone else produces better code, drops the > support for the original, but then the author complains about being > told they'd support his code, and going with another code base... > > Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code. Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of "should be". I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. Back to your finale: > Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups - are both necessary for this project to even mumble it's first line of code. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
ml> (And, as well, that you do not even understand the role the core plays ml> in the project. Hint: it is not primarily technical in nature.) For those curious to know how the project works, the following online resources may help: A project model for the FreeBSD Project http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/index.html The FreeBSD development process: a case study http://www.cs.colostate.edu/puml/pub/FreeBSD_TSEVersion.pdf The FreeBSD Committers Guide http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
[cross post to -current removed] On Thu, 5 Jan 2006 19:54, Jo Rhett wrote: > On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > > On each 'client' PC.. > > NFS mount /usr/src and /usr/obj > > installkernel > > reboot > > installworld > > Works fine on home computers behind firewalls. > > Useless on public servers that don't run RPC. > Useless on flash-based servers where minimizing writes is necessary. > (mergemaster does far far far too many writes) For NFS mount, read: any network file system. You can also use, say IPSEC to protect the NFS packets (although I'm not claiming it's a trivial thing to set up..) As for restricting the number of writes - that is a totally separate issue and isn't very relevant to this discussion. > > You are putting words in the mouth of core@ - > > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. I just know that core has > either struck it down or been Silent. In general core IS silent. Core isn't some governing body that decides what happens in FreeBSD and plans in detail what happens. You are showing a fundamental misunderstanding about how FreeBSD "works". Also, you just said "... the topic is always struck down ..." - what do you mean? Are you claiming someone from (or claiming to be from core) said "Don't do this, we won't allow it"? If so, can you supply proof? > A good binary update mechanism shouldn't be just the network. Updates from > flash devices, ISO images, etc should all work much the same way. Absolutely. In fact you could put /usr/src and /usr/obj on a CD/DVD/Flash drive and upgrade that way. I would *welcome* a more sophisticated method for binary upgrades that was a lot smarter. I imagine pretty much everyone else would too. > > Unless you mean "core@ said they would not support packaging the base" > > which is different. > > People have clearly identified the problems that prevent a useful binary > update mechanism from working, and what they need from core. Some have > asked for core packages, others have other ideas, and some have said > "anything that gives me versioning ability" and and..? Anyway, so what? Nothing stops you writing such a system, and I contend it isn't necessary to version the base system, or package it specially to do binary upgrades. Something similar to freebsd-update could do it. > > This is not true - I don't see it as being mandatory to be able to apply > > binary updates. (Case in point - freebsd-update works fine without it) > > freebsd-update works "fine" if you run GENERIC with no build options. > Back to "useful for home computers". So, uhh, how would your magical binary upgrade system handle custom kernels? Why would it be any different? You still haven't explained how this would work.. > freebsd-update is hampered by the exact problems I'm listing here. > Difficulty determining "what I have", no method to store "what I did" and > no effective backout mechanism to speak of. Then feel free to expand on it. This IS an open source project - you can see how everything is written, if you want to improve it > Nobody that I know cares whether or not the solution manifests as core os > packages, but some sort of core versioning ability has to be developed and > supported by the core. I don't think core is really very relevant here - core is there to mostly settle disputes. The way forward is to achieve consensus and have working solutions. If you supply a working framework then I think you'll find a lot of support materialises. The problem is when you are just proposing vapourware solutions everyone steps in and wants it done their way. Code speaks louder than words :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpOsYpsgg2xj.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. This information is publicly available if you want to do the research. > I just know that core has either struck it down or been Silent. The latter is an entirely different case from the former, and you've been claiming core has done the former. This, and the above, tell me that you're not interested in checking your facts before making an accusation. (And, as well, that you do not even understand the role the core plays in the project. Hint: it is not primarily technical in nature.) Because of this, it's more much difficult for me to give your technical arguments as much credence as I would otherwise. As a final observation, FreeBSD is rarely advanced by postings of the form 'FreeBSD must do XYZ'. This is primarily because volunteers work on whatever they feel interested in doing with their free time, rather than the priorities anyone else sets for them. But your mileage may vary. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: > > You are putting words in the mouth of core@ - > > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. I just know that core has > either struck it down or been Silent. I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
> Patrick M. Hausen, and lo! it spake thus:
> > Any suggestions for an alternative to NFS if your 'client' servers
> > are located "all over the world" and you want to installworld across
> > the Internet? I was planning to use NFS/TCP secured by IPSec
> > transport mode, but anything less complicated would be greatly
> > appreciated ;-)
On Fri, Dec 23, 2005 at 02:56:57AM -0600, Matthew D. Fuller wrote:
> This is one of the situations where r{dist,sync}'ing out the binaries
> makes more sense than NFS mounting and running installworld (which
> would be awful awful slow, above and beyond security and convenience
> issues).
This works fine for small patches (ie cvs patch last year). How do you
handle configuration changes/comparisons? (ie mergemaster stuff?)
--
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) > You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say "we'll support this". I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. > I find it very hard to believe > that core would suggest someone NOT implement a good framework for doing full > binary upgrades via the network. A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. > Unless you mean "core@ said they would not support packaging the base" which > is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said "anything that gives me versioning ability" and > > For binary upgrades without booting from CD-ROM to be possible, we need > > versioning of some sort at the OS level. Core OS packages are the most > > This is not true - I don't see it as being mandatory to be able to apply > binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works "fine" if you run GENERIC with no build options. Back to "useful for home computers". freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining "what I have", no method to store "what I did" and no effective backout mechanism to speak of. Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. > > popular suggestion, but not the only path. Every year this topic comes up > > and gets struck down again. > > Yes, because a) it isn't necessary, b) it may not solve the problem, c) there > are no patches to evaluate. > > I think the people suggesting it see it as a panacea to fix their problems > but > haven't fully evaluated it. You're arguing my own points. Again, nobody (that I know) cares that it manifests as core OS packages. Certainly the existing package system used for ports wouldn't work as-is for this task. But the have/did/undo problems remain to be solved. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> On Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of > Jo Rhett, and lo! it spake thus: > > > > No, you're missing the point. More core OS upgrades means less > > incremental patches (which are easier to apply than a full update). On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > Right. I don't understand how B follows A here. > > These patches come from where? Security advisories, mailing list > discussions, and eating too much beef right before bed and waking up > at 2am with brilliant ideas? Why would there be less of them, just > because RELENG_X_Y_RELEASE tags are laid down more often? FreeBSD provides patches for two major OS revisions, right? If you have more OS revisions in less time, then you have a smaller window of support time. Simple. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > Having done full OS upgrades a number of times, I can't remember the > last time it took more than 5 or 10 minutes (during most of which the When the servers are in 17 countries around the world, with no CD-ROM access. You keep missing the point about "not your home computer". > > Back to the point, the comments aren't "bad". Your idea that binary > > operating system upgrades from ISO are "easier" demonstrates that > > you're talking about home computers, not production servers. > > Oh, no. Heck, I find that upgrades from SOURCE are "easier". In > fact, just last month I bought my first CD burner, so it wasn't until > a few weeks ago that I even burned my first ISO (and that, just to > test the burner and figure out how to do it), and I've never booted or > installed off one. For small groups of servers, I NFS mount > installworlds, and for larger groups, I rdist out binaries. But it > always comes from source. You can't do source installations on flash-based systems. You can't do NFS across the Internet (we don't even have RPC working at all on production systems) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Sun, 25 Dec 2005 02:02, Brian Candler wrote: > Linux has an extremely neat solution for this (sshfs) but I don't know of > anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in > architecture which allows filesystems to run in userland. I believe it > makes an sftp connection to the remote host, and then exposes it as if it > were a real filesystem. Someone ported FUSE to FreeBSD for the Google SoC. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpdzXsf31mjA.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, Dec 23, 2005 at 09:51:15AM +0100, Patrick M. Hausen wrote: > Any suggestions for an alternative to NFS if your 'client' servers > are located "all over the world" and you want to installworld across > the Internet? I was planning to use NFS/TCP secured by IPSec transport > mode, but anything less complicated would be greatly appreciated ;-) > > Anyone using ggated/ggatec for that purpose? I think that would not work unless you had a second FreeBSD installation on the remote machine and rebooted into that while you were upgrading the first. That's because you can't safely modify a block filesystem while it's mounted by someone else (even read-only). You could try tunneling NFS/TCP through ssh port forwarding. Never tried it myself, and there may be some gotchas. Linux has an extremely neat solution for this (sshfs) but I don't know of anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in architecture which allows filesystems to run in userland. I believe it makes an sftp connection to the remote host, and then exposes it as if it were a real filesystem. Regards, Brian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, 23 Dec 2005 21:10:19 +0530 Joseph Koshy <[EMAIL PROTECTED]> wrote: > www.infrastructures.org > www.isconf.org and perhaps also http://www.cfengine.org/ and probably others. IMHO, FreeBSD is a good os, with good options on configuration and management. It is not a systems management tool / system, and (IMHO) it shoildn't try to be that either. Let those who need it build the necessary tools to do large scale FreeBSD administration and maintenance. If the tool is good, it will be used. So far, I have read only a lot of bikeshedding. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
phk> Bring to system administration what source code phk> version control brought to programming. www.infrastructures.org www.isconf.org -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
I have consistently ignored all emails in this thread because the use of the word "demand" in the Subject. Whenever people use words like "demand" or "somebody should" in FreeBSD contexts, it indicates cluelessness to me. Cluelessness about how the project works and cluenessness about how things happen in the project and a touch of insensibility to the developers how seldom are paid to listen to such drivel. The precense if "binary updates" in the subject also indicated to me that we had to do with people who didn't really know what they were talking about nor indeed the implications of attempting to do what they demanded. Now that I've read the tread anyway I can to my chagrin see that I was right. In my opinion, and I readily admit that since I only have 20+ years of experience managing UNIX computers I may be totally wrong, binary updates is not what we really want. It's what people are used to, but it is not what they want. It would be much better to invest time in developing a configuration management system that allows the system administrators of FreeBSD installations to do their job more effectively than to spend time giving them the tool they know inwards and outwards is not an effective way to do their job. The assignment is simple, and with creative thinking maybe the solution is also: Bring to system administration what source code version control brought to programming. Merry Xmas, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Brian Candler wrote: > I think the real concern here is: for how long after RELEASE_X_Y are binary > patches for it made available? I build FreeBSD Update patches for all the branches supported by the FreeBSD Security Team. To answer a couple of other questions: FreeBSD Update is something which I _personally_ support; it isn't supported by the _project_, because at the moment there isn't anyone else who could take over running it if I get hit by a bus. Re the long list of requests people have made (starting with "amd64 support" and "make this officially supported by the project"), I'll get to those as soon as I have time. Sadly, I have a pesky thing called "a full time job" and my FreeBSD time has been occupied with portsnap lately. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, 23 Dec 2005 19:26, Matthew D. Fuller wrote:
> > the Internet? I was planning to use NFS/TCP secured by IPSec
> > transport mode, but anything less complicated would be greatly
> > appreciated ;-)
>
> This is one of the situations where r{dist,sync}'ing out the binaries
> makes more sense than NFS mounting and running installworld (which
> would be awful awful slow, above and beyond security and convenience
> issues).
I guess one problem is that is replicating installworld's behaviour can be
difficult as it does more than just install files sometimes.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgpJLWYEOBSRc.pgp
Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > > No, you're missing the point. More core OS upgrades means less > > incremental patches (which are easier to apply than a full update). > > Right. I don't understand how B follows A here. > > These patches come from where? Security advisories, mailing list > discussions, and eating too much beef right before bed and waking up > at 2am with brilliant ideas? Why would there be less of them, just > because RELENG_X_Y_RELEASE tags are laid down more often? I think the real concern here is: for how long after RELEASE_X_Y are binary patches for it made available? If the policy is "every RELEASE_X_Y has binary patches available for Z months after its release", then clearly it doesn't matter how many RELEASE_X_Y's are made in this period. If the policy is "binary patches are made available for the last N releases", then the availability lifetime of binary patches is (N * release interval). As long as N is made sufficiently large, then it's not a problem. There is a risk that reducing the interval between releases does not cause a corresponding increase in N, thus forcing people to perform full updates to a new release more often. > > Huh? That's backwards. If we can't schedule the downtime for a > > full operating system upgrade (which takes far longer than it > > should) then the system won't get upgraded. > > Having done full OS upgrades a number of times, I can't remember the > last time it took more than 5 or 10 minutes ... > For small groups of servers, I NFS mount > installworlds, and for larger groups, I rdist out binaries. But it > always comes from source. That's good for you and a certain clan of highly experienced FreeBSD system administrators. However I believe that there's a far larger pool of people for whom binary installs and upgrades makes much more sense. At one end of the spectrum are those bailing out from Linux, and the other end are people who want an audit trail for every binary back to a 3rd-party release medium. (I started off in the first group, but now fall into the second) Regards, Brian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, Dec 23, 2005 at 09:51:15AM +0100 I heard the voice of
Patrick M. Hausen, and lo! it spake thus:
>
> Any suggestions for an alternative to NFS if your 'client' servers
> are located "all over the world" and you want to installworld across
> the Internet? I was planning to use NFS/TCP secured by IPSec
> transport mode, but anything less complicated would be greatly
> appreciated ;-)
This is one of the situations where r{dist,sync}'ing out the binaries
makes more sense than NFS mounting and running installworld (which
would be awful awful slow, above and beyond security and convenience
issues).
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
Hi, Folks! > On your central PC.. > buildworld once. > builkernel once for each of the different kernels you are using. > > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Any suggestions for an alternative to NFS if your 'client' servers are located "all over the world" and you want to installworld across the Internet? I was planning to use NFS/TCP secured by IPSec transport mode, but anything less complicated would be greatly appreciated ;-) Anyone using ggated/ggatec for that purpose? Thanks, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of Jo Rhett, and lo! it spake thus: > > No, you're missing the point. More core OS upgrades means less > incremental patches (which are easier to apply than a full update). Right. I don't understand how B follows A here. These patches come from where? Security advisories, mailing list discussions, and eating too much beef right before bed and waking up at 2am with brilliant ideas? Why would there be less of them, just because RELENG_X_Y_RELEASE tags are laid down more often? > Huh? That's backwards. If we can't schedule the downtime for a > full operating system upgrade (which takes far longer than it > should) then the system won't get upgraded. Having done full OS upgrades a number of times, I can't remember the last time it took more than 5 or 10 minutes (during most of which the system can keep running its normal services, just a little more crunched on CPU or I/O). Well, OK, I can; it was when I moved servers from 2.2.x to 4.x. But that's a rather exceptional case, and next time THAT happens, I'm darn well using it as an excuse to strongarm new hardware out of somebody and replace the server at the same time... > Not to be rude, but I think your definition of analogy is wrong. No, you're right. "Hyperbole" was probably a better word, but even that doesn't quite fit. My ability to find the right word is flaky at times. I don't understand the basis of your assertion that more common tagging means suddenly you can't apply individual patches. > Back to the point, the comments aren't "bad". Your idea that binary > operating system upgrades from ISO are "easier" demonstrates that > you're talking about home computers, not production servers. Oh, no. Heck, I find that upgrades from SOURCE are "easier". In fact, just last month I bought my first CD burner, so it wasn't until a few weeks ago that I even burned my first ISO (and that, just to test the burner and figure out how to do it), and I've never booted or installed off one. For small groups of servers, I NFS mount installworlds, and for larger groups, I rdist out binaries. But it always comes from source. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, 23 Dec 2005 08:42, Jo Rhett wrote: > > Using a build server as a testbed and to generate new packages or even a > > new kernel + world will reduce the amount of work required, but FreeBSD > > does require some level of administration and maintenance. > > We already have that. But again, I'm not sure what you are trying to say > here. The centralized server makes patching and port upgrades easier. It > does _NOTHING_ for core OS upgrades because there is no supported mechanism > for doing binary upgrades except from the ISO. Thus, we are finally back > on topic. Uhh.. On your central PC.. buildworld once. builkernel once for each of the different kernels you are using. On each 'client' PC.. NFS mount /usr/src and /usr/obj installkernel reboot installworld Sure there are no tools to automagically do this, but I don't believe core would say "no, we will never support this". > I have made suggestions. Everyone has made suggestions. Most of us have > produced code to work around the problem, but the core OS team has always > refused to support or acknowledge these efforts. You are putting words in the mouth of core@ - I find it very hard to believe that core would suggest someone NOT implement a good framework for doing full binary upgrades via the network. Unless you mean "core@ said they would not support packaging the base" which is different. > For binary upgrades without booting from CD-ROM to be possible, we need > versioning of some sort at the OS level. Core OS packages are the most This is not true - I don't see it as being mandatory to be able to apply binary updates. (Case in point - freebsd-update works fine without it) > popular suggestion, but not the only path. Every year this topic comes up > and gets struck down again. Yes, because a) it isn't necessary, b) it may not solve the problem, c) there are no patches to evaluate. I think the people suggesting it see it as a panacea to fix their problems but haven't fully evaluated it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGhZEDHKKBL.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Dec 22, 2005 at 04:45:09PM -0500, Chuck Swiger wrote: > FreeBSD releases new .ISO images several times a year, but you've got the > tools to make .ISO images of patch releases yourself, if you want to. I > don't think that the FreeBSD project can shorten the release cycle below a > month or so, which means that patch releases are always going to be on the > (b)leading edge... I'm not sure you're paying attention to what I'm saying. This was your reply to my message about systems without CDs, with only flash drives, etc. ISOs won't help. > >And taking systems offline for a .1 > >update gets annoying fast. Dealing with all the file comparisons which are > >exactly the same except for the CVS tag takes hours for no good reason. > >Multiple many hours by hundreds of systems, and you could easily have a > >full time person just doing FreeBSD upgrades. > > Using a build server as a testbed and to generate new packages or even a > new kernel + world will reduce the amount of work required, but FreeBSD > does require some level of administration and maintenance. We already have that. But again, I'm not sure what you are trying to say here. The centralized server makes patching and port upgrades easier. It does _NOTHING_ for core OS upgrades because there is no supported mechanism for doing binary upgrades except from the ISO. Thus, we are finally back on topic. > >I don't care about ports, just the base OS. Ports we've built the > > I've got firewalls with a single-digit number of ports installed, but > anything else seems to acquire 100-200 or so. Again, I don't care about ports. The largest number of ports installed on any production system we have is 18. And having a centralized server where we can build and export the packages works just fine. The portaudit tools are very useful in this regard, when pointed at internal servers. There is no similar mechanism for OS upgrades, which is what we're talking about here. Ports is not a problem. > I'm with you on this, but suggesting solutions is more useful than just > noting the existence of problems. I have made suggestions. Everyone has made suggestions. Most of us have produced code to work around the problem, but the core OS team has always refused to support or acknowledge these efforts. For binary upgrades without booting from CD-ROM to be possible, we need versioning of some sort at the OS level. Core OS packages are the most popular suggestion, but not the only path. Every year this topic comes up and gets struck down again. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote: On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote: YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, including X11, KDE, printing, Mozilla, etc worked just fine. There are no ISO for patch releases. FreeBSD releases new .ISO images several times a year, but you've got the tools to make .ISO images of patch releases yourself, if you want to. I don't think that the FreeBSD project can shorten the release cycle below a month or so, which means that patch releases are always going to be on the (b)leading edge... And taking systems offline for a .1 update gets annoying fast. Dealing with all the file comparisons which are exactly the same except for the CVS tag takes hours for no good reason. Multiple many hours by hundreds of systems, and you could easily have a full time person just doing FreeBSD upgrades. Using a build server as a testbed and to generate new packages or even a new kernel + world will reduce the amount of work required, but FreeBSD does require some level of administration and maintenance. Upgrading the ports from there was somewhat annoying I don't care about ports, just the base OS. Ports we've built the infrastructure to handle properly, and very few ports are installed on production systems. I've got firewalls with a single-digit number of ports installed, but anything else seems to acquire 100-200 or so. Now, if you want to talk about upgrading to intermediate patch releases, you've got a valid point there. :-) That is exactly the point. Both .01 and .1 releases are annoying. I'm with you on this, but suggesting solutions is more useful than just noting the existence of problems. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> On Sat, Dec 17, 2005 at 02:00:21PM -0800 I heard the voice of > Joe Rhett, and lo! it spake thus: > > > > Increasing the number of deployed systems out of date [...] On Sat, Dec 17, 2005 at 08:37:25PM -0600, Matthew D. Fuller wrote: > This doesn't make any sense. If you install a 6.0 system, in 6 months > (assuming you installed it right when 6.0 was cut, for simplicity), it > will be 6 months out of date. It's neither more nor less out of date > if the current release is then 6.1, or 6.2, or 8.12; it's still 6 > months back. No, you're missing the point. More core OS upgrades means less incremental patches (which are easier to apply than a full update). That means that more systems will fall out of date because of the time-consuming nature of full operating system upgrades. > A case could, in fact, be made that more common releases lead to far > FEWER deployed systems out of date, since it makes it far easier for > those who already use binary upgrades instead of source to get things > faster. Huh? That's backwards. If we can't schedule the downtime for a full operating system upgrade (which takes far longer than it should) then the system won't get upgraded. Small incremental patches can be built on central systems and rsynced outwards fairly easily in comparison. > Now, this is not to say that easier incremental binary upgrades are a > bad thing, but bad analogy doesn't help anybody... Not to be rude, but I think your definition of analogy is wrong. There was no analogy in my comments - no parallelism at all. I was focused on the single topic, and not referring to anything else. Back to the point, the comments aren't "bad". Your idea that binary operating system upgrades from ISO are "easier" demonstrates that you're talking about home computers, not production servers. I'm talking about production environments, which I made very clear in my description. ...few have CDs ...many don't have local consoles, or local staff ...many don't have local disks at all (flash-based systems) "Install new OS from ISO" is completely impractical in all of these environments. "Install from source" is impossible in most. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> On Sun, Dec 18, 2005 at 09:55:33AM +, Matthew Seaman wrote: > > Doesn't creating a binary updates system that's going to be practical to use > > require implementation of that old and exceedingly bikesheddable subject: > > packaging > > up the base system? On Sun, Dec 18, 2005 at 12:13:09PM -0500, Kris Kennaway wrote: > No, after all the *existing* binary update systems don't require > packaging of the base system. None of which work properly in production environments. They work fine for home computers running GENERIC, and who can sustain some downtime for upgrade failures. And they are all completely un-auditable. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sun, Dec 18, 2005 at 09:55:33AM +, Matthew Seaman wrote: > Doesn't creating a binary updates system that's going to be practical to use > require implementation of that old and exceedingly bikesheddable subject: > packaging up the base system? EXACTLY. That's why we need core team support. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
> > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > > There will be three FreeBSD 6 releases in 2006. > On Sat, Dec 17, 2005 at 02:00:21PM -0800, Joe Rhett wrote: > > While this is nice, may I suggest that it is time to put aside/delay one > > release cycle and come up with a binary update mechanism supported well by > > the OS? Increasing the speed of releases is good. Increasing the number > > of deployed systems out of date because there are no easy binary upgrade > > mechanisms is bad. > > > > It has been bad, it's getting worse. On Sat, Dec 17, 2005 at 06:46:27PM -0500, Kris Kennaway wrote: > Suggestions are nice, but who do you think will work on solving this? I and many others have proposed binary update mechanisms, and are all willing to work on them. The core freebsd team has not shown willingness to work with such an effort. Without that, we'd be patching the update mechanism with every new release, which kind of defeats the point. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote: > YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on > an > IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, > including X11, KDE, printing, Mozilla, etc worked just fine. There are no ISO for patch releases. And taking systems offline for a .1 update gets annoying fast. Dealing with all the file comparisons which are exactly the same except for the CVS tag takes hours for no good reason. Multiple many hours by hundreds of systems, and you could easily have a full time person just doing FreeBSD upgrades. > Upgrading the ports from there was somewhat annoying I don't care about ports, just the base OS. Ports we've built the infrastructure to handle properly, and very few ports are installed on production systems. > Now, if you want to talk about upgrading to intermediate patch releases, > you've > got a valid point there. :-) That is exactly the point. Both .01 and .1 releases are annoying. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sun, Dec 18, 2005 at 12:13:09PM -0500, Kris Kennaway wrote: > > Doesn't creating a binary updates system that's going to be practical to use > > require implementation of that old and exceedingly bikesheddable subject: > > packaging > > up the base system? > > No, after all the *existing* binary update systems don't require > packaging of the base system. Except that the existing binary update system is broken in several fundamental ways. I guess the reason it gets little attention is because most developers are happy to (or even prefer to) rebuild their systems from source. Regards, Brian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sun, Dec 18, 2005 at 09:55:33AM +, Matthew Seaman wrote: > Chuck Swiger wrote: > > >Upgrading the ports from there was somewhat annoying, as this guy's > >machine had > >~400 or so, but deleting them all, and then using "pkg_add -r " works just > >fine > >if you want to grab the latest current binaries. From there you can > >portupgrade > >as usual. > > > >Now, if you want to talk about upgrading to intermediate patch releases, > >you've > >got a valid point there. :-) > > Doesn't creating a binary updates system that's going to be practical to use > require implementation of that old and exceedingly bikesheddable subject: > packaging > up the base system? No, after all the *existing* binary update systems don't require packaging of the base system. Kris pgpaf2O2IcxGV.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Chuck Swiger wrote: Upgrading the ports from there was somewhat annoying, as this guy's machine had ~400 or so, but deleting them all, and then using "pkg_add -r " works just fine if you want to grab the latest current binaries. From there you can portupgrade as usual. Now, if you want to talk about upgrading to intermediate patch releases, you've got a valid point there. :-) Doesn't creating a binary updates system that's going to be practical to use require implementation of that old and exceedingly bikesheddable subject: packaging up the base system? After all, you're going to need some mechanism for auditing servers down the line (yes, this machine has had the vital fix to the foo daemon applied), and while bumping the patch level on the release sorta works to do that, it implies a new kernel and a reboot for each patch applied if it's going to be visible. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sat, Dec 17, 2005 at 02:00:21PM -0800 I heard the voice of Joe Rhett, and lo! it spake thus: > > Increasing the number of deployed systems out of date [...] This doesn't make any sense. If you install a 6.0 system, in 6 months (assuming you installed it right when 6.0 was cut, for simplicity), it will be 6 months out of date. It's neither more nor less out of date if the current release is then 6.1, or 6.2, or 8.12; it's still 6 months back. A case could, in fact, be made that more common releases lead to far FEWER deployed systems out of date, since it makes it far easier for those who already use binary upgrades instead of source to get things faster. Now, this is not to say that easier incremental binary upgrades are a bad thing, but bad analogy doesn't help anybody... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Joe Rhett wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: >>There will be three FreeBSD 6 releases in 2006. > > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. > > It has been bad, it's getting worse. YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, including X11, KDE, printing, Mozilla, etc worked just fine. Upgrading the ports from there was somewhat annoying, as this guy's machine had ~400 or so, but deleting them all, and then using "pkg_add -r " works just fine if you want to grab the latest current binaries. From there you can portupgrade as usual. Now, if you want to talk about upgrading to intermediate patch releases, you've got a valid point there. :-) -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Sat, Dec 17, 2005 at 02:00:21PM -0800, Joe Rhett wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > There will be three FreeBSD 6 releases in 2006. > > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. > > It has been bad, it's getting worse. Suggestions are nice, but who do you think will work on solving this? Kris pgpEsGItnIQSu.pgp Description: PGP signature
Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > There will be three FreeBSD 6 releases in 2006. While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
