Re: Another EPIA M 9000 update (was Re: More compartive power/performance results (was Re: Lower power SMP boxes?))
Matthew Dillon [EMAIL PROTECTED] wrote: Summary: EPIA M 9000 17-25W EPIA M E600016-22W EPIA 80011-20W EPIA 5000 9-15W (5W idle, 15W playing DVD) (this is non-inclusive of any hard drives) That's not bad (taking into account the lack of hard drives). For comparison purposes, here are a couple of random data points: [ NOTE: the following *includes* power consumption by hard drives, etc., but no monitor. ] System #1: ~70W 333MHz Celeron (66MHz FSB), 384MB RAM, Abit BH6 motherboard Some generic ATI Rage-based video card 10GB IBM drive (might be 60GXP -- I've forgotten) Two Maxtor DiamondMax 7200RPM 120GB drives Promise Ultra100 TX2 Intel Pro 100/S LAN Some generic DVDROM drive, floppy No extra cooling fans (yet?) System #2: ~170W (~200W+ with 100% CPU 3D rendering) Athlon 2100XP, 768MB PC2100 RAM (slow ;-(), Asus a7v8x motherboard Nvidia GeForce4 Ti200 video card, w/128MB LeadTek WinFast TV2000XP TV card 60GB IBM drive (60GXP, I think) 40GB Maxtor DiamondMax drive Plextor 12/10/32 CDRW Pioneer DVDROM, floppy Intel Pro 100/S LAN One extra cooling fan (in addition to the two in the power supply). Power was measured using an actual wattmeter, and not via an ampmeter (although, as modern PC power supplies supposed are now supposed to be power-factor-corrected, an ampmeter can give good results). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB to IDE converter
Josef Karthauser [EMAIL PROTECTED] wrote: USB hasn't changed much in -stable between 4.4 and now. We've got a lot of new usb code in -current though, and I'm hoping to have the bugs ironed out before 4.6. Really? I couldn't get my USB hard disk working with a -stable from mid-February, but it worked with -stable from mid-March or so (although, looking at the CVS logs, there really doesn't seem to be any real changes). I'm now using -stable from around March 24, and everything's mostly working. The only problems I currently have are: * USB not functional on a laptop after a resume (being worked on in -current, I see). * Intermittent, umass0: Phase Error, residue = 8192, hangs when transferring large amounts of data (~10MB-30MB). I'm hoping that this isn't an hardware problem. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB to IDE converter
Brian Dean [EMAIL PROTECTED] wrote: I just got one of these hoping that it would work under FreeBSD but so far can't make it work: Does it need drivers for Win2K or WinXP (drivers for Win98 and below are OK)? If it needs drivers for Win2K or XP, then the device may not be fully USB-mass-storage compliant, which means that it'll be difficult (if not impossible) to get it working with FreeBSD (someone may have to write a driver for it). If it doesn't need drivers, then I'm at a loss as to suggest what to do next, except to upgrade to the latest FreeBSD-STABLE. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd-hackers-digest V5 #429
Chad Kline [EMAIL PROTECTED] wrote:
* Olympus digital cameras (D-370)
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, OLYMPUS, D-*, *},
/*quirks*/ DA_Q_NO_6_BYTE
usbdevs -v reports:
Controller /dev/usb0:
addr 1: self powered, config 1, OHCI root hub(0x),
OPTi(0x), rev 0x0100 port 1
addr 2: self powered, config 1, C-1 Digital Camera(0x0102),
Olympus(0x07b4), rev 0x1015 port 2 powered
Two comments on the above quirk entry:
1. I'm pretty sure that the string comparisons are case-sensitive.
OLYMPUS does not match Olympus.
2. You appear to have a C-1 (etc.) camera, and so D-* will never match
C-1 Digital Camera. Try C-*, instead.
For USB hard disks, at least (which may also apply to cameras), you also
need to be running a pretty recent version of -STABLE; I'm pretty sure
that 4.5-RELEASE can't be used (which is what you're using). I know
that a -STABLE of around mid-February will *NOT* work (which is what
makes me think that -RELEASE also doesn't work), and one as of March 19
does (but might have problems with the new ATA code).
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: HOW to debug memory corruption efficiently?
Robert Suetterlin [EMAIL PROTECTED] wrote: Unfortunately I'm neither proficient in C++ nor efficient in debugging, so I stumble around the problem rather blindfolded. Once I blamed the compiler, systemlibraries and operating system, I knew I needed some help. The problem appeared on a linux system, but I guess the techniques I might need will be the same under Linux, FreeBSD or any un*x. Unfortunately, you'll probably have to debug this the hard way. Figure out what part of memory is being trashed, and then figure out what is trashing the memory. If the memory address/data is consistent, you might be able to use the i386 hardware breakpoint debug registers to help you. The best -- but horribly expensive -- way is to port the software to another Unix platform (like Solaris or HP-UX), and use Rational Software's Purify to locate the memory corruption. It's almost a no-brainer to use, and it works ungodly well. You don't even need source code to use purify -- object files are enough, as purify works at *link* time (you don't have to specially compile your code, unless you want to take advantage of special purify APIs). The downside is that your program does run 3-10X slower, and Purify is pretty expensive (but it's such a killer programming app). It's not available for either FreeBSD or Linux, though. Purify's nearest (commercial) competitor is ParaSoft's Insure++. Perhaps things have improved but, when we last evaluated it a year or two back, it was a LOT slower than purify (unusably slow for our applications). I seem to recall 5-10X slower than purify (maybe more). It can detect a few problems that purify does not, however (e.g., bad arguments to printf()). Insure++ needs access to source code for best results. I believe a Linux version is available. There is no open-source equivalent to purify (and probably won't be, due to patent issues). The closest thing is GNU checker, but that's a pale, feeble dust speck compared to purify (assuming that you even manage to get checker working). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)
Nate Williams [EMAIL PROTECTED] wrote: Unfortunately, I'm unable to run tcpdump on the client, since it's running NT and we're not allowed to install any 3rd party apps on it (such as the WinDump package). NT??? You wouldn't happen to be seeing performance problems with Samba, I hope? There are some known Samba/FreeBSD issues that can cause abysmal performance (~30-40KB/sec -- yes, kilobytes/sec), even with 100BT cards. No hangs or aborts, though. I've only seen this problem with DOS network stacks, but it wouldn't surprise me if it also affected some version of NT. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wake up on lan driver support
Wilko Bulte [EMAIL PROTECTED] wrote: WOL only requires a few things of the machine to be woken up: 1. The motherboard must support WOL. 2. The LAN card must support WOL. 3. You must have connected the special WOL cable between the LAN card and the motherboard. 4. You must have enabled WOL on the motherboard. 5. You must have a power supply that supplies sufficient power on the standby power rail to satisfy the needs of the lan card. Not all PSUs seem to do that. Yes, definitely (thanks for the addition!). Many older power supplies cannot supply enough current on the +5VSB rail to support WOL. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wake up on lan driver support
[EMAIL PROTECTED] (Hellmuth Michaelis) wrote: 6. The LAN card driver must support waking up of the card and/or the LAN card driver must not disable waking up of the card. [ I think we're in violent agreement here, and that we're now quibbling over subtle differences in the English language. ] I don't think you need *support* in the driver. What you do need is for the driver/ACPI *bugs* to be fixed (any existing BIOS-configured settings like WOL need to be preserved and not destroyed by the driver). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wake up on lan driver support
[EMAIL PROTECTED] wrote: I think it requires device driver support because it has to be enabled (at least, that's what the devices I know about require). No, it does not (at least, not for WOL -- you do need APM in order to use halt -p to turn off the system, though). It does not require any special driver support on the machine to be woken up, or from the machine that sends the special wake-on-lan packets. I've been using WOL since FreeBSD 4.2/4.3 (well, for a short while, at least, until I did an impressively stupid boneheaded unmentionable that burned out my motherboard's WOL support ;-(). WOL only requires a few things of the machine to be woken up: 1. The motherboard must support WOL. 2. The LAN card must support WOL. 3. You must have connected the special WOL cable between the LAN card and the motherboard. 4. You must have enabled WOL on the motherboard. That's it. Now, you only have to send the special WOL packets to the system to be woken up (someone's already mentioned the software, in another posting, which also does not require any special driver support). I've used both FreeBSD and Windows to send the packets. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: secure Filesystem
A while back, Alfred Perlstein [EMAIL PROTECTED] wrote: However, on a somewhat aging 128MB laptop, a 200+MB cfsd puts the system into swap h*ll pretty quickly. I think cfsd has some linked lists which thrash a lot of pages. That's unfortunate. Good thing is that cfs is open source. Got Patches ? :) A couple of months back, I briefly looked into it, but nothing (simple) came to mind. However, upon perusing the code again, cfsd appears to be using a plain hash table with 1024 buckets and a linked list at each bucket. The number of buckets is controlled by two simple #define's in cfs.h: #define HSIZE 1024 #define HMASK 0x3ff /* change these together, please */ These are pretty easy to change (HSIZE must currently be a power of 2), and you generally don't have to worry about hash function issues (the file inode is used as the hash function). My test case has 20+ files, occupying ~1.4GB, and increasing the hash table size (number of buckets) to 1M (1024*1024) greatly improved swap performance (not surprising, as following the linked lists is what unnecessarily dragged in lots of pages). On my laptop with 128MB RAM, there was a significant change in resident memory footprint: VM used RES (max) original 1024 bucket cfsd: ? ? 128K bucket cfsd: 445MB 80-90MB 1024K bucket cfsd: 458MB 30-35MB (20MB typ) Of course, increasing the number of buckets increased the initial cfsd size (to 14-16MB, in the case of the 1M buckets), but that's acceptable. [ And the cfsd process doesn't shrink when you cdetach ;-( ] -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: secure Filesystem
Mike Smith [EMAIL PROTECTED] wrote: The memory is not freed until you unmount (and then, the memory is only free'd for use by other cfs mounts -- the process size does not, of course, shrink). It doesn't? Does it just use malloc for these structs? When you say of course, you kinda imply you're thinking of the bad old malloc behaviour... While it uses malloc(), memory seems to be fragmented such that the process doesn't shrink (or doesn't shrink much -- memory leak, perhaps?). I haven't looked into exactly why, and was largely lamenting the insult after injury -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: secure Filesystem
Konstantin Chuguev [EMAIL PROTECTED] wrote: Look at /usr/ports/security/cfs. It's a useland crypto-filesystem that runs over NFS. I'd say, it's a daemon pretending to be an NFS server. It's running locally on port other than NFS. Very nice implementation, I use it a lot. A small problem with it is that it seems to support 7-bit file names only. A bigger problem is that doing anything with a file uses up 1-2KB PER FILE. If you want to see cfsd grow *really big*, do a find . of any large cfs-controlled hierarchy with lots of files. I'd really like to put my MH mail messages under cfs, but I've got too many files (I can't afford having a 200+MB cfsd). The memory is not freed until you unmount (and then, the memory is only free'd for use by other cfs mounts -- the process size does not, of course, shrink). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: secure Filesystem
Alfred Perlstein [EMAIL PROTECTED] wrote: A bigger problem is that doing anything with a file uses up 1-2KB PER FILE. If you want to see cfsd grow *really big*, do a find . of any large cfs-controlled hierarchy with lots of files. I'd really like to put my MH mail messages under cfs, but I've got too many files (I can't afford having a 200+MB cfsd). This is what swap is for. :) If cfsd doesn't touch all that now unused memory it'll simply be paged out and probably only paged in occasionally. Well, yes. ;-) However, on a somewhat aging 128MB laptop, a 200+MB cfsd puts the system into swap h*ll pretty quickly. I think cfsd has some linked lists which thrash a lot of pages. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
cscope open-sourced!
FYI, For those who haven't heard, cscope has been open-sourced by SCO (under a BSD-style license, no less)! See: http://cscope.sourceforge.net/ I've got patches for FreeBSD, as well as a couple bugfixes, in case anyone wants to turn this into a port (I don't have the time, sorry). -- Darryl Okahata [EMAIL PROTECTED] http://web.sr.hp.com/~darrylo/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
"Jordan K. Hubbard" [EMAIL PROTECTED] wrote:
I've used all kinds of software memory checkers, from "CheckIt" to
highly proprietary packages that cost even more money, and the only
thing they managed to convince me of is that swapping in known-good
memory is the best and fastest way out of these situations. Unless
I'll second this. I've had memory problems in the past, and every
memory checker I used said that the memory was good. Only by swapping
out the bad memory (I don't have access to an hardware memory checker)
was I able to fix my problems.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Severe problems with softupdates.
Josef Karthauser [EMAIL PROTECTED] wrote:
I'm still trying to recover my laptop from a really severe filesystem
crash using softupdates. The machine hung due to a problem with
power managment so it needed a reboot. Now fsck won't clean up without
Out of curiousity, did you get this crash while attempting to get
suspend/hibernation to work (i.e., they don't work, and you're trying to
get them to work)? I've noticed that, on some laptops with buggy (?)
APM implementations, the IDE controller/disks are never properly
reinitialized at resume time, with the result that the FS gets really
trashed (I basically had to reinstall FreeBSD, because, even if the
directories get reconnected, various individual files are corrupted).
I've fixed this on my laptop, but never made a proper patch (or
fixed it "correctly"), as few people appear to have this problem (I
appear to be the only one). If you want to see what I did, see:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=116906+120859+/usr/local/www/db/text/1999/freebsd-mobile/19991107.freebsd-mobile
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Search a symbol in the source tree
But, what various and interesting methods to search symbols there are ! Do people actually read what's posted here? A few days ago, I posted a detailed comparison of various packages. Go read the archives: http://www.freebsd.org/cgi/getmsg.cgi?fetch=331467+341670+/usr/local/www/db/text/1999/freebsd-hackers/19991017.freebsd-hackers Side note: Shigio Yamaguchi [EMAIL PROTECTED] has found some issues and bugs regarding GLOBAL, and so GLOBAL is not as bad as the article makes it out to be. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Search a symbol in the source tree
hed through (and displayed hits in) non-source files, like configure, configure.in, Makefiles, etc.. It is possible to have glimpse exclude certain files and index only those files you want indexed. However, I don't have the time to configure and test this. Perhaps someone else will do this. * Mkid/mkid2/mkid3/id-utils appear to generate the smallest index databases, and they run quickly. They're great for looking up where a particular identifier is used (e.g., "gid ptrace", which is an intelligent grep), but it can't just tell you where something is defined, and only that place. The place where something is defined is output along with every place that it's used. You're basically doing a very intelligent grep. However, grep'ing via gid is *MUCH* faster than "global -g" (it's like 100X faster); on the other hand, "global -s" is often comparable to gid. Mkid and friends can also (supposedly, as I've never tried it) tell you where a number occurs, in any base. If you know the number 100 is somewhere in your source code, mkid can show you where it occurs, as "100" (decimal), "64" (hex)", or "144" (octal). Only source files are indexed, as mkid friends only know about certain languages (C, C++, assembly being a few). Also, comments aren't indexed, although gid will display hits in comments (because the file being grep'd contains a hit in a non-comment line). However, the "id-utils-3.2" package for -current dumps core when used to index /usr/src. I don't have the time to track this down. On my system, indexing /usr/src using mkid3 took a bit over 2 minutes, and the indices took up around 9.1MB. The index was built using: find . -type f | grep '\.[chsSly][cxp]*$' | time mkid - (Note: id-utils is further broken, since it cannot take the list of files to index from stdin or a file -- this example is for mkid3.) Both glimpse and global index more files by default (in the case of glimpse, Makefiles, CVS/Root, CVS/Repository, COPYRIGHT files, etc. were indexed). It's VERY fast. On my system, searching for ptrace takes under 0.5 sec.: gid ptrace Yup, that's under one-half second, with 195 lines of output. Let's try looking for where "utmp.h" is used: gid utmp.h This takes around 2.5 seconds. * Bottom line: For general-purpose use, mkid and friends is best, as long as you don't need to search through comments or non-source files (Makefiles, README's, etc.). The database index is reasonably small, the indexing time is relatively quick, and the search times are often comparable to or better than those of global. However, mkid and friends can't just tell you where something is defined; they can only show where it is defined and used. If you need to search through comments, or need to search non-source files, glimpse is good. The index is larger than that of mkid/id-utils, and the search speed is decent, but not great. For many searches, it's faster than plain grep, although it can be comparable to grep in some cases. I've got mixed feelings about global. On the one hand, you can't beat it for locating where a function is defined, and it's very good at showing where a variable is used. However, for best results, you have to remember to use different options when searching for function definitions, identifier usage, preprocessor definitions, etc., and you may still have to resort to doing a full grep because, for some searches, global is too slow. The indices for global are HUGE, and indexing takes much longer than other approaches. I'm surprised that global is part of the base distribution, instead of being a port. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
Wes Peters [EMAIL PROTECTED] wrote: Darryl Okahata wrote: ... however, how the H*LL are the clueless newbie hordes supposed to know or learn this? As much as we'd like them to be, they're not exactly born with this knowledge, and I somehow doubt there's an "XXX for Dummies" book that covers this. The old-fashioned way: look before you leap. It is common courtesy to read any newsgroup or mail list long enough to get a feel for it before jumping in and making an ass of yourself. The "old-fashioned way"? While the "look before you leap" philosophy, which is excellent advice, has been around Usenet since time immemorial, I've yet to meet or hear about anyone that's actually done it (when they were a newbie, that is), although people here could be the first. As much as we'd like people to follow the "old-fashioned way", the Usenet/Internet is a strange, unfamiliar place. Even intelligent people have trouble applying "common sense" to it, at least at first. Treating all questions as "novice crud, to be shunned/insulted", is not very productive. It makes the FreeBSD crowd look like they're saying "see figure 1" to all newcomers. [ For those of you young enough to not know what "see figure 1" is, see: http://www.things.org/~jym/fun/see-figure-1.html ] We shouldn't have to rename a list called freebsd-hackers into freebsd-hackers-clueless-newbies-stay-away just because a couple of children have trouble accepting that nobody had the time to answer their questions. I agree. I feel the same way about adults who act like children. However, people seem to be treating all "non-advanced" questions as "useless novice crud, to be insulted and shunned". There's got to be something in the middle ground. On the one hand, you definitely don't want to cater to the lazy, but you also don't want to treat all "simpler questions" as crud. It's like using an incinerator to kill fleas on a dog; yes, it works, but it has undesirable side-effects. If someone sees one of these "simpler" questions, they should either ignore it, point them to the FAQ (assuming that the FAQ has an answer), or post a polite answer, without emotionally-loaded phrases. This is and has been common courtesy on Usenet newsgroups and Usenet, later Internet mailing lists, since I've had Usenet access - about 1985. If you don't know that, you don't even belong on the net, let alone this newsgroup. Ah. This here's a pefect example of an emotionally-loaded and possibly insulting sentence. Yes, what is said is largely true, but it's said in a fashion that is, well, rude (this doesn't bother me, but it would definitely bother other people). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
"Daniel C. Sobral" [EMAIL PROTECTED] wrote:
Why the hell does the clueless newbie hordes expects any answer when
posting a message to a list without reading the list charter and
without a single clue of how the list works is beyond me.
No one's disputing this. In fact, I agree with you.
Of course, that's no reason to be impolite to these newbies. I'm
just explaining that they have no place here in this list, and
that's that. It's not a newbies list. Now, if the newbie in question
keeps inflicting his cluelessness upon us, he *will* get hammered
back. That just happens when you keep annoying people.
There's the problem. While I agree with you about persistent,
annoying, and utterly clueless newbies, I don't agree with the apparent
sentiment (with which you may or may not agree) where all newbies (and
not just in -hackers) should be flamed and roasted. I've seen perfectly
innocent questions (asked once), from non-persistent/non-annoying
newbies, get flamed in -questions.
I recall you complaining about being ignored three times.
Heh. It wasn't me complaining. You need to go back and read the
thread.
This is, believe it or not, a reasonable
question/belief/expectation. If it's really asked that commonly, why
not turn it into a FAQ?
That's actually a good idea. Tell you what, you read the previous
threads and prepare a good FAQ entry in docbook, send me the patches
and I'll commit it.
I'll take you up on this, if you can guarantee that it'll show up
on the FreeBSD web page FAQ in a reasonable period of time (say,
preferably under two weeks, but definitely under a month). A couple of
years ago, I did submit some FAQ entries, which seemingly took a
geologically long period of time to appear in a useful location (the web
page). And this is why I stopped writing FAQ entries: if I write a FAQ
entry, I want it to be useful and made available to those who need it --
I don't want it to sit around buried in the repository, where only the
people who don't need it have access to it.
Of course, this was a couple of years ago, and things may have
changed. However, as the FreeBSD FAQ still appears to say that it's for
2.X (it's confusing, actually), perhaps not.
[ And, yes, I'm more than willing to submit proper docbook patches, if
they'll be made available to newbies (e.g., on the web page FAQ)
within a reasonable amount of time. ]
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
much more charitable than his). Looking at the current flamefests, and thinking about what was said by the Major Linux Personage, I'd have to say that there's a lot of ugly truth there -- and I do really wish he was wrong. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
"Daniel C. Sobral" [EMAIL PROTECTED] wrote: It's very simple: if I (emphasis on "I") think answering your message is worth the time in which I could read ten, twenty other messages, I'll do so. The same applies to each other person on the list, developer or not. Very true. There are things one can do to improve their chances of seeing the message answered. For example: ... excellent advice, which everyone should follow. ... however, how the H*LL are the clueless newbie hordes supposed to know or learn this? As much as we'd like them to be, they're not exactly born with this knowledge, and I somehow doubt there's an "XXX for Dummies" book that covers this. In many respects, venturing into a newgroup or mailing list is much like visiting a foreign country, where the customs and social mores are different than yours. For example, let's say that you've never been to the United Kingdom. Since people there speak "English", you won't have any problem communicating, right? Well, not quite. You might get some amused looks if you ask for the "public bathroom", and you might be very puzzled if someone says to you, "I'll knock you up around half-ten." If you ask for "chips", you may not get what you expected. In the same way, there are "different mores and customs" in newsgroups and mailing lists. To us, things like "make the messages easy to read", "use quoting", etc. are obvious, but how the H*LL are newbies supposed to know this? I see very few people trying to politely correct newbies, but many people "going postal" after one-too-many newbie questions. Example of people wanting someone else to do their homework: "I noticed FreeBSD's malloc() does not return an error when it allocates more memory than available. Can't you do [options]?" While I'm sure you believe that all people who post questions like this, want others to do their homework for them, I don't see that. From that one "message", I can't tell the poster's motives or thought processes. I just see someone asking a question. Possible, correct response(s) to such a question include: * Ignore it. If you can't say anything nice, don't say it at all. * Answer: "No, doing so is non-trivial. The reasons for this have been mentioned in numerous other postings, and so, for more information, please read the XXX mailing list archives on YYY. Try searchiing for `ZZZ'." If you do answer, do *NOT* use emotionally-loaded words, like "lazy" or "clueless". Flamefests lie that way. [ I'm using the word, "clueless", because I'm trying to hammer a point across. ] This is a recurring thread, you can look up on the archives to read how it goes. And how is the newbie supposed to know this, if no one tells them? Also, telling them via insults and the like is, well, rude. Basically, the person doesn't like the present behavior, and would like to have an alternative (or have it changed completely). This is, believe it or not, a reasonable question/belief/expectation. If it's really asked that commonly, why not turn it into a FAQ? -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
"Jay West" [EMAIL PROTECTED] wrote: The merced executes PA-RISC instructions natively. It also executes x86 instructions natively. If the chip you get doesn't do one or the other, it's because that section has been lobotomized for marketing/contract reasons due to where you get the chip from. The section is still on the silicon though... As a side comment, note that there is more than one "Merced Linux port" (it'll be interesting to see how they merge the efforts, if at all). There's the VA/Intel port, and there's a lesser-known one from HP Labs (it's been demo'd at the HP booth at recent Linux trade shows). From the secondhand info I've heard, it may be further ahead than the VA/Intel one. Back in February, I did see a very early version boot on some laptop running a Merced simulator. At the time, it wasn't very functional, being able to do ps, ls, and not much else, but I was surprised at how fast the simulator ran on the laptop (I think the boot sequence took a couple of minutes, but I didn't do any actual timings). However, that was six months ago, and quite a bit has supposedly been done since then. I've heard that it's "almost usable" (whatever this means). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
Jay West jlw...@tseinc.com wrote: The merced executes PA-RISC instructions natively. It also executes x86 instructions natively. If the chip you get doesn't do one or the other, it's because that section has been lobotomized for marketing/contract reasons due to where you get the chip from. The section is still on the silicon though... As a side comment, note that there is more than one Merced Linux port (it'll be interesting to see how they merge the efforts, if at all). There's the VA/Intel port, and there's a lesser-known one from HP Labs (it's been demo'd at the HP booth at recent Linux trade shows). From the secondhand info I've heard, it may be further ahead than the VA/Intel one. Back in February, I did see a very early version boot on some laptop running a Merced simulator. At the time, it wasn't very functional, being able to do ps, ls, and not much else, but I was surprised at how fast the simulator ran on the laptop (I think the boot sequence took a couple of minutes, but I didn't do any actual timings). However, that was six months ago, and quite a bit has supposedly been done since then. I've heard that it's almost usable (whatever this means). -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: [URGENT] CVS problems]
Mark Jaffe wrote:
CVS is issuing an "out of memory" message on attempting to checkin a
12MB file. What can I do? There is 300M of swap on the machine, it is
running FreeBSD 2.2.8, and CVS says:
"Concurrent Versions System (CVS) 1.9.26 (client/server)"
Anyone help?
How big is the history file size (compared to the processes' max
allowed data size)? CVS has a number of brain-damanged areas; one in
particular is that CVS reads the *ENTIRE* history file into memory when
doing stuff ... and it's doing so simply to scan the history file
line-by-line ....
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: [URGENT] CVS problems]
Mark Jaffe wrote: CVS is issuing an out of memory message on attempting to checkin a 12MB file. What can I do? There is 300M of swap on the machine, it is running FreeBSD 2.2.8, and CVS says: Concurrent Versions System (CVS) 1.9.26 (client/server) Anyone help? How big is the history file size (compared to the processes' max allowed data size)? CVS has a number of brain-damanged areas; one in particular is that CVS reads the *ENTIRE* history file into memory when doing stuff ... and it's doing so simply to scan the history file line-by-line -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum performance
Greg Lehey g...@lemis.com wrote: On Thursday, 17 June 1999 at 3:43:10 -0400, David E. Cross wrote: I have a drive that is rated at ~16 Meg/second, and indeed it delivers on t he order of 15+ Meg/second. If I use Vinum to create a concatinated device of 2 such units performance drops to 2.5 Meg/sec. This seems like a drastic drop in performance. Indeed, if you're comparing apples with apples. Possible marginally-related data point: with the 3.1-RELEASE vinum, and with striped drives (yes, I know the original user is using concatenated devices), I saw pretty bad write performance with the default filesystem frag size. Increasing the frag size (via newfs), increased performance substantially. -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum performance
Greg Lehey g...@lemis.com wrote: On Friday, 18 June 1999 at 1:14:20 -0700, Darryl Okahata wrote: Possible marginally-related data point: with the 3.1-RELEASE vinum, and with striped drives (yes, I know the original user is using concatenated devices), I saw pretty bad write performance with the default filesystem frag size. Increasing the frag size (via newfs), increased performance substantially. That shouldn't have anything to do with it. If you see anything unusual in Vinum performance, please tell me. It shouldn't, perhaps, have anything to do with it, but it did. I'm simply reporting empirical results, where I kept the stripe size constant and varied the filesystem frag size. I was able to get around a 2X improvement in write speed by increasing the frag size. Why, I don't know. I do know that I saw what I saw. ;-) This was, however, using 128K stripe sizes. Perhaps there's an interaction between small stripes and frag sizes? Also, I'm still stuck using the 3.1-RELEASE vinum. I want to upgrade to something newer, but I can't do so until I manage to backup my system (and I've got a lot of files to backup). ;-( It's easy to come to incorrect conclusions about the cause of performance problems, and disseminating them doesn't help. Follow the links at It's not so much of a conclusion as a data point. I'm simply reporting what I saw. Note that I am NOT saying that varying the frag size is the most significant way of improving performance. I'm sure that you're correct in your recommendations. However, I was able to significantly affect write performace simply by changing the frag size. As I've said, I don't know why, but it happened. I don't know how reproducible this is; maybe it's related to rotational latencies, the particular drive type, drive firmware, CPU speed, etc.. I don't know -- but I do know that it happened, and I'm simply reporting a data point. This is just a single data point, and we all know how dangerous it is to extrapolate from a single data point. ;-) However, if others report their findings, we may or may not find a trend. -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kernel config script
Wes Peters w...@softweyr.com wrote: If you mean lack of competition would make UNIX more homogenous and more viable to every Tom, Dick, and Jane that comes down the pike, I will agree with that. I just disagree that this is success. UNIX was never meant to be a word processor loader, and complete overkill for such an application. I'm curious: in your opinion, what is the purpose of Unix? Personally, I'd much rather use a single OS for everything -- including word processing. I don't -- today -- but that's where I'd like to be. -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a two-level port system?
Peter Jeremy jere...@gsmx07.alcatel.com.au wrote: How about storing each port as a single file in ar(5) format, which is unpacked into the directory structure when make'd? ar(5) is a text format, which means it can easily be managed by CVS, which includes a tool for manipulating its contents - ar(1). This isn't all that different from the existing *.tar.gz port files. If you use those, you get all the advantages of your approach, plus fewer disadvantages: Benefits: - The ports tree would become ~2500 inodes and ~~32MB. - The entire ports tree is still available on the machine. - No need to change port process to handle ar files. - No need to CVS commit ar files. (BTW, CVS can also handle binary files, so ASCII vs. binary is a non-issue.) - Smaller size than ar files. Disadvantages: - Unpacked ports will use about twice as much disk space (3 times if you include the original CVS archive). -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kernel config script
David Scheidt dsche...@enteract.com wrote: On Sun, 30 May 1999, Bill Huey wrote: That's fundamentally disturbing especially coming from other fellow Unix variant folks. Inter-UNIX rivalries are one of things that has kept unix healthy for so long. Linux tends to pick up most of the 3L1t3 dudez, who don't know Inter-Unix rivalries are one of the big things that's slowed down Unix development and allowed Windows to thrive. If the rivalries didn't exist, Unix would be *MUCH* better than it currently is. I'm not just talking about FreeBSD vs Linux; I'm talking about all of the other major Unix vendors, too. I think Bill has a point: all this rivalry is disturbing. I'm surrounded by Linux users, and yet I still manage to use FreeBSD without having to stoop to emotional arguments and name-calling. Personally, I find all this hand waving, venting of hot air, and attempted kicking of hind parts rather boring. I've got better and often more enjoyable things to do. For those of you who enjoy all this name-calling and dirt-flinging, I've got one thing to say: grow up and get a life. -- Darryl Okahata darr...@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
