Re: [re]writable cdrom drive
> > This does not actually erase the data, so if you have used say 100MB > > you will only have 550MB left. You can actually erase the media using > > 'cdrecord blank=all', which takes a while. > In my experience, this is not true. I have used blank=fast on a CDRW > that has over 500 MB written, and then written another 500 MB without I think there's a little confusion here and I don't want to add to it. But... I thought it the case that a CDRW that is fully reformatted (taking 30 minutes; equivalent to blank=all?) can hold 650MB, while a CDRW that is quickly reformatted (to packet writing aka DirectCD-formatting; is this what blank=fast does?) can hold only about 500 MB. It doesn't matter how is on the disk before the quick format happens. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
> One thing www.buy.com is really good for, ... > is to get pricing information on a general search. You can then use it > to do comparison shopping. Or, just use one of the pricing web servers. I use (and in the order I prefer) Pricescan, KillerApp, and Shopper (web pages are s/.*/www.\1.com/, of course). These allow you to search for the best price from a number of different vendors, including Buy, Onsale/AtCost, etc. The best price on the Yamaha CRW4416S (4x4x16 SCSI INT) is $186, found at Pricescan and from at least 3 vendors. The best price on the CRW6416S (6x4x16 SCSI INT) is $246, found at Shopper (the only one quoting this drive). I like KillerApp's interface the best, but it doesn't carry as many products as the others and lately it's pricing database doesn't seem up to date. Unlike the others, it also gives you technical specs on the products, as well as links to the mfg's specific product page. This is invaluable. KillerApp also lets you make comparisions of multiple products. Pricescan has a search interface similar to, and slightly better than, KillerApp's. It far beats Shopper in terms of usefulness. But, Shopper has more products listed. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
> "32bit is enought for everthing" Just mention the horrible header offset field. Lots of good TCP nits. Anyway, can't this argument be settled by separating the mechanism and policy. Adding a simple rc.conf tweak to enable them should be enough. But, consider going back to the discusssions leading up to the Host Requirements RFC (1122). The particular problem was that the original timeout value for keepalives was tiny (a few minutes). 1122 dictated the corrections for this. Here are the important points from section 4.2.3.6: 1. keepalives MUST default to off 2. the minimum timeout MUST be no less than two minutes 3. keep-alives SHOULD only be invoked in server applications This mostly says that always_keepalive should continue to default to off (but, perhaps, a easy hook in rc.conf should exist to turn them on). John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
Of course, DB 2 is still available as an easily installed port/package. John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
> Right or wrong, you forgot: > > 5. BSD tradition. > > Case 5 justifies Fortran. By that logic, you'd also have to add a Pascal compiler to the base system. Neither makes much sense when they can both be ports (or packages) easily addable at install or compile time by the small % of the FreeBSD population that will actually use them. John "BSD & me: together since 1983" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: EGCS breaks what(1)
> 'what' is broken. C does not impose any sort of address ordering
> restriction on globals or autos that are declared next to each other.
Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh)
that is broken, believing that the two variables will be allocating in
contiguous memory.
Changing newvers.sh to generate
char sccs[] = "@(" "#)" "FreeBSD ...";
char version = "FreeBSD ...";
will make "what" on the kernel work again, at the expense of about 100
duplicated
bytes.
The real question is whether the extreme alignment and padding used by EGCS can
be turned off, especially for 486s.
John
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: T/TCP in FreeBSD-3.x
> Why I'm asking about this, is because I recently read an advice in one > of the FreeBSD mailing lists, > about "Why my dial-up PPP connection from a FreeBSD box is so slow > comparing with Windows NT > (about ten times slower)?" > > And the advice was (without explanations): "Try to switch off the > TCP_EXTENSIONS in /etc/rc.conf". This isn't something that can be fixed in FreeBSD's TCP. Rather, it is a general bug in how TCP Header Compression is defined for PPP and SLIP. Basically, TCP Header Compression will not compress any TCP segment that contains a TCP option. This means the use of ANY TCP option, whether T/TCP or RTTM, will cause your PPP links to not compress those packets and, thus, make your link slower. Unfortunately, just fixing FreeBSD isn't the answer, because you need to fix EVERY implementation of PPP to accept and generate TCP segments with options. The new "IP Header Compression" Internet Draft specifies how this is to be done. John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
