RFC: newsyslog enhancements
I've put a tarball of my enhancements to newsyslog on http://www.freebsd.org/~hm/newsyslog.tar.gz The differences to the in-tree versions are: - ability to archive rotated logfiles into a separate configurable directory - provide another method (in addition to the ISO 8601 format) of specifying log rotation times, i.e. it is now possible to specify rotate at the last day of every month at midnight or rotate every week on Sunday at 23:00 hr - much clean up source, run through bde's KNF filter The changes have in part or full already been reviewed by Sheldon Hearn and Gary Jennejohn. This version of newsyslog runs on several production (3.4) machines since November 3, 1999 without problems. If there are no strong objections, i'll commit it to current. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD on PowerPC?
Robert Withrow schrieb: Don't see anything about this on the web page. Is there any activity/interest in porting FreeBSD to the PowerPC, and in particular to embedded (non-MAC) systems? I've been pinging "core" people about this but haven't seem to teak their interrest. I gather that BSDI has a powerPC port, but I'd rather use the FreeBSD codebase rather than theirs, for a number of reasons. Perhaps if just select portions of there code were used it would be OK. When a PowerPC port starts, I can contribute some work. Got some idle Power macs sitting in a shelf. Anyhow, my level of experience is limited. I can do compiles and patches, as well as do some limited bugfixing, but don't count me in as Unix expert. -Christoph Sold P.S: Apologies if my Netscape mailer misbehaves again... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tiny GENERIC patch
At Wed, 29 Mar 2000 09:55:45 +0200, Sheldon Hearn wrote: On Wed, 29 Mar 2000 09:22:11 +0200, Johan Karlsson wrote: I have just submitted a 'follow-up' to the PR with this info. Are you sure you sent mail to [EMAIL PROTECTED] with "kern/17536" on the subject line? I can't see any follow-up on the PR. :-( No I did not think at all and replyed to the mail I got back from [EMAIL PROTECTED] :-( Should I re-send it or will it show up anyway. /K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tiny GENERIC patch
On Wed, 29 Mar 2000 11:22:48 +0200, Johan Karlsson wrote: Should I re-send it or will it show up anyway. Re-send to [EMAIL PROTECTED], taking care to preserve the "kern/17536" on the subject line. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
OpenBSD says it has optimised kernel fdalloc. Is this relevant for FreeBSD
I was browsing through the OpenBSD changelog http://www.openbsd.org/plus.html and came across a line which said optimised kernel fdalloc which pointed to this URL http://www.usenix.org/publications/library/proceedings/usenix98/full_papers/banga/banga_html/banga.html Is this relevant for FreeBSD ? Regards, Yusuf -- Yusuf Goolamabbas [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tiny GENERIC patch
At Wed, 29 Mar 2000 11:26:22 +0200, Sheldon Hearn wrote: On Wed, 29 Mar 2000 11:22:48 +0200, Johan Karlsson wrote: Should I re-send it or will it show up anyway. Re-send to [EMAIL PROTECTED], taking care to preserve the "kern/17536" on the subject line. Done I have also seen the follow-up using the wed interface. /Johan K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD says it has optimised kernel fdalloc. Is this relevant for FreeBSD
In message [EMAIL PROTECTED], Yusuf Goolamabbas w rites: I was browsing through the OpenBSD changelog http://www.openbsd.org/plus.html and came across a line which said optimised kernel fdalloc which pointed to this URL http://www.usenix.org/publications/library/proceedings/usenix98/full_papers/banga/banga_html/banga.html Is this relevant for FreeBSD ? The problem: yes, the solution: maybe. Other people have worked on an eventqueue based solution. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Killing threads
Can anyone coment on the below with authority? I'm learning a bit about threads and I'm curious what the answer is. Thanks, rus --- "Vladimir Butenko, Stalker Software, Inc." wrote: Stefan Seiz [EMAIL PROTECTED] wrote: [snip] To have it kill unneeded threads? It will kill "excessive" threads. AFAIR, it will start to kill if the unemployment level is more then 1/3: if a thread finishes a job and the number of unemployed threads waiting for a job is more than 1/3 of the Max number of threads(channels) allowed for that service, the thread is not placed into the wating pool, but is killed instead. Is this recommended? That depends on OS. Killing threads is a dark area in many thread implementations. We know that it is safe on Windows, Solaris, and looks like safe on MacOSX. On other platforms - use on your own risk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anybody have tools to read a Digital Unix vdump tape on FreebSD?
Does anybody know of tools to read a Digital Unix "vdump" tape on FreeBSD? I have a number of such tapes, and would prefer to read them on an (Intel) FreeBSD box instead of having to reinstall DU on a machine which has had its disks wiped. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
obviously not the one that has the error. Are you paying attention? You really are an arrogant prat aren't you. How do you know it's the same one? Have you asked him? Let me guess.. you're *assuming* aren't you. Wait, so we were talking about the "newer" intel boards not being fully supported in the fxp driver and this drubb chimes in with "Im using an eepro with no problems"clearly that isnt relevant, since on-one along the line ever said that all intel cards didnt work. So, it is clear that you too are not paying attention, yet you seem to have an opinion regarding things that you also know little about. Dont browbeat me for putting down some dope who doesnt know what hes talking about who feels compelled to voice an opinion based on ignorance. What is really funny is that, as usual, all of the people who feel compelled to make comments about me are not experiencing the problemits real easy to pick on someone when the issue doenst effect you. Meanwhile, the problem is fixed, and scads of people who have experienced the problem are emailing me to thank me for lighting a fire under some butts. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
On Wed, 29 Mar 2000, Dennis wrote: So, it is clear that you too are not paying attention, yet you seem to have an opinion regarding things that you also know little about. Dont browbeat me for putting down some dope who doesnt know what hes talking about who feels compelled to voice an opinion based on ignorance. What is really funny is that, as usual, all of the people who feel compelled to make comments about me are not experiencing the problemits real easy to pick on someone when the issue doenst effect you. So, let me get this right, it's OK for you to be abusive to somebody who has a problem, but the rest of us have to keep quiet. Quite a hypocrite really, aren't you? Time to add some mail filters... -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
Maybe I got lost in the hub-bub, but I am still having trouble getting my onboard NIC to work, still get unsupported phy errors. When you say its fixed are you refering to the patch the DG sent out the other day, or your patch. I applied DG's patch and the problem still exists. And I cant compile my kernel with your patch. Does your if_fxp.c file need to be compiled on a 3.4 system? Because I am running 4.0. In any case I am starting to get real frustrated again. Maybe I am using the wrong patch or something?! -John On Wed, 29 Mar 2000, Dennis wrote: obviously not the one that has the error. Are you paying attention? You really are an arrogant prat aren't you. How do you know it's the same one? Have you asked him? Let me guess.. you're *assuming* aren't you. Wait, so we were talking about the "newer" intel boards not being fully supported in the fxp driver and this drubb chimes in with "Im using an eepro with no problems"clearly that isnt relevant, since on-one along the line ever said that all intel cards didnt work. So, it is clear that you too are not paying attention, yet you seem to have an opinion regarding things that you also know little about. Dont browbeat me for putting down some dope who doesnt know what hes talking about who feels compelled to voice an opinion based on ignorance. What is really funny is that, as usual, all of the people who feel compelled to make comments about me are not experiencing the problemits real easy to pick on someone when the issue doenst effect you. Meanwhile, the problem is fixed, and scads of people who have experienced the problem are emailing me to thank me for lighting a fire under some butts. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How good a job of PCI config will freebsd do?
Question, has anyone tried booting freebsd on raw hardware, i.e. absent a bios? I am curious as to how good a job it can do if, e.g., no enable bits are set in PIIX4, BARs are not set on PCI devices, no IRQs are assigned, and so on. Anyone feel they are close enough to this to say? See www.acl.lanl.gov/linuxbios to see why I am asking. I see no reason I could not also put FreeBSD as the BIOS in nvram as well. If you're trying to build a cluster, you have to kill the BIOS. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Onboard Intel NIC
Dear Dennis, The reason Poul-Henning Kamp threatened to filter you is because you were insulting people (and yes, in response they insult you too). He did not do so because you were critisizing FreeBSD's method of working. Many have done that without getting threatening remarks from Poul-Henning Kamp. In the e-mail that sparked all this, you write two paragraphs. The second paragraph is clear and to the point. The first paragraph is not. Perhaps you could leave out the first paragraph and only send the second next time? Kees Jan == You are only young once, but you can stay immature all your life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
Question, has anyone tried booting freebsd on raw hardware, i.e. absent a bios? I am curious as to how good a job it can do if, e.g., no enable bits are set in PIIX4, BARs are not set on PCI devices, no IRQs are assigned, and so on. Anyone feel they are close enough to this to say? Not good. You'd also have to take care of PCI setup, interrupt routing, any board-specific hacks using the GPIO bits, etc. (eg. on most systems you'll need to turn the CPU fan, power LEDs, etc. on) Doing this without the BIOS is likely to be a major PITA, and different for every single board. Outside of some expensive and boring embedded vendors' products, you're unlikely to get the sort of information you need without reverse-engineering the BIOS that's already there. See www.acl.lanl.gov/linuxbios to see why I am asking. I see no reason I could not also put FreeBSD as the BIOS in nvram as well. If you're trying to build a cluster, you have to kill the BIOS. Well, they're going to have the same basic stuff, and I can see that they're not having much fun trying to get there. I'm curious as to what you mean by "have to kill the BIOS" though; I'm not seeing why it's an issue. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody have tools to read a Digital Unix vdump tape on FreebSD?
On Wed, Mar 29, 2000 at 03:59:52PM +0200, [EMAIL PROTECTED] wrote: Does anybody know of tools to read a Digital Unix "vdump" tape on FreeBSD? I have a number of such tapes, and would prefer to read them on an (Intel) FreeBSD box instead of having to reinstall DU on a machine which has had its disks wiped. Vdump, the dump incarnation for Tru64 AdvFS, can to the best of my knowledge only be read by vrestore. I'm afraid your stuck to using a T64 box for this. -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
At 04:26 PM 3/29/00 +0100, Paul Robinson wrote: On Wed, 29 Mar 2000, Dennis wrote: So, it is clear that you too are not paying attention, yet you seem to have an opinion regarding things that you also know little about. Dont browbeat me for putting down some dope who doesnt know what hes talking about who feels compelled to voice an opinion based on ignorance. What is really funny is that, as usual, all of the people who feel compelled to make comments about me are not experiencing the problemits real easy to pick on someone when the issue doenst effect you. So, let me get this right, it's OK for you to be abusive to somebody who has a problem, but the rest of us have to keep quiet. Quite a hypocrite really, aren't you? No, I never "abused" anyone personally until they abused me. Its called "self defense" in free countries. The thread started: dennis has the PHY problem in the fxp driver been fixed yet? if so is where can i get it? wes peters why dont you just get it yourself - then called me lazy and incompetent DG no, i havent fixed it yet, I've been sick dennis ok, thanks, Thats all I wanted, if I listened to peters I would have wasted all that time on a wild goose chase --- flamed by many Im sorry that lots of folks like to make comments about subjects that dont involve them, but thats part of the public experience. I just wanted to know if the stupid driver was fixed yet. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
On Wed, 29 Mar 2000, Mike Smith wrote: Well, they're going to have the same basic stuff, and I can see that they're not having much fun trying to get there. actually, "they" is "me": that's my project. Yeep. You don't know Fra Dolcini, do you? That looks like a Really Unpleasant Undertaking. 8( I'm curious as to what you mean by "have to kill the BIOS" though; I'm not seeing why it's an issue. Unless you've had to work with 1024 BIOS upgrades, it's not easy to see the need :-) Er. Ok, I can dig that. However, there are only about three or four different flash architectures commonly in use, and we can hope that people are going to start using things like the Intel Firmware Hub, and hopefully EFI later on. I realise that you're not about to throw your cluster hardware over for a pile of IA64 boxes just yet, but it strikes me that it'd be easier just to write a userland flash updater than to rewrite the BIOS from scratch. 8) Nevertheless, I'll drop it here. I was curious what FreeBSD could do. Nothing, I'm afraid. We expect the plaform firmware to work as expected/ documented... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Join up
I would like to join the FreeBSD information group as I have become a newbie FreeBSD administrator for the last severa lmonths. I can be emailed at [EMAIL PROTECTED] or [EMAIL PROTECTED] Thank you To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody have tools to read a Digital Unix vdump tape on FreebSD?
Yeah- and if you fund a public domain version of this, maybe you can also find something to read old DSC or BRU tapes? :-) On Wed, 29 Mar 2000, Wilko Bulte wrote: On Wed, Mar 29, 2000 at 03:59:52PM +0200, [EMAIL PROTECTED] wrote: Does anybody know of tools to read a Digital Unix "vdump" tape on FreeBSD? I have a number of such tapes, and would prefer to read them on an (Intel) FreeBSD box instead of having to reinstall DU on a machine which has had its disks wiped. Vdump, the dump incarnation for Tru64 AdvFS, can to the best of my knowledge only be read by vrestore. I'm afraid your stuck to using a T64 box for this. -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nlThe FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
Maybe I got lost in the hub-bub, but I am still having trouble getting my onboard NIC to work, still get unsupported phy errors. When you say its fixed are you refering to the patch the DG sent out the other day, or your patch. I applied DG's patch and the problem still exists. And I cant compile my kernel with your patch. Your problem is unrelated to the problems that other people were having. I'll work with you privately to narrow it down. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
On Wed, 29 Mar 2000, Mike Smith wrote: Yeep. You don't know Fra Dolcini, do you? That looks like a Really Unpleasant Undertaking. 8( It's getting there. Also SiS is now a supporter. Long term, we may see motherboards specifically designed for the OSS community, with real docs yet. Also, I can't see any way to get to 3-second reboot (one of the things we need) given the stupid way BIOSes work. PXE is not an answer. cluster hardware over for a pile of IA64 boxes just yet, but it strikes me that it'd be easier just to write a userland flash updater than to rewrite the BIOS from scratch. 8) You haven't look at how intel designs and documents some of their motherboards, particularly the L440GX+. They won't tell people what they need to know to update flash on this one. Result: you have to boot DOS to upgrade flash. Stupid of them. Also, there are an amazing number of advantages to having a real OS in the flash. Once you start thinking about it, it becomes hard to live without. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
On Wed, 29 Mar 2000, Mike Smith wrote: Yeep. You don't know Fra Dolcini, do you? That looks like a Really Unpleasant Undertaking. 8( It's getting there. Also SiS is now a supporter. Long term, we may see motherboards specifically designed for the OSS community, with real docs yet. Also, I can't see any way to get to 3-second reboot (one of the things we need) given the stupid way BIOSes work. PXE is not an answer. Having a chipset vendor onside isn't a bad thing, for sure, and I can see where the current design of PC BIOS code wouldn't help. One thing that puzzles me though is why you want to stick with the PC BIOS... cluster hardware over for a pile of IA64 boxes just yet, but it strikes me that it'd be easier just to write a userland flash updater than to rewrite the BIOS from scratch. 8) You haven't look at how intel designs and documents some of their motherboards, particularly the L440GX+. They won't tell people what they need to know to update flash on this one. Result: you have to boot DOS to upgrade flash. Stupid of them. Er, I have, which is why I was observing that what you're trying to do on the larger scale is just a bit masochistic. Also, there are an amazing number of advantages to having a real OS in the flash. Once you start thinking about it, it becomes hard to live without. I'd prefer real firmware, actually. OF isn't all that bad, and I seem to recall that Parag Patel is porting it to run on the L440GX+. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
Mike Smith wrote: I'd prefer real firmware, actually. OF isn't all that bad, and I seem to recall that Parag Patel is porting it to run on the L440GX+. Heh - yup, I'm right in the middle of port SmartFirmware to the L440GX+. Definitely masochistic. I've decided that drilling a hole through my head would be faster with the same results, only with less pain. Anyway, we've had our L440GX+ surgically altered and it's now sporting a Meritec socket in place of the flash part. I've just now ordered a PromICE with trace as the old hit-n-miss techniques to get something out of the serial port from ROM just ain't working. I've come to the conclusion that there is absolutely nothing about PC hardware that is in any way shape or form designed correctly. *Everything* about it is wrong wrong wrong. Don't get me started. The port is progressing. I already have a RAM version of SF running happily, probing devices, booting images off of the net, etc. Getting it bootstrapped out of ROM is the current task. SF always runs in 32-bit `flat' mode, ROM or RAM. Ronald G. Minnich wrote: It's getting there. Also SiS is now a supporter. Long term, we may see motherboards specifically designed for the OSS community, with real docs yet. Also, I can't see any way to get to 3-second reboot (one of the things we need) given the stupid way BIOSes work. PXE is not an answer. Don't know if SmartFirmware will be able to meet the 3-second boot, but it should definitely be faster than a BIOS. For one thing, we don't pretend that we can run an exhaustive and completely trustworthy memory test. :) (Not even sure if this is possible, actually.) You haven't look at how intel designs and documents some of their motherboards, particularly the L440GX+. They won't tell people what they need to know to update flash on this one. Result: you have to boot DOS to upgrade flash. Stupid of them. This is why I'm burning the entire flash part in an external programmer. Once SmartFirmware is running on the motherboard, it'll be able to update and burn new images over the net, including your original one. Bootstrapping will still need a floppy to boot under the old BIOS, run a RAM version of SmartFirmware, download a ROM image over the net, burn it in, then reset. -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
can't install Linux compatibility, or, why RPM isn't our friend
I have been trying without success to install the linux_base package. The install target in the makefile calls rpm to install the RPM-format package files, but the bash package mysteriously fails to install. Turning on debugging for rpm give no useful info. Has anybody seen this? I'm running 3.2-RELEASE, but with an up-to-date /usr/ports. order# make install === Installing for linux_base-6.1 setup-2.0.5-1.noarch.rpm filesystem-1.3.5-1.noarch.rpm basesystem-6.0-4.noarch.rpm ldconfig-1.9.5-15.i386.rpm glibc-2.1.2-11.i386.rpm termcap-9.12.6-15.i386.rpm libtermcap-2.0.8-18.i386.rpm bash-1.14.7-16.i386.rpm execution of script failed error: /usr/ports/distfiles/rpm/bash-1.14.7-16.i386.rpm cannot be installed *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. order# To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Proposed new Bourne shell init files
Still no comment on this, so here's to a wider audience. Doug Original Message Subject: Re: cvs commit: src/share/skel dot.cshrc dot.login src/etc/rootdot.cshrc dot.login Date: Sun, 26 Mar 2000 00:55:40 -0800 From: Doug Barton [EMAIL PROTECTED] Organization: Triborough Bridge Tunnel Authority To: Robert Watson [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] I'm really glad someone is taking a look at this. Please don't take any of my comments as criticism. :) Robert Watson wrote: rwatson 2000/03/25 12:23:40 PST Modified files: share/skel dot.cshrc dot.login etc/root dot.cshrc dot.login Log: o Migrate path, umask from dot.login to dot.cshrc I'm a little confused about moving umask. Doesn't it make more sense in dot.login, since it mostly applies to login shells? Maybe it has some application in non-interactive shells I'm not aware of. o Comment out display of fortune by default. Good move. This made my boss nuts when we started using freebsd at work. o Synch root's .cshrc/.login and non-root's .cshrc/.login in terms of gratuitous variables set (EDITOR). Another good move. FWIW, you have two small gratuitous differences. --- /usr/src/share/skel/dot.cshrc Sat Mar 25 15:23:36 2000 +++ /usr/src/etc/root/dot.cshrc Sat Mar 25 15:23:43 2000 @@ -1,4 +1,4 @@ -# $FreeBSD: src/share/skel/dot.cshrc,v 1.11 2000/03/25 20:23:34 rwatson Exp $ +# $FreeBSD: src/etc/root/dot.cshrc,v 1.26 2000/03/25 20:23:38 rwatson Exp $ # # .cshrc - csh resource script, read at beginning of execution by each shell # @@ -22,6 +22,7 @@ if ($?prompt) then # An interactive shell -- set some stuff up + set prompt = "`hostname -s`# " set filec set history = 100 set savehist = 100 --- /usr/src/share/skel/dot.login Sat Mar 25 15:23:36 2000 +++ /usr/src/etc/root/dot.login Sat Mar 25 15:23:43 2000 @@ -1,4 +1,4 @@ -# $FreeBSD: src/share/skel/dot.login,v 1.15 2000/03/25 20:23:34 rwatson Exp $ +# $FreeBSD: src/etc/root/dot.login,v 1.21 2000/03/25 20:23:39 rwatson Exp $ # # .login - csh login script, read by login shell, after `.cshrc' at login. # @@ -6,4 +6,4 @@ # # Uncomment to display a random cookie each login: -# [ -x /usr/games/fortune ] /usr/games/fortune -s +# [ -x /usr/games/fortune ] /usr/games/fortune Also, one thing that's bugged me forever about the csh files is that "righteous" is misspelled. :) I also think that using "022" instead of just "22" would be less confusing to the user, since the man page says that the values should be specified in octal. Similar changes probably need to be made in other dot.* files for root and skel, as all of these files seem to set different aliases, environmental variables, prompts, and have different semantics. I'm a bash/sh user, so I've taken the liberty of making up some new files. The intention is that you can do with these files what you've done with the csh ones, namely synch src/share/skel and src/etc/root, with the one exception mentioned below. Rather than submit patches, I've just attached them since the differences are pretty substantial in terms of organization. I used the existing files as a basis, and added the 'unlimit' function I've used for years. It's the one thing that csh has that I'm jealous of. :) Printing out what's being set helps unprivileged user understand what items aren't being changed. For root's dot.profile you need to add the following: --- dot.profile Sat Mar 25 23:24:25 2000 +++ dot.profile.rootSat Mar 25 23:41:15 2000 @@ -8,6 +8,8 @@ # Export all the environment variables to clean things up a bit set -o allexport +HOME=/root + # Remove /usr/games and /usr/X11R6/bin if you want PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/games:$HOME/bin If it turns out that putting the umask setting in the profile (roughly equal to dot.cshrc) then here is a patch for that: --- dot.profile.mineSat Mar 25 23:24:25 2000 +++ dot.profile Sun Mar 26 00:14:52 2000 @@ -24,6 +24,9 @@ # Turn off allexport to prevent possible foot-shooting set +o allexport +# Allows permissions of -rwxr-xr-x +umask 022 + # Set ENV to a file invoked each time sh is started for interactive use. ENV=$HOME/.shrc; export ENV Commentary on my files. . . Using allexport instead of an explicit 'export' for every variable makes the file easier to read, and gives a novice user one less thing to worry about. The PATH may be a little much, but I wanted to bring it in line with the one you're using for csh. I also rearranged the order to try and put the most frequently used directories first. login sets the initial PATH to '/usr/bin:/bin' so I thought it would be a good idea to emulate that. Also, I checked 'hash' for a while as a rough statistical analysis, and this is the PATH
Re: Proposed new Bourne shell init files
In message [EMAIL PROTECTED] Doug Barton writes: : --- /usr/src/share/skel/dot.cshrc Sat Mar 25 15:23:36 2000 : +++ /usr/src/etc/root/dot.cshrc Sat Mar 25 15:23:43 2000 : @@ -1,4 +1,4 @@ ... : if ($?prompt) then : # An interactive shell -- set some stuff up : + set prompt = "`hostname -s`# " : set filec : set history = 100 : set savehist = 100 Ahem. This should be `hostname -s %` unless this is only for root. I thought that this was for everybody. Only root should have a # prompt. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Shared /bin and /sbin
I have a system that has one file system on it (eg everything is on /). I'm finding that a lot of space is wasted on the multiple static copies of libc in /sbin and /bin. I was thinking about building, for this system only, /bin and /sbin dynamic. Has anybody ever done this? What are the implications of doing this. I can't think of anything that would stop this from working, but I thought I'd run it by people here. I'm aiming to have a system that is part way between PicoBSD and normal FreeBSD in terms of size. I need more flexibility than the PicoBSD crunchgen binary has to offer, but don't nee all of FreeBSD for the application I'm deploying. Comments? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
