Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Just fwiw (probably nothing), I'd like to express a strong yes please vote for a move in this direction. I currently use djb's daemontools to manage qmail and dnsserver+tinydns, and am pretty sure that I'm going to migrate the rest of my /usr/local/etc/rc.d services under there too, now that I have a reasonable understanding of how it works. None of these run as root, so .pid files wouldn't work well anyway. About the only thing that daemontools doesn't offer in this regard is the sort of dependency-directed start order being discussed for the new /etc/rc.d (and present in NetBSD). I'm not sure what to make of that. I suspect that djb just expects services that depend on other services to wait around until the other service is running (perhaps by exiting so that the service manager can start it again five seconds later). I'm not sure that I can see a problem with that, frankly: not being able to cope with unresponsiveness of some other service implies fragility in the face of restarting or failure of that other service. Maybe there are races or deadlocks that way? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, Jun 16, 2001 at 05:39:49PM -0400, Garance A Drosihn wrote: Mind you, I do agree that it would be very nice if we [the industry] could figure out benchmarking tactics which did not depend on the knowledge level of the person doing the benchmark. It would also be really nice to see lasting peace in every corner of the globe, but that also isn't going to happen without divine intervention. Getting back to benchmarks, the problem is that as soon as someone designs a benchmark, some members of the competition (the competition in whatever field is being benchmarked) sits down and figures out how to look good on that benchmark. The way that the SPEC organisation manages it (and has been doing a pretty good job on CPU/memory benchmarks over the years) is to work hard to make sure that the work done by the benchmark _is_ representative of the sorts of work that real people do with the sorts of systems where you're interested in CPU performance. That way, companies that figure out how to look good on the benchmark tend to actually make their platform behave well for a wide variety of applications. The other thing about SPEC benchmarks is that the interested parties benchmark themselves, and disclose their configurations, so that those reading the results can (a) reproduce them and (b) know what sorts of things that they should do if they want to make their own applications run as well as that. I remember that the last time this question arose, someone suggested raising a fund to buy (yes, the sad part of SPEC is that they sell the test suite to fund future developments) SpecWEB. How is that effort going, and do the folk who have volunteered to run it have access to suitably impressive hardware? (That last point is likely a stumbling block for either FreeBSD _or_ Linux. You can bet that if Microsoft wanted to win SpecWEB races they'd be able to buy better hardware than any group that's scratching to get $800 together...) For OS benchmarking, what we probably need is something like SpecWEB with Laser association(the sailing variety) one-design rules for the hardware. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Mon, Jun 04, 2001 at 12:52:57AM +0100, Mark Valentine wrote: I'd leave the bug alone, pending real enlightenment... Me too. I've never met a command name with an = in it. By the way, who uses env(1) anyway? In the past twenty years, I've only ever used it as shorthand for printenv(1). What's this csh(1) thing? :-) How else do you throw away your environment, to make sure that daemons that you start with sudo don't do anything silly? I'm pretty sure that I copied this /etc/start_if.ed0 from somewhere, rather than making it up: env - PATH=$PATH dhclient ed0 It's also quite commonly used in /usr/local/etc/rc.d scripts, including qmail and courier-imap. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Fri, May 25, 2001 at 08:49:21PM +, Terry Lambert wrote: There is _no_ performance problem with the existing implementation, if you treat postgres as the existing implementation; it will do what you want, quickly and effectively, for millions of record keys. Does postgres make a good mail archive database? Can it handle arbitrary record lengths? It couldn't the last time I looked at it. Why are you treating an FS as if it were a relational database? It is a tool intended to solve an entirely different problem set. I'm not treating it as a relational database. But if mail messages aren't conceptually files, then I don't know what they are. One of my personal mail folders has 4400 messages in it, and I've only been collecting that one for a few years. It's not millions, but its a few more than the 500 that I've seen some discuss here as a reasonable limit (why is that reasonable?) and it's many many more than the 72 or so limit available in ADFS. I changed over to Maildirs becuase I like the fact that I can use normal Unix file search and manipulation programs on individual messages, as well as a wider set of MUAs (thanks to courier IMAP...), and because folder opening doesn't bog down when there are a couple of messages with really large attachments in them, the way mbox folders do. You are bitching about your hammer not making a good screwdriver. If the file system isn't a good place to store files, then what is it good for? Souce code trees only? There are application specific databases available for that too. What have you got left? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Sat, May 26, 2001 at 07:25:16PM +1000, Andrew Reilly wrote: One of my personal mail folders has 4400 messages in it, and I've only been collecting that one for a few years. It's not millions, but its a few more than the 500 that I've seen some discuss here as a reasonable limit (why is that reasonable?) and it's many many more than the 72 or so limit available in ADFS. I realised as soon as I pressed the send button that my current use of large directories for mail files doesn't actually involve any random access: the directory is read sequentially to build the header list. It is quite concievable that a performance tweak to the IMAP server could involve a header cache in a relational database of some sort, and that would certainly contain references to the individual files, which would then be accessed randomly. /usr/ports/distfiles on any of the mirrors probably contains upwards of 5000 files too, and there is a strong likelyhood that these will be accessed out-of-order by ports-makefile-driven fetch requests. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Fri, May 25, 2001 at 06:17:33AM +1000, Greg Black wrote: the life of all users of the system simpler. There's no real excuse for directories with millions (or even thousands) of files. One of the things that I've always liked about Unix was that there aren't as many arbitrary limits on what you can do and how you can do it, as there are on other platforms. For example, I once used an Acorn Archimedes computer, which had an OS called RISC-OS. The advanced disk filing system, ADFS, had some cute limits built in: no more than 10 characters in a file name, and no more than 70 (?memory fades) files in a directory. Nothing in Unix stops you from putting millions of files in a directory. There are (I mantain _obviously_) good reasons to want to do that. The only thing that stops you is that _some_ Unix platforms, using _some_ file systems, behave badly if you do that. They should be fixed. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On 25 May, Greg Black wrote: This is just not true. For the vast majority of the systems that have ever been called Unix, attempting to put millions of files into a directory would be an utter disaster. No ifs or buts. It might be nice if this were different, although I see no good reason to support it myself, but it's generally not a serious possibility and so applications that depend on being able to do that are plain stupid. Their authors are either too lazy to make their use of the file system a bit more sensible or too stupid to know that file systems are not databases. The right answer is to write applications with some understanding of the basics of software engineering or computer science. It's got nothing to do with the basics of software engineering or computer science. It's got to do with interface definitions and APIs. Where in open(1) does it specify a limit on the number of files permissible in a directory? The closest that it comes, that I can see is: [ENOSPC] O_CREAT is specified, the file does not exist, and the directory in which the entry for the new file is being placed cannot be extended because there is no space left on the file system containing the directory. [ENOSPC] O_CREAT is specified, the file does not exist, and there are no free inodes on the file system on which the file is being created. [EDQUOT] O_CREAT is specified, the file does not exist, and the directory in which the entry for the new file is being placed cannot be extended because the user's quota of disk blocks on the file system containing the direc- tory has been exhausted. [EDQUOT] O_CREAT is specified, the file does not exist, and the user's quota of inodes on the file system on which the file is being created has been exhausted. or perhaps: [ENAMETOOLONG] A component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters. All of which quite clearly indicate that if one wants to put all of ones allocation of blocks or inodes into a single directory, then one can, as long as the name and path length limits are observed. See: there's a system defined limit, and it's documented as such. That's what I was getting at. You're welcome to claim a documentation bug, and add the appropriate caveat. It seems clear to me that Hans Reiser (and Silicon Graphics before him) have taken the more obvious approach, of attempting to remove the performance limitation inherent in the existing implementation. You can moan about tree-structured vs relational databases, but if your problem space doesn't intrinsically map to a tree, then it doesn't stop the tree-structring transformation that Terry mentioned from being a gratuitious hack to work around a performance problem with the existing implementation. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, Feb 06, 2001 at 12:13:57PM -0800, Alfred Perlstein wrote: * Andre Oppermann [EMAIL PROTECTED] [010206 12:07] wrote: Does sendmail even use fsync()? It better. :) Quick grep of the sendmail sources shows most of the six fsync calls protected by a flag (SuperSafe or nofsync ). I don't know what circumstances can provoke either of those flags to be zero, but if they can be, then it mightn't be doing any fsyncs. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pentium 4
One big difference of the P4 is the SSE2 instructions and registers. It's now reasonable to ignore the old floating point stack altogether, and do floating point work with the SSE register file, getting the SIMD speed up where that's useful. (Because sse can now do doubles as well as floats.) However that depends on the OS doing the appropriate saves on the SSE register file on context switches. Do we do that (yet)? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sat, Dec 16, 2000 at 06:37:56PM -0800, Jordan Hubbard wrote: PS. Before this starts a flame war, let me say that I really believe that MacOS X is a very good thing for everyone involved, although the choice of Mach for the microkernel seems a little arbitrary if not misguided. It's hardly arbitrary, though the jury's still out as to whether it's misguided or not. You may remember that Apple bought a little company called NeXT a few years back. Well, that company's people had a lot to do with the OS design of OS X and let's not forget the design of NeXTStep. Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? Not that there can't be a good reason. There probably is. I just haven't heard it. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1
Has any more come of this? I've just started playing with LADSPA (The Linux Audio Developer's Simple Plugin API http://www.ladspa.org) on my FreeBSD 4-STABLE box, and run into a similar problem. This is an entirely C API, and the demonstration applications are all straight C, but some of the plugins themselves are written in C++. Without doing anything extra, attempting to dlopen() one of these C++ shared libraries produced an Undefined symbol __get_eh_context. In the spirit John's fix (I think): On Wed, Sep 13, 2000 at 05:49:11PM -0700, John Polstra wrote: As a work-around, try adding this to your main program. (I am assuming it is a C++ program too.) extern void terminate(void); void (*kludge_city)(void) = terminate; I didn't actually do that (took a while to find the message in the archives), but did: (a) Changed the source file names to .cc, so that they would be compiled as C++ code, and (b) added a gratuitous class definition and use to a common file, so that __get_eh_context and friends would be included in the executable. Neither of these made the problem go away, which surprised me, because nm on the resulting executable showed the symbol to be defined. I guess the dynamic linker doesn't look in the executable, only the shared libraries? This suggestion: Another possibility would be to link explicitly with libgcc when creating your dynamic library: cc -shared -o libphptest.so ... -lgcc Works, even when the applications are compiled as ordinary C programs again. I haven't tried running a system with more than one C++ plugin yet, so I worry a little that there will be multiple definition name clashes. If the dynamic linker is smart enough to not worry about that, then this does seem to be the "right" way to go, in some sense, because the resulting shared library seems to have "pure" C linkage. Perhaps we could put something about this in the Handbook, or (better) the gcc info pages? Is there a central repository of information about FreeBSD's binutil and compiler state? I noticed a few things in the gcc info pages about ABI-affecting switches (thunks for vtables and the like). There are obviously system defaults for these switches, but I don't know where to find out what they are. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF rtld and environment variables...
On Wed, Jul 26, 2000 at 02:00:46PM -0600, Nate Williams wrote: No, that's the one case where they help. But people aren't trying to squeeze whole systems into small disks anymore; Really? News to me... Well, even if there are/were folk who want tiny disk footprints, and crunching everything isn't going to do the whole job, wouldn't a compressed filesystem be a better way to approach this? At least that way you'd still be able to page from the executable(s), and all of the on-disk data would bennefit too. (I've read serious suggestions in comp.arch that it could be benneficial to compress DRAM, with hardware decompression/ compression on the way in and out of cache...) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UUU: Bug in StarOffice5 Port
On Wed, Jul 12, 2000 at 03:09:49AM -0400, Sean Lutner wrote: I install Star Office 5.2 on my 4.0-STABLE box tonight. I didn't use ports. I ahve linux emulation enabled. I got the bin file, ran it and it installed. The only quirk I hit was the location Star Office looks for test in. It wanted it in /usr/bin/test and it's in /bin/test. A simple ln -s later, I was running Star Office 5.2. The port maybe obselete now. I've just done it myself, but I had a little more trouble than that. I unzipped the .bin file (even though it's executable and should do that itself), and set up a LD_LIBRARY_PATH variable that included the directory where all of that went, as well as the linux compat libraries, tmp, and a few others. After that it pretty much just worked. Tell me: does it find the linux_jdk port, if that's installed? I'm running without Java/Javascript at the moment. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 12:47:38PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. That would probably explain why W'98 gets confused when you _do_ change the hardware configuration while in suspend state. Pretty silly state to get into, then, if hardware like floppy drives are easy to add or remove, and the box looks as though it's off... Any good theories about how to avoid this problem? Avoid S4 and go all the way to shutdown, with a flag set on the boot disk? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 06:36:14PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Maybe I'm wrong because of lack of my understanding on crush dump and : loader. Please help us :-) I think that you might be able to do this. The real tricky part maybe saving hardware RAM that the drivers expect to be there when you wakeup. I thinking of video ram and the X server's font cache, to name one example. Drivers will need a "your hardware may have been zonked" entrypoint, think about the i8254 counter or all the weird versions of write only or "write here - read there" I/O registers in existence. That sounds way too hard. Why not restrict suspend activity to user-level processes and bring the kernel/drivers back up through a regular boot process? At least that way the hardware and drivers will know what they are all up to, even if some of it has changed in the mean time. Obviously the video driver will need to send a signal or clue to the Xserver saying "you own the device, you'd better do something" Yeah. The X server has far too much "driver" level code in it already, so probably needs to be tweaked to re-initialise itself properly. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Andrew Reilly" writes: : That sounds way too hard. Why not restrict suspend activity to : user-level processes and bring the kernel/drivers back up through : a regular boot process? At least that way the hardware and drivers : will know what they are all up to, even if some of it has changed : in the mean time. Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) I'm concerned about trying to take short-cuts with booting, because I've seen both the Toshiba laptop that I'm using now, and my mother's HP desktop system hang horribly hard when they should have been coming out of suspend. (Both W'98.) I like the idea that my laptop will save power by shutting down after a while, but I don't want to get into trouble if I forget whether I was docked or not, or whether the floppy was plugged in or not, when next I turn it on. (*) Speaking of which: why are we considering doing process dumps into a _different_ swap-ish partition, instead of just ensuring that all processes are sleeping in the normal swap partition? If that was done, then they would just page themselves back in as needed, on wake-up. Sorry for blathering. This is just really interesting stuff. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:30:55PM -0700, Brooks Davis wrote: On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote: (*) Speaking of which: why are we considering doing process dumps into a _different_ swap-ish partition, instead of just ensuring that all processes are sleeping in the normal swap partition? If that was done, then they would just page themselves back in as needed, on wake-up. Because swap doesn't work that way anymore. They days where every page of memory had to be backed by disk are long gone. This means that there may not be anywere to put processes which are in memory unless you allocate somewhere to save all (or practicaly all) of memory. But to do the proposed state save to disk, there _must_ be enough disk space to back all of the process pages. In any case, I haven't seen many laptops capable of using more then 256MB of RAM which isn't exactly much of a modern disk. My laptop has 256MB of RAM and ships with up to a 10GB disk. I've retrofitted it with a non-standard 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB disk it shipped with, the suspend to disk partition is only 4% of my disk. The issue isn't with the size of the disk storage required, but with the mechanism. Why dedicate 256M to a suspend partition, and invent a new process saving mechanism, instead of making your existing swap partition 256M larger and using the existing swap pager? Processes do still wind up in "sleep" state, completely paged out, don't they? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. Don't the normal TCP timeouts take care of existing connections? I doubt that a "server class" system will be going into suspend mode for any reason, but I would imagine that suspend/resume should look much like network outage for the clients of suspended servers. For the only place that I can see it mattering (laptops), I suspect that suspend/resume should be an X session manager and application level job, and the kernel should just shutdown and boot as normal. I know that there aren't too many X applications that do all of the session management things, but maybe that would change if suspend actions interacted with the popular desktops in the appropriate way. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: In the last episode (Apr 26), Sheldon Hearn said: On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: Is FreeBSD's behavior correct? Why or why not? You can use the included code snippet to verify that this occurs. FreeBSD has traditionaly violated the IEEE FP standard in this regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember what file this is in so I can't check.) Huh? I'm pretty sure you've got this backwards. FreeBSD has traditionally upheld the standard and we only recently decided to go with the flow in 5.0. No; we held our moral ground against IEEE, until 5.0 when we gave in. The IEEE standard says "trap nothing". For most programs, this is the wrong thing to do, since they are not signal-processing apps or numerical analysis programs and a divide by zero is a coding error. I'd rather have my program die on an unexpected divide by zero than continue with invalid data. Why should we treat (1.0/0.0) any differently from (1/0)? Because 0.0 might be the closest approximation to whatever number you were really trying to divide by that the hardware can manage. 0 is never an approximation to 1 or -1. Dividing is for wimps, anyway.:-) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote: [open source is irrelevant because none but but the authors can really fix things] [open source _means_ that it's never finished] [the existing commercial support sucks] Seems like a pretty pointless and content-free set of remarks to be making on the mailing lists of a successful open-source project. Particularly from someone who obviously _does_ use and support open source projects. Go on, what's your real point? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
On Mon, Mar 13, 2000 at 04:14:34AM -0500, Dennis wrote: At 09:19 AM 3/13/00 +1300, Joe Abley wrote: I have yet to find a "real product" with good documentation. I hate when these discussions get so out of context. The original point regarded source code, and whether it was useful enough to allow end-users to maintain their own systems simply by having it, since many of the caveats and "code tricks" are known only to the authors, or because of the substantial learning curve of fully understanding a hardware device. Well, I've been able to get several problems "fixed" as a result of having the source code. I might not be able to fix the problem myself, but I can usually (a) work around it and (b) submit a detailed-enough PR or message to the author, including a pointer to the problem piece of code and what I think's wrong with it, that a fix has been installed in very short order. How much better would I have fared with Solaris, SCO or NT? What does it matter if there are users that can't derive even this level of utility from the source, when there _arent_ any better alternatives. Again, your complaint has no positive arguments for ways to improve the situation, or alternative scenarios that would be better. It is just an unhelpful whinge. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
On Mon, Mar 06, 2000 at 01:45:44PM -0500, John Baldwin wrote:
On 06-Mar-00 Doug Barton wrote:
All that said, if the ports make system depends on the current
behavior, it has to be fixed before we can contemplate any changes.
Patches accepted.
The construction
set -- ${MAKE_MACRO} ; for i ; do echo $i; done
seems to do what we want. Well, it works with bash and
freebsd's sh.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Bugs and their ubiquity (was an extended rant about PCI DMA)
Hi Wes, On 07-Dec-99 Wes Peters wrote: Andrew Reilly wrote: On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote: Software is created by humans, and humans are fallible, therefore the software is also fallible. No, that doesn't logically follow. Just because it's possible for humans to make mistakes doesn't mean that it's impossible to do or make something (eventually) without mistakes. With the exception of TeX, *no* software is bug-free. In my extensive experience, no software with the exception of TeX is free of serious bugs. That's a little strong, don't you think? I can't remember encountering any bugs, serious or not, in any of the consumer electronics devices I use on a day-to-day basis. I've written a number of embedded signal processing applications myself that do exactly what they're supposed to, and don't ever break. I suspect that it's probably easier to be confident about code that does the same thing hundreds or thousands of times a second than code that will (with good luck and good management) never be run in anger, though. Using the example of TeX, what do you consider is special about it? A happy accident? Isn't it more likely that careful coding to a good design, with well defined inputs and outputs, and subsequent exposure to a great deal of peer review and testing has a little to do with it? How are those conditions different from those faced by any of the subsystems of FreeBSD, except perhaps by degree? Your belief or lack thereof doesn't change the existence of the bugs, it just leads YOU to be surprised when they crop up in the oddest ways, while I am not. My beliefs haven't got much to do with it. Most of my interaction with my own software involves the belief that the subtle bugs are being masked by the obvious bugs. But I use the bugs that I find to teach me about my code and the states that it can find itself in. I leave assertions and invariant checks behind to make sure that the eroneous conditions don't re-occur, or re-design to accommodate them if they represent legal states. In my experience this beats any amount of interactive debugger single-stepping or crash-dump analysis. Remember: in the message that you quoted, I mentioned that the desirable state was one where we were "surprised at a crash of any sort", rather than "convinced by analytic proof that crashes were impossible". Sure, the difference between "surprised by crashes" and "surprised by lack of crashes" is one of degree, but it's a pretty important degree. My personal perception is that FreeBSD is currently much closer to the former state than the latter. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote: Software is created by humans, and humans are fallible, therefore the software is also fallible. No, that doesn't logically follow. Just because it's possible for humans to make mistakes doesn't mean that it's impossible to do or make something (eventually) without mistakes. Even when formal proof isn't possible (the usual case) careful design, backed up by design-based assertions and tests can produce code that does not have bugs. FreeBSD is a big and complicated thing, but it's (largely) composed of subsystems that can be maintained, designed and tested by individuals. I think that a goal of "surprise at a crash of any sort" isn't unreasonable, and highly desirable. I'll take "right" over "fast", and both over "features" any day. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A new package fetching utility, pkg_get
On Mon, Sep 27, 1999 at 08:09:13AM +0100, Nik Clayton wrote: On Mon, Sep 27, 1999 at 10:22:34AM +1000, Andrew Reilly wrote: What I'd like is a little weekly crontab script that runs after my weekly ports cvsup, and tells me which of the ports that I "subscribe to" has changed, so that I can think about rebuilding it. ports/sysutils/pkg_version. Then apply the patches at http://www.freebsd.org/~nik/pkg_version.diff pkg_version.1.diff and use the -c flag. This is lovely. And it re-inforces one of my pet theories: if you want a program badly enough that you're prepared to write it, someone else almost certainly has... Thanks. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A new package fetching utility, pkg_get
On Sun, Sep 26, 1999 at 01:52:36AM +0200, Oliver Fromme wrote:
While we're talking about making package handling easier for
newbies, I'd like to present two simple shell scripts that I
wrote quite some time ago. Yeah, I know I could send-pr this,
but I'm not sure if they're really worth it (if someone thinks
they are, then I'll send-pr them).
Here's a bit of me-too-erism, and (I hope) some food for thought
and discussion:
I've longed for a mechanism to keep the ports that I use as
up-to-date as the rest of my FreeBSD system. Unfortunately,
some ports I don't use very often, and so forget that they're
there.
Unfortunately (again), the port name-version_number identifier
isn't _quite_ unique enough to use as a key for tracking ports.
For example: ssh and docbook have multiple versions for the same
base name installed concurrently.
What I'd like is a little weekly crontab script that runs after
my weekly ports cvsup, and tells me which of the ports that I
"subscribe to" has changed, so that I can think about rebuilding it.
This is the closest I've come, so far. Comments and suggestions
welcome, of course:
pkg_info -a -q -I tags
pkg_info -a -I | awk '{print $1}' | paste -d\| - tags | sort
-t\| -k 2 alist
sort -t\| -k 4 /usr/ports/INDEX |\
join -t\| -o1.1,2.1 -1 2 -2 4 alist - |\
awk -F\| '{if ($1 != $2) print $1 "--" $2}'
This throws up some obvious candidates, like:
mutt-1.0b1--mutt-1.0b2
But also some dubious ones:
bzip2-0.9.0c--bzip-0.21
bzip2-0.9.0c--bzip2-0.9.5c
And some that seem to have different pkg_* names from the values
in the INDEX file:
squid-2.2--squid-2.0
squid-2.2--squid-2.1
This probably also loses for any ports where the comment field
has changed...
I've thought about parsing the "updated ports" list that gets
posted to usenet every (?) month or so, but that seems hard too.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
On Sun, Sep 12, 1999 at 02:47:21PM +0200, Jeroen Ruigrok/Asmodai wrote: * Simon Marlow ([EMAIL PROTECTED]) [990912 13:05]: I'd like to make a port for our Haskell compiler, GHC (see http://research.microsoft.com/users/t-simonm/ghc). There are some subtle problems with this: - GHC depends on itself. That is, you need GHC installed in order to build GHC. - GHC depends on Happy, our parser generator. - Happy depends on GHC (it's written in Haskell). So, one solution would be to provide a binary port, say ghc-bin, which would install a binary distribution. I checked the modula-3 port, and it doesn't seem to have a binary port, so what's the accepted way of doing this? It's not a port yet, but compiles from it's distribuiton without problems: SmallEiffel is also written in itself, but has a natural intermediate compilation phase which is ANSI C. The distribution just includes the C, from which the compiler and tools is built. That seems to work pretty well. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
On Sun, Sep 12, 1999 at 02:47:21PM +0200, Jeroen Ruigrok/Asmodai wrote: * Simon Marlow (simon...@microsoft.com) [990912 13:05]: I'd like to make a port for our Haskell compiler, GHC (see http://research.microsoft.com/users/t-simonm/ghc). There are some subtle problems with this: - GHC depends on itself. That is, you need GHC installed in order to build GHC. - GHC depends on Happy, our parser generator. - Happy depends on GHC (it's written in Haskell). So, one solution would be to provide a binary port, say ghc-bin, which would install a binary distribution. I checked the modula-3 port, and it doesn't seem to have a binary port, so what's the accepted way of doing this? It's not a port yet, but compiles from it's distribuiton without problems: SmallEiffel is also written in itself, but has a natural intermediate compilation phase which is ANSI C. The distribution just includes the C, from which the compiler and tools is built. That seems to work pretty well. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
On Thu, Sep 09, 1999 at 01:21:09PM +0200, Markus Stumpf wrote: On Thu, Sep 09, 1999 at 12:08:01PM +1000, Andrew Reilly wrote: really easy, with a shell script that's just a case $SENDER It's even "easier" :-) I subscribe new mailing lists (and resubscribed old ones) as [EMAIL PROTECTED] Well, that's arguably the way qmail wants it to be, but not helpful if you want your mailing list traffic to come through the one ISP-provided pop account. (Costs less that way, with my current ISP.) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: damn ATX power supplies...
On Thu, Sep 09, 1999 at 10:35:52AM -0700, Mike Smith wrote: Disabled no automatic restart on power failure You _should_ be able to change this. none of them is satisfactory especially for picoBSD things such as routers or firewalls where an UPS is overkill... You can always hotwire the supply; go dig up a pinout for the ATX power connector and you'll see that if you ground the power-on line the PSU will come up... How is it that BIOS settings can affect this? Do they fiddle with some battery-backed switch on the motherboard? I have an ATX system that must be looking for a keyboard-located power switch of some sort. It won't power up unless I unplug the (PS-2) keyboard, and then plug it back in again. That seems as though there's something fairly complicated in the system that _is_ being powered up. I think I'll try your hot-wiring trick. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
On Thu, Sep 09, 1999 at 01:21:09PM +0200, Markus Stumpf wrote: On Thu, Sep 09, 1999 at 12:08:01PM +1000, Andrew Reilly wrote: really easy, with a shell script that's just a case $SENDER It's even easier :-) I subscribe new mailing lists (and resubscribed old ones) as maex-listn...@space.net Well, that's arguably the way qmail wants it to be, but not helpful if you want your mailing list traffic to come through the one ISP-provided pop account. (Costs less that way, with my current ISP.) -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: damn ATX power supplies...
On Thu, Sep 09, 1999 at 10:35:52AM -0700, Mike Smith wrote: Disabled no automatic restart on power failure You _should_ be able to change this. none of them is satisfactory especially for picoBSD things such as routers or firewalls where an UPS is overkill... You can always hotwire the supply; go dig up a pinout for the ATX power connector and you'll see that if you ground the power-on line the PSU will come up... How is it that BIOS settings can affect this? Do they fiddle with some battery-backed switch on the motherboard? I have an ATX system that must be looking for a keyboard-located power switch of some sort. It won't power up unless I unplug the (PS-2) keyboard, and then plug it back in again. That seems as though there's something fairly complicated in the system that _is_ being powered up. I think I'll try your hot-wiring trick. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
On Wed, Sep 08, 1999 at 05:43:17PM -0700, Amancio Hasty wrote: 3. Needlessly cross-posted (watch your cc lines, loser! :). On a different topic, does anyone know of a good X mailer (currently I am using exmh) : There aren't any. :-) (depends on your value of "good") 1. user friendly 2. filtering capability I've decided that threading isn't the mailer's job. I don't want to have to wade through a mailbox full of lists when I'm connecting from off site, and have shut down my on-site mailer. Lots of folk use procmail, but since I'm using qmail as an MTA, I thought I'd see if I could use it's native methods, and it's really easy, with a shell script that's just a case $SENDER block. 3. thread topic support The best threading mail reader that I've come across is mutt, but that might be too traditional for your option 1. If you find a pretty, lightweight X-based MUA that does a good job with threads (and MIME, and PGP), I'd like to know about it too. XFMail isn't acceptable, because I've got 130M of mbox mail boxes in a deep directory hierarchy, and I'd like to keep them that way. The last time I looked at XFMail it insisted on an un-nested mh-directory style of mailbox. Is it still the case? Nate: it's a while since I looked at VM on XEmacs. I found its layout cluttered and it's key sequences awkward. How configurable is it, really? Do you use it as it comes out of the box? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
On Wed, Sep 08, 1999 at 05:43:17PM -0700, Amancio Hasty wrote: 3. Needlessly cross-posted (watch your cc lines, loser! :). On a different topic, does anyone know of a good X mailer (currently I am using exmh) : There aren't any. :-) (depends on your value of good) 1. user friendly 2. filtering capability I've decided that threading isn't the mailer's job. I don't want to have to wade through a mailbox full of lists when I'm connecting from off site, and have shut down my on-site mailer. Lots of folk use procmail, but since I'm using qmail as an MTA, I thought I'd see if I could use it's native methods, and it's really easy, with a shell script that's just a case $SENDER block. 3. thread topic support The best threading mail reader that I've come across is mutt, but that might be too traditional for your option 1. If you find a pretty, lightweight X-based MUA that does a good job with threads (and MIME, and PGP), I'd like to know about it too. XFMail isn't acceptable, because I've got 130M of mbox mail boxes in a deep directory hierarchy, and I'd like to keep them that way. The last time I looked at XFMail it insisted on an un-nested mh-directory style of mailbox. Is it still the case? Nate: it's a while since I looked at VM on XEmacs. I found its layout cluttered and it's key sequences awkward. How configurable is it, really? Do you use it as it comes out of the box? -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, Sep 05, 1999 at 09:00:00PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Warren Welch writes: Might be a good time have a sys/dev/sio and have pccard, cardbus, pci and isa attachments there. Yes, I did say cardbus, since I have seen cardbus PCI modems that are NOT winmodems. And USB? This reference says that you can (now? soon?) buy a laptop docking station with all of the usual ports, connected only by USB... http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm Hmm. What sort of level of nesting do we support for this sort of thing? It's probably possible to buy USB interface cards that plug into ISA, PCI, SCSI? And vice-versa? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Limit of bus hierarchies (was Re: PCI modems do not work???)
On Mon, 06 Sep 1999, Warner Losh wrote: : http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm : : Hmm. What sort of level of nesting do we support for this sort : of thing? It's probably possible to buy USB interface cards : that plug into ISA, PCI, SCSI? And vice-versa? USB doesn't present a 16550A interface to the host, so I don't think that sio would have a USB attachment. So there's going to be manufacturer-specific terminal/serial port drivers to talk to the serial ports on USB-attached laptop docking stations, like the Annex ethernet terminal server things? I guess in the Windows world they must provide 16550-virtualisation software, or else everyone's copy of Telix or TeraTerm won't work. Or the parallel ports vs parallel-port scanners. Or maybe these docking stations just won't work at all... -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Mon, Sep 06, 1999 at 07:15:00PM -0400, Ugen Antsilevitch wrote: Supporting winmodems btw would be nice, although i doubt manufacturers will give us their code. That might not be necessary, eventually. I've heard, obliquely, of a project to develop "open source" modem (data pump) software that is obviously aimed at these things. It's not rocket science (well, not to DSP folks), and it is well and truly standardised. It would be a good final-year EE project in the right school. Also, since the theoretical limits of the POTS channel have pretty much been reached with V.34-bis or V.90, it's not even a moving target any more. No wonder they're cheap now. Does anyone know whether there's more to a "WinModem" than a line hybrid, a codec and a PCI interface? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Mon, Sep 06, 1999 at 07:15:00PM -0400, Ugen Antsilevitch wrote: Supporting winmodems btw would be nice, although i doubt manufacturers will give us their code. That might not be necessary, eventually. I've heard, obliquely, of a project to develop open source modem (data pump) software that is obviously aimed at these things. It's not rocket science (well, not to DSP folks), and it is well and truly standardised. It would be a good final-year EE project in the right school. Also, since the theoretical limits of the POTS channel have pretty much been reached with V.34-bis or V.90, it's not even a moving target any more. No wonder they're cheap now. Does anyone know whether there's more to a WinModem than a line hybrid, a codec and a PCI interface? -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, Sep 05, 1999 at 09:00:00PM -0600, Warner Losh wrote: In message 4.2.0.58.19990906100437.04bf3...@arthur.intraceptives.com.au Warren Welch writes: Might be a good time have a sys/dev/sio and have pccard, cardbus, pci and isa attachments there. Yes, I did say cardbus, since I have seen cardbus PCI modems that are NOT winmodems. And USB? This reference says that you can (now? soon?) buy a laptop docking station with all of the usual ports, connected only by USB... http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm Hmm. What sort of level of nesting do we support for this sort of thing? It's probably possible to buy USB interface cards that plug into ISA, PCI, SCSI? And vice-versa? -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Limit of bus hierarchies (was Re: PCI modems do not work???)
On Mon, 06 Sep 1999, Warner Losh wrote: : http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm : : Hmm. What sort of level of nesting do we support for this sort : of thing? It's probably possible to buy USB interface cards : that plug into ISA, PCI, SCSI? And vice-versa? USB doesn't present a 16550A interface to the host, so I don't think that sio would have a USB attachment. So there's going to be manufacturer-specific terminal/serial port drivers to talk to the serial ports on USB-attached laptop docking stations, like the Annex ethernet terminal server things? I guess in the Windows world they must provide 16550-virtualisation software, or else everyone's copy of Telix or TeraTerm won't work. Or the parallel ports vs parallel-port scanners. Or maybe these docking stations just won't work at all... -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, Sep 01, 1999 at 10:51:10PM +0200, Pascal Hofstee wrote: On Wed, 1 Sep 1999, Doug wrote: On Wed, 1 Sep 1999, Sheldon Hearn wrote: I plan to add a user ``smtp'' with UID 25 and a member of group ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is primarily for the convenience of maintainers of mail ports. Why not do this as part of the port itself, ala majordomo? That works just fine and is completely non-controversial because you don't get it unless you ask for it. I would just liek to point out that Postfix is also doing the exact same thing ... user postfix ... (as well as a group maildrop) Another data point: qmail adds _seven_ new users, and one new group. It has a very paranoid security model. I think that it uses a script to add them, but maybe I did it myself. It was a while ago... -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, Sep 01, 1999 at 10:51:10PM +0200, Pascal Hofstee wrote: On Wed, 1 Sep 1999, Doug wrote: On Wed, 1 Sep 1999, Sheldon Hearn wrote: I plan to add a user ``smtp'' with UID 25 and a member of group ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is primarily for the convenience of maintainers of mail ports. Why not do this as part of the port itself, ala majordomo? That works just fine and is completely non-controversial because you don't get it unless you ask for it. I would just liek to point out that Postfix is also doing the exact same thing ... user postfix ... (as well as a group maildrop) Another data point: qmail adds _seven_ new users, and one new group. It has a very paranoid security model. I think that it uses a script to add them, but maybe I did it myself. It was a while ago... -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
Hi Greg, hackers list, I don't want to express an opinion about the need or otherwise for mandatory locking, but I would appreciate a teensy clarification of the problem domain: On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Are you suggesting that random user processes have to do all of this every time that they access a vinum drive? I thought that access was mediated by a driver or server process. Isn't this process in a position to ensure the integrity of the transaction without any help from locking mechanisms? If some major maintenance utility needs to run on the raw device, during which time the state is inconsistent as far as user processes are concerned, isn't it sufficient to remove their read priveliges? Sorry if these are dumb questions. I have had no experience at file system or data-base applications, but I do want to learn as much about them as I can. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
Hi Greg, hackers list, I don't want to express an opinion about the need or otherwise for mandatory locking, but I would appreciate a teensy clarification of the problem domain: On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Are you suggesting that random user processes have to do all of this every time that they access a vinum drive? I thought that access was mediated by a driver or server process. Isn't this process in a position to ensure the integrity of the transaction without any help from locking mechanisms? If some major maintenance utility needs to run on the raw device, during which time the state is inconsistent as far as user processes are concerned, isn't it sufficient to remove their read priveliges? Sorry if these are dumb questions. I have had no experience at file system or data-base applications, but I do want to learn as much about them as I can. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Swap overcommit
On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: Actually, applications are written assuming that malloc() will not fail, generally speaking. Is this really the case? I'm pretty sure I've _never_ ignored the possibility of a NULL return from malloc, and I've been using it for nearly 20 years. I usually print a message and exit, but I never ignore it. I thought that was pretty standard practise. This is just a random comment, orthogonal to the overcommit issue, but I've seen both you and Matthew say this now, and I was surprised both times. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Beating system usage down
On Thu, Jun 24, 1999 at 12:34:06PM -0700, Mike Smith wrote: Just for those that have been following the benchmarking thread, this is exactly the same symptom set that FreeBSD demonstrates when loaded by WebBench. The gotcha here is, again, the giant kernel lock. Rather than trying to do the Solaris thing of mutexing everything, why don't we go in the opposite direction, and configure a multi-processor box as a cluster that happens to have really fast communications? Probably not as easy as it sounds, particularly since it would involve writing a memory network device driver, and some boot code to partition the main memory, and probably an extra layer of interrupt handling code, to hand device interrupts around. Er, yuck. It's just that it sounds as though it would be simpler to start with a blank sheet and a clean reentrant scheduling scheme, and graft pieces of FreeBSD back on top, than it would be to add that sort of functionality onto an existing traditionally structured Unix. -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
