Re: Standard sbc and pcm support in GENERIC kernel?
On Thu, 4 Mar 2004, Brandon D. Valentine wrote: On Wed, Mar 03, 2004 at 05:03:40PM +0100, Jorn Argelo wrote: I've been on the question list for some time, and I have noticed that many people do not know how to get sound support up and running in FreeBSD 5.X. I know that re-compiling the kernel is easy enough, but there are still people not willing to do so, as I have noticed on the list. Therefor I thought it might be an idea to put sound support in the GENERIC kernel configuration, so that newbies will no longer find themselves stuck with that. If they'd read pcm(4) they'd know how to get sound support up and running without recompiling their kernel. Is there something wrong with requiring that a new user bother to read the documentation? No, but it is also a reasonable expectation for the OS to autodetect and load support for common hardware - which includes most of the popular soundcards. [ I do not speak for the FreeBSD project. ] Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: march is great success ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Fri, 5 Mar 2004, Daniel Lang wrote: Hi, David Raistrick wrote on Fri, Mar 05, 2004 at 08:27:56AM -0800: [..] kldload snd_driver is of course the correct way to do it. FWIW, kldunload snd_driver does /not/ unload all of the modules that kldload snd_driver loads. [..] snd_driver is a module that contains _all_ drivers, thus you have the best chance to get sound working. Unloading it, will of course unload the whole module with all drivers. There is no way to leave one of the drivers in the kernel. I agree, that there is not much documentation which driver module supports which sound device (or I was not successful to dig that up). However, you can determine the correct module, by subsequently loading and unloading each individual driver module. The one which attached to your sound device and actually works (check /dev/sndstat as well) is obviously the correct one. And you really want this to be something somebody new to FreeBSD and possibly unix has to go through to get sound working (afetr finding the documentation, of course)??? Not a very efficient way, but it works. :) Best regards, Daniel -- IRCnet: Mr-Spock - kommst du siehst du, gehst du hast du, weisst du, krass! - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sun, 11 Jan 2004, Andreas Braukmann wrote: On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leidinger writes: fine, but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. and I'm pretty sure, that you'll provide means to migrate the vinum volumes on -current systems transparently and in-place to regular partitions? vinum (IMHO) is a quite valuable piece of software. I'm using it quite intensively; *especially* on -current-boxes I'm in need of most flexible storage management. oh yes - and please fix disklabel to support an arbirtary number of file system per a disk or slice in the process, because otherwise it will not be converting many setups. -Andreas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Where is FreeBSD going?
On Fri, 9 Jan 2004, Lev Serebryakov wrote: Hello, Doug! Thursday, January 8, 2004, 8:29:34 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs revision number, even if you have to use a command line option to get it. But it should not require any kind of special treatment. -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: Where is FreeBSD going?
On Fri, 9 Jan 2004, Lev Serebryakov wrote: Hello, Narvi! Friday, January 9, 2004, 4:28:57 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) N Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs N revision number, even if you have to use a command line option to get it. N But it should not require any kind of special treatment. It is NOT perfectly normal cvs revision number. WHAT TYPE of revision number is it? See, the problem is that you are thinking in overly constrained terms of revision numbers that cvs creates by default, and even so don't think about RCS at all. CVS is not a real CM system its an half-assed one built on top of RCS. 1.2.1 could be a branch (this would be the usual case) or it could be a file revision created by ci(1). in fact, even old (ok, the old here is relative) versions of cvs let you create it as file revision. Normal numbers are (first level of branching is showed only): x.y -- TRUNK x.y.0.(2n) -- MAGIC for branch (in SYMBOLS only) (2n) here is completely - utterly, totaly, etc - bogus. x.y.(2n).z -- Revision on branch x.1.(2n+1) -- Vendor branches (in SYMBOLS only) x.1.(2n+1).z -- Vendor imports see above for 2n. Ok, ok, it should be some broken vendor branch. But what do you say about `1.1.2'? Or even simple `1' (look into sysintall's Attic). simple 1 is simple - somebody was using ci, and forgot about dots. 1.1.2 is similar to 1.2.1. BTW, repo from FreeBSD 4.9 is parsed almost without such errors (sysinstall, pppd + kernel part of ppp, zoneinfo). Some problems are with double symbols (one symbolic name marks two revisions: MAGIC one and simple one), and with symbols, which marks unexistent revisions (many, many such symbols over all repository). But my computer doesn't have enough memory to finish conversion process. It may be worthwhile to collect such and have somebody do a fixup. -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Fri, 9 Jan 2004, Gary W. Swearingen wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. You obviously don't want to discuss this, and it's easy to guess the real reasons. Your main problem here, and apparently that of your lawyers, is that you don't understand what the issues are to which copyright law is to be applied. The legality of collective copyrights was not my issue. Your other problem is putting words in people's mouth; I would never admit to know not knowing US copyright law because I know it quite well enough to argue FreeBSD's IP issues with anybody. If I don't write with the same seeming authority as you, that's more your problem than mine. I expected my comments to be ignored or brushed off, but I didn't expect to be brushed off in your rude and insulting manner. Maybe when I've recovered, and if I haven't made my move to NetBSD yet, I'll write up a more complete explanation of FreeBSD's IP problems instead of trying to deal with the likes of you in a conversation. Please do. But could you also include reasoning for use of US specific view (if thats what you are going to use) as there is essentially no reason why US copyright regulations and practices should preferentialy apply to it. Especially as the licence has no such stipulations about applicable law in it. We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going? the never-ending thread
On Fri, 9 Jan 2004, Matt Freitag wrote: Narvi wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. So there are cases of code by authors being committed into the codebase without their knowledge/consent? This would be a problem. If code is being committed against license, I definitely see an issue here. Consider code merges from Net/OpenBSD. There is no explicit permission involved nor needed. However, If you /GIVE/ your IP to the FreeBSD community, it's no longer yours. Either way, apparently you'll never make everyone happy, even as Well... See, this is the place where people go wrong. Nobody is *GIVING* their IP or code to anybody (and this includes the original sources from Berkeley), they are simply licencing it. And unsuprisingly enough, there is a difference - a big one - between two two. Whetever one needs to be concerned about that is yet againan altogether different matter. The same would by the way apply even if all of FreeBSD was GPL licenced. hundreds (or thousands) of people give away their time to produce something at no cost to you, there's still always going to be someone complaining. (We refer to this as a sense of entitlement - Many people have this, and it's an unfortunate growing fad all over.) If you don't want your code in FreeBSD, don't submit it. Anyone going to pursue some indictments against Coyote Point Systems? Since their load-balancing hardware runs FreeBSD, and I don't believe (I'm unsure, but from the info I've gotten, it doesn't sound like it.) that they give you any of the source with your purchase of their hardware, Hmm There is no scenario at all under which they would have to give you their code. None at all. -mpf + - - | Resistance is futile, assimilation into the FreeBSD community is inevitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Copyrights (was: Where is FreeBSD going?)
On Fri, 9 Jan 2004, Rahul Siddharthan wrote: Narvi wrote: We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. Copyright transfer is certainly not required if the code was released by the original author under a suitable free software licence (BSD/GPL/LGPL or others that permit FreeBSD to redistribute them). All that is required is that you retain the author's copyright statement in the source files. Required for what? For use of the code as we are all doing, sure, no argument. The paragraph above was about his perception of the code being in a shoddy situation due to apparent attribution of copyright to a body in a way that does not actually cause the transfer of copyright to said body (whetever it exists as a legal / physical entity anywhere or not). I just pointed out that the reversal of such situation is essentialy impossible even if such was desirable (which I doubt it is) or tried. And no, IMHO there is no real reason to even try. You can of course not do this with copyrighted material in general. It is the free software licence that allows you to do it if you abide by its conditions. If the claim is that there is code in the tree whose licensing status is doubtful, you should point out that code. I have made no such claim - and I heavily doubt there is such code. I did not make any claims at all about code, only about the copyright ownership and that it essentialy remains in the hands of the developers. Which is ok. And no, I don't really think there is much point in having long discussions over this... [snip - umm, yes] Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Which would obviously mean that there would be lots of volunteers for the position of floppy maintainer? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Steven Hartland wrote: Need necessitates effort? Precicely. Or even more precicely - the RE team provided an alternative path to eliminating floppy support which they could cope with. It follows that people who want floppy support should work towards that because the other option: you tell RE team that they had better shut up and make it work is not workable becuase they have no compulsion to listen to your and could just walk away any minute they bloody well want anyways. It thus follows that some persons out of the we want floppy support to stay around had better start volunteering to be floppy maintainers. - Original Message - From: Avleen Vig [EMAIL PROTECTED] How you made the jump from I don't want to buy a CD burner to install FreeBSD to I will be a floppy maintainer I'm not sure. :-) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On Thu, 29 May 2003, [iso-8859-1] Thorsten Futrega wrote: Dear users, The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. yay! but what about c++ support? - Remove GNU tar. double yay! - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. mostly yawn... If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On Fri, 30 May 2003, Narvi wrote: [snip] Ahem.. i am very embarrassed about having sent the reply, everybody please pretend I was nowhere near the thread, pretty please? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc problem/openoffice failure
On Tue, 27 May 2003, Don Lewis wrote: On 27 May, Julian Elischer wrote: For the last month (more actually)(and after completely rebuilding my system and all the ports on it) I have not been able to compile the openoffice port due to gcc failures. (I have posted the message earlier several times) Has anyone been able to compile the openoffice port recently? somewhere in it's private compilation of mozilla (why does it do that? I already have mozilla running?) gcc (doing c++) has a heart attach and keels over dead. I think the reason to make the build take longer. Lots of fun on 400 MHz PII. the mozilla addresbook - OOo integration part of OOo needs a patch that continues suffer the sad fate of many uncomitted mozilla patches. if you change the main mozilla port to use it, you could just use the main one and no longer need the separate build. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lower power SMP boxes?
On 5 Feb 2003, Benno Rice wrote: On Wed, 2003-02-05 at 07:25, Narvi wrote: On Sat, 1 Feb 2003, Kurt J. Lidl wrote: [snip] How else are you going to do the physical interrupt steering? Unless they have gone through the effort of implementing a whole new and different steering mechanism -- which would fly in the face of having off-the-shelf OS support from the people in Redmond, at the very least. At least at some point there was a thing called OpenPIC which the then big two alternative x86 processor vendors AMD and Cyrix promised to support. In practice I believe it ever only got used on one or two PPC boards. One or two like every new world Macintosh. =) In fact quite a lot of PowerPC boards use OpenPIC as it's specified in the CHRP spec, which IBM and Apple follow for the most part. I know that Motorola's MPC10x host-pci bridge chipsets also have an OpenPIC-compatible PIC in them. I also wouldn't be surprised if the Mai Logic chipset used on the Teron CX motherboards has one as well. Ah, well, I didn't know that it migrated to the PPC mainstream - these are very much 95/96/97 memories. So by virtue of ppc mp support freebsd would also get nearer to x86 openpic mp support (should any such ever show up)? -- Benno Rice [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network block device.
On Wed, 29 Jan 2003, Matthew N. Dodd wrote: On Wed, 29 Jan 2003, Brandon D. Valentine wrote: IMO NBD is less of a hack than you think it is. It is one of the necessary components for creating a single system image from a cluster of commodity hardware and this is something Linux developers are working earnestly on. They're targeting a poor man's NUMA. Sorry, it still sounds dumb. They should really look at Sprite. (And anyone thats doing clustering and not looking at VMS deserves what they get.) On a real cluster running a single image all all the drives would just show up. There wouldn't be any hacking going on. Stuff like this kind of requires 64 bit machines to be at all useful. Only as long as only clusters with some level of single system image (for various values of it) are allowed to be real clusters. But calling NBD a necessary component of a single system image is very probably wrong - its almost at cross purposes to getting to a single system image cluster. NBD is neither needed (you could use say transaction based function shipping for one example) nor sufficent. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network block device.
[cc: reduced] On Wed, 29 Jan 2003, Brandon D. Valentine wrote: On Wed, Jan 29, 2003 at 06:06:20PM -0500, Matthew N. Dodd wrote: What you really want is SCSI over IP. Anything else is just a hack and not to be trusted. I think that NFS is less of a hack than NBD though. IMO NBD is less of a hack than you think it is. It is one of the necessary components for creating a single system image from a cluster of commodity hardware and this is something Linux developers are working earnestly on. They're targeting a poor man's NUMA. In this case the A cluster - no matter how transparently it has a single system image - is not a NUMA. DSM is not really NUMA either, and not all that many things really benefit from DSM - most things aplicable to DSM run better if you use a combination of messgae passing and io/function shipping instead. But going to NBD is a flawed idea in that unless you are planning to use it for a database that can manage its own locking you are better off with a file system instead. idea is that each node [network] boots a very minimal operating system image which acts as a slave to the master node, making its hardware (disks in this case) available via some interconnect using network block devices. Then the operating system on the master node can mount the devices under one unified /. OpenMosix is working on solving the other parts of the puzzle, which are scheduling and cache/memory coherency. Myrinet is rapidly converging on SGI's CrayLink interconnect as a low-latency memory bus, making this possible in the next few years on PC hardware. MyriNet is not a memory bus - its a fast message passing interface. You can use it to imnplement DSM (big suprise, you can with 10Mbit ethernet aswell) but it doesn't have the hardware you would need to actually make use of it as ccNUMA. Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net We've been raised on replicas of fake and winding roads, and day after day up on this beautiful stage we've been playing tambourine for minimum wage, but we are real; I know we are real. -- David Berman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Lower power SMP boxes?
On Sat, 1 Feb 2003, Kurt J. Lidl wrote: On Sat, Feb 01, 2003 at 11:21:49AM -0800, Matthew Dillon wrote: :On Sat, Feb 01, 2003 at 10:17:23AM +0100, Mats Larsson wrote: : Via just recently announced their new Nehemiah processor capable of smp, : presumably slow as its precursor but also the lowest power consuming : processor at the market (at least with standard socket fcpga motherboard) :[...] : http://www.via.com.tw/en/viac3/c3.jsp : :It says IO/APIC support in future versions. So, it's not an SMP option :today, as I understand it. : :-Kurt Although, this is more a deficiency in the way FreeBSD is designed. Using an APIC is nice, but not absolutely necessary. All we need are good specs on how VIA's SMP cpus interact with each other and we could support it. How else are you going to do the physical interrupt steering? Unless they have gone through the effort of implementing a whole new and different steering mechanism -- which would fly in the face of having off-the-shelf OS support from the people in Redmond, at the very least. At least at some point there was a thing called OpenPIC which the then big two alternative x86 processor vendors AMD and Cyrix promised to support. In practice I believe it ever only got used on one or two PPC boards. I like the 11 watts specified in the paper. That *is* low power for the class of system they are selling. I don't see a clock specification but I assume it is going to be at least as fast as the ~900MHz M-9000. It says the new generation VIA C3 processor is available at speeds starting at 1GHz in the paragraph under Enhanced Digital Media Performance. -Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: verbose device probing ?
On Tue, 21 Jan 2003, Bruce A. Mah wrote: If memory serves me right, Arun Sharma wrote: On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote: PS. I personally ignore the severity and priority fields of PRs. The importance of many PRs I've dealt with is very much inflated. Perhaps you should change the severity field to a lower level then ? Or is there a different problem (such as lack of good tools) that prevent you from doing that ? The severity and priority fields can be changed manually but that doesn't solve the problem that relying on the user-specified severity and priority fields for anything meaningful just doesn't work. The only point that I was trying to make with my comment was that you shouldn't place much weight on the contents of the severity and priority fields in the database. This sounds like throwing the baby out with the water - it would be better to find a relatively clueful volutnteer(s) who would make sure the fields are set to sensible values. This is sometimes reffered to asbug triaging. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: verbose device probing ?
On Tue, 21 Jan 2003, Terry Lambert wrote: The priority field is rather ridiculous, in a volunteer project, at least one that does not have some sort of scheduling enforcement (i.e. one could envision a system where all changes must have PR's associated with them, and priority was assigned by consensus through the email moral equivalent of a manager's meeting, and people were not permitted to check in priority N items, if there were any PR's of priority N+1 outstanding, etc.). This is not really true - you can always use the field as a hint to wannabee hackers and patch submitters as to what they should be spending their time on. And while nothing can make sure they actually spend time on those and not other things (whetever related to FreeBSD at all or not) , its better than a mass of largely uncategorized bugs. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Disk reliability (was: Tagged Command Queuing or Larger Cache?)
On Wed, 30 Oct 2002, Greg 'groggy' Lehey wrote: On Tuesday, 29 October 2002 at 2:03:50 +, Daniel O'Connor wrote: On Tue, 2002-10-29 at 01:54, Kenneth Culver wrote: I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives are pretty unreliable though. Hrmm, I havn't tried those, but just about every WD drive I've used has ended up with problems which were of course handled by the warranty, but even then, I still had to reinstall the os and pull a bunch of stuff from my backups which was a pain to do for each failure. Like I said, just my personal experience. I don't think the new 8MB cache drives have been out long enough to actually develop the problems I've seen on WD drives though. Yes, but my point is that the AA drives are bad, but the BB drives seem good. I have been using them for a while (~1 year) without trouble. I've had trouble with BB drives. Given that they have (or had) a 3 year warranty, 1 year of experience isn't very much to go by. Personally I find that no HD manufacturer has a good reputation - they have all made trashy drives at one point. Give the general time it takes for problems to surface vs product lifetimes makes deciding what to buy a PITA :( That's a more valid point. Note that WD and Seagate have dropped their warranty on IDE drives from 3 years to 1 year. What does this say to you? That the cost cutting and pricewars on IDE drives are close to the point where the drives are essentially disposables - buy it, use until fails, throw away and buy a new(er) model. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.1 ISO CRC
On Wed, 2 Aug 2000, Dimitar Peikov wrote: Hi, Could someone send me CRC code for the 4.1 ISO image or to be available on ftp server for downloading? What will CRC give you that MD5 checksums (available) doesn't give you? -- Dimitar Peikov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pointer to people `in charge' of FreeBSD make ?
Ouch! Don't mangle VPATH use. If you want to get the other behaviour, leave the thing in place and provide a switch to get the other one. And no, I am not in charge of FreeBSD make. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some proposals to FreeBSD kernel
[i think this might just as well belong in -questions]
On 10 xxx -1 [EMAIL PROTECTED] wrote:
Hello
I'm 18-year-old newbie UNIX programmer that currently use
FreeBSD and is really thankfull of it.I run it on DUAL PII/333.
Some days ago my friend tell me that with simple user rights
and whit only 1 line of code he could crash my machine. I laught
but he did it :(.
What he wrote was ' int main(void) {while(1) fork(); }' compiled it
and run it. Within a second /kernel said "proc: table is full" and
died. I tried this on some other BSD unixes and the result was
same. (BTW Minix 2.0 seem unaffected and probably other SVR4
variants, because you can limit the number of system processes
and system still have resources to work fine(although slow))
And you can do the same with BSD. See limits(1), csh(1), sh(1),
login.conf(5)
With sysctl() I found that my system can work with up to 532 procs
simulanteously, but didnt found where this value is set in the src/
or probably where it is computed.
See LINT - it is computed from maxusers.
So I sit down and wrote a static library that introduse a new fork()
(nfork()) and _exit() (nexit()) whose only purpose is to lower the
effect ot fast fork()s by sleeping accordingly to the number of times
fork() was called.I tend to make some more things with that piece
of code (in the attachment) and probably to add it to the kenel src
but for now it is easier to use it as a library.
I'm not really sure how usefull this is in general.
Any suggestions about tarball included are welcome.
Looking forward to hearing from you.
Thanks for reading my letterIx
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
On Thu, 6 Jul 2000, Nick Rogness wrote: On Thu, 6 Jul 2000, Sean Lutner wrote: Bridges create a broadcast zone. broadcast packets will cross the bridge unobstructed. OK. So do bridged interfaces fall within the same collision domain?... or are they just members of the same broadcast domain? They can't be in the same collison domain - you'll realise it if you think about it for a second. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default (x86) floating point precision
On Tue, 27 Jun 2000, Steve Kargl wrote: Daniel Eischen wrote: Oddly, this causes problems with GNAT (Ada is a high level language) because it wants/expects 64-bit extended precision. It seems as if GNAT for linux-i386 also uses 64-bit extended precision. The only other GNAT i386 platform that doesn't use 64-bit precision is NT. So is the above comment still valid? Does GNAT use the math library in /usr/lib? I've been testing our math library against UCBTEST, and there appear to be some pecularities. I need to dig deeper to understand all the info produced by UCBTEST. The point of this note is that turning on 64-bit extended precision in GNAT might be compromised by libm.a. Well, some things can easily depend on there being no double rounding to get the correct results. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Josef Karthauser wrote: 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. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) You obviously haven't considered the ability to be able to near hot-swap motherboard and cpu - or even RAM - in this way. Joe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Fri, 9 Jun 2000, Michael Bacarella wrote: I appreciate the KA7 PCI/ISA combo slot instead of the useless AMR thingy Asys has on their praised K7V (mind you, I like Asus as such, excellent experiences with them over the years). Ugh. I was suprised that I couldn't find an Asus K7V without a stupid AMR slot, especially since I only heard good things about the board itself. I made an honest attempt but just ended up ordering it anyway. I've tried to figure out what that slot does but I've only come across market-speak. What does it do? If AMR == Asus Media Slot, then it's a slot that is simultaneously PCI and ISA, so you can have a PCi video card and ISA soundcard on one card. They're about a third of the size of a PCI slot, so I don't see how that would be conveniant. :) But isn't it at the end of a PCI slot? If no, then they actually did come with a next stupid thing that has the same abreviation. A switched away from asus some time before athlon came out. Michael Bacarella New York Connect Net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System management with large groups
On Fri, 19 May 2000, Jonathan Laventhol wrote: Dear FreeBSD Hackers -- I've got a technically-straightfordward but nonetheless business-critical problem with the groups structures in FreeBSD which perhaps you kind souls can help me with. *** BACKGROUND *** [snip] Question 4: What do people think might break? Would it be better, worse, or impossible to do this with NIS? My gut feeling says worse. Have you looked into the ACL patches for FreeBSD? Question 5: Has anybody done anything like a vigr (like vipw) for /etc/group? Our (locally-written) user database would be changing the groups all the time. Many thanks, my FreeBSD heroes, if anybody has anything to offer on this. Best regards, Jonathan. -- Jonathan Laventhol Technology Director Imagination 25 Store Street South Crescent London WC1E 7BL England | Tel +44 171 323 3300Fax +44 171 323 5801 | ___| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] Finding people with GSM phones (was Re: GPS heads up )
On Mon, 8 May 2000, Kris Kirby wrote: BTW, you do realize that in many cases "off" for your cell phone doesn't really mean off, right? :) I have strong objections to small transcievers (what cell phones actually are) that operate close to my body and don't let me know when they are transmitting. When you're talking on it, you know it's transmitting, but I'm talking about just about every other time when you've got it on your belt or clipped to your side. I know they aren't high power, but we don't know long term effects (actually, we do; we just don't know the thresholds for triggering cancer, etc.). Well, maybe we do. Just read the other day that the british are planning to make warning signs compulsory on mobile phones... I'm not thrilled at the aspect of a radio close to my head either. You can feel a radio after it's been transmitting for a while and think: "Something close to the amount of heat generated by this radio has been sent out over the ether and I was standing right in front of it." Yes, to cook your noodle you'd need a couple hundred watts but still, it's energy. - Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. [EMAIL PROTECTED]| --- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
On Sat, 22 Apr 2000, Matthew Dillon wrote: [snip] disk itself is probably the bottleneck. Disk writes tend to be somewhat slower then disk reads and the seeking alone (between source file and destination file), even when using a large block size, will reduce performance drastically verses simply reading or writing a single file linearly. Double buffering may help a disk-to-disk file copy, but I doubt it will help a disk-to-same-disk file copy. Wouldn't coping the file to another disk and then back to the original one than just a simple copy in some cases be faster then? After all, you are saving a lot of head seeks. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 20 Mar 2000, MikeM wrote: Has anyone thought of Unicode support on FreeBSD? Depends on what you mean by 'Unicode support'. If you use a suitable encoding (UTF-8?) everything should work, only it might look strange, as userland doesn't support it. It is largely a 'application space' problem as I understand it - you need to modify each and every utility to know that file names should be treated as strings of wide characters. Toolkits providing a 'select file' std dialog need to be dealt with. I think that it is inevitable that eventually FreeBSD will *need* to support unicode if it wants to continue as a viable operating system in the future. This means that it probably will need to be modified from the ground up. I am not well versed in the specifics of what's needed, but if someone could explain it to me I'd be gratefull. See above for a subset. Is it possible, or is it totally out of the question? What would it require? Is there any way of implementing partial support, working in stages, untill it is fully supported? Thanks, Mike. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dennis' inability to fix the eepro driver
On Sat, 11 Mar 2000, Mike Smith wrote: [snip] Why haven't you considered hiring somebody to document the parts you are intersted in? Would solve at least half the problem... To be fair to Dennis, it's not the cost of paying the dropout to fix this driver that's at issue here. Documentation for the eepro parts is not easy to get; I only have one outdated hardcopy, and I get all sorts of weird stuff thrown at me. Nah. It wasn't in response to anything that dealt with the driver. Nothing to do with eepro at all. It was in response to the rant about how everything was undocumented spaghetty code so few people could make any sense of that people were virtually dependant on those few. [snip] -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dennis' inability to fix the eepro driver
Uhhh... And before anybody gets all kinds of funny ideas, no, i am not trying to blackmail Dennis. On Sun, 12 Mar 2000, Narvi wrote: On Sat, 11 Mar 2000, Mike Smith wrote: [snip] Why haven't you considered hiring somebody to document the parts you are intersted in? Would solve at least half the problem... To be fair to Dennis, it's not the cost of paying the dropout to fix this driver that's at issue here. Documentation for the eepro parts is not easy to get; I only have one outdated hardcopy, and I get all sorts of weird stuff thrown at me. Nah. It wasn't in response to anything that dealt with the driver. Nothing to do with eepro at all. It was in response to the rant about how everything was undocumented spaghetty code so few people could make any sense of that people were virtually dependant on those few. [snip] -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
I snipped the following from the cc: "Jordan K. Hubbard" [EMAIL PROTECTED], Didier Derny [EMAIL PROTECTED], hope they don't mind 8-) On Fri, 10 Mar 2000, Thierry.herbelot wrote: "Jordan K. Hubbard" wrote: [SNIP] If you think it's possible to bend the FreeBSD project to anyone's corporate will then you've never even come close to understanding who we are or what we stand for. That's a shame since one would think 6 years to be more than enough time to gain such an understanding. - Jordan Then, what are the benefits for both parties ? For the FreeBSD project : - many more supported platforms (Sparc, PowerPC, Arm ?) definately. - better Intel SMP ? Possibly not only intel smp, according to Wes Peters. - new developpers ? I would say yes. - increased credibility via the support network of BSDi ? add marekting, market penetration, additional name recognition, corporate contacts and a lot of other things. For BSD/OS : - better exposure thanks to OpenSource ? - Yahoo dollars ? - access to a greater community of **volunteer** testers ? Access to the developer pool ? TfH (This is absolutely not a flame bait : I'm very happy to imagine I could eventually get for-pay support for FreeBSD machines at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Thierry Herbelot /"\ ASCII RIBBON CAMPAIGN \ / AGAINST HTML MAIL NEWS mailto:[EMAIL PROTECTED] X PAS DE HTML http://perso.cybercable.fr/herbelot / \DANS LES COURRIELS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
On Sat, 11 Mar 2000, Marco van de Voort wrote: Then, what are the benefits for both parties ? For the FreeBSD project : - many more supported platforms (Sparc, PowerPC, Arm ?) Merced? . definately. I'm not sure if that is a good thing if it is pursued by the core team, at least not for impopular or older targets. Which targets would these be? ARM? Note that for the code - when it is available for integration - needs to be actually integrated by somebody, not to mention the userland, maintenance, etc. Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm 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, 11 Mar 2000, Dennis wrote: [EMAIL PROTECTED] writes... The very fact that source is available means that you can pay any scruffy unshaven hacker to fix it for you, instead of suffering at the hands and whims of, say, a FreeBSD "vendor" as you are doing. I would figure that at least you (of all people) realize that someone else can come in and get it done, and that you could optionally pay someone to do this. [snip - paying a dropout $100/h to fix drivers] Another point is that Open Source is virtually synonomous with "Totally undocumented". The linux community, years into it, are still totally dependent on Alan Cox to fix drivers properly (mostly because the OS is completely undocumented and changes are made on a whim regularly). D. Becker continues to be the only one that can properly fix the ethernet drivers because they are such a mess and poorly documented. Why haven't you considered hiring somebody to document the parts you are intersted in? Would solve at least half the problem... [snip] dennis Emerging Technologies, Inc. - http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX Multiport T1 and HSSI/T3 UNIX-based Routers Bandwidth Management Standalone Systems Bandwidth Management software for LINUX and FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Generating interrupts ?
On Wed, 13 Oct 1999, Johan Kruger wrote: In DOS it's possible to load the AX register with DA8C and generate a int 15, which will return the BIOS version string and the chipset identification int CL register. How do i do it in FreeBSD, and how do i generate a interrupt for that manner ? You don't. Well, at least not without VM86. Why do you want it? (and what about freebsd-alpha mchines?) Greeting fellow FreeBSD users, by the way, 4.0-CURRENT builds a release just fine, and it's Linux emulator (sorry for the word emulator ) is exellent, try it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Sorry, this is somewhat late. On Wed, 6 Oct 1999, Wilfredo Sanchez wrote: | Have you given consideration to systems where the user/group database is | kept for (possibly a large) number of computers in a centralised manner by | say hesiod or nys (nis+). It would be nice if there was an easy interface | with these so that distributing the local system id numbers need not be | done by hand. It's complicated. We do have a distributed database (NetInfo) and we considered perhaps using the name of the NetInfo domain to determine local vs. foreign. The problem is that distributed databases are sometimes hierarchical, and can be mixed. For example: Well, people for some reason miss the point. What I was talking about is the 'interface', and that it be easy to attach things to it. Site A will want to distribute the ids via hesiod. Site B will want to distribute the ids via nis+. Site C wants to do it via Netinfo Site D wantd to use LDAP. There may be others (SNMP?). One way to do this is for example to have: a) a parameter (by default null) that specifies which program to run to get a list of local system ids b) a parameters (by default null) that specifies which program to run if we want to verify if a certain id has been added to the set of local ids since the startup. As the program can be anything (inc. a shell script) almost any way of distributing the local systems ids can be accomodated. This is of course just one way to achieve it (think of PAM). [snip] -Fred -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fun with vinum
On Mon, 11 Oct 1999, Greg Lehey wrote: On Sunday, 10 October 1999 at 19:33:44 +0300, Narvi wrote: Should you decide to use vinum keep in mind that you: a) reboot to make sure that whatever you just set up can automatically start itself This is always a good idea. You don't have to do it immediately, of course. b) alternatively vinum l vinum makedev vinum create -f configfile vinum start is your friend and avoids most of the problem I don't understand why you would want to do this. You certainly don't want vinum create followed by vinum start. Well, maybe 'vinum start' is not needed. vinum l - load vinum, but not teh disk conf vinum makedev - clean the /dev/vinum directory vinum create ... - tell vinum what the setup is. IMHO it should not panick the kernel when it doesn't like the disk setup. IMO it shouldn't panic. Could it be there's more to this message than you're divulging? Well, that happens if you post too late. The problem is (see a)) that it does not automatically start, or rather, it tries but immediately panicks. And vinum read panicks the system, as does vinum start. The system is 3.3-STABLE, less than a week old. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On Tue, 5 Oct 1999, Pat Dirks wrote: Hi, I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group. We've been struggling with the question of how best to handle permissions on disks that are moved between systems for Mac OS X and Mac OS X Server: the problem is that numeric IDs in inodes (or their moral equivalent) written on the filesystem on one system don't necessarily map to the same user, if they're valid at all, on another system (although they MIGHT). With ZIP drives holding appreciable volumes of data and multi-gigabyte FireWire drives becoming more common this is an issue that will definitely pop up more and more as people carry data with them on removable disk filesystems. [snip] Have you given consideration to systems where the user/group database is kept for (possibly a large) number of computers in a centralised manner by say hesiod or nys (nis+). It would be nice if there was an easy interface with these so that distributing the local system id numbers need not be done by hand. -Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On Wed, 6 Oct 1999, Darren R. Davis wrote: Narvi wrote: [snip] Have you given consideration to systems where the user/group database is kept for (possibly a large) number of computers in a centralised manner by say hesiod or nys (nis+). It would be nice if there was an easy interface with these so that distributing the local system id numbers need not be done by hand. If I was going to look into that kind of approach I would seriously look into some sort of Directory Server tie in through LDAP. Darren Only people at *MANY* sites are already using NIS and Hesiod (or some entirely different way ) and are very unlikely to migrate to LDAP or some other directory or not directory scheme for it, or probably even adapt it. No matter *what* scheme they are already using, they will expect the interface to the system ids to be able to use it. Mandating scheme XYZ is just like saying "Here, this is how we want you to distribute passwords. Forget about Kerberos and NIS+ or whatever other scheme you may have in place." Which is why I only talked about the interface, not what might be behind it or connected to it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: [snip] That's an interesting argument on the part of a few people. The commercial UNIX I first adminned had wired down, short names for disks (rz0, rz1, rz2, ... ). This was very nice. This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. As long as you don't move a hard disk from one bus on the controller to the other 8-) -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
On Fri, 1 Oct 1999, Bruce A. Mah wrote: If memory serves me right, [EMAIL PROTECTED] wrote: This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. Well...I personally prefer the short names. On systems with multiple controllers, the commercial UNIX I used (Ultrix) just continued its numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets you do exactly the same thing. Having long device names is confusing to users who only have one disk controller (and I'd bet this is the vast majority). It took me a long The vast majority has just one disk. Given the fast growth in disk sizes, that majority will not decrease. time to grok the syntax of Solaris device names and I still get confused about this. Commercial or free doesn't have anything to do with this issue...this scheme would force users to remember and type extra characters that many of them don't need. (/dev/da0s1a is long enough, but /dev/dac0t0d0s1a is a little ridiculous for someone that has only one controller and one drive.) If you want to *SOLVE* the problem, then make the disk wiring happen before the kernel is booted. After all, we have a real cute boot loader that can definately load the /boot/disk.wire file 8-) The problem after all is *NOT* one of names but that disks not change names unless the administrator wishes so. It doesn't matter the least how we call them. [snip] Cheers, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On Thu, 9 Sep 1999, Julian Elischer wrote: I think he wants something like an "inverted chroot" (you can see out but others can't see in? (into all facets, e.g. process stats, etc.) It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody in such a 'jar' would not notice (be able to notice) the existence of others at all. With somedata hiding and given file systems mounted only in such a 'jar' the ones in it would have no way of telling. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On Thu, 9 Sep 1999, Julian Elischer wrote: I think he wants something like an inverted chroot (you can see out but others can't see in? (into all facets, e.g. process stats, etc.) It sounds like a FreeBSD VM, VM taken to mean virtual machine. Anybody in such a 'jar' would not notice (be able to notice) the existence of others at all. With somedata hiding and given file systems mounted only in such a 'jar' the ones in it would have no way of telling. julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SPARC?
On Mon, 23 Aug 1999, Dennis wrote: I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? dennis It is more correct to say that it passes in and out of the thoughts of people from time to time, with very little code that has actually materialised. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SPARC?
On Mon, 23 Aug 1999, Dennis wrote: I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? dennis It is more correct to say that it passes in and out of the thoughts of people from time to time, with very little code that has actually materialised. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Doesn't the qsort just switch to isort *if* the partition to sort is short enough? Got to check it out, but afaik the size at that qsorts switch to isort is usually between 8 and 24, with 16 being most common - both halfs are shorter than 16, so they get isorted. Sander There is no love, no good, no happiness and no future - all these are just illusions. On Wed, 18 Aug 1999, Christopher Seiwald wrote: The FreeBSD qsort implementation has a rather nasty degenerate case. If you have data that partitions exactly about the median pivot, yet which is unsorted in either partition, you get get treated to an insertion sort. Example: 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 qsort picks 10 as the median, does no swaps on its first pass, and so decides to switch to an insertion sort. The idea is that if no swaps occur, the data is likely to be nearly already sorted and a good candidate for insertion sort. This turns out to be a (very) bad idea if you have some unsorted data buried in the middle of a (very) large dataset. The implementation claims to come from Bentley and McIlroy's paper, "Engineering a Sort Function," and this is largely true, but the insertion sort optimization(?) isn't in that paper. The GNU qsort.c only does an insertion sort if it is below a certain threshhold in size, and so never attempts such a sort on the whole dataset. (The GNU qsort does a number of other things pooh-poohed in the Bentley paper.) It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. Christopher Christopher Seiwald Perforce Software 1-510-864-7400 [EMAIL PROTECTED] f-f-f-fast SCM http://www.perforce.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Doesn't the qsort just switch to isort *if* the partition to sort is short enough? Got to check it out, but afaik the size at that qsorts switch to isort is usually between 8 and 24, with 16 being most common - both halfs are shorter than 16, so they get isorted. Sander There is no love, no good, no happiness and no future - all these are just illusions. On Wed, 18 Aug 1999, Christopher Seiwald wrote: The FreeBSD qsort implementation has a rather nasty degenerate case. If you have data that partitions exactly about the median pivot, yet which is unsorted in either partition, you get get treated to an insertion sort. Example: 1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11 qsort picks 10 as the median, does no swaps on its first pass, and so decides to switch to an insertion sort. The idea is that if no swaps occur, the data is likely to be nearly already sorted and a good candidate for insertion sort. This turns out to be a (very) bad idea if you have some unsorted data buried in the middle of a (very) large dataset. The implementation claims to come from Bentley and McIlroy's paper, Engineering a Sort Function, and this is largely true, but the insertion sort optimization(?) isn't in that paper. The GNU qsort.c only does an insertion sort if it is below a certain threshhold in size, and so never attempts such a sort on the whole dataset. (The GNU qsort does a number of other things pooh-poohed in the Bentley paper.) It's a pretty straightforward change to bypass the insertion sort for large subsets of the data. If no one has a strong love for qsort, I'll educate myself on how to make and contribute this change. Christopher Christopher Seiwald Perforce Software 1-510-864-7400 seiw...@perforce.com f-f-f-fast SCM http://www.perforce.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch to IA/64, but with IRIX. If SGI wants to continue building Origins, esp the high CPU count ones, IRIX is to stay for a long time. | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. An end to high-end MIPS may come ... if Merced, etc. peform well enough. As this is a topic beaten to death on comp.arch, everybody interested should look there. Nintendo 64 uses MIPS. Which doesn't matter all that much. MIPS cpus for nintendo could be made by say MISP, not SGI (and SGI sold/is trying to sell MIPS). It also seems a bit overzealous. You bet. It seems it is to hard foir the journalists to actually read the press releases. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
On Mon, 16 Aug 1999, Terry Lambert wrote: On Fri, 13 Aug 1999, Terry Lambert wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Given that they say they're dropping IRIX and going with Linux, I don't think it'll be a problem. Can you please site a reference for this, other than wishful thinking by the Linux camp? Here's one: http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html But just about every trade rag covered it. Begging your pardon, but: | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch to IA/64, but with IRIX. If SGI wants to continue building Origins, esp the high CPU count ones, IRIX is to stay for a long time. | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. An end to high-end MIPS may come ... if Merced, etc. peform well enough. As this is a topic beaten to death on comp.arch, everybody interested should look there. Nintendo 64 uses MIPS. Which doesn't matter all that much. MIPS cpus for nintendo could be made by say MISP, not SGI (and SGI sold/is trying to sell MIPS). It also seems a bit overzealous. You bet. It seems it is to hard foir the journalists to actually read the press releases. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
On Sat, 14 Aug 1999, Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method (using my modified libcrypt - see http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz), but ran out of time. I hope to be able to work on it again in a few weeks once I get my computer back, now that I'm in the US. Now taht you are in the US, you have to give it up (until you aren't) or keep a separate versions and describe to others in broad terms what you did to it. You can't save it back there, 'cause that would be exporting 8-) Kris Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
On Sat, 14 Aug 1999, Mark Murray wrote: Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). This makes the most sense. Thrash it out as a port, and if that works, we can bring it into both repositories. Why not just wait and bring the openssl library in? A new telnet authentifications method that just we used is not terribly usefull. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
On Sat, 14 Aug 1999, Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method (using my modified libcrypt - see http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz), but ran out of time. I hope to be able to work on it again in a few weeks once I get my computer back, now that I'm in the US. Now taht you are in the US, you have to give it up (until you aren't) or keep a separate versions and describe to others in broad terms what you did to it. You can't save it back there, 'cause that would be exporting 8-) Kris Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Threaded X libraries
On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: I'm attempting to build the X11 libs with the thread safety stuff (I beleive Linux can already be built like this) and have discovered when linking that we don't have the getpwnam_r getpwuid_r functions in out libc_r. Is anyone planning on adding these? Stephen See the archives - I think it has already come up at least once. Sander There is no love, no good, no happiness and no future - all these are just illusions. It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media Layer) work. It dies quite frequently when starting sound graphics in some of the test apps. I am suspicious that it requires a threadsafe libX11. -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? Sander There is no love, no good, no happiness and no future - all these are just illusions. On Thu, 12 Aug 1999, Nick Sayer wrote: Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff with SRA authentication and IDEA encryption. It requires the libutil from 3.2 (or better), but it appears to work pretty well. Please don't download it if you're outside the US. But if you are in the US, you can grab it from ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz Move your existing /usr/src/crypto/telnet out of the way and unpack the tgz into /usr/src/crypto. Then cd into telnet and make. In particular, anyone who sees any stupid stuff in the Makefiles (I had to guess a lot) or anything that would break existing (kerberos) functionality, please let me know. It seems to me, though, that since there were no Makefiles in there before the kerberos stuff must be using its own Makefiles with these source files or some such magic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Threaded X libraries
On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: I'm attempting to build the X11 libs with the thread safety stuff (I beleive Linux can already be built like this) and have discovered when linking that we don't have the getpwnam_r getpwuid_r functions in out libc_r. Is anyone planning on adding these? Stephen See the archives - I think it has already come up at least once. Sander There is no love, no good, no happiness and no future - all these are just illusions. It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media Layer) work. It dies quite frequently when starting sound graphics in some of the test apps. I am suspicious that it requires a threadsafe libX11. -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SRA+IDEA Telnet
How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? Sander There is no love, no good, no happiness and no future - all these are just illusions. On Thu, 12 Aug 1999, Nick Sayer wrote: Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff with SRA authentication and IDEA encryption. It requires the libutil from 3.2 (or better), but it appears to work pretty well. Please don't download it if you're outside the US. But if you are in the US, you can grab it from ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz Move your existing /usr/src/crypto/telnet out of the way and unpack the tgz into /usr/src/crypto. Then cd into telnet and make. In particular, anyone who sees any stupid stuff in the Makefiles (I had to guess a lot) or anything that would break existing (kerberos) functionality, please let me know. It seems to me, though, that since there were no Makefiles in there before the kerberos stuff must be using its own Makefiles with these source files or some such magic. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
[cc: list trimmed] On Thu, 15 Jul 1999 [EMAIL PROTECTED] wrote: In that scenario, the 512MB of swap I assigned to this machine would be dangerously low. With 13GB disks available for a couple of hundred bucks, my machines aren't going to run out of swap space any time soon, even if I commit to disk. All I want for Christmas is a knob to disable overcommit. --lyndon CVSup the source repository and start writing. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
[cc: list trimmed] On Thu, 15 Jul 1999 lyn...@orthanc.ab.ca wrote: In that scenario, the 512MB of swap I assigned to this machine would be dangerously low. With 13GB disks available for a couple of hundred bucks, my machines aren't going to run out of swap space any time soon, even if I commit to disk. All I want for Christmas is a knob to disable overcommit. --lyndon CVSup the source repository and start writing. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum performance
On Thu, 17 Jun 1999, David E. Cross wrote: I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the 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. Any ideas what I am doin incorrectly? Try changing stripe size. How big is it right now? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum performance
On Thu, 17 Jun 1999, Greg Lehey wrote: On Thursday, 17 June 1999 at 11:10:08 +0300, Narvi wrote: On Thu, 17 Jun 1999, David E. Cross wrote: I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the 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. Any ideas what I am doin incorrectly? Try changing stripe size. How big is it right now? This was a concatenated plex. Do we know that for a fact? It could be concatenated by striping. And no, i am not sure he was using vinum terminology (and he didn't say plex anywhere). Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SGI releases source code of OpenVault
On Thu, 3 Jun 1999, Pavel Narozhniy wrote: Hello Free downloads of source code of OpenVault here: http://www.sgi.com/software/opensource/openvault/ Does anybody want to port it to FreeBSD? -- Pavel Narozhniy nic-hdl: PN395-RIPE http://www.sumy.net I guess there might be those who want to port it. But it's complex and most people don't have tape libraries. Depending on the fate of OpenVault and it's spread, it may well be beneficial to have OpenVault included in the FreeBSD base after some time. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Database holywars?
On Thu, 20 May 1999, Dan Moschuk wrote: | ¿Have you considered PostgreSQL? It is on the ports collection, and is a | heavy duty database engine, with transactions, subqueries (only partial | support), etc. Version 6.5 will be released in about two weeks, and it | adds MVCC (multi-version concurrency control), which will improve a lot | its multi-user capabilities. And, I know of some projects that are using | it for multi-GB databases. I've been using it for or student database | for more than two years (since version 6.0), and am quite happy with | it. See www.postgresql.org for more information. If I recall correctly, isn't postgresql *based* off of the Berkeley DB engine? -Dan No. At least I really don't think so. the lineage of postgresql is postgres-postgres95-postgresql Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Sat, 15 May 1999, Greg Lehey wrote: On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: In the last episode (May 14), David Scheidt said: On Sat, 15 May 1999, Greg Lehey wrote: :It seems there's a need, and the possibility. Would somebody like :to suggest a syntax? ifconfig interface ether ab:cd:ef:fe:dc:ab [options] makes sense to me. And the next step would be to make the kernel realize that two cards ifconfig'd with the same MAC address are meant to be bonded together as one route (lots of switches support this). I have some machines that I'd love to be able to get 20MB/sec bandwidth between transparently. I think you need to reconsider that idea. How are you going to double the bandwidth of the wire? The cards don't have to be on the same wire, they just need to connect to the same switch. Indeed, I don't think two cards can be on the same wire with 10/100BaseT/TX. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
On Fri, 14 May 1999, Wes Peters wrote: Matt Curtin wrote: On Thu, 13 May 1999 10:25:21 -0400, Dennis den...@etinc.com said: Dennis All software has bugs TeX has no bugs. TeX has no *known* bugs. To the best of my knowlege, even Dr. Knuth has not yet been able to *prove* it is correct. But it's the exception, not the rule. It certainly is, but perhaps it shouldn't be. I've worked on a few carefully verified systems, and they are quite expensived to create. They're the kind of systems that you hope would be carefully checked, though, since they involve flinging nuclear bombs at people. Anyone want to pony up a few dozen million dollars to do an NSCCA on FreeBSD? Would somebody use such a version even if somebody did come up with the money? After all the months spent at verifing the correctness of FreeBSD, they would wake up in the world where FreeBSD has meanwhile moved on by some version numbers and has tons of new features everybody wants. IMHO we have some years till we have enough stability that such a thing would be even a sensible thing to do (as in - there are enough people who will want to run it and parts can be merged back). -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
