[Fwd: Re: Anybody actually using gigabit ethernet?]
Josef Karthauser wrote: Couldn't it read: tcp_extensions=NO # Switch RFC1323 extensions on? How about: tcp_extensions=NO # Set to Yes to turn on RFC1323 extensions That would match existing style and be a lot more clear. I can submit a PR if anyone thinks that's really necessary... Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Version 1.23 of mergemaster available for gamma test
Greetings, Since several of the people who've asked for changes to mergemaster are on this list I thought I'd give y'all first crack at the new version. I've incorporated the suggestions I've received over the last 6 months, including a fix for the dreaded PAGER problem. You can retrieve a production-ready version by doing: 'fetch http://home.san.rr.com/freebsd/mergemaster-1.23.tgz' I would appreciate it if those of you using freebsd 3.x or -current would give it a go since I don't think I'll get my test system updated before the ports freeze (on the 10th, yes?). Of course, comments and suggestions are welcome. Selected comments from my RCS log are below. Enjoy, Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' revision 1.23 move mm_install function declaration out of the loop, duh add pwd_mkdb reminder if user installs new master.passwd revision 1.22 rm the temp versions of /etc/spwd.db /etc/passwd and /etc/pwd.db before the comparison starts since comparing them is bogus anyway revision 1.21 fix the order of the PAGER tests add listing of files only in /etc to -v option revision 1.20 skip the umask test if it's an autorun since we won't be installing anything revision 1.19 Fix some style nits Add fatal error for the case where any part of make'ing /usr/src/etc fails revision 1.18 Fix problem of PAGER not in PATH To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Question on 2.2.8 - -current upgrade procedure
I've been doing some reading and I think I have a grip on what I need to do to go from 2.2.8-Release to -current on my scratch box. Please check me and let me know if I've got it right: 1. Install 3.1-Stable sources 2. make upgrade 3. make world 4. make new kernel 5. reboot 6. Install -current sources 7. make world 8. make new kernel 9. reboot Now, the main question I have is, at what points do I want to upgrade /etc? I ask both for my own edification, and for the purpose of testing the new version of mergemaster. I generally upgrade /etc/ before I make world (after backing up of course) so I'm guessing I want to do it between #2 and #3, and again between #6 and #7. TIA, Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How stable is -current?
First off, let's assume that I'm aware of all the traditional caveats re -current being bleeding edge, read the lists, etc. and am willing to deal with that. Now let's assume that I am trying to convince the powers that be at work to use freebsd for an upcoming CGI server project. Here is a relatively precise quote from the boss, I think what we're going to do is set up a box with dual 500's and put linux on it because vendor of one of our proprietary CGI solutions says that their stuff runs best on linux, I think because of the disk access or something like that. So the most important things I need to know (in no particular order): 1. In general how stable is -current? I know it goes through periods of instability, but assuming that I'm following the lists and know when not to build, could I put a 4.x box up and not be embarrassed? 2. Our architecture is *highly* dependent on NFS. I know that the good work on NFS is happening in -current, which is why I'm considering it. How well does -current NFS mix with an almost all-Sun network? Any plans on MFC'ing the NFS fixes to -stable? 3. How good and how stable is SMP currently, and does -current offer any big advantages over -stable in SMP? 4. How about other new features, like soft updates and vinum? Any other words of advice would be greatly appreciated. My experience says that a linux box won't handle the load that we're going to put on it, so if I can come up with something that works and outshines linux I earn points for me, and the project at the same time. If on the other hand, it chokes, errr... that'd be bad. :) I have a scratch box at home that is completely blow-up-able, so putting in the time to make it work is not a problem, I just need to know where to start. TIA, Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How stable is -current?
Greg Lehey wrote: I know it goes through periods of instability, but assuming that I'm following the lists and know when not to build, could I put a 4.x box up and not be embarrassed? Yes, but that's a big assumption: assuming everything went OK. How do you known in advance whether you're not going to find a bug which eats its way, termitelike, through your file systems, and one day you look at the machine and it just falls into a heap of dust on the floor. *Chuckle* Great visual. Of course, odd surprises are not completely unexpected in any freebsd branch, and of course I do plan to take appropriate measures to protect our customer's stuff. The system I'm planning to design will require read-only access from the CGI box to the rest of the world, and almost everything on the box itself will be redundant data anyway. This will be true regardless of what platform we use, so I think this is a unique opportunity to test -current in a relatively pain-free, high load environment. At the same time, I would prefer that it's not crashing regularly because it's my potatoes in the sling, so to speak if I convince them to use freebsd. 4. How about other new features, like soft updates and vinum? Vinum is available in -STABLE as well. It's the same code. I thought that soft updates were also pretty stable. Ok, thanks for the info on vinum. If I'm going to make this work I need to show disk access as good or better than linux, so I'm looking for every edge. What I'm hearing here is that you want to go to -CURRENT because of NFS. Yes, exactly. The other factors you mentioned aren't significant to me, I'm quite familiar with traditional freebsd development cycle instability. :) INRE Jordan's comments about moving the -current NFS improvements to -stable, obviously I'd rather run -stable in a production environment, so assuming we can get a patchset together I could do some testing of that at home since I have two boxes now. My understanding from what I've read was that the changes depended on some architectural improvements in -current that couldn't (easily) be ported back, but I'm still way behind on mail, so I am probably not all up to date on that. However I can't emphasize strongly enough how much our system depends on NFS. Whether that's a good thing or not isn't for me to decide, I just work there. :) I must say though, working in an all-Sun environment it's easy to get used to how easy NFS makes things. I'm starting to feel the same way about samba since I set it up on my home network. Thanks very much to everyone for the responses, they were very helpful. If anyone else has comments or suggestions I welcome them of course. Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How stable is -current?
Matthew Dillon wrote: The only major bugfixes that have not been backported from -current to -stable in regards to NFS are the NFS/TCP fix, which is being backported now, and a number of fixes to the VM system when dealing with mmap(), which cannot be backported until we backport the entire -current VM system. Ok, that's good news. I'd like to stick with -stable if I can. No pressure, but do you have an ETA on the VM backport? I'm assuming that something like that is down the road, probably after 3.2? The mmap() breakage is unavoidable in -stable but hopefully will not cause serious problems for people. The breakage is related to garbarge showing up in the mmap()'d pages *after* the logical file EOF. That is, if you have a 500 byte file and mmap() it into a 4K page, data occuring after offset 500 may or may not be 0. Hrrrmm... ok. So what could happen due to this bug, and how would I spot it? Meanwhile I'll keep an eye on the commits for that NFS backport. Thanks muchly for the update. :) Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Simple DOS against 3.x locks box solid
m...@seidata.com wrote: On Thu, 4 Mar 1999, Chris Costello wrote: Add /etc/login.conf restrictions if you don't want your users to do that. Speaking of which... I've always used login.conf to set limits for specific user classes... However, it seems like some login.conf options just don't work. Is there a place I can get detailed information on login.conf (other than the man page) telling what options are implemented, and which ones are not? The source is your only guide unfortunately. Several people have promised to do a comprehensive list and update the man page, but no one has come through yet. If you do the research please share your results. :) Good luck, Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mergemaster should be merged in to the main tree.
Jaye Mathisen wrote: This utility is too valuable for all the update not to at least have a mention of it. Thank you. :) The occasional compliment makes the hard work worthwhile. At the very least, references should be made to it in /usr/src/Makefile as part of the conversion process, and inthe /usr/src/UPDATING file. I wouldn't object to it being publicized more than it is.. I don't have a /usr/src/UPDATING file though, is that something new in 3.x? I would be willing to get permission from the author if people think it's a good idea. *Wave* I don't think putting it in the base is really feasible, since the chances of me getting commit privileges to do that are very small. :) Besides, I would much rather see the installation routine modified to include various things from the ports/packages tree rather than continuing to add (arguably) non-critical things to the base. There are a lot of people who install FreeBSD who don't upgrade very often, and to them something like mergemaster would be bloat. What I'd like to see is a section of sysinstall that asks what the user is going to do with freebsd, and suggests some packages to install. E.g., Are you planning to upgrade your system on a regular basis? Ok, here's some things you should install, like cvsup, mergemaster, etc. Doug -- *** Chief Operations Officer, DALnet IRC network *** Like desperadoes waiting for a train . . . To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
