Re: Where is FreeBSD going?
On Thursday 08 January 2004 13:05, Munish Chopra wrote: On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. [...cvs2svn.py scheduled for 1.0...] What about arch? I have it installed, but $realjob has prevented me from looking at it. And, unless I misunderstand, Perforce is available for free for non-profits, and the client is a free download. Other than a desire to be pure and use open source exclusively, what objection is there to Perforce? (And even considering that desire, Perforce is built upon open source: RCS and BDB, if I understand correctly). Speaking as a former CVS repo-meister (for a company that evaporated out from under me), Perforce really is a better mousetrap. No more, I updated in the middle of a commit problem, because commits are transactional. No more Oh, god, this merge sucks, because Perforce keeps track of what was merged when, and where. The latest versions rather painlessly support cross-branch merges, too (i.e., pulling changes from one branch to another without having to first push up to and pull down from a common ancestor). Triggers can be written to prevent inadvertent DoSes (p4 integ -I //depot/branch1/... //depot/branch2/...) and to do submit-time checks. Risks are more easily mitigated with branches, and pulling/pushing of selected changes is MUCH easier (no more need to generate and apply patches by hand). Generating weird-elmo hybrid mappings of the tree is also a snap, and the repo itself doesn't bloat as badly because P4 uses its database to keep track of where histories go, rather than actually physically copy a file to move it in the repo. CVS: cp /CVSROOT/foo/bar /CVSROOT/foo/baz cvs delete foo/bar cvs commit (but bar,v lives forever, if you want to keep the change history and/or if you ever want to check out an old tagged revision of the tree) Perforce: p4 integ -t foo/bar foo/baz p4 delete foo/bar p4 submit (foo/baz doesn't actually physically exist. P4 keeps a DB record that foo/baz points to foo/bar, and this operation is only visible in the branch in which it was done, until that branch is pushed up to its parent) With Perforce, no repo-meister intervention is needed. Add in the ability to use local proxies to cache frequently-fetched files and revisions, and you have a winner, IMHO. I'm starting to sound like a spokesman. I'm not--just a *very* satisfied user. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] Turning coffee into software since 1990. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
: Agreed. Like I've said, the main problem I see is complexity. It : wouldn't matter as much if there were 5-10 people with deep knowledge of : SMPng, but with 1 or 2 hackers working on it, the chance that everything : will be ever fixed is quite small. : :IMO, the easiest way to start the SMP work (from a FreeBSD monolithic :approach), is to flatten as much of the VFS/VM code as possible into :a continuation scheme... That is something that I could have done 5yrs :ago in a few weeks, and then keep the networking system as it is. :There would be shims deployed that would still support the sleep/wakeup :scheme, so that the non-networking could and the new flat interface could :be debugged... (It is NOT a good idea to bug the networking guys until :the new scheme would be debugged.) : :At that point, there would be a code with explicit context carried around, :and no nesting or stack context. This would have a small benefit of avoiding :multiple deeply nested kernel stacks... : :Given the very flat scheme, each subsystem could be recoded into a :message passing or simple continuation scheme (whatever is appropriate.) :The system would be naturally able to be reworked -- without the :hidden dependencies of the stack. VFS/VM layering problems then :become resolvable. : :This is NOT a total solution, but should be the beginning of a thinking :exercise that seems to lead into the correct direction. (Don't :criticize this based upon the completeness of my prescription, but :on what can eventually be developed!!!) I have been trying to figure out how to implement asynch system calls in DFly, which is a very similar problem to the one posed by the VFS stack. I don't think we can use a pure continuation scheme, but I do think the required context can be minimized enough to fit in a structure. In DFly, the natural structure to hold the contextual information is the message structure that was used to initiate the operation in the first place. So, in regards to async system calls, the message structure contains an additional union that lays out contextual storage requirements for each system call. For example, the contextual information required to support nanosleep() would primarily be a timeout structure. (This is in fact the only system call that can be run asynch in DFly at the moment... I am using it as an experimental base to try to refine the code requirements to reduce complexity). The blocking points for both system calls and VFS calls (which are the real problem being solved here) tend to be related to blocking on I/O events, locks, and mutexes. In DFly I primarily have to worry about I/O events and locks and not so much about mutexes. Also, in DFly, We are serializing many major subsystems and segregating high performance structures, such as PCB's, by associating them with a single thread. This fits very well with the continuation scheme idea because we would prefer to have only a few threads which handle multiple data structures (to make best use of available cpus), and this means that we cannot simply 'block' in such threads whenever we feel like it without screwing up parallelism. -Matt Matthew Dillon [EMAIL PROTECTED] :Oh well -- I cannot think too much about this stuff, or I'll actually :get emotionally involved again. I need to get a 'normal' job, not :working at home and need to interact with people instead of CRTs. :-). :(I give a sh*t about FreeBSD, and hope that WHATEVER problems that :truly exist are fully resolved.) There is alot of blood sweat and :tears in that codebase, and being involved in the project should be :done with great respect. : :John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Mon, 12 Jan 2004, Matthew Dillon wrote: : Agreed. Like I've said, the main problem I see is complexity. It : wouldn't matter as much if there were 5-10 people with deep knowledge of : SMPng, but with 1 or 2 hackers working on it, the chance that everything : will be ever fixed is quite small. : :IMO, the easiest way to start the SMP work (from a FreeBSD monolithic :approach), is to flatten as much of the VFS/VM code as possible into :a continuation scheme... That is something that I could have done 5yrs :ago in a few weeks, and then keep the networking system as it is. :There would be shims deployed that would still support the sleep/wakeup :scheme, so that the non-networking could and the new flat interface could :be debugged... (It is NOT a good idea to bug the networking guys until :the new scheme would be debugged.) : :At that point, there would be a code with explicit context carried around, :and no nesting or stack context. This would have a small benefit of avoiding :multiple deeply nested kernel stacks... : :Given the very flat scheme, each subsystem could be recoded into a :message passing or simple continuation scheme (whatever is appropriate.) :The system would be naturally able to be reworked -- without the :hidden dependencies of the stack. VFS/VM layering problems then :become resolvable. : :This is NOT a total solution, but should be the beginning of a thinking :exercise that seems to lead into the correct direction. (Don't :criticize this based upon the completeness of my prescription, but :on what can eventually be developed!!!) I have been trying to figure out how to implement asynch system calls in DFly, which is a very similar problem to the one posed by the VFS stack. I know that Matt knows all this but.. The thing about async syscalls is that by definition, the context needs to be split.. Something goes back to the caller and something stays behind to compete the operation. The 2nd something can be a saved message, or a full saved context. Dfly would use the first methond and FreeBSD uses the 2nd method. (KSE threads are based upon asyncronous system calls). In case 2 you need a way for the program to cope with the fact that syscalls return without having done what they were asked to do.. this is what the kse threading library and API do. I don't think we can use a pure continuation scheme, but I do think the required context can be minimized enough to fit in a structure. In DFly, the natural structure to hold the contextual information is the message structure that was used to initiate the operation in the first place. In order to make the state minimal, you need to know what state is important to keep in every situation. In FreeBSD there is not enough knowledge about this so we keep the entire thread state. If the requests were encapsulated in messages then that would help, but you still need to keep other state available.. for example, if you sleep while doing the 3rd part (out of 4) of a large read (that the kernel has broken up due to allocation discontinuities on the disk for example) then you still need to keep track of that and the original message probabyl doesn't have the storeage context for that. So, in regards to async system calls, the message structure contains an additional union that lays out contextual storage requirements for each system call. yes but you have to design your system for that from scratch.. (Dfly is doing it with a retroactive scratch :-) For example, the contextual information required to support nanosleep() would primarily be a timeout structure. (This is in fact the only system call that can be run asynch in DFly at the moment... I am using it as an experimental base to try to refine the code requirements to reduce complexity). The blocking points for both system calls and VFS calls (which are the real problem being solved here) tend to be related to blocking on I/O events, locks, and mutexes. In DFly I primarily have to worry about I/O events and locks and not so much about mutexes. Also, in DFly, We are serializing many major subsystems and segregating high performance structures, such as PCB's, by associating them with a single thread. This fits very well with the continuation scheme idea because we would prefer to have only a few threads which handle multiple data structures (to make best use of available cpus), and this means that we cannot simply 'block' in such threads whenever we feel like it without screwing up parallelism. right.. It depends if yuo thin that doing all that work is worth it.. If you are happy to save the running context and return another that doesn't hold any locks etc. then you can make the existing code work. But it has costs of course. -Matt
RE: Where is FreeBSD going?
Well, I know that it's legal to omit one's own copyright claim, but for some organization to lay claim to copyrights owned by you or me seems very wrong. It's a violation of BSD-type licenses and a violation of the concept of attribution that is behind the licenses. A legal entity has made the false claim of copyright ownership, whether that's an informal organization or the person who wrote the claim with a pseudonym. I'm not sure how you or I have been damaged, but I supose that a lawyer could find a way. Anyone who can legally created derived or aggregated works from a work to which you hold copyright may place their own copyright on those derived or aggregated works. This in no way affects your original copyright. DS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD would be preferable but GPL is probably acceptable (given two potential SCMs with similar features, the BSD licensed one would be selected in preference to the GPL one). Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
--- Garance A Drosihn [EMAIL PROTECTED] wrote: At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) (I am very interested in subversion, but it is still something I need to learn more about...) I think we must wait until a 1.0 version is available. SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, so moving it to svn is probably not a step forward IMHO ;-). cheers, Pedro. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 10:00 AM + 1/11/04, Doug Rabson wrote: On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD preferable ... Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Jan 11, 2004, at 5:19 PM, Garance A Drosihn wrote: At 10:00 AM + 1/11/04, Doug Rabson wrote: On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD preferable ... Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) Subversion servers require Berkeley DB and potentially Apache if you want to use mod_dav_svn as your server. If you don't want to use mod_dav_svn you can avoid the dependency on Apache. Subversion clients require APR (the Apache Portable Runtime) and potentially Neon (a webdav client library) if you want to use mod_dav_svn as your server. In any event, I'm not convinced that importing Subversion into the tree is necessary even if you do want to use it. There's no real reason it can't just live in the ports tree as it does now. -garrett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sat, Jan 10, 2004 at 09:05:50AM -0800, Pedro F. Giffuni wrote: I think we must wait until a 1.0 version is available. SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, so moving it to svn is probably not a step forward IMHO ;-). No, the projects/ repository is in CVS. There's also a perforce repository that people use for development work, but it's not what Garance was talking about. Kris pgp0.pgp Description: PGP signature
Re: SCM options (was Re: Where is FreeBSD going?)
At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) (I am very interested in subversion, but it is still something I need to learn more about...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
Garance A Drosihn wrote: At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) (I am very interested in subversion, but it is still something I need to learn more about...) I haven't been following this too closely, so forgive me if this has been mentioned. Does Subversion support any type of transaction based committing? One of the frequent problems with CVS is when someone grabs source while someone is in the middle of a large or multi-part commit. -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
I haven't been following this too closely, so forgive me if this has been mentioned. Does Subversion support any type of transaction based committing? Yes. Commits are atomic. Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 9:05 AM -0800 1/10/04, Pedro F. Giffuni wrote: --- Garance A Drosihn [EMAIL PROTECTED] wrote: That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, ... Ah. I did not realize it was already using Perforce. Yeah, I would not suggest making that change. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD would be preferable but GPL is probably acceptable (given two potential SCMs with similar features, the BSD licensed one would be selected in preference to the GPL one). The decision on how to manage the SCM is totally independent of the choice of SCM - it relates to the ease of maintenance of the SCM. There's no reason why an in principle decision couldn't be made now. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
Peter Jeremy wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD would be preferable but GPL is probably acceptable (given two potential SCMs with similar features, the BSD licensed one would be selected in preference to the GPL one). Indeed - I was just adding to the comments about subversion by pointing out that its BSDness is a point in its favour. The decision on how to manage the SCM is totally independent of the choice of SCM - it relates to the ease of maintenance of the SCM. There's no reason why an in principle decision couldn't be made now. Except that the decision of whether our SCM was imported into src/contrib or not might be effected by its license. I mean I know there's plenty of GPLed code in there already, but adding to it might not be such a popular move. Anywho - the topic of SCM is something that rears it's head once in a while (I've really enjoyed how one post from our troll has led to conversations about just about everything :D ). I think we need to wait for subversion to hit 1.0 and then evaluate it carefully. I can't really think of a change to FreeBSD more wide-ranging than changing our SCM, and it would need buy-in from your common-or-garden CVSup user, through commiters and the core team. That's not to say that we can't change. The benefits of doing so are obvious. But we certainly don't want any nasty surprises on the way. Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-08 16:36:30 -0800: On Thu, Jan 08, 2004 at 06:36:42PM +0100, Roman Neuhauser wrote: That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Repo-copies are not allowed during the freeze, but are any other time. ok, so someone (at least two people) out there is confused about this, and this only further proves my statement about the uncertainty. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? No, please raise this on the ports list. ok, cc'd to ports, Mail-Followup-To set. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004.01.08 21:39:07 -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : and the Copyright page has that plus a similar claim for : FreeBSD, Inc. (For 2004, even.) That should be changed. To? I have noticed FreeBSD, Inc on the copyright page a few times, but I never really knew what to replace it with. -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thu, 08 Jan 2004 17:29:34 + Doug Rabson [EMAIL PROTECTED] wrote: The three main showstoppers for moving FreeBSD to subversion would be: [...] 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. subversion properties (svn propset) would allow you to do this in a satisfactory manner. -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | |---| | B3A7 F5BE B2AE 67B1 AC4B | | 0983 956D 1F4A AA54 47CB | |---| | http://www.kerneled.com | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: Ryan Sommers [EMAIL PROTECTED] writes: : Something like this might also jeopardize the : project's not for profit status. The project is not a legally incorporated entity at this time, and never has been in the past. And yet the Legal page carries a claim of copyright for The FreeBSD Project and the Copyright page has that plus a similar claim for FreeBSD, Inc. (For 2004, even.) I've not seen a US statute about false copyright claims, but I think it would be less risky to say all intellectual property is owned by its owners, in the manner of some trademark statements. The Legal page could tell about using CVS to determine who owns what so they can be tracked down and asked if the copyright page is correct about what license they've got it under. :) Whether the project is for profit depends upon the definition, if the project is claiming copyright ownership, because gains of intellectual property is considered (by US copyright law, at least) to be a financial gain. But lots of organizations, formal and informal, have financial gains without problems with being considered for profit, so if someone sees for profit problems, they should be specific about what the problems might be. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : And yet the Legal page carries a claim of copyright for The FreeBSD : Project It is a psudonymous work by The FreeBSD Project. Are you saying that The FreeBSD Project is a pseudonym for many of individuals, or what? And why does it matter with respect to whether an extra-legal entity may claim copyright ownership? : I've not seen a US statute about : false copyright claims, but I think it would be less risky to say all : intellectual property is owned by its owners, in the manner of some : trademark statements. No, the above is perfectly legal under US and International Copyright law. Well, I know that it's legal to omit one's own copyright claim, but for some organization to lay claim to copyrights owned by you or me seems very wrong. It's a violation of BSD-type licenses and a violation of the concept of attribution that is behind the licenses. A legal entity has made the false claim of copyright ownership, whether that's an informal organization or the person who wrote the claim with a pseudonym. I'm not sure how you or I have been damaged, but I supose that a lawyer could find a way. What is your theory of why it's legal? I'm really interested. Are you saying it's just another way of saying copyrights are owned by individual members of the informal FreeBSD project? That seems legal enough, I guess, but it's a quite different statement, IMO. And as it doesn't follow the form giving by US copyright law I wonder if it is sufficent legal notice in the USA, if you plan to sue infringers for the most money possible. For profit or not is irrelvant, given that there's no legally incorporated entity for the project. I'm fairly sure that members of informal organizations can be held liable for the acts of other members in the USA. For example, under the Racketeer Influenced and Corrupt Organizations (RICO) Act. And even if all members could not be held liable, persons directly responsible for the wrongdoing could be. Example wrongdoings are not paying taxes on the profit or not reporting the profit. But I admit that this issue seems unlikely to cause problems as long as someone pays taxes on any obvious profits other than copyright licenses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-09 15:32:53 +0300: On Thu, 08 Jan 2004 17:29:34 + Doug Rabson [EMAIL PROTECTED] wrote: The three main showstoppers for moving FreeBSD to subversion would be: [...] 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. subversion properties (svn propset) would allow you to do this in a satisfactory manner. Please explain how props can be used to embed custom keywords in bodies of the files in a satisfactory manner, e. g. on svn export. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : : : And yet the Legal page carries a claim of copyright for The FreeBSD : : Project : : It is a psudonymous work by The FreeBSD Project. : : Are you saying that The FreeBSD Project is a pseudonym for many of : individuals, or what? And why does it matter with respect to whether : an extra-legal entity may claim copyright ownership? Yes. It is a collection of individuals. It is explicitly allowed for in copyright law. : : I've not seen a US statute about : : false copyright claims, but I think it would be less risky to say all : : intellectual property is owned by its owners, in the manner of some : : trademark statements. : : No, the above is perfectly legal under US and International Copyright : law. : : Well, I know that it's legal to omit one's own copyright claim, but : for some organization to lay claim to copyrights owned by you or me : seems very wrong. Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] Simon L. Nielsen [EMAIL PROTECTED] writes: : On 2004.01.08 21:39:07 -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : : and the Copyright page has that plus a similar claim for : : FreeBSD, Inc. (For 2004, even.) : : That should be changed. : : To? I have noticed FreeBSD, Inc on the copyright page a few times, but : I never really knew what to replace it with. The FreeBSD Project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 8 Jan 2004, Doug Rabson wrote: I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. I admit to having not tried it, but I wonder how well OpenCM (http://www.opencm.org/) would compare. I think it would have a smaller footprint than Subversion. Sean --- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Fri, 9 Jan 2004, Gary W. Swearingen wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. You obviously don't want to discuss this, and it's easy to guess the real reasons. Your main problem here, and apparently that of your lawyers, is that you don't understand what the issues are to which copyright law is to be applied. The legality of collective copyrights was not my issue. Your other problem is putting words in people's mouth; I would never admit to know not knowing US copyright law because I know it quite well enough to argue FreeBSD's IP issues with anybody. If I don't write with the same seeming authority as you, that's more your problem than mine. I expected my comments to be ignored or brushed off, but I didn't expect to be brushed off in your rude and insulting manner. Maybe when I've recovered, and if I haven't made my move to NetBSD yet, I'll write up a more complete explanation of FreeBSD's IP problems instead of trying to deal with the likes of you in a conversation. Please do. But could you also include reasoning for use of US specific view (if thats what you are going to use) as there is essentially no reason why US copyright regulations and practices should preferentialy apply to it. Especially as the licence has no such stipulations about applicable law in it. We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going? the never-ending thread
Narvi wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. So there are cases of code by authors being committed into the codebase without their knowledge/consent? This would be a problem. If code is being committed against license, I definitely see an issue here. However, If you /GIVE/ your IP to the FreeBSD community, it's no longer yours. Either way, apparently you'll never make everyone happy, even as hundreds (or thousands) of people give away their time to produce something at no cost to you, there's still always going to be someone complaining. (We refer to this as a sense of entitlement - Many people have this, and it's an unfortunate growing fad all over.) If you don't want your code in FreeBSD, don't submit it. Anyone going to pursue some indictments against Coyote Point Systems? Since their load-balancing hardware runs FreeBSD, and I don't believe (I'm unsure, but from the info I've gotten, it doesn't sound like it.) that they give you any of the source with your purchase of their hardware, Hmm -mpf + - - | Resistance is futile, assimilation into the FreeBSD community is inevitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going? the never-ending thread
On Fri, 9 Jan 2004, Matt Freitag wrote: Narvi wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. So there are cases of code by authors being committed into the codebase without their knowledge/consent? This would be a problem. If code is being committed against license, I definitely see an issue here. Consider code merges from Net/OpenBSD. There is no explicit permission involved nor needed. However, If you /GIVE/ your IP to the FreeBSD community, it's no longer yours. Either way, apparently you'll never make everyone happy, even as Well... See, this is the place where people go wrong. Nobody is *GIVING* their IP or code to anybody (and this includes the original sources from Berkeley), they are simply licencing it. And unsuprisingly enough, there is a difference - a big one - between two two. Whetever one needs to be concerned about that is yet againan altogether different matter. The same would by the way apply even if all of FreeBSD was GPL licenced. hundreds (or thousands) of people give away their time to produce something at no cost to you, there's still always going to be someone complaining. (We refer to this as a sense of entitlement - Many people have this, and it's an unfortunate growing fad all over.) If you don't want your code in FreeBSD, don't submit it. Anyone going to pursue some indictments against Coyote Point Systems? Since their load-balancing hardware runs FreeBSD, and I don't believe (I'm unsure, but from the info I've gotten, it doesn't sound like it.) that they give you any of the source with your purchase of their hardware, Hmm There is no scenario at all under which they would have to give you their code. None at all. -mpf + - - | Resistance is futile, assimilation into the FreeBSD community is inevitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going
Sorry to jump in the conversation so late, and without reading the entire thread to date, but has anyone considered tla as an scm, it handles merging and branching much more sanely than cvs or svn, not to mention the benefits of distributed development and the dumb server model. and there are tools available (cscvs for one) that will convert cvs to tla archives with full history. Just a thought. And as for the memory issues in conversion, cscvs uses SQLite as a storage medium during conversion to alleviate the need for mass amounts of memory during the conversion process, with quite a nice performance boost. Mike Partin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. You obviously don't want to discuss this, and it's easy to guess the real reasons. Your main problem here, and apparently that of your lawyers, is that you don't understand what the issues are to which copyright law is to be applied. The legality of collective copyrights was not my issue. Your other problem is putting words in people's mouth; I would never admit to know not knowing US copyright law because I know it quite well enough to argue FreeBSD's IP issues with anybody. If I don't write with the same seeming authority as you, that's more your problem than mine. I expected my comments to be ignored or brushed off, but I didn't expect to be brushed off in your rude and insulting manner. Maybe when I've recovered, and if I haven't made my move to NetBSD yet, I'll write up a more complete explanation of FreeBSD's IP problems instead of trying to deal with the likes of you in a conversation. We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Quoting Miguel Mendez [EMAIL PROTECTED]: Matthew Dillon wrote: interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. My thoughts exactly. Every time I have this kind of argument, be it on irc or in a mailing list, I get told that Sun needed X years to do the fine grained locks in Solaris and other similar crap. Solaris was possible because Sun could throw more engineers at the problem if needed. FreeBSD is not in such situation. How many people have intimate knowledge of the VM subsystem? How many people besides John Baldwin have ever touched the SMPng code? I don't think anybody has doubts about your programming-fu, btw :) One comment: I doubt that I could do the things that I used to be able on FreeBSD. However, it has been my position (for years), that the many-mutex ad-hoc approach would require brilliant people to implement, and incredibly brilliant people to maintain. (I have lost alot of context -- due to persistent burnout, but still remember alot of the problems.) serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, Agreed. Like I've said, the main problem I see is complexity. It wouldn't matter as much if there were 5-10 people with deep knowledge of SMPng, but with 1 or 2 hackers working on it, the chance that everything will be ever fixed is quite small. IMO, the easiest way to start the SMP work (from a FreeBSD monolithic approach), is to flatten as much of the VFS/VM code as possible into a continuation scheme... That is something that I could have done 5yrs ago in a few weeks, and then keep the networking system as it is. There would be shims deployed that would still support the sleep/wakeup scheme, so that the non-networking could and the new flat interface could be debugged... (It is NOT a good idea to bug the networking guys until the new scheme would be debugged.) At that point, there would be a code with explicit context carried around, and no nesting or stack context. This would have a small benefit of avoiding multiple deeply nested kernel stacks... Given the very flat scheme, each subsystem could be recoded into a message passing or simple continuation scheme (whatever is appropriate.) The system would be naturally able to be reworked -- without the hidden dependencies of the stack. VFS/VM layering problems then become resolvable. This is NOT a total solution, but should be the beginning of a thinking exercise that seems to lead into the correct direction. (Don't criticize this based upon the completeness of my prescription, but on what can eventually be developed!!!) IMHO ULE is making progress quite fast. I wouldn't rely on it for production, but so far is looks very good. The need for a new scheduler (or extreme rework on BSD) whenever you see the threads bouncing around from CPU to CPU. My temporary hack solutions couldn't work right, and it is good that the issue is being researched. non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). Yes, that's the main problem I see, not much on the scheduler side, but on the 6-trillion-mutexes side. The IQ of the maintainers would probably have to be 6-trillion, which would definitely allow the very few elegible developers to maintain their high priest status forever :-). See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. Makes me wonder if some of the solutions proposed by DragonFly could be ported to FreeBSD, but I doubt it will be done, since it's more or less admitting that the current solution is wrong. Sometimes, I think that people have their egos directed wrongly... The egos should be fed by the excellent behavior/performance/reliability of the FreeBSD OS. Being embarassed about appropriately borrowing code or ideas from other sources (WITH APPROPRIATE ATTRIBUTION) is counter productive. A developer should be able to say I was wrong, or my code/design needs rework, without any problems. No-one produces the golden perfect code for the first iteration!!! Oh well -- I cannot think too much about this stuff, or I'll actually get emotionally involved again. I need to get a 'normal' job, not working at home and need to interact with people instead of CRTs. :-). (I give a sh*t about FreeBSD, and hope that WHATEVER problems that truly exist are fully resolved.) There is alot of
Re: Where is FreeBSD going?
On Thu, 8 Jan 2004, Doug Rabson wrote: DR I've been re-evaluating the current subversion over the last couple of DR weeks and its holding up pretty well so far. It still misses the DR repeated merge thing that p4 does so well but in practice, merging does DR seem to be a lot easier than with CVS due to the repository-wide DR revision numbering system - that makes it easy to remember when your DR last merge happened so that you don't merge a change twice. DR DR The three main showstoppers for moving FreeBSD to subversion would be: DR DR 1. A replacement for cvsup. Probably quite doable using svnadmin DRdump and load. DR 2. Support for $FreeBSD$ - user-specified keywords are not supported DRand won't be until after svn-1.0 by the looks of things. DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. For the third point, take a look at http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.71.763.tar.g The author uses FreeBSD repository as main test field ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004-01-09 11:38 -0600, Sean Farley [EMAIL PROTECTED] wrote: I admit to having not tried it, but I wonder how well OpenCM (http://www.opencm.org/) would compare. I think it would have a smaller footprint than Subversion. I have prepared a port of OpenCM, but didn't have time to test it, yet. For that reason, I have not yet imported it into the ports repository. Just in case somebody wants to test OpenCM (or my port ;-) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SCM options (was Re: Where is FreeBSD going?)
Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. cheers, Pedro. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Matthew Dillon wrote: interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. My thoughts exactly. Every time I have this kind of argument, be it on irc or in a mailing list, I get told that Sun needed X years to do the fine grained locks in Solaris and other similar crap. Solaris was possible because Sun could throw more engineers at the problem if needed. FreeBSD is not in such situation. How many people have intimate knowledge of the VM subsystem? How many people besides John Baldwin have ever touched the SMPng code? I don't think anybody has doubts about your programming-fu, btw :) serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, Agreed. Like I've said, the main problem I see is complexity. It wouldn't matter as much if there were 5-10 people with deep knowledge of SMPng, but with 1 or 2 hackers working on it, the chance that everything will be ever fixed is quite small. but there are a lot of things in there that people are going to want to rewrite in coming years, and rewriting by people other then the original authors is one of the reasons why we had so much trouble in the 2.x and 3.x days. Look at how little VFS has been touched in the It depends whether we're talking about evolutionary changes or revolutionary changes. Are you talking about radical changes like e.g. moving from the BSD scheduler to ULE or more like interface and code refactorization? In the former, yes, new bugs will be introduced, which leads again to the problem of too complex code managed by too few people. I mean, I don't think anyone can honestly say that the scheduler is 'done', or even close to done. Look at how long the original 42 scheduler IMHO ULE is making progress quite fast. I wouldn't rely on it for production, but so far is looks very good. non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). Yes, that's the main problem I see, not much on the scheduler side, but on the 6-trillion-mutexes side. See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. Makes me wonder if some of the solutions proposed by DragonFly could be ported to FreeBSD, but I doubt it will be done, since it's more or less admitting that the current solution is wrong. Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've become extremely efficient at adding people to /etc/postfix/access :-P Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I agree the ports tree has not been completely open for as long as it should be recently. This is due to unforeseen problems that resulted in significant delays for both 4.9-RELEASE and 5.2-RELEASE. It's difficult to see how this could have been handled any better. Hopefully there will be fewer problems with future releases. Non-committers can help here by testing -STABLE and -BETA snapshots more extensively so that more problems are ironed out before the ports tags are laid down. (An alternative might be to delay the ports tagging until later in the release cycle, but I suspect that is just as likely to cause problems by having last minute ports breakages cause delays). Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. I'm not sure what is meant by this paragraph. CVS doesn't support renaming files or directories - which can be a nuisance. As used within the Project, repocopy means manually copying parts of the repository to simulate file/directory duplication or renaming. This ability is restricted to a very small subset of committers - normal committers have to request repocopies as do non-committers. OTOH, replicating the complete FreeBSD CVS repository is trivial via either CVSup or CTM and both procedures are documented in the handbook. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
: See? I didn't mention DragonFly even once! Ooops, I didn't mention : DFly twice. oops! Well, I didn't mention it more then twice anyway. : :Makes me wonder if some of the solutions proposed by DragonFly could be :ported to FreeBSD, but I doubt it will be done, since it's more or less :admitting that the current solution is wrong. : :Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've :become extremely efficient at adding people to /etc/postfix/access :-P : :Cheers, :-- : Miguel Mendez [EMAIL PROTECTED] I think the correct approach to thinking about these abstractions would be to look at the code design implifications rather then just looking at performance, and then decide whether FreeBSD would benefit from the type of API simplification that these algorithms make possible. The best example of this that I have, and probably the *easiest* subsystem to port to FreeBSD (John could probably do it in a day), which I think would even wind up being exremely useful in a number of existing subsystems in FreeBSD (such as the slab allocator), would be DFly's IPI messaging code. I use the IPI messaging abstraction sort of like a 'remote procedure call' interface... a way to execute a procedure on some other cpu rather then the current cpu. This abstraction allows me to execute operations on data structures which are 'owned' by another cpu on the target cpu itself, which means that instead of getting a mutex, operating on the data structure, and releasing the mutex, I simply send an asynch (don't wait for it to complete on the source cpu) IPI message to the target cpu. By running the particular function, such as a scheduling request, in the target cpu's context, you suddenly find yourself in a situation where *NONE* of the related scheduler functions, and there are over a dozen of them, need to mess with mutexes. Not one. All they need to do to protect their turf is enter a critical section for a short period of time. The algorithm simplification is significant... you don't have to worry about crossing a thread boundary, you can remain in the critical section through the actual switch code which removes a huge number of special cases from the switch code. You don't have to worry about mutexes blocking, you don't have to worry about futzing the owner of any mutexes, you don't have to worry about the BGL, you don't have to worry about stale caches between cpus, the code works equally well in a UP environment as it does in an SMP environment... cache pollution is minimized... the list goes on an on. So looking at these abstractions just from a performance standpoint misses some of the biggest reasons for why you might want to use them. Algorithmic simplification and maintainability are very important. Performance is important but not relevant if the resulting optimization cannot be maintained. In anycase, I use IPIs to do all sorts of things. Not all have worked out... my token passing code, which I tried to use as a replacement for lockmgr interlocks, is pretty aweful and I consider it a conceptual failure. But our scheduler, slab allocator, and messaging code, and a number of other mechanisms, benefit from huge simplifications through their use of IPI messaging. Imagine... the messaging code is able to implement its entire API, including queueing and dequeueing messages on ports, without using a single mutex and (for all intents and purposes) without lock-related blocking. The code is utterly simple yet works between cpus, between mainline code and interrupts with preemption capabilities, and vise-versa. There are virtually no special cases. Same with the slab code, except when it needs to allocate a new zone from kernel_map, and same with the scheduler. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 05:23:30PM -0500, Garance A Drosihn wrote: I would add that I've been running almost exclusively on 5.x for over a year now (except for one machine which I have not rebooted in over a year...). There have been some *very* painful transitions at various times, but once I get past the transitions the system has been quite stable. (fwiw, in my case, I am only running on desktop systems). Well, what you've told me there is: - 5.x is a pain in the arse to make the transition to - You're not running FBSD in the same environment I am - But for you that's all OK, and I should agree :-) Which doesn't get us much further down the road, but thanks for the input. I have two boxes here that need to go into a co-lo tomorrow, and therefore need to be installed today. 5.2-RC2 does seem to be holding out better than expected now I've had it up for a week or so on a dev machine. I'm tempted to whirl it out on these boxes, but if they die I'm screwed. Dunno. I'm not sure if I can trust you, Des, and others when it's my cahunas on the line. So, once we stop making major API/ABI changes and the branch is truly stable (with a 6.x branch for new cutting-edge developments), I personally am quite confident that 5.x will be a stable, production-quality system. And there are a number of features in 5.x that I think are tremendous advantages -- especially for boxes in a production setting. It might be worth somebody getting those written up and sent out to -advocacy to start the ball rolling, as per another mail somewhere in this monstrous thread. My guess is you're going to have a large bar tab at the next BSDcon... Certainly I hope so! I've run tabs at the bar at conferences before, and I'm sure I'll do it again... -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Roman Neuhauser [EMAIL PROTECTED] writes: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I strongly suspect that this could be at least partially alleviated by giving portmgr more package-building hardware to play with. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:45:25PM -0600, Ryan Sommers wrote: On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. Absolutely. At least in Britain, the Project could then be seen as working as an agent which has the potential to cause problems that we don't need and probably would find very hard to deal with. Ceri -- pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-08 18:33:40 +1100: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. I'm not sure what is meant by this paragraph. CVS doesn't support renaming files or directories - which can be a nuisance. As used within the Project, repocopy means manually copying parts of the repository to simulate file/directory duplication or renaming. This ability is restricted to a very small subset of committers - normal committers have to request repocopies as do non-committers. I somewhat lumped two things together there: * general port updates from lot of people going through a handful of committers, which on one hand helps QA by adding eye balls, but OTOH slows the process down. * repocopies go through a fraction of the abovementioned handful Now, I'm by no means advocating everybody should get ssh login on [dnp]cvs.freebsd.org; I just can't wait for the day when FreeBSD uses a SCM that handles tags and branches efficiently (so that people can freely create branches of areas they hack), that has permissions model with file- or directory-level granularity (so that people can be granted commit e. g. in /ports/x11-wm/openbox and nowhere else), etc. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 07:47 PM 1/6/2004, Avleen Vig wrote: Advocacy is NOT a race Yes, it is. Linux is where it is today because it grabbed more buzz, sooner, than BSD. --Brett Glass ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: if you find that something is inadequately documented, or unclearly documented, then you need to make specific suggestions on what should be done to improve the documentation. We *need* this kind of feedback to figure out how to make the docs better from the point of view of the target audience. Kris pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thu, Jan 08, 2004 at 11:09:49AM +0100, Dag-Erling Sm?rgrav wrote: Roman Neuhauser [EMAIL PROTECTED] writes: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. I strongly suspect that this could be at least partially alleviated by giving portmgr more package-building hardware to play with. It's certainly true that we're lacking in build hardware for some non-i386 platforms (particularly sparc64), and this made it pretty tricky to build packages for 5.2 on those architectures (a full sparc64 build takes at least a month). I've heard some rumours of donated equipment waiting to be installed, but I don't know what the status of that is. Likewise, a 5.2 i386 build takes about a week, which means that the freeze *cannot* be shorter than this, even if everything goes perfectly (which, in practise, never happens). This time around, the freeze started on 23 Nov and was lifted on 3 Dec. That's 10 days, which is about as good as you could hope for. If we could build packages in - say - a day, we'd be able to cut the freeze time down further, although I expect the duration would become limited by the speed at which problems can be corrected. Every now and then we get offers of access to a machine here or a machine there to help with building packages. The main problem with donating machine resources is that there's limited space in the freebsd.org equipment racks, and the package build system currently needs LAN-equivalent connectivity between the machines. To be useful we'd either need a full cluster of faster machines located somewhere, or to find time to rewrite the build scripts to work efficiently with remote build resources. Kris pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thursday 08 January 2004 07:57 am, Roman Neuhauser wrote: Now, I'm by no means advocating everybody should get ssh login on [dnp]cvs.freebsd.org; I just can't wait for the day when FreeBSD uses a SCM that handles tags and branches efficiently (so that people can freely create branches of areas they hack), that has permissions model with file- or directory-level granularity (so that people can be granted commit e. g. in /ports/x11-wm/openbox and nowhere else), etc. Note that cvs_acls.pl and the avail files already allow directory-level (and possibly file-level) ACLs. They aren't very widely used at the moment, however. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:19, Robert Watson wrote: On Wed, 7 Jan 2004, Roman Neuhauser wrote: [1] has core@ considered subversion (devel/subversion)? Everyone has their eyes wide open looking for a revision control alternative, but last time it was discussed in detail (a few months ago?) it seemed there still wasn't a viable alternative. On the src tree side, FreeBSD committers are making extensive use of a Perforce repository (which supports lightweight branching, etc, etc), but there's a strong desire to maintain the base system on a purely open source revision control system, and migrating your data is no lightweight proposition. Likewise, you really want to trust your data only to tried and true solutions, I think -- we want to build an OS, not a version control system, if at all possible :-). Subversion seems to be the current favorite to keep an eye on, but the public release seemed not to have realized the promise of the design (i.e., no three-way merges, etc). You can peruse the FreeBSD Perforce repository via the web using http://perforce.FreeBSD.org/ -- it contains a lot of personal and small project sandboxes that might be of interest. For example, we do all the primary TrustedBSD development in Perforce before merging it to the main CVS repository. I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Ryan Sommers wrote: On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. The point was not to take away from contributing developers only to pay someone who is familiar with the problem. I don't want to have to hire someone that doesn't have a clue on the problem and takes 6 months to even become familiar with a specific PR. I don't see anything wrong with paying someone who is working on my PR. Even it is a small amount. I'm not a company and can't afford to hire a programmer to develop a driver for me personally. However, if someone is working on a driver already and is time contstrained, I would pay some money to help relieve some of the time stress involved. I gave suggestions for keeping developers happy and efficient. Money is the only REAL answer. Perhaps this could be done through a company that contracts just FreeBSD developers. I know of no such company. I guess I will have to be satisfied with -jobs for now. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. (I'm going to be looking for a full time job in about 11 months and if I got one where I got to code/administer BSD I'd feel I was in Heaven.) :-) Agreed. -- Nick Rogness [EMAIL PROTECTED] - How many people here have telekenetic powers? Raise my hand. -Emo Philips ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-07 23:17:31 -0800: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In a message written on Thu, Jan 08, 2004 at 10:35:47AM -0700, Nick Rogness wrote: Perhaps this could be done through a company that contracts just FreeBSD developers. I know of no such company. I guess I will have to be satisfied with -jobs for now. https://www.rentacoder.com/ Maybe someone could get them to make a FreeBSD section, where only people with commit bits can apply for jobs or something -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] Ryan Sommers [EMAIL PROTECTED] writes: : I really don't like the idea of making this a policy, or even some : official part of the project. It has been going on for years. I've been paid to fix FreeBSD bugs by my employer and as an independent contractor for years now. These fixes get into the FreeBSD system on their merrits, but likely wouldn't have happened if someone wasn't willing to foot the bill. : Something like this might also jeopardize the : project's not for profit status. The project is not a legally incorporated entity at this time, and never has been in the past. There is a FreeBSD Foundation, but that's a completely independent organization. Prior to that there was FreeBSD, Inc, which Joran ran as a clearing house for help to those working on the project, but FreeBSD, Inc never was the project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. Perfection (or as close as possible) of cvs2svn.py is scheduled for 1.0. They've entered beta now, but without scanning the lists I suppose that's sometime 2004. I've noticed some other projects having problems with repository conversion, but at least things seem to be getting better. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 2004-01-08 at 18:05, Munish Chopra wrote: On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. Perfection (or as close as possible) of cvs2svn.py is scheduled for 1.0. They've entered beta now, but without scanning the lists I suppose that's sometime 2004. I've noticed some other projects having problems with repository conversion, but at least things seem to be getting better. There seems to be a reasonably common problem where a single branch point ends up with more than one branch name. This certainly happens in the FreeBSD cvs. If you ignore that error, it gets about 1000 commits into the conversion but then dies with an error in the branch handling code (probably caused by the first problem). There are outstanding problems with vendor branches which it looks like they will fix before 1.0. I've been using the scripts to convert another large repository and they are not quick - my current test has been going for 2.5 days now and it still has about six months worth of repository to convert (the cvs history goes back about seven years in total). I estimate that the complete conversion will take about 3 days and will contain about 15000 commits... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 2:27 AM -0800 2004/01/08, Kris Kennaway wrote: It's certainly true that we're lacking in build hardware for some non-i386 platforms (particularly sparc64), and this made it pretty tricky to build packages for 5.2 on those architectures (a full sparc64 build takes at least a month). I've heard some rumours of donated equipment waiting to be installed, but I don't know what the status of that is. I've got a SPARC64 box sitting downstairs, waiting for me to install it. Actually, I've got four of them. I was planning on using one for FreeBSD support, one for NetBSD, one for OpenBSD, and one for Solaris. I was also thinking about using the OpenBSD/sparc64 box as a primary firewall (until I can get something better), but I imagine that NetBSD really doesn't need much more sparc64 support right now -- maybe I could reconsider using that one for sparc64 package support. Likewise, a 5.2 i386 build takes about a week, which means that the freeze *cannot* be shorter than this, even if everything goes perfectly (which, in practise, never happens). This time around, the freeze started on 23 Nov and was lifted on 3 Dec. That's 10 days, which is about as good as you could hope for. If we could build packages in - say - a day, we'd be able to cut the freeze time down further, although I expect the duration would become limited by the speed at which problems can be corrected. Sounds to me like a reliable RAM disk for temporary files would be very helpful. There are at least one or two PCI card models that I think can take up to 8GB, and which I know work with Linux. If they don't already work with FreeBSD, I would imagine it shouldn't take too much work to fix that. Every now and then we get offers of access to a machine here or a machine there to help with building packages. The main problem with donating machine resources is that there's limited space in the freebsd.org equipment racks, and the package build system currently needs LAN-equivalent connectivity between the machines. To be useful we'd either need a full cluster of faster machines located somewhere, or to find time to rewrite the build scripts to work efficiently with remote build resources. Hmm. I would seriously consider donating one or two sparc64 boxes to the project (once I confirm they work ;-), but I would want to make sure that there is space to support them. Otherwise, I would be willing to run them from my basement. Of course, that's precisely the problem you already have. I've done a bit of script hacking in the past. Do you have any idea what would be required to hack these scripts to suit? Alternatively, I might be able to get you some additional build resources somewhere else. In fact, I think this other place is probably already quite familiar with FreeBSD, and they might be surprised to hear about this need -- should I contact them? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, Jan 08, 2004 at 06:36:42PM +0100, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2004-01-07 23:17:31 -0800: On Wed, Jan 07, 2004 at 09:08:38PM +0100, Roman Neuhauser wrote: The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. That might be technically true, but it's misleading and doesn't support the point you're trying to make. During this period the ports collection has only been frozen for a couple of weeks, and the majority of commit activities were not restricted for the rest of the period in question. That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Repo-copies are not allowed during the freeze, but are any other time. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? No, please raise this on the ports list. Kris pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : : Ryan Sommers [EMAIL PROTECTED] writes: : : Something like this might also jeopardize the : : project's not for profit status. : : The project is not a legally incorporated entity at this time, and : never has been in the past. : : And yet the Legal page carries a claim of copyright for The FreeBSD : Project It is a psudonymous work by The FreeBSD Project. : and the Copyright page has that plus a similar claim for : FreeBSD, Inc. (For 2004, even.) That should be changed. : I've not seen a US statute about : false copyright claims, but I think it would be less risky to say all : intellectual property is owned by its owners, in the manner of some : trademark statements. No, the above is perfectly legal under US and International Copyright law. : The Legal page could tell about using CVS to : determine who owns what so they can be tracked down and asked if the : copyright page is correct about what license they've got it under. :) That's likely overkill, but might not be a bad idea. : Whether the project is for profit depends upon the definition, if : the project is claiming copyright ownership, because gains of : intellectual property is considered (by US copyright law, at least) to : be a financial gain. But lots of organizations, formal and informal, : have financial gains without problems with being considered for : profit, so if someone sees for profit problems, they should be : specific about what the problems might be. For profit or not is irrelvant, given that there's no legally incorporated entity for the project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Paul Robinson [EMAIL PROTECTED] writes: If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. I am currently working for an ISP whose infrastructure is based 75% on FreeBSD 5.1. The remaining 25% are a nameserver running 4.7, a mail server and a backup server running 5.2, and a BGP router running a month-old -CURRENT. I am about to start in a new job at a company that builds a high- performance network security appliance based on FreeBSD. The version they travel around with to show off to potential customers runs on -STABLE; the development version runs on -CURRENT. I asked them what it was like to develop on -CURRENT compared to -STABLE. Their answer: a relief. Now tell me again why you think FreeBSD 5 is a disaster, and why you think we're out of touch with our users and admins. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
I wrote: Mark has mailed me off-list. His tone isn't great. I probably deserve the Fuck off. Go away. I'l deal with that seperately. :-) A few things to say about this: 1. I was not quoting Mark verbatim here. He didn't tell me to go away in the same paragraph. :-) 2. It was a private e-mail, and it's tone/content should have stayed as such, and so I was wrong to allow leakage. 3. The specific context of my mail to which he was replying, that caused him to get upset with me was where I stated in public: In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. 4. In private I've already apologised for that particualr comment as I realise now it was very Daily Mail of me to make it (for those of you without access to the Daily Mail, congratualations), and it's only fair as it spilled out onto the public lists, that I apologise here too. Mark also apologised for swearing at me. Oh, and I should also add, in an attempt at public humiliation to make sure I behave better in future that in the e-mail where I replied to Mark privately, I finished with the following: It wasn't meant to be taken as being personally offensive, but I am pissed off that people just said Oh the start of this thread was just a troll, ignore it when there were issues that did need to be raised and aired and discussed that the original post touched on (badly). Now I'm just pissed off that never happened in a constructive manner, and I'm part to blame. I think that is a fair summation, and perhaps a good point to let that particular branch of the thread die. And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
fwiw, the original mail was mine, written almost a year ago. Date: Tue, 4 Feb 2003 11:15:27 +0100 From: Shaun Jurrens [EMAIL PROTECTED] Subject: dillon@'s commit bit: I object To: [EMAIL PROTECTED] While I still stand by my original thoughts, I didn't reproduce this from any faked e-mail address. This is all in the archives with the ensuing rants. It is a pity that our troll doesn't have any original thoughts of his own... I had to laugh a bit when I saw this... not sure if I'm flattered or insulted. I'd apologize to Maxime, but it wasn't my doing... He's a big boy anyway, and I'm not a troll. -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 5:35 PM + 2004/01/06, Paul Robinson wrote: The cleverness of the troll was: 1. It was written by somebody who at the least had read these lists for at least the last two years Maybe. It would be easy enough to skim the archives. 2. It aired the real frustrations of those of us without commit bits Define us. You sure as hell aren't speaking for me. 3. It was on the whole, apart from the personal attacks, reasonably correct. Evidence, please. And therein lies a problem. The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Not at all true. Mark Murray (among others) has stressed the need for people with different talents to contribute to the project. We need more people who can help us do proper QA. We need more people who can help us write good documentation. We need people who have a lot of skills that are not necessarily related at all to writing code. If you have a set of skills that you think could be useful, please contact Mark or one of the other members of -core to find out how you might be able to contribute to the project. Otherwise, if you're not willing to try to put your money where your mouth is, then please shut up. Except, when Matt Dillon did submit, he was told to back out his changes and then lost his commit bit. This was because there was an imminent commit due from somebody working on SMP, which still isn't finished really. I have the greatest respect for Matt, but he has been a serious problem for the project for a long time. His technical disagreements with other members of the project are just one relatively minor aspect of those problems. His personality has been a much bigger issue. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. Who cares about users? This is their project after all. If you want to feel like this is your project, then you need to find a way to take ownership of some part. See above. Personally, unless the madness around SMP, the 5- branch and various other bits are ironed out, I can see my next server deployment making use of DragonFly. Please let us know how it turns out. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Wes Peters said: [Charset iso-8859-1 unsupported, filtering to ASCII...] On Monday 05 January 2004 11:14 am, Brett Glass wrote: I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. The current system of governance is open and inclusive of those who have demonstrated the talent, ability, and willingness to be contributors to FreeBSD. The current core team is made up of a mix of big-time coders like Peter and Warner, and small-time coders like myself (now slightly below middle of the pack on commits) and a variety of other skills. ... Somebody whose viewpoint doesn't extend beyond the virtual memory system, for instance, may be critical to the success of a kernel, but that doesn't necessarily make them the best person to steer a complex product that brings 10,000 applications along with it. It is INTERESTING to comment on someone whose viewpoint doesn't extend beyond the VM system, because out of Greenman, me and even Matt Dillon, (and the extremely respected alc), I don't know of any people with a myopic VM viewpoint. An example of that might be Matts ability and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management improvements (which aren't really VM per se), early playing with the ATA driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt' get installed because of softupdates making it redundant), careful rework of certain portions of low level code, and it is definitely ludicrous to claim that Greenman was VM myopic. The biggest problem that I currently see on the technical side has NOTHING to do with the individual competencies, but the SMP locking complexity issues that I had predicted would happen. By looking at the locking from the VFS, VM, IPC and hardware standpoints (I admittedly wasn't and STILL AM NOT competent on networking issues), it is very very clear that restructuring the system to support more coherent and orderly locking would make the system INFINITELY more maintainable. It might even be worthwhile to start a rearchitecting now, recognizing that there were important things learned during the current exercise. The VFS and VM systems have numerous interdependencies, due to the very desired specified coherency, desired modularity and natural control/data flow. EVEN THOUGH it is very possible to make superficial modifications to the traditional structure in order to support adequate SMP locking, the design will likely become unmaintainable for future improvements or restructuring, the structure will be susceptable to bit rot. The VFS, VM and scheduling mechanisms could have (with nominal effort) been upgraded to use more of a realtime kernel structure (while retaining the timesharing behavior when desirable.) Using tsleep or its derivatives for process blocking with control/data stack context being intermingled with sundry data structure (and subsystem) locks make for a design that will sustain a high priesthood for years. (A wonderful side-effect of breaking the tsleep/stack marriage, is that VFS layering can be much easier decoupled from the VM and VFS interaction and coherency issues.) This should also have positive consequences WRT network stack state... Perhaps a good first step would have been to progressively remove the dependency upon stack context during thread/process blocking. This has several interesting positive side effects... However, this definitely breaks from the sleep/wakeup paradigm. There are numerous ways to break the dependency on the stack context, and I am partial to using continuations along with a few other possible paradigms. I haven't looked into these issues for years, but there might be some schemes that are even more effective or architecturally 'clean.' All this said, I still think that FreeBSD is the best choice for a general purpose OS. It is good that the system still works smoothly under load (something that I tirelessly strived for), making sure that during heavy loading conditions that system latencies (while waiting on various internal resources) are minimized. FreeBSD is proof that system caching doesnt' have to be continually manually tuned for any normal configuration... John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Please suggest an alternative, given that almost all the labor is volunteer labor. There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. IMHO it's reasonable to prioritize concrete suggestions over wish-list items. What else should we be doing? Except, when Matt Dillon did submit, he was told to back out his changes This had more to do with personalities than technology. Other people have had patches rejected, backouts requested, and in some cases, backouts forced upon them. Many of those people are still with the project. In a cooperative anarchy, things are never going to be perfect; further, I think it's unfair to generalize this one situation to saying this or that contribution doesn't count. This was the culminating incident of a long-standing clash between strong personalities. It's too bad that it worked out the way it did, but I think other than that it's not useful to make generalizations from this one controversy. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. What you may be interpreting as resentment may actually just be frustration at being once again in the middle of being told things are broken without concrete suggestions about how it can be fixed. Please come up with some kind of definite proposal that you think would alleviate your, and others', concerns; and post it and let us discuss it. Keep in mind that as you do so it's a volunteer project, and you have to address the interests of the current volunteers too. Perhaps you can suggest a way to bring more volunteers in without losing any of the existing ones. I certainly don't have any answers to these kinds of questions; let me take a look at yours. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Tue, Jan 06, 2004 at 08:52:37PM +, Colin Percival wrote: At 20:31 06/01/2004, Mark Linimon wrote: There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. Speaking of which... if there's one thing which could be done to improve committer / non-committer relations, it would be to *do* something with all those PRs. The ports team is pretty good -- my maintainer updates have always been committed fairly quickly -- but I've never had a src patch committed without badgering committer(s) about my PRs. Hm, it is one of the weak spots for sure. Not much different from paid-for development work, most people I've ever met working in that area tried to avoid doing maintenance work aka bug fixing. 2nd to avoiding maintenance work is not writing documentation if at all possible :) Not an excuse, just an observation. W/ -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 11:28 PM + 2004/01/06, Paul Robinson wrote: Accepted. It came from [EMAIL PROTECTED] and therefore can only represent my own opinion. In the future, may I suggest that you make this sort of statement more clear at the beginning? It sounded to me like you were standing up as a self-appointed champion of the rest of the world. But I know a lot of people who are looking at deploying 5- who aren't just pissed off - they're *scared*. FreeBSD-5 was always going to be problematical. There have probably been more things changed for this major version than for any previous major version in history, maybe even for all previous major versions combined. They bit off a great big honking whackload with this version, and they knew it. That's why we're so far behind the original release timetable (one year? two years?). Any reasonable production-oriented plan would have been to stick with 4.x until such time as 5.x has been declared STABLE, and then wait for another minor release or two after that. Timetables can (and do) slip, so you'd have to build that into the picture. I don't think many of the developers understand this. My personal opinion is that I believe many of them understand this better than you know. See above. To us (yes, I'm not speaking for Brad Knowles), FreeBSD is not a project we spend our spare time on and love and adore. Well, it is, but it's also a lot more. It defines our careers. We roll out something that isn't quite right, our jobs are finished. I've been there. I was the only FreeBSD guy bringing in machines into the largest ISP in Belgium, where everyone else was a Linux fanatic. They learned to respect the machines I brought in and how rock-solid they were, and my co-workers have since taken over and rolled out even more FreeBSD servers since I left. I believe they have the largest USENET news servers in the country, and the machines are also some of the most robust in the facility. Right now, if somebody asks me what our roll-out strategy is for the next 18 months, I have to respond don't know, whereas the Linux guys are just laughing... don't even start me on what the Windows guys are doing to my career right now See above. Roll out 4.x for now, wait for 5.x to stabilize. That should have been the plan since 5.x first became -CURRENT years ago. The Linux guys have a lot to deal with, too. Red Hat licensing is now looking nearly as expensive as Sun, Mandrake is bankrupt, SuSE is being bought by Novell (in preparation to kill it?), and who else is left? They've always had a schizophrenic situation, with the dichotomy between the kernel developers versus the distribution creators. Windows? Well, Longhorn just got pushed out yet another year -- wait until 2005 or 2006, at least. Nothing to worry about there. OK, so it has got personal... I accept it is not the FreeBSD development team's job to look after my career, and to date I've looked after that by myself OK, but all I'm asking is you try and at least understand where some people are coming from on this. I understand, and I believe that the vast majority of the FreeBSD developers understand. Mark has mailed me off-list. His tone isn't great. I probably deserve the Fuck off. Go away. I'l deal with that seperately. :-) In my original draft of my response, I basically told you to STFU myself. I decided that discretion was the better part of valor, and toned down that remark. But I can certainly understand the frustration resulting from having seen your post. OK, I've never run into that. Over on the DragonFly stuff, he seems pleasant enough and his ideas are innovative, strong, if sometimes... *cough*... eccentric (e.g. replacing sysinstall with an Apache server and a load of PHP...), but I'll accept I haven't seen that, and I know others have had their problems there. Well, since it's his project, I'm sure he feels a lot more secure. Perhaps he's taken some lessons from previous mistakes with the FreeBSD project, and he's working to avoid re-living them with DragonFly. I did see the fall-out on these lists with the argument that caused it all to kick off about a year ago though, and I don't think others on the project dealt with him (in public at least) fairly. Again, just my opinion, I wasn't involved, don't know what happened in private. I don't think that we saw more than the slightest bit of what really happened. I will agree that I think this matter could have (and should have) been better handled with regards to the public aspects, but anyone who was watching the lists at the time should have noted that this was not a new type of problem, and there were multiple references to previous situations of a similar nature. Ooooh, no. That isn't what I want at all. I just want end-users to feel they have a voice. That's all. Maybe they
Re: Where is FreeBSD going?
Paul Robinson writes: In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. 4. In private I've already apologised for that particualr comment as I realise now it was very Daily Mail of me to make it (for those of you without access to the Daily Mail, congratualations), and it's only fair as it spilled out onto the public lists, that I apologise here too. Mark also apologised for swearing at me. I consider hands to have been shaken over this. :-). And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) I've been thinking of your objection to the submit a patch reply, and I offer this as a proto-thought on how it can be applied to non-coders: As FreeBSD is a volunteer project, I suspect part of the problem is getting said volunteers to do things that they would otherwise not do. Submit a patch can be easily(?) extendted to cover a much wider area of volunteer-organised work than simply code. Under specifically _patches_, there are code, documentation and web page patches, but there is also a need for organizational skills. The PR database frequently gets blitzed by keen folks who get lots of PRs closed, follwed by burnout. We are doing rather well with our release-engineering team (Go Scott L!), and our currently active admin@ crowd are doing a great job, but we could still use skills, and these are not necessarily of the coding kind. SO - instead of submit a patch perhaps if we were to go submit something tangible and useful? This can be anything that will forward the progress of FreeBSD. It could be something lofty like paying the salary of a developer who will then work primarily on projects useful to yourself. It could be commissioned work for a particular project you would like to see done. It could be a financial or equipment donation. It could be a donation of your time in a way that would be useful (please help here by finding something that needs doing and offering to do it, rather than expecting us geeks to find it for you!). It could be _anything_ that forwards the aims of the project and that you can do, and it preferably needs to be something that can be done autonomously (or as autonomously as possible). You will not get paid, you may not get thanked, but you will have the satisfaction of actually getting something done, and if you like FreeBSD as much as I do, that is an end in itself! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Hi, Time to force use of gnupg or something like that to prevent this to happen. Just an opinion. Yours, Nuno Teixeira On Tue, Jan 06, 2004 at 02:52:58PM +0100, Maxime Henrion wrote: Hi all, Since several people actually thought this mail was written by me, I'm replying here to tell it wasn't. This mail was sent by the same guy who periodically impersonate one of the FreeBSD committers to rant about the project. His mail doesn't reflect my thoughts at all. Please all let this thread die. Thanks, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Nuno Teixeira SDF Public Access UNIX System - http://sdf.lonestar.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 02:09:33AM +0100, Brad Knowles wrote: FreeBSD-5 was always going to be problematical. There have probably been more things changed for this major version than for any previous major version in history, maybe even for all previous major versions combined. They bit off a great big honking whackload with this version, and they knew it. That's why we're so far behind the original release timetable (one year? two years?). Any reasonable production-oriented plan would have been to stick with 4.x until such time as 5.x has been declared STABLE, and then wait for another minor release or two after that. Timetables can (and do) slip, so you'd have to build that into the picture. Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. You are 100% right, in that all documentation, communication from FreeBSD developers and soforth has pointed to remain on 4.x for production machines until 5.x has a stable release, and that it will be a while. From a practical point of view that has been rapidly breaking down over the last 6-12 months. People need features in 5.x. Various people have decided (for good reason, I'm not questioning the decisions) that a large number of features go into 5.x, and because of the difficulty in back porting don't go into 4.x. Indeed, the only reason I'm running -current now is I need support for an Atheros wireless card. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. You can't delay one year or two years in a production environment. New hardware needs drivers in that time. New protocols become production deployed in that time. I am also a firm believer that having all the developers focused so much on meeting deadlines for all this new complexity leaves them out of time to deal with the PR's that have been piling up. For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Mom said it best, small bites, chew with your mouth closed. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 10:22:44AM -0500, Lanny Baron wrote: Just what we are wondering. Where is all the FreeBSD community support for a Server company that fully supports FreeBSD? It certainly is not in this letter. Disclaimer: Until this message I didn't know www.FreeBSDsystems.com existed, and I know nothing about them other than what the front page of their web server has on it. I believe you've missed the point completely. Building a new server farm is an important, but specialized niche. Sure I can buy hardware that is only 100% fully supported. I may have to pay a little more, but to some degree that's ok. The point is that the person trying FreeBSD at home (where Linux is a competitor), or wanting to put it on their desktop at work (where IT just gave them a PC with windows, and the boss will let them run FreeBSD, but won't buy yet another PC to do it) suffer. OS's like FreeBSD and Linux make their way into the enterprise from the ground up, running on the old leftover box in the corner. So, do I support companies like (but not specifically) www.freebsdsystems.com, sure. Does that mean the freebsd development team can forget about all the other hardware out there in massive quantities, heck no. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Leo Bicknell wrote: From a practical point of view that has been rapidly breaking down over the last 6-12 months. People need features in 5.x. Various people have decided (for good reason, I'm not questioning the decisions) that a large number of features go into 5.x, and because of the difficulty in back porting don't go into 4.x. Indeed, the only reason I'm running -current now is I need support for an Atheros wireless card. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. You can't delay one year or two years in a production environment. New hardware needs drivers in that time. New protocols become production deployed in that time. I am also a firm believer that having all the developers focused so much on meeting deadlines for all this new complexity leaves them out of time to deal with the PR's that have been piling up. My perspective as a developer is that there were a lot of things in FreeBSD that needed an overhaul. SMP for example. Sure, it's not perfect and probably still has a ways to go, but this touched a lot of things. I fully expected FreeBSD-5 to get worse before it got better, perhaps lose some folks to Linux because they couldn't wait for stable -5 features. Could it have been better managed? Sure, in a better world where we had more of our developers getting paid to do this (we're lucky that we still have a handful or two of them). For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Mom said it best, small bites, chew with your mouth closed. I understand this position, but I think this step was a necessary one for the future of the project. My $.02. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Hi, Leo Bicknell wrote: [snip] For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Just what we are wondering. Where is all the FreeBSD community support for a Server company that fully supports FreeBSD? It certainly is not in this letter. As for the parts from China part, we don't buy any 'cheaper by anything' components. We don't look for a way to sell 'cheap servers'. We soley build that which runs extremely well on our Servers with FreeBSD 4.x or 5.x on it. When I read about people who buy Servers from the major players the large computer companies such as those listed above and who by the way, don't give a flying *#@ about FreeBSD, I wonder why the principles here continue to be loyal to the FreeBSD community. Mom said it best, small bites, chew with your mouth closed. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Lanny Baron Proud to be 100% FreeBSD http://www.FreeBSDsystems.COM Toll Free: 1.877.963.1900 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-07 14:29:35 +: Paul Robinson writes: And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) I've been thinking of your objection to the submit a patch reply, and I offer this as a proto-thought on how it can be applied to non-coders: As FreeBSD is a volunteer project, I suspect part of the problem is getting said volunteers to do things that they would otherwise not do. Submit a patch can be easily(?) extendted to cover a much wider area of volunteer-organised work than simply code. Under specifically _patches_, there are code, documentation and web page patches, but there is also a need for organizational skills. The PR database frequently gets blitzed by keen folks who get lots of PRs closed, follwed by burnout. We are doing rather well with our release-engineering team (Go Scott L!), and our currently active admin@ crowd are doing a great job, but we could still use skills, and these are not necessarily of the coding kind. Help us (users, port maintainers and random porters w/o commit) help you (committers). There are two areas I can (and do in one of them) participate: ports and documentation. Activities in both areas result in patches, and those need a committer. PRs need more hands, more people who can commit stuff. Quite a few port maintainers could have commit, even limited to just parts of the ports tree (IOW just their ports). The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. While minor stuff can be managed by keeping multiple working copies, thorough documentation (or just any, really) on setting up local cvs mirror and using $CVS_LOCAL_BRANCH_NUM is sorely missing; or did I get it right quite recently that this is discouraged because of software issues (ISTR it was jdp@ who said it)? Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) [1] has core@ considered subversion (devel/subversion)? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Roman Neuhauser wrote: [1] has core@ considered subversion (devel/subversion)? Everyone has their eyes wide open looking for a revision control alternative, but last time it was discussed in detail (a few months ago?) it seemed there still wasn't a viable alternative. On the src tree side, FreeBSD committers are making extensive use of a Perforce repository (which supports lightweight branching, etc, etc), but there's a strong desire to maintain the base system on a purely open source revision control system, and migrating your data is no lightweight proposition. Likewise, you really want to trust your data only to tried and true solutions, I think -- we want to build an OS, not a version control system, if at all possible :-). Subversion seems to be the current favorite to keep an eye on, but the public release seemed not to have realized the promise of the design (i.e., no three-way merges, etc). You can peruse the FreeBSD Perforce repository via the web using http://perforce.FreeBSD.org/ -- it contains a lot of personal and small project sandboxes that might be of interest. For example, we do all the primary TrustedBSD development in Perforce before merging it to the main CVS repository. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 12:42 PM +0100 1/7/04, Dag-Erling Smørgrav wrote: Paul Robinson [EMAIL PROTECTED] writes: If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. I am currently working for an ISP whose infrastructure is based 75% on FreeBSD 5.1. ... I am about to start in a new job... I asked them what it was like to develop on -CURRENT compared to -STABLE. Their answer: a relief. I would add that I've been running almost exclusively on 5.x for over a year now (except for one machine which I have not rebooted in over a year...). There have been some *very* painful transitions at various times, but once I get past the transitions the system has been quite stable. (fwiw, in my case, I am only running on desktop systems). So, once we stop making major API/ABI changes and the branch is truly stable (with a 6.x branch for new cutting-edge developments), I personally am quite confident that 5.x will be a stable, production-quality system. And there are a number of features in 5.x that I think are tremendous advantages -- especially for boxes in a production setting. My guess is you're going to have a large bar tab at the next BSDcon... Certainly I hope so! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
:It is INTERESTING to comment on someone whose viewpoint doesn't extend :beyond the VM system, because out of Greenman, me and even Matt Dillon, :(and the extremely respected alc), I don't know of any people :with a myopic VM viewpoint. An example of that might be Matts ability :and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation :of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management :improvements (which aren't really VM per se), early playing with the ATA :driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt' :get installed because of softupdates making it redundant), careful rework of :certain portions of low level code, and it is definitely ludicrous :to claim that Greenman was VM myopic. Currently in FreeBSD-5 there are far fewer people able to work on a wide range of subsystems due to the complexity of the SMP environment. That should be clearly obvious to everyone... I rarely see cross-disciplinary commits (though there are other reasons for that observation beyond the complexity of the SMP environment). Certainly I see far fewer such commits then occured in the 4.x days. Focus is good, but the complexity of the APIs are such that as some of the current developers move on to other things large swaths of code are going to start to become unattended through lack of understanding, and it could potentially swamp the relatively few interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. I have no doubt that FreeBSD-5 can be stabilized with the current development crew, but the warning signs abound and if the SMP environmental interfaces are not simplified FreeBSD-5 will end up in serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, but there are a lot of things in there that people are going to want to rewrite in coming years, and rewriting by people other then the original authors is one of the reasons why we had so much trouble in the 2.x and 3.x days. Look at how little VFS has been touched in the intervening years despite the fact that it is obvious that it has needed a serious rewrite for the last decade. I can barely figure it out even now and I have spent hundreds of hours working on VFS. I mean, I don't think anyone can honestly say that the scheduler is 'done', or even close to done. Look at how long the original 42 scheduler was worked on after it was originally finished? Same goes for the VM system, VFS, the slab allocator, the mutex related code, the USB code (EHCI for example), and everything else. Simplifying maintainance should be of paramount concern to everyone, and the number one most complex issue in FreeBSD-5 right now are the SMP related APIs and non-deterministic scheduler side effects like preemptive cpu migration, indirect preemptive switching to non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 9:57 AM -0500 1/7/04, Leo Bicknell wrote: Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. I agree with this observation, but then it's easy to see that in hindsight. We started on some ambitious targets when 5.x started, and at the time we believed we were going to have a lot more full- time development resources than we ended up with. That whole big problem with the dot.com bubble bursting. I do think we need to tackle a somewhat smaller chunk of projects for 6.0, so it won't take so long to get it done. I also expect we have a much more realistic idea of what our resources are than we had in late 1999. You can't delay one year or two years in a production environment. Actually, in a production environment you're more than happy to delay a year or two. You don't want constant churn. You don't want new API's and ABI's every year. The problem for freebsd is that 4.0 was released in March of 2000, and that was advertised as a stable release. 5.0 was released in January of 2003 -- and was explicitly *not* a stable release. We could stand to have a major stable release every two years, or maybe even every three years, but this is going to be more like four years. That is too long. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. (I'm going to be looking for a full time job in about 11 months and if I got one where I got to code/administer BSD I'd feel I was in Heaven.) :-) 2) Setup a mailling list for just new developer questions. This would be a great idea, however, it might be something the hackers@ list was originally intended for. Unfortunately I think no matter what list you create there will always be those feelings and people that will speak like that. People just have to remember that although it may sound as if someone is ridiculing them it might not be there intention. The Internet is a rather flat medium for communicating emotion. 3) Simple but time consuming requests from developers - Isn't it possible to have developers pass off some of their simple tasks to others? Think of it like a pet dog. Your dog may be able fetch your newspaper but he couldn't read it. Still fetching the newspaper takes time! The requests I see are usually Jr. kernel type requests. Everyone wants to contribute at the kernel level but that takes a lot of knowhow and experience working with fbsd's kernel. Let users get involved with simple (stupid) tasks which are time consuming. Now define simple... Again, I think a JKH (Junior Kernel Hacker) list (like the one PHK had for awhile) would be a great addition. I'll even volunteer to maintain it if developers were willing to help me by providing these small projects for people to work on. As someone attempting to join the ranks of people in the Submitted by: log lines this is one of the hardest things for me to do is find something I can work on. I think this might be some duplication of the PR database; some PRs are things that could be accomplished without too much skill. I think the trouble though is wading through to find these specific issues. Perhaps such a list could contain cross-references to the PR db. -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
3) Simple but time consuming requests from developers - Isn't it possible to have developers pass off some of their simple tasks to others? Think of it like a pet dog. Your dog may be able fetch your newspaper but he couldn't read it. Still fetching the newspaper takes time! The requests I see are usually Jr. kernel type requests. Everyone wants to contribute at the kernel level but that takes a lot of knowhow and experience working with fbsd's kernel. Let users get involved with simple (stupid) tasks which are time consuming. Now define simple... Again, I think a JKH (Junior Kernel Hacker) list (like the one PHK had for awhile) would be a great addition. I'll even volunteer to maintain it if developers were willing to help me by providing these small projects for people to work on. As someone attempting to join the ranks of people in the Submitted by: log lines this is one of the hardest things for me to do is find something I can work on. The only problem with a JKH list is that there need to be committers willing to review and commit PRs that are created from the tasks on the list. About a year ago I started working on one of PHK's tasks, opened up 4 PRs, and found absolutely nobody willing to review or commit them. After a month of pinging people and waiting for feedback (and getting absolutely none), I just stopped working on it. It's these kinds of impasses that prevent people who have the skills and time from actually contributing to the project. There really isn't any use opening PRs and creating patches if they're never going to get committed (or by the time someone decides to commit them, the patches need to be moved forward 3 or 4 releases.) -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Where is FreeBSD going?
I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. --Brett Glass At 11:43 AM 1/5/2004, Munden, Randall J wrote: This makes me wonder if it isn't time for a new -core. -Original Message- From: Maxim Hermion [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Where is FreeBSD going? I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of glue that binds FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat. The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain unless someone is willing to pay for my time (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past. Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically). If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about). You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid glee club that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few others), although I find his method of expressing it extreme, I often wished he'd have just visited the offenders personally with a clue bat. All in all, history will judge if -core has made the right decision. I
RE: Where is FreeBSD going?
At 12:40 PM 1/5/2004, Munden, Randall J wrote: Right. What concerns me most is the rise in the incidence of trolls all trolling about the same subject or along the same vein. Would someone please explain what is going on? As a production user of fBSD this is troubling. It's probably one of the Slashdot BSD is dead trolls. The fact is, though, that there ARE things about FreeBSD that could stand improvement. These days, when I build a box, I am torn between using FreeBSD 5.x -- which is not ready for prime time but is at least being worked on actively -- and using 4.9, which isn't as stable as it should be because the developers broke the cardinal rule of making radical changes to -STABLE. This *is* a real issue for those of us who are admins. FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their sandbox. So, some of the criticism is actually valid. --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: Where is FreeBSD going?
Mark, You are totally right with the stuff that is starting to stick. Let us all be happy and continue to support the freebsd.org core team. Internal fights are pretty common, no one can ever be happy with other's choices. But i think it's a shame that one would have to resign or worse the freebsd project hangs and perhaps gets killed by this foolish actions. Keep hanging tight guys!!! Regards, Remko Lodder -Oorspronkelijk bericht- Van: Mark Dixon [mailto:[EMAIL PROTECTED] Verzonden: maandag 5 januari 2004 23:23 Aan: Remko Lodder; [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Onderwerp: Re: [Freebsd-hackers] Re: Where is FreeBSD going? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 05 Jan 2004 22:01, Remko Lodder wrote: I Never ever noticed that these things are playing within freebsd.org I See a healthy and good working organisation behind freebsd.org I think they are really productional and give out releases a lot of times. Sorry yeah, I didn't phrase that all that well. I also fully support the people putting hours of their time into producing a great OS. I just think that with all of this mud being thrown, some of it is starting to stick. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQE/+ePmLqgJ90OcaiARAuPrAKD44kok+WrOBnDEt/a39RKq6c+4GwCfeBIe 6N7mnoWJFWcCKARVNUpBCIY= =IEuG -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Where is FreeBSD going?
At 04:00 PM 1/5/2004, Munden, Randall J wrote: I think this is what is on my mind these days. I'm preparing to load up some machines for production soon (I've already put it off for too long waiting for 5-STABLE) and I don't like what I'm seeing -- with both the mud slinging here and the performance in the lab (mostly anecdotal). I don't think that *this* conversation is mud slinging. What's happening on Slashdot, on the other hand, is. FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their sandbox. So, some of the criticism is actually valid. I noticed it too but I just chalked it up to being crazy busy and not paying much attention. Nope, it's not because you're too busy. It's true. FreeBSD is getting fewer mentions in the mainstream press, and fewer commercial apps, lately. Linux is mentioned as if it was the ONLY alternative to Windows. Work is needed to raise FreeBSD's profile. --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Experienced programmers can be leaders very effectively if they get feedback regularly from users. Its part of software development to communicate with users. Provided the leadership listens to users requirements, and acts in that interest there is no problem. In reality, there are several types of users of FreeBSD including: Programmers System Administrators College Students (i fit in the first 3 groups) Hobbyists and young people who heard its like linux (lol) (sorry if i left your group out) Lucas Holt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Mon, Jan 05, 2004 at 10:30:03AM -0800, Maxim Hermion wrote: I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of glue that binds Sincerely, Maxim Hermion FreeBSD committer Dare I ask for some form of proof this is you? Later on you say you can't use your real name but you don't think that anybody is stupid enough to not notice the similarity in your name? How about a signed reply? -lewiz. -- I was so much older then, I'm younger than that now. --Bob Dylan, 1964. -| msn:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] | url:www.lewiz.org |- pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
Hi all, Since several people actually thought this mail was written by me, I'm replying here to tell it wasn't. This mail was sent by the same guy who periodically impersonate one of the FreeBSD committers to rant about the project. His mail doesn't reflect my thoughts at all. Please all let this thread die. Thanks, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Where is FreeBSD going?
-Original Message- From: Brett Glass [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:16 PM To: Munden, Randall J; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Where is FreeBSD going? At 04:00 PM 1/5/2004, Munden, Randall J wrote: I think this is what is on my mind these days. I'm preparing to load up some machines for production soon (I've already put it off for too long waiting for 5-STABLE) and I don't like what I'm seeing -- with both the mud slinging here and the performance in the lab (mostly anecdotal). I don't think that *this* conversation is mud slinging. What's happening on Slashdot, on the other hand, is. Right, I typed that wrong. This conversation certainly isn't mud slinging -- open, honest discussion can do nothing but good [no matter the outcome]. Honestly, I picked up the troll thread because I'm curious as to why someone would commit so much time in effort to trolling these lists. In my experience it's a good idea to explore the reasoning behind that type of dedication (faulty or not) for no other reason that discovery. On-the-other-hand some people accuse me of being obsessive about information. /me shrugs All I can do now is apologize for 'feeding the troll' or rather, sorry for calling attention to a subject that may be painful, cliché or overused to others. FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their sandbox. So, some of the criticism is actually valid. I noticed it too but I just chalked it up to being crazy busy and not paying much attention. Nope, it's not because you're too busy. It's true. FreeBSD is getting fewer mentions in the mainstream press, and fewer commercial apps, lately. Linux is mentioned as if it was the ONLY alternative to Windows. Work is needed to raise FreeBSD's profile. Which leads me to query, given limited time an resources, what can I do? I've moved many a production server to fBSD over the last 10 or so years -- some of them literally -- by blathering nonstop about the virtues of the OS. So what else is there? Do I need to start writing documentation or publishing and pimping more Howtos on the intarweb? Should I brush up on my C and start patching? Frankly, I'd never given thought to providing more effort. The OS has always done it's own advocacy in my experience. --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/free bsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Monday 05 January 2004 11:14 am, Brett Glass wrote: I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. The current system of governance is open and inclusive of those who have demonstrated the talent, ability, and willingness to be contributors to FreeBSD. The current core team is made up of a mix of big-time coders like Peter and Warner, and small-time coders like myself (now slightly below middle of the pack on commits) and a variety of other skills. I strongly encourage all FreeBSD committers to continuously watch for people who might be good core team members. Watch for leadership, for a sense of fair play, and for the ability to steer FreeBSD, from both technical and organizational viewpoints. Look for someone with 'the big picture,' and a vision of where FreeBSD is headed that you share. Somebody whose viewpoint doesn't extend beyond the virtual memory system, for instance, may be critical to the success of a kernel, but that doesn't necessarily make them the best person to steer a complex product that brings 10,000 applications along with it. We don't appear to have anyone like that on core now, and I doubt we will in the future. Programmers, system administrators, end users, and anyone else who wants to contribute to FreeBSD are welcome to contribute in whatever way they can. Anyone can file a PR about any aspect of the system they find troubling, or delightful, or have a better way of doing. Strike up a relationship with a committer or two (or twenty), let your ability and willingness to work be known, and become a committer too. 400 or so of your peers have already done it. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Tuesday 06 January 2004 09:05 am, Munden, Randall J wrote: Honestly, I picked up the troll thread because I'm curious as to why someone would commit so much time in effort to trolling these lists. In my experience it's a good idea to explore the reasoning behind that type of dedication (faulty or not) for no other reason that discovery. On-the-other-hand some people accuse me of being obsessive about information. /me shrugs People who hate rarely require rational reasons for hating. Attempting to apply logic to that which is not logical is not likely to produce useful results. Which leads me to query, given limited time an resources, what can I do? I've moved many a production server to fBSD over the last 10 or so years -- some of them literally -- by blathering nonstop about the virtues of the OS. So what else is there? Do I need to start writing documentation or publishing and pimping more Howtos on the intarweb? Should I brush up on my C and start patching? Yes, to all of the above. Pick the one(s) you enjoy most, or that you wish to learn most, and dig in. Best of all would be to write or fix some code, or write some articles that get printed on dead trees -- what Brett likes to call 'the mainstream press.' You know, those things the IT management leaves on the floor of the mens room. Frankly, I'd never given thought to providing more effort. The OS has always done it's own advocacy in my experience. Advocacy is important only if you want to conquer the world. Brett apparently does; many of us just want an operating system that meets our needs, and don't particularly care what somebody else uses. IMO, casual 'desktop' or 'laptop' computer users are probably better served by Mac OS X than anything I want to turn FreeBSD into, which is why my 68 year old father is a Mac owner. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Munden, Randall J [EMAIL PROTECTED] writes: This makes me wonder if it isn't time for a new -core. No, just a better email filter. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Munden, Randall J wrote: Right, I typed that wrong. This conversation certainly isn't mud slinging -- open, honest discussion can do nothing but good [no matter the outcome]. The cleverness of the troll was: 1. It was written by somebody who at the least had read these lists for at least the last two years 2. It aired the real frustrations of those of us without commit bits 3. It was on the whole, apart from the personal attacks, reasonably correct. Which leads me to query, given limited time an resources, what can I do? I've moved many a production server to fBSD over the last 10 or so years -- some of them literally -- by blathering nonstop about the virtues of the OS. So what else is there? Do I need to start writing documentation or publishing and pimping more Howtos on the intarweb? Should I brush up on my C and start patching? And therein lies a problem. The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Except, when Matt Dillon did submit, he was told to back out his changes and then lost his commit bit. This was because there was an imminent commit due from somebody working on SMP, which still isn't finished really. As for users, sysadmins, people who through advocacy go about sourcing funding, sponsorship, support? They don't matter. It's the first time I've seen a software project where users are almost actively despised. Sometimes I get confused and think I must be reading an OpenBSD list instead - that's how they do it over there, and that's why I haven't run OBSD for 4 years. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. Who cares about users? This is their project after all. And yeah, people will think I'm trolling, but I'm not. I'm just not happy with the way non-programmers are treated. My perogative, but as the project is defined as being a group of developers, it's not my project and therefore my opinion is worthless. Ask yourself this: What is the core goal of the FreeBSD project? To produce the best in it's class? Best for who? Developers? Are you a developer? Maybe it's not the OS for you then unfortunately. Personally, unless the madness around SMP, the 5- branch and various other bits are ironed out, I can see my next server deployment making use of DragonFly. At least they listen to people who don't submit patches due to the limitations of time/skill/whatever. No, I'm not a Matt fan - I like and respect most on -core and others. I just think 5- has got... well, it's all a bit out of hand really, isn't it? All they had to do was ask a few sysadmins and end users what they thought. All of this could have been avoided nearly 2 years ago. Just my tuppence worth, which few are interested in, but ho-hum. -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Wes Peters wrote: People who hate rarely require rational reasons for hating. Attempting to apply logic to that which is not logical is not likely to produce useful results. Incorrect. Everybody who hates believes they have a rational reason for doing so. That others do not think that those reasons are rational is why hatred increases, and why ultimately, Europe has, on the whole and recently (last 60 years) in a more fragmented fashion, spent the last 2,000 years at war. But that's another issue. Advocacy is important only if you want to conquer the world. Brett apparently does; many of us just want an operating system that meets our needs, and don't particularly care what somebody else uses. IMO, casual 'desktop' or 'laptop' computer users are probably better served by Mac OS X than anything I want to turn FreeBSD into, which is why my 68 year old father is a Mac owner. And that's all well and good. But if you don't consult end-users in general, you're going down a slippery slope. Do not be suprised if after years of hard work when you finally -RELEASE, if the world of end-users sidles up to you at the launch party and whispers in your ear You realise what you've produced is a pile of shit, right? - you never listened to what they wanted, and so not suprisingly you missed it. If you don't have a set of aims to measure by, it's oh so easy to claim success when all the outsiders think you've spent too much time on the crack pipe. All I'm suggesting (and no, I'm not the troll, but I'd thank him, whoever he is), is that maybe the Theo de Raadt school of thought that only developers count is not a grown-up, mature and efficient system of software development when we all have definite goals in mind. Nobody is asking anybody to work for free. I'm suggesting that non-developers can assist developers in refining the project's goals, aims, direction and make sure that the work the developers carry out is the best possible. -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Where is FreeBSD going?
-Original Message- From: Wes Peters [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 11:23 AM To: Munden, Randall J; Brett Glass; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Where is FreeBSD going? On Tuesday 06 January 2004 09:05 am, Munden, Randall J wrote: Honestly, I picked up the troll thread because I'm curious as to why someone would commit so much time in effort to trolling these lists. In my experience it's a good idea to explore the reasoning behind that type of dedication (faulty or not) for no other reason that discovery. On-the-other-hand some people accuse me of being obsessive about information. /me shrugs People who hate rarely require rational reasons for hating. Attempting to apply logic to that which is not logical is not likely to produce useful results. Correct. s/reasoning/root cause/ That's what I intended. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 5 Jan, Brett Glass wrote: It's probably one of the Slashdot BSD is dead trolls. The fact is, though, that there ARE things about FreeBSD that could stand improvement. These days, when I build a box, I am torn between using FreeBSD 5.x -- which is not ready for prime time but is at least being worked on actively -- and using 4.9, which isn't as stable as it should be because the developers broke the cardinal rule of making radical changes to -STABLE. This *is* a real issue for those of us who are admins. The worst breakage of 4-STABLE in recent memory was the PAE commit, which I got the impression was driven by end-user demand. Probably folks who had expensive systems with 4GB of RAM who wanted to be able to run 4-STABLE production systems and make use of all that RAM right now and not wait for 5.x to become production-worthy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Tue, 6 Jan 2004, Paul Robinson wrote: And therein lies a problem. The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. While it's clearly the case that many people have met with the submit a patch response, that's probably more a property of time constraints from developers than a lack of desire to work with users to produce a system users want. Many FreeBSD developers find FreeBSD of particular appeal because it gives them a chance to produce a system they've always wanted to use: one that addresses the frustrations of many other systems out there. For example, a fair number of FreeBSD developers have their time funded by Internet Service Providers who appreciate the scalability, performance, and mangeability of FreeBSD when deployed on tens of thousands of machines. They bring changes to FreeBSD regularly reflecting those needs. Many FreeBSD developers do hang out in the public IRC channels and try to answer questions, hang out on questions@, stable@, etc. Sometimes, you post a question and get the answer That doesn't work yet, but we're looking for a few good developers..., but frequently, you also get a patch and If you could try this and see if it helps with your problem... Obviously, the harder question you ask, the more likely you'll get We're looking for a few good developers... :-). The marketting department of Microsoft may be able to keep their less user-friendly developers from talking to their users, but many people would argue that one of the greatest benefits of open source is increasing that communication, even if it means the unwashed developers talk to real people once in a while. A great many developers pick FreeBSD to work on because they're quite aware of what users of other systems have to deal with, and want to produce a system people can use. But no one is paying the bills for hand-holding, so unless people step up to do the hand holding (thanks greatly to those who do!) it's not going to happen. We'd appreciate your help in making it happen, if that's something that strikes you as done wrong or poorly. As with any commercial software development enterprise, we also have limited resources, but unlike a commercial software development enterprise, we can help involve a much larger community in building and supporting a product. Personally, unless the madness around SMP, the 5- branch and various other bits are ironed out, I can see my next server deployment making use of DragonFly. At least they listen to people who don't submit patches due to the limitations of time/skill/whatever. No, I'm not a Matt fan - I like and respect most on -core and others. I just think 5- has got... well, it's all a bit out of hand really, isn't it? The reality is that operating system development takes a lot of time, energy, and expertise. We can't pull a next generation operating system out of hats overnight -- it takes literally hundreds of man years of work to do. It's not something one, three, or even ten people can do alone. FreeBSD 5.x remains a work in progress, but has made a lot of progress in the right direction. I think what you think of as madness is a necessary step on the path of a major engineering project. I can't think of any major project I've seen where at some point, people haven't taken a pause for a breather saying Oh my god -- what have we gotten ourselves into. On the other hand, I think referring to it as madness dismisses years of hard work by a great many competent and dedicated developers. A year ago, M:N threading was extremely far from productionability -- today, it's on the cusp of being there, with higher performance and increasingly high reliability. It's almost ready for 5-STABLE. There's substantial on-going work on SMP, with a huge investment of time and energy into the network stack, VM system, VFS, process support, scheduling, etc. These are areas where the primary feedback today is going to be stability and performance, and believe me, we're listening. All the FreeBSD developers I correspond with regularly run FreeBSD 5 on their desktops, on their servers, in their appliances, etc, to make sure we keep shaking out problems. Many companies have production products based on 5.x, and their feedback (and contributions) have been valuable. We've also invested substantial efforts in areas like compiler toolchains, standards compliance, not to mention new features. 5.x is, at long last, starting to land; it will take about one more minor version number to get there, we believe, but it is in dramatically better shape than it was a year or two ago. As I said above: writing operating systems isn't a small task. Companies invest tens (hundreds) of millions of dollars writing and maintaining operating systems, and (net across developers, if you actually bill for the volunteer
Re: Where is FreeBSD going?
At 20:31 06/01/2004, Mark Linimon wrote: There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. Speaking of which... if there's one thing which could be done to improve committer / non-committer relations, it would be to *do* something with all those PRs. The ports team is pretty good -- my maintainer updates have always been committed fairly quickly -- but I've never had a src patch committed without badgering committer(s) about my PRs. Don't misunderstand me; I think the project is heading in the right direction, and committers are doing a great job. But I think the contributions of non-committers could make FreeBSD even better, and those contributions are being largely lost or ignored. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] Paul Robinson [EMAIL PROTECTED] writes: : Except, when Matt Dillon did submit, he was told to back out his changes : and then lost his commit bit. This was because there was an imminent : commit due from somebody working on SMP, which still isn't finished : really. You mischaracterize the situation badly. Dillon lost his commit bit because he didn't play well with others. The deeper technical issues aren't as cut and dried as you make them sound. Dillon's contributions, while interesting in their own right, wouldn't have completed SMP. And the specific point of contention has been finished now for at least 6 months. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
I just have one comment... who gives a shit. Let this useless thread die. William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Brad Knowles wrote: Define us. You sure as hell aren't speaking for me. Accepted. It came from [EMAIL PROTECTED] and therefore can only represent my own opinion. But I know a lot of people who are looking at deploying 5- who aren't just pissed off - they're *scared*. I don't think many of the developers understand this. To us (yes, I'm not speaking for Brad Knowles), FreeBSD is not a project we spend our spare time on and love and adore. Well, it is, but it's also a lot more. It defines our careers. We roll out something that isn't quite right, our jobs are finished. Right now, if somebody asks me what our roll-out strategy is for the next 18 months, I have to respond don't know, whereas the Linux guys are just laughing... don't even start me on what the Windows guys are doing to my career right now OK, so it has got personal... I accept it is not the FreeBSD development team's job to look after my career, and to date I've looked after that by myself OK, but all I'm asking is you try and at least understand where some people are coming from on this. If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. If you have a set of skills that you think could be useful, please contact Mark or one of the other members of -core to find out how you might be able to contribute to the project. Mark has mailed me off-list. His tone isn't great. I probably deserve the Fuck off. Go away. I'l deal with that seperately. :-) I have the greatest respect for Matt, but he has been a serious problem for the project for a long time. His technical disagreements with other members of the project are just one relatively minor aspect of those problems. His personality has been a much bigger issue. OK, I've never run into that. Over on the DragonFly stuff, he seems pleasant enough and his ideas are innovative, strong, if sometimes... *cough*... eccentric (e.g. replacing sysinstall with an Apache server and a load of PHP...), but I'll accept I haven't seen that, and I know others have had their problems there. I did see the fall-out on these lists with the argument that caused it all to kick off about a year ago though, and I don't think others on the project dealt with him (in public at least) fairly. Again, just my opinion, I wasn't involved, don't know what happened in private. If you want to feel like this is your project, then you need to find a way to take ownership of some part. See above. Ooooh, no. That isn't what I want at all. I just want end-users to feel they have a voice. That's all. Maybe they do, and I don't see it. Maybe they don't *and that's for the good for the project* but in my opinion, it just seems odd. Please let us know how it turns out. Actually, no, I suspect 4.9 will keep me going for at least another 18 months, by which point hopefully 5- stable will be back where everybody wants it. In fairness, tonight, I was sat at a BSD User Group meeting in front of my laptop with a fresh copy of 5- and I (for one reason or another) was digging around and found a copy of the 5- roadmap article in /usr/share/doc which I hadn't read in a long time. I honestly wish I'd read that before posting my last mail to this list. An apology of sorts is due, and you may have it. Sorry. And yes, I was having a bad day, and my tone was rotten to those of you who put so much time into FreeBSD, and all I ask in future is that you realise that some points about bitrot, bloat, bad performance and a lack of *feeling* the end user gets heard is enough to cause real problems for a lot of people. -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 20:31 06/01/2004, Mark Linimon wrote: There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. Speaking of which... if there's one thing which could be done to improve committer / non-committer relations, it would be to *do* something with all those PRs. The ports team is pretty good -- my maintainer updates have always been committed fairly quickly -- but I've never had a src patch committed without badgering committer(s) about my PRs. Don't misunderstand me; I think the project is heading in the right direction, and committers are doing a great job. But I think the contributions of non-committers could make FreeBSD even better, and those contributions are being largely lost or ignored. Exactly. I've filed PRs that have languished for months, and then after picking some random person from -current or -stable, the patches in the PR get committed within a week. I'd imagine that there's a lot of PRs that get dropped because they sit for 6+ months and then the submitter can't be found or cannot reproduce the situation. I think the problem is that too many commiters are focused on their own corner of the project, and there's nobody left to handle all the general sort of PRs. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Mon, Jan 05, 2004 at 01:52:50PM -0700, Brett Glass wrote: FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their sandbox. So, some of the criticism is actually valid. Advocacy is NOT a race or a popularity contest. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Where is FreeBSD going?
This makes me wonder if it isn't time for a new -core. -Original Message- From: Maxim Hermion [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Where is FreeBSD going? I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of glue that binds FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat. The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain unless someone is willing to pay for my time (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past. Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically). If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about). You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid glee club that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few others), although I find his method of expressing it extreme, I often wished he'd have just visited the offenders personally with a clue bat. All in all, history will judge if -core has made the right decision. I personally believe it was a decision made in weakness. The loss the project as a whole will suffer is greater than the bruised ego's the -core has had to deal with in its communications with Matt. Matt was an extremist, but he put up or shut up. I wish I could say that for most of -core. This is a personality confict in a technical project. I'd say that most of you take this just as personally as Matt did, but instead of insulting him in a moment of anger, you shoot off
