Re: mktemp() patch
> I still suggest not using symbols at all, since I'd like to be able to > quickly remove tempfiles by hand without worrying if I have to escape # > or ^, etc. Then disable globbing first. (csh et al) "set noglob" or (sh et al) "set -f noglob". John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
> | >which is not believed to cause any problems with shells. The PID is also > | Some shells parse # as a deletion character if memory serves me right. > Also ^ is used for substitutions in many shells (as in ^faulty^ok). Why would you care if some shell used the a character in some special way? In general, you are not going to be typing the filename generated by mktemp() et al. And when you do, use the shell's strong quote (ala ') to escape such characters. (before someone mentions, almost none of these restrictions apply to scripts) > Symbols '=' and '+' are prohibited in some other filesystems. Specific examples of filesystems supported by FreeBSD and likely used by programs invoking mktemp(), please! (I'm not sure that the NetWare filesystem counts!) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
This is the same way that OS servers under Mach3 were developed and debugged! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
> Had > the file been split and a checksum computed for each piece, I could have > grabbed only the affected portion of the ISO. This is screaming for an FTP server mod similar to the wuftpd code that will automatically run tar|gzip. That is, given a file "foo", serve "foo.aa" to be the first (server-defined) chunk size of the file. Define "foo.md5" to be a (precomputed) list of md5 checksums for each chunk. The ftp server automatically just open's and seeks in the single file and returns the proper amount of bytes. Result: server only stores 1 copy (the whole, large file), the clients can grab either the whole or the parts. For instance, ftp://ftp.freebsd.org/pub/FreeBSD/releases/4.0-RELEASE/bin/bin.tgz might be served with a chunk size of 235Kb. BTW, other than the checksums, it is possible for an ftp client to grab arbitrarily sized chunks of a file using the FTP "RESTart" option. I don't know of a client that supports this, but it would be easy to add. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: here's some feedback on 4.0-RC ...
> o Is there a way to increase the number of lines of console output that are > "remembered" when you hit Scroll-Lock. Is this the MSGBUF_SIZE parameter? > What would be the consequences of increasing this slightly? e. The value compiled into the kenrnel is set with SC_HISTORY_SIZE; see LINT or syscons(4). I normally up this to 500. The problem with that is that syscons apparently preallocates all the history memory, for all the virtual consoles. Since MAXCONS defaults to 16, that can be a lot of memory. Perhaps a modest increase in the default SC_HISTORY_SIZE, but with sysinstall doing a CONS_HISTORY ioctl to increase the value on just the first vty? John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
> Again, lemmie get on my soap box, and ask have you looked at the man page, > and compared the memory required when using -s to the memory required by > gzip? Actually, lemmie get on my soap box and ask have you measured the time that bunzip2 takes to run? While it does give better compression in many cases, it is just too SLOW. Using "-s" on decompression just makes it slower. I played on a test machine (PII 233MHz 192Mb, spare ST34502LW disk) with some large package binaries: 17991680 netscape-communicator-4.08.tar 19660800 netscape-communicator-4.61.tar 21934080 netscape-communicator-4.7.tar time gzip *tar 80.284u 1.608s 1:23.66 97.8%113+616k 3+528io 0pf+0w time gunzip *gz 7.984u 1.392s 0:12.84 72.9% 115+674k 498+971io 0pf+0w time bzip2 *tar 220.777u 1.718s 3:44.74 98.9% 61+8531k 936+471io 0pf+0w time bunzip2 *bz2 64.601u 1.928s 1:07.30 98.8%61+4855k 4+964io 0pf+0w time bzip2 -s *tar 205.854u 1.938s 3:32.95 97.5% 61+2388k 1012+492io 1pf+0w time bunzip2 -s *tar 121.860u 2.054s 2:05.65 98.6% 61+3167k 2+965io 0pf+0w A decompression time of 13 seconds vs. 67 seconds (or 125 seconds with "-s). Given that ports and packages need a multi-CD anyway, I don't think the speed penalty of bzip2 is worth it. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel config utility
> Some people were afraid that it would end up like the Windows registry. But it wouldn't, because that isn't the right thing. A kernel config utility should end up functioning like XF86Setup. When was the last time most people made an XF86Config file since that program came around? > and we would need to start providing and maintaining a > database which describes the drivers in more detail. Exactly! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
