RE: pmap bomb on 4.0-STABLE
Dear Mahlon, > > Can anyone tell me what this means - and even better, a fix? It's > my understanding that pmap concerns shared memory, is it possible > I have a bad stick of ram floating around? > Bad memory sticks are easy to find. Just rip out half the RAM and let the box run for a few days, then let it run off the other half for a while. Check case cooling too. Kees Jan PS. Please notice that crossposting is generally frowned upon. People tend to ignore you if you do this. 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: A novel idea....
Read #1, but skip the rest, it's opinion. BSD license, right? Without disagreeing with any of the previous points, let me step into evangelism mode here and borrow/add my own comments. Please take replies to the evangelism list, however (maybe post a variant of this on FreeBSD.org someplace). > In short, these are the reasons I prefer FreeBSD: 1) The file system is so much better than any Linux file system, ReiserFS included. Question: Is UFS a balanced btree? I don't think so, but I could be wrong. In either case, UFS is by far and away superior to ext[\d]. Check out soft-updates if you really want to be impressed. 2) The system isn't made by idiots. This is opinion. There are some bright people in the Linux crowd, but there are also some "hackers" that hack kludges instead of elegantly solving the problem. I've found, in my experience, that the FreeBSD development team seems to search out the elegant/correct solution as opposed to the quick solution. Idiots may be going a bit far and the start of a flame war (please avoid this, or let me know if you want a list for flames and I'll set one up, but please not here!). 3) The system's development is controlled, and the system is consistent because of that. This is one of the great benefits of a central development model/system. 4) FreeBSD never trashed my data. I 2nd this. I've lost many a GB of data to ext2 or other Linux FS's. UFS has been a rock for many years and many many many many servers, and a long time ago in a galaxy far far away, I think I heard a rumor of lost data... but that was the HD spindle coming loose and shredding the platter (ie, not something the file system could do much about). 7) I hate RMS with a passion (remember, he's the Communist hypocrite who claims his software is Free). I shouldn't comment, so I won't. ::grin:: 8) For a firewall, ipfw blows the doors off of Linux's iptables/ipchains/ipmasq/whatever. If you want a stateful firewall, look at ipf (also very very very very very nice!!!) I'm waiting for ipf to get bridging support in the kernel, then you'd have a firewall that would surpass any of your wildest dreams (no MAC addresses on the Ethernet cards, while retaining ipf stateful filtering). 9) I prefer the file system hierarchy. Designed extremely well... try an upgrade with cvsup, make world, and mergemaster: you'll never want to administer anything else ever again (except possibly AIX, but that maybe hardware envy on my part). 10) Bug fixes and development happen much quicker. See tonight and the ntpd bug. The patch was submitted before, or less than one hour after it hit bugtraq. 11) None of those shitty SVR4 bootscripts and symlinks; no abundance of pointless runlevels. rc scripts are centralized and convenient, but this is largely SA opinion. RC scripts are extremely easy to update, tweak, IMHO. 13) The FreeBSD base system behaves better than any Linux base system (e.g., the stuff in /usr/bin and /bin). Agreed, and it runs very well on old klunker systems are great w/ FreeBSD (P100's make great bridge firewalls). A new Linux install, on the other hand, is typically a monolithic beast that's rather large (disk and ram). 15) Development is more conservative (e.g., I don't see a bunch of EXPERIMENTAL warnings in /sys/i386/conf/LINT, like I do in Linux kernels). If you want bleeding, on the other hand, check out -CURRENT, which gets messages every now and then that run along the lines of "I'm going to break such and such for a few hours while I apply some patches, hold on." At the same time... I have yet to have a problem with a morning compile of -CURRENT (I know, I'm lucky). 16) FreeBSD is lighter than Linux. I'll leave this in. See #13. 18) Ports. 'ya can't forget them. 19) Kernel configs are cake 20) Multi-staged booting. You don't need to change your MBR when you install a new kernel (or want to roll back to a different kernel). I think I've only been stuck high and dry w/o a bootable system twice in four years and well over 400+ servers. Just my ramblings. I don't evangelize much, but it strikes me as odd that some of this info isn't on the homepage of FreeBSD. FWIW -sc -- Sean Chittenden PGP signature
Re: A novel idea....
> 8) For a firewall, ipfw blows the doors off of Linux's > iptables/ipchains/ipmasq/whatever. > > If you want a stateful firewall, look at ipf (also very very > very very very nice!!!) I'm waiting for ipf to get bridging support FreeBSD's ipfw is stafeful as well, and there are no plans (at least not from me!) to get bridging support in ipfilter cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: A novel idea....
Dear Andrew, > > 18) Ports. 'ya can't forget them. > More importantly, ports that are going to work on all free BSD's. If you haven't been keeping track of Open Packages, those guys have put the pedal to the metal. > > Just my ramblings. I don't evangelize much, but it strikes me > as odd that some of this info isn't on the homepage of > FreeBSD. FWIW -sc > I think that's part of the "try it, and see for yourself" mentality. If you like FreeBSD, you use it, and you don't need FreeBSD evangelism. If you don't like FreeBSD, you go away and you don't need FreeBSD evangelism. 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
unsupport fxp PHY's revisited
When booting FreeBSD 4.x on a system board with onboard fxp ethernet we developed for a research project here, we observe the same behaviour as described in the Dec 2000 -hackers thread "RE: yet another unsupported PHY in fxp driver" David Greenman wrote: : >nope, type 0, addr 0. does this indicate (perhaps) another size change? : : It indicates that something is wrong with the SEEPROM. Is it a SuperMicro : motherboard? If so, they changed the layout in the SEEPROM. Is a change in the SEEPROM the only cause for the fxp driver to detect a type and addr of 0 for the PHY in the 82559? Or are there other possible causes for this? I'm messing with hacking the fxp driver to force it to try and use the internal PHY -- I believe it's an 82555 from what I read in the earlier thread? -- but havent done serious testing of that yet. It is possible that company that did much of the fabrication/design work for us did something similar to what Mr Greenman described with the SuperMicro motherboard in the Dec 2000 thread. The markings on the chip itself say 82559C which intel's lighter-than-air datasheet says is the latest rev of the chipset. Intel also talks about an ipsec/crypto chip that can be coupled with the 82559C but we're not using that (and it's not supported in FreeBSD as far as I know anyway) more details below --Jon Kuroda ISTORE, another UCB EECS research project. >From a verbose boot of a generic kernel: Onboard fxp0 (the wacky one) found-> vendor=0x8086, dev=0x1229, revid=0x09 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base febf9000, size 12 map[14]: type 1, range 32, base ee80, size 6 map[18]: type 1, range 32, base feba, size 17 ... PCI card fxp4 (the normal well behaved one) found-> vendor=0x8086, dev=0x1229, revid=0x08 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base febfa000, size 12 map[14]: type 1, range 32, base ef00, size 6 map[18]: type 1, range 32, base fea0, size 20 ... fxp0: port 0xecc0-0xecff mem 0xfeb4-0xfeb5,0xfebf6000-0xfebf6fff irq 11 at device 15.0 on pci0 fxp0: Ethernet address 10:00:65:83:39:11 bpf: fxp0 attached (ethernet mac addr not standard for intel, specific to our site) fxp4: port 0xef00-0xef3f mem 0xfea0-0xfeaf,0xfebfa000-0xfebfafff irq 9 at device 20.0 on pci0 fxp4: Ethernet address 00:90:27:4f:db:e7 bpf: fxp4 attached ... fxp0: warning: unsupported PHY, type = 0, addr = 0 fxp4 (a normal intel pci card) has type = 7, addr = 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should I switch? [was Re: A novel idea....]
> > 7. FreeBSD is developed very rapidly. Especially if you subscribe to > mailing lists, you can see bugs fixed almost as soon as they are > mentioned. New features are added more conservatively, however. New > stuff is tried out in -CURRENT, where the heavy-duty FreeBSD hackers > make it stable, then merge it into -STABLE. The reason Linux became more > popular than FreeBSD is, as I've read: Linux development is > helter-skelter--anybody can make changes to the system and redistribute > them with ease. As a consequence, a wide range of people worked to > develop the components on your Debian system. This distribution and > encouragement led to confusion, but also popularity. FreeBSD, on the > other hand, is maintained by a fixed group of committers. While you can > still modify your system, it is more difficult to get random changes > into the main code tree. The result is a more structured and sane > development process, with an emphasis on stability rather than untested > additions. While it's true anyone can make changes to Linux and redistribute them with ease, I don't see how it's a point of difference. What prevents me from taking a bit of BSD, changing it and distributing it how I will? Actually getting a change into a distribution of Linux requires convincing a Responsible Person that it's a good idea, and that Responsible Person is going to take care either because his job may be on the line if he gets it wrong, or it's his pet part of the overall Scheme of Things and he really truly cares about it. In that regard, I don't see that FreeBSD is a lot different from a distribution. Remember too that a good deal of the software on BSD is the same as is on linux. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 & linux information. Configuration, networking, combined IBM ftpsites index. Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
system slows down to a crawl
hi there, not a big pain, but rather puzzling. when i play heretic on 4.2 stable (no sound) after i get killed couple of times and reload the previously saved game system gets slower and slower (pIII, 128 RAM). just wandering if there is some memory leak in heretis, since when i kill the game system goes back to its normal speed. p. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: system slows down to a crawl
Dear Peter, > > not a big pain, but rather puzzling. when i play heretic on > 4.2 stable (no > sound) after i get killed couple of times and reload the > previously saved > game system gets slower and slower (pIII, 128 RAM). just > wandering if there > is some memory leak in heretis, since when i kill the game > system goes back > to its normal speed. > It sounds more like something that belongs on -questions, rather than -hackers. If I were you, I'd have a look at a book named "System Performance Tuning". I forget the author, but it's one of the Nutshell handbooks. After reading through that you will be able to answer your own question, and know how to squeeze a little extra oompf out of your box. 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: struct malloc_type; problems with MALLOC_(DEFINE|DECLARE)
See pr docs/24797. You need to include sys/param.h and sys/kernel.h Responsible [EMAIL PROTECTED] harti On Thu, 5 Apr 2001, Jochen Kaiser wrote: JK>Hello, JK> JK>I've got some problems with JK> JK>MALLOC_DEFINE(M_DNDF, "ip_dndf", "dndf kernel aquisitions"); in my .c file JK> JK>and/or JK> JK> MALLOC_DECLARE(M_DNDF); in my .h JK> JK>In sys/malloc.h it shows that MALLOC_DEFINE initializes the malloc_type JK>struct to default values. JK> JK>When I know use it in my kernel code, I get a warning like: JK>../../netinet/ip_dndf.c:20: warning: type defaults to `int' in declaration of `SYSINIT' JK>../../netinet/ip_dndf.c:20: warning: parameter names (without types) in function declaration JK>../../netinet/ip_dndf.c:20: warning: data definition has no type or storage class JK>../../netinet/ip_dndf.c:20: warning: type defaults to `int' in declaration of `SYSUNINIT' JK>../../netinet/ip_dndf.c:20: warning: parameter names (without types) in function declaration JK>../../netinet/ip_dndf.c:20: warning: data definition has no type or storage class JK> JK> JK>I did search the rest of the kernel code, but I couldn't find any of it JK>that did an assignment to the struct malloc_type. JK> JK>Do I have an error of concept ? JK> JK>thanks in advance, JK> JK>Jochen Kaiser JK> JK> -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
struct malloc_type; problems with MALLOC_(DEFINE|DECLARE)
Hello, I've got some problems with MALLOC_DEFINE(M_DNDF, "ip_dndf", "dndf kernel aquisitions"); in my .c file and/or MALLOC_DECLARE(M_DNDF); in my .h In sys/malloc.h it shows that MALLOC_DEFINE initializes the malloc_type struct to default values. When I know use it in my kernel code, I get a warning like: ../../netinet/ip_dndf.c:20: warning: type defaults to `int' in declaration of `SYSINIT' ../../netinet/ip_dndf.c:20: warning: parameter names (without types) in function declaration ../../netinet/ip_dndf.c:20: warning: data definition has no type or storage class ../../netinet/ip_dndf.c:20: warning: type defaults to `int' in declaration of `SYSUNINIT' ../../netinet/ip_dndf.c:20: warning: parameter names (without types) in function declaration ../../netinet/ip_dndf.c:20: warning: data definition has no type or storage class I did search the rest of the kernel code, but I couldn't find any of it that did an assignment to the struct malloc_type. Do I have an error of concept ? thanks in advance, Jochen Kaiser -- Jochen Kaiserkind@IRCNET, phone +49 9131 85-28134 Network Administration mailto:[EMAIL PROTECTED] Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany GPG public key: http://www.uni-erlangen.de/~unrza2/public_key.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unsupport fxp PHY's revisited
In article <[EMAIL PROTECTED]> you wrote: > When booting FreeBSD 4.x on a system board with onboard fxp ethernet we > developed for a research project here, we observe the same behaviour as > described in the Dec 2000 -hackers thread "RE: yet another unsupported > PHY in fxp driver" Jonathan Lemon has mad some modifications to the fxp driver that might fix the problem for you. Have a look at: http://www.flugsvamp.com/~jlemon/fbsd/drivers/ -- Larry Baird| http://www.gnatbox.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unsupport fxp PHY's revisited
In article [EMAIL PROTECTED]> you write: >When booting FreeBSD 4.x on a system board with onboard fxp ethernet we >developed for a research project here, we observe the same behaviour as >described in the Dec 2000 -hackers thread "RE: yet another unsupported >PHY in fxp driver" You might want to try the updated fxp driver, which is available at http://www.flugsvamp.com/~jlemon/fbsd/drivers/Intel_EtherExpress/ This uses a different method for detecting the PHYs. >From a verbose boot of a generic kernel: > >Onboard fxp0 (the wacky one) >found-> vendor=0x8086, dev=0x1229, revid=0x09 This looks like an Intel Pro/100S Management Adapter. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pmap bomb on 4.0-STABLE
> > Can anyone tell me what this means - and even better, a fix? It's > > my understanding that pmap concerns shared memory, is it possible > > I have a bad stick of ram floating around? > > > Bad memory sticks are easy to find. Just rip out half the RAM and let the > box run for a few days, then let it run off the other half for a while. Of course, this is pretty far from scientific troubleshooting, especially when it crashes at random times. It's also highly undesirable to cripple the machine, considering it's a production box. I just need to know if pmap_entry really does have anything to do with physical ram, before I go off on a ram swapping goose chase, just to find out a month down the road the problem isn't fixed. -- Mahlon Smith InternetCDS http://www.internetcds.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pmap bomb on 4.0-STABLE
A friend of mine swears by this memory testing utility: http://reality.sgi.com/cbrady_denver/memtest86/ Apparently it tries a bunch of diffrent test patters that are likely to find memory problems that a simple test wouldn't find. It is cool because you just just write the image to a 1.44mb floppy and boot from that to do the test. A major downside is how long it takes. It takes around 8 hours on my laptop to do the full suite of tests. Not very useful for a production server..but something that probably be done on every system you create before you move it to producton. Joe Gleason - Original Message - From: "Mahlon Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 12:10 Subject: Re: pmap bomb on 4.0-STABLE > > > Can anyone tell me what this means - and even better, a fix? It's > > > my understanding that pmap concerns shared memory, is it possible > > > I have a bad stick of ram floating around? > > > > > Bad memory sticks are easy to find. Just rip out half the RAM and let the > > box run for a few days, then let it run off the other half for a while. > > > Of course, this is pretty far from scientific troubleshooting, especially > when it crashes at random times. It's also highly undesirable to cripple > the machine, considering it's a production box. > > I just need to know if pmap_entry really does have anything to do with physical > ram, before I go off on a ram swapping goose chase, just to find out a > month down the road the problem isn't fixed. > > -- > Mahlon Smith > InternetCDS > http://www.internetcds.com > > 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: pmap bomb on 4.0-STABLE
On Thu, 5 Apr 2001, Joseph Gleason wrote: :A friend of mine swears by this memory testing utility: : :http://reality.sgi.com/cbrady_denver/memtest86/ : :Apparently it tries a bunch of diffrent test patters that are likely to find :memory problems that a simple test wouldn't find. It is cool because you :just just write the image to a 1.44mb floppy and boot from that to do the :test. : :A major downside is how long it takes. It takes around 8 hours on my laptop The major downside is that software memory testing isn't conclusive. If it detects a problem, you've probably got one. If it doesn't, you may still. The only way to be sure is to use a hardware tester. If you don't have one, and most of us don't, you have to resort to swapping memory. : -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
project * ** kldload ufs *** i feel that a real microkernel OS should'nt have a bloated kernel in the sense, that heavy OS equipment like a FileSystem should run as a module on top of the kernel. i aim to make ufs run as a module on FreeBSD, which surely would require a lot of serious kernel code<-entry points. -- pitfall 1. the system after boot will load the kernel image into core fromdisc. 2. kernel runs init. 3. if init fails, then access to disk is'nt possible as thefilesystem module is not running. ** i do not know how HURD does it ** i have'nt done a lot of kernel hacking so if anyone can shed some light on this subject, i'd be really grateful FreeBSDRules __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
On Thu, 5 Apr 2001, Aman Sharma wrote: > > project * > ** kldload ufs *** > i feel that a real microkernel OS should'nt have a > bloated kernel in the sense, that heavy OS equipment > like a FileSystem should run as a module on top of the > kernel. > i aim to make ufs run as a module on FreeBSD, which > surely would require a lot of serious kernel > code<-entry points. It shouldn't be too bad as long as you force the loader to load the module, otherwise you run into a chicken & egg problem. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Network throughput tuning
Hi,
I run two systems on an intranet. The intranet itself is rather large,
but the two machines in question are connected to the same 100 Mbps/FDX
switch. I would like to optimize network throughput for Machine 1.
Machine 1 is a AMD K6-2 233 w/ 64 MB RAM running FreeBSD 4.2-STABLE from
around mid march and has a dc NIC. Machine 2 is a dual Celeron 466 running
Linux 2.4.2, and also has a dc NIC ("de4x5" driver in Linux terms).
In order to measure network throughput, I make sure _not_ to use the
disk I/O subsystem and issue the following commands:
machine1:~$ rsh machine2 dd if=/dev/zero bs=1048576 count=128 > /dev/null
(Linux doesn't understand bs=1m)
which yields between 9.0 and 9.2 MB/s which looks good.
machine2:~$ rsh machine1 dd if=/dev/zero bs=1m count=128 > /dev/null
gets me between 7.6 and 7.8 MB/s while this used to be 8.4 MB/s when
machine1 was still running Linux.
In short: the BSD machine receives 9.1 MB/s and sends 7.7 MB/s. Not that
I'm complaining, and the lower send rate may well be due to the Linux
box not handling the incoming stream well, but my question is: Did I
do _everything_ on the BSD box to ensure maximum throughput?
The tuning I did is:
sysctl -w kern.ipc.maxsockbuf=2097152
sysctl -w net.inet.tcp.rfc1323=1
sysctl -w net.inet.tcp.sendspace=1048576
sysctl -w net.inet.tcp.recvspace=1048576
Thanks in advance,
Niek
--
Conscience doth make cowards of us all.
-- Shakespeare
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: Network throughput tuning
Try using netperf (http://www.netperf.org/) too. I've found it to be an
extremely valuable tool.
Charles
-Original Message-
From: Niek Bergboer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 4:35 PM
To: [EMAIL PROTECTED]
Subject: Network throughput tuning
Hi,
I run two systems on an intranet. The intranet itself is rather large,
but the two machines in question are connected to the same 100 Mbps/FDX
switch. I would like to optimize network throughput for Machine 1.
Machine 1 is a AMD K6-2 233 w/ 64 MB RAM running FreeBSD 4.2-STABLE from
around mid march and has a dc NIC. Machine 2 is a dual Celeron 466 running
Linux 2.4.2, and also has a dc NIC ("de4x5" driver in Linux terms).
In order to measure network throughput, I make sure _not_ to use the
disk I/O subsystem and issue the following commands:
machine1:~$ rsh machine2 dd if=/dev/zero bs=1048576 count=128 > /dev/null
(Linux doesn't understand bs=1m)
which yields between 9.0 and 9.2 MB/s which looks good.
machine2:~$ rsh machine1 dd if=/dev/zero bs=1m count=128 > /dev/null
gets me between 7.6 and 7.8 MB/s while this used to be 8.4 MB/s when
machine1 was still running Linux.
In short: the BSD machine receives 9.1 MB/s and sends 7.7 MB/s. Not that
I'm complaining, and the lower send rate may well be due to the Linux
box not handling the incoming stream well, but my question is: Did I
do _everything_ on the BSD box to ensure maximum throughput?
The tuning I did is:
sysctl -w kern.ipc.maxsockbuf=2097152
sysctl -w net.inet.tcp.rfc1323=1
sysctl -w net.inet.tcp.sendspace=1048576
sysctl -w net.inet.tcp.recvspace=1048576
Thanks in advance,
Niek
--
Conscience doth make cowards of us all.
-- Shakespeare
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: system slows down to a crawl
On Thu, Apr 05, 2001 at 03:24:49PM +0100, Koster, K.J. wrote: > If I were you, I'd have a look at a book named "System Performance Tuning". > I forget the author, but it's one of the Nutshell handbooks. After reading > through that you will be able to answer your own question, and know how to > squeeze a little extra oompf out of your box. > > Kees Jan I just went out and bought that book. It is titled "System Performance Tuning," by Mike Loukides, published by O'Reilly, with a swordfish on the cover. It's 11 years old, which means it was pre-FreeBSD (indeed, even pre-Linux!), but the main focus is 4.3BSD, which makes many aspects still relevant. I am finding it to be an interesting read. It does some comparison between Xenix, SunOS, BSD UNIX and System V (releases 3 and 4). -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD on BookPC
Paul Marquis wrote: > > Can an end user buy a Sahara/Safari or do you have to be an OEM? If I > have to be an OEM, where can an individual purchase one? Sorry, catching up on e-mail finally. You should be able to buy a Sahara or Safari from any US FIC distributor. I'll ask at work tomorrow for our contact. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
