Re: Annoucning DragonFly BSD!
I'm doing a build world of dragonfly now, this is definately not vaporware, or a troll. what they are doing could open up several new and interesting areas for bsd. While it's true that most branches of the bsd tree have occured over people issues. This one looks like it will stand on technical merit alone. Nobody could of made the changes that have been made to the kernel in a space of a month to the big tree. and multiple ways of looking at the same problem is a good thing. That defines CS and that is what the BSD'S have always been at there heart. Rob --- Matthew Dillon [EMAIL PROTECTED] wrote: : anyway, not our Latin alphabet ] effort, a dubious idea to divide : the number of shoulders that load sits on. There's already another : cross platform ports project anyway (Freshports?) : - A new distribution mechanism (whatever) ? maybe - but again : if better, that technology should be adopted merged into other BSDs. : : http://www.dragonflybsd.org/ may be a just a troll erection, it's : constructed so there's nothing real to see. A troll site ? No : where to click sample code inside browser, you'd have to cvsup : extract localy to check real code. No interest until others confirm real. : :you missed the entire source tree? look again.. :and I doubt that a troller would have redesigned the entire kernel :to make a troll and made it work.. if he did we should invite him in.. Yes, that would be some trick, considering that the unified diff between my tree and -stable is over 347,000 lines long! Sheesh, I guess I really *do* have to get cvsweb up and running for people to believe it, ftp and cvsup apparently aren't enough! : :it's himm.. believe it.. I don't understand, do some people not believe that I am heavy-weight kernel programmer? GRIN I mean, sheesh, this reminds me of my old Commodore PET days, when I wrote a centipede game entirely in 6502 machine language and submitted it to cursor magazine for publication. They declined, I think because they didn't quite believe that a 14 year old kid could *do* that. It was a damn fine game, too, the last level featured an invisible centipede who only turned visible for a few seconds when you hit one of his segments. : ( Julian Stacey [EMAIL PROTECTED] ) : The logo is useless ( a troll give away ?): Useless! You try staring a three inch long DragonFly in the face for half an hour! It was fate is what it was, that Fred was so photogenic because it took about 20 shots before I got him framed and focused properly and he basically refused to budge despite my comings and goings, only occassionally startling, flitting around the yard a bit, and then landing right smack back on the same frond he had just taken off from. : There's too many BSD's already. More complete BSDs aren't of : personal or business benefit. More kernels, tools, experiments : in ports/packaging etc could be useful though, but to be of most : benefit such work should be fully integratable, not further split : the available BSD workforce. : Julian Stacey Freelance Systems Engineer, Unix Net Consultant, Munich. : :Well if you take away his commit bit treeat him unfairly, what other :choice does he have? Well, I don't really care about that, but this points to an interesting dichotomy in the perception of people who use open source and of people who write it. I don't know about other open source programmers but my motivation is interest and invention. It has nothing at all to do with towing some imaginary line. Why should it matter what operating system base I choose? If Linus felt that way he would never have started Linux. It is a concept that non-programmers like to banter about on forums like slashdot but it is utterly meaningless to most of the people that do the actual programming. There is responsibility, yes, but it is an effect rather then a cause. History is filled with underdogs winning against the behemoths against all apparent odds, and turning into behemoths themselves only to be displaced by the next underdog when their little clique starts believing in its own immortality. As a programmer who has gone through several generations of operating environments I don't believe in the immortality of anything, least of all FreeBSD or Linux, or my own code. But it doesn't stop me from working my favorite project on my favorite platform, whatever that happens to be. Ultimately the only thing that survives history is the invention and the concept, and memory. If people can see that a concept works and go and implement it in their own favorite environment then that counts as a success and another notch on my sleave regardless of anything else. If people can
Re: tcpdump delay?
On Wed, Mar 19, 2003 at 11:06:10AM +0100, John Angelmo wrote: I needed to do some tcpdump from my box on the rl0 interface. The IP was changed to one that dosn't match our network and I noticed that everything had a 3 min delay(both traffic in and out from the interface), my current build is from yesterday and the box didn't have any heavy load. As soon as I changed back to my standard IP everything worked fine, but still a 3 min delay seems odd. /John tcpdump -ln -l kills buffered output, i.e. waiting for a large amount of data before it starts writing -n tells us not do lookup each ip.. should help rob To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
source upgrade broken?
Gentleman, Please correct me if I am wrong but it appears, that the source upgrade path from 4.* to 5.0 is broken. I havent played with it much but it appears thatbuilding the kernel, depends on somethings new to the -current compiler, and the compiler is dependant on stuff in the 5.-current kernel. I realize that with all the stuff thats been ripped out of 5.0 and added, that a clean install is probably the best way to go. I am just curious if it truly is borked or if it is just me. Robert Garrett To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: source upgrade broken?
On Mon, Mar 17, 2003 at 03:10:08AM -0800, Doug Barton wrote: Are you guys precisely following the instructions in src/UPDATING? most definately, the new compiler depends on new syscalls in the kernel, and the kernel depends on new options in the compiler. I could not find anything about this situation in UPDATING. I'm doing a fresh checkout of the -current tree while I'm writing this. I believe the procedure I followed was cvs co src -t . gperf rebuild bombed due to missing includes.. went ahead and tried make buildworld bombed on tar is a directory during the clean phase.. wasted my obj directory.. rm -rf /usr/obj cd /usr/src make buildworld and bombed on rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o update.o tar.1.cat rm: tar: is a directory *** Error code 1 this is of course todays current as of 5:30 a.m CST Rob On Mon, 17 Mar 2003, Scott Sipe wrote: I second that problem. Tried doing an upgrade yesterday, and it didn't work--missing libc.so.4 error given during make installworld. Scott - Original Message - From: Robert Garrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 16, 2003 3:53 AM Subject: source upgrade broken? Gentleman, Please correct me if I am wrong but it appears, that the source upgrade path from 4.* to 5.0 is broken. I havent played with it much but it appears thatbuilding the kernel, depends on somethings new to the -current compiler, and the compiler is dependant on stuff in the 5.-current kernel. I realize that with all the stuff thats been ripped out of 5.0 and added, that a clean install is probably the best way to go. I am just curious if it truly is borked or if it is just me. Robert Garrett To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: source upgrade broken?
On Mon, Mar 17, 2003 at 07:51:34AM -0800, Brooks Davis wrote: On Mon, Mar 17, 2003 at 07:44:02AM -0600, Robert Garrett wrote: On Mon, Mar 17, 2003 at 03:10:08AM -0800, Doug Barton wrote: Are you guys precisely following the instructions in src/UPDATING? most definately, the new compiler depends on new syscalls in the kernel, and the kernel depends on new options in the compiler. I could not find anything about this situation in UPDATING. I'm doing a fresh checkout of the -current tree while I'm writing this. I believe the procedure I followed was cvs co src -t . gperf rebuild bombed due to missing includes.. went ahead and tried make buildworld bombed on tar is a directory during the clean phase.. wasted my obj directory.. rm -rf /usr/obj cd /usr/src make buildworld and bombed on rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o update.o tar.1.cat rm: tar: is a directory *** Error code 1 this is of course todays current as of 5:30 a.m CST You need to either do your checkouts with the -P (prune) option or do an update afterwards with it (i.e. cvs update -d -P) so tar isn't bogusly a directory. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 Yes, I forgot the -P option for cvs, and I also used the old method of building a kernel, using the make buildkernel option apperantly has corrected the issue that I was having, ... old habits die hard :).. Rob To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Patch to improve mutex collision performance
Could someone tell me where documentation concerning the use of perforce and or, how to gain access to is located? Up until very recently I was not aware of it's existence. This would make it very difficult for someone new to the Project to contribute. It seems to my line of thinking that the existence of a repository That is undocumented, that is used for major development proccess's Breaks our development model. Further enhancing the Elite attitude that is so often proscribed To BSD* developers. Robert Garrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jochem Kossen Sent: Thursday, February 21, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Patch to improve mutex collision performance On Thu, Feb 21, 2002 at 10:36:39PM +0100, Dag-Erling Smorgrav wrote: Miguel Mendez [EMAIL PROTECTED] writes: Well, if all developers started using p4, things would be easier and work better in the long term. p4 is lightyears ahead of cvs, and, from what I've read in this thread, developers are not exactly happy with cvs now, as it's limitations have become evident. Perforce also has limitations. It does a number of things better than CVS, and a number of things worse. Its main problem, IMHO, is that it tries to do too much, at the expense of basic functionality. As it seems people are forming a list of cvs alternatives, anyone ever took a look at arch? http://regexps.com/#arch A buddy of mine just mentioned it, and it seemed to fit in this discussion, i don't know it myself though. It's covered under the GPL. Jochem To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: simple (but important) task for junior kernel hacker
On Wed, 12 May 1999 at 10:04:09 +0200, Poul-Henning Kamp wrote: I don't have time just now to attend this particular detail, which manifests itself by swapinfo/pstat -p showing /dev/(null) for device name. The problem in short is that libkvm:kvm_getswapinfo.c has it's fingers in the kernels memory and pulls out a dev_t without knowing how to (and it shouldn't be taught this!) convert it to a udev_t. The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c to pick up the information using some (for this purpose constructed) sysctl variables (sysctlbyname(3) please!), and let the kernel convert the dev_t to udev_t before passing it out to userland. So for any aspiring kernel hackers out there: have at it. Patches accepted. In general libkvm should not grovel around in a running kernel but only use sysctlbyname(3). -- the only place in the entire libkvm where a dev_t is used is kvm_proc.c line 230 this particular section completely looses me Rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: simple (but important) task for junior kernel hacker
On Wed, 12 May 1999 at 10:38:41 +0200, Poul-Henning Kamp wrote: In message 19990512033344.e21...@phc.igs.net, Robert Garrett writes: On Wed, 12 May 1999 at 10:04:09 +0200, Poul-Henning Kamp wrote: I don't have time just now to attend this particular detail, which manifests itself by swapinfo/pstat -p showing /dev/(null) for device name. The problem in short is that libkvm:kvm_getswapinfo.c has it's fingers in the kernels memory and pulls out a dev_t without knowing how to (and it shouldn't be taught this!) convert it to a udev_t. The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c to pick up the information using some (for this purpose constructed) sysctl variables (sysctlbyname(3) please!), and let the kernel convert the dev_t to udev_t before passing it out to userland. So for any aspiring kernel hackers out there: have at it. Patches accepted. In general libkvm should not grovel around in a running kernel but only use sysctlbyname(3). -- the only place in the entire libkvm where a dev_t is used is kvm_proc.c line 230 this particular section completely looses me There is a dev_t passed out to pstat -s in a datastructure. Right and thats where it comes from kvm_proc.c is responsible for dealing with pstat at least the way I read that file Rob -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
