Re: Change default for periodic/weekly/400.status-pkg ?
Miroslav Lachman wrote: > I think it should be user configurable in /etc/periodic.conf if > somebody want to use INDEX or not. It already is user configurable. My point is to change the default, because the current default is useless. It should also be noted that change is "safe", because the output of the weekly cron script does not change at all if everything is alright. Only if some ports lost their origin, this fact is noted in the output. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Change default for periodic/weekly/400.status-pkg ?
Hi, Currently, the periodic/weekly/400.status-pkg script uses the ports' INDEX file if it exists. On my machines, the INDEX file exists, and the periodic script produces output like this: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: $ That is, apparently everything is up to date, so I don't have to do anything. But this is wrong. When I change it to use /nonexistent in place of the INDEX file, I get this output: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages pkg-config-0.25_1 was orphaned: devel/pkg-config $ A-ha! The first line is to be expected (netpbm-manpages is a "fake" port that I maintain locally), but the second line about pkg-config is much more important. Now this makes me look at ports/UPDATING, revealing that pkg-config was replaced by pkgconf. Therefore I propose to change the default for the periodic script to use /nonexistent. It does not change the output that usually appears, it only produces _additional_ output for installed packages whose origin disappeared. This is valuable information, I think. Also, the INDEX file could be outdated, which might lead to wrong results, so using the INDEX file by default is probably not a good idea anyway. Last but not least: Contrary to what the pkg_version(1) manpage suggests, the periodic script actually finishes slightly faster when no INDEX file is used. There doesn't seem to be any reason why the real INDEX file should be used. What do you think? Best regards Oliver PS: Specifying /nonexistent is different from /dev/null. The latter makes pkg_version assume that it is an empty INDEX file, causing different behaviour (not useful) than a non-existing file. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: page fault in pmap_remove_all
Alan Cox wrote:
> On Tue, Aug 10, 2010 at 9:43 AM, Oliver Fromme wrote:
>
> > Hi,
> >
> > This is i386 -current as of 2010-08-04.
> > It was building the toolchain for amd64 when it happened.
> > I'll keep the vmcore around, so I can dig more into it
> > if someone tells me what to do.
> >
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i386-marcel-freebsd"...
> >
> > Unread portion of the kernel message buffer:
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address = 0x0
> > fault code = supervisor write, page not present
> > instruction pointer = 0x20:0xc083bc86
> > stack pointer = 0x28:0xe50a1a94
> > frame pointer = 0x28:0xe50a1ac4
> > code segment= base 0x0, limit 0xf, type 0x1b
> >= DPL 0, pres 1, def32 1, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 5785 (install)
> > trap number = 12
> > panic: page fault
> > Uptime: 6h13m9s
> > Physical memory: 951 MB
> > Dumping 182 MB: 167 151 135 119 103 87 71 55 39 23 7
> >
> > #0 doadump () at pcpu.h:231
> > 231 __asm("movl %%fs:0,%0" : "=r" (td));
> > (kgdb) list *0xc083bc86
> > 0xc083bc86 is in pmap_remove_all (atomic.h:318).
> > 313 atomic_readandclear_int(volatile u_int *addr)
> > 314 {
> > 315 u_int res;
> > 316
> > 317 res = 0;
> > 318 __asm __volatile(
> > 319 " xchgl %1,%0 ; "
> > 320 "# atomic_readandclear_int"
> > 321 : "+r" (res), /* 0 */
> > 322 "=m" (*addr) /* 1 */
> > (kgdb) backtrace
> > #0 doadump () at pcpu.h:231
> > #1 0xc05daef0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
> > #2 0xc05db11d in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:590
> > #3 0xc0840583 in trap_fatal (frame=0xe50a1a54, eva=0)
> >at /usr/src/sys/i386/i386/trap.c:945
> > #4 0xc08407d0 in trap_pfault (frame=0xe50a1a54, usermode=0, eva=0)
> >at /usr/src/sys/i386/i386/trap.c:858
> > #5 0xc0840cf3 in trap (frame=0xe50a1a54) at
> > /usr/src/sys/i386/i386/trap.c:533
> > #6 0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> > #7 0xc083bc86 in pmap_remove_all (m=0xc150e9e8) at atomic.h:318
> > #8 0xc07e9544 in vm_fault (map=0xc38463c0, vaddr=684290048,
> >fault_type=1 '\001', fault_flags=Variable "fault_flags" is not
> > available.
> > ) at /usr/src/sys/vm/vm_fault.c:499
> > #9 0xc08406c0 in trap_pfault (frame=0xe50a1d28, usermode=1, eva=684290048)
> >at /usr/src/sys/i386/i386/trap.c:837
> > #10 0xc0840b5e in trap (frame=0xe50a1d28) at
> > /usr/src/sys/i386/i386/trap.c:399
> > #11 0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> > #12 0x0804858c in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (kgdb)
> >
> >
> If at all possible, I would like to know the value of "pv->pv_va" in
> pmap_remove_all().
Sure.
(kgdb) print /x pv->pv_va
$1 = 0x28c89000
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] [sys/conf/newvers.sh] Cleanup and additions.
jhell wrote: > Based on the parts of the script with the additions for tracking source > using git(1) I set out to add support for mercurial hg(1) and ended up > cleaning some of the script while making some of those additions. > [...] > I have opened a PR: misc/149510 here: http://bit.ly/buBqXc Just out of curiosity, why are you obfuscating this if statement? -if [ ! -r version ] -then -echo 0 > version -fi +[ ! -r version ] && echo 0 >version It should rather be fixed like this (FreeBSD standard is to put if...then on one line): -if [ ! -r version ] -then +if [ ! -r version ]; then On a tangential note ... I've been using a wrapper script for "make kernel" for ages, long before svn existed. It adds the date of the checked-out sources to the release name, e.g. uname -rsm gives "FreeBSD 8.1-PRERELEASE-20100720 i386" on this machine. http://people.freebsd.org/~olli/scripts/makekernel Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
page fault in pmap_remove_all
Hi,
This is i386 -current as of 2010-08-04.
It was building the toolchain for amd64 when it happened.
I'll keep the vmcore around, so I can dig more into it
if someone tells me what to do.
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc083bc86
stack pointer = 0x28:0xe50a1a94
frame pointer = 0x28:0xe50a1ac4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 5785 (install)
trap number = 12
panic: page fault
Uptime: 6h13m9s
Physical memory: 951 MB
Dumping 182 MB: 167 151 135 119 103 87 71 55 39 23 7
#0 doadump () at pcpu.h:231
231 __asm("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc083bc86
0xc083bc86 is in pmap_remove_all (atomic.h:318).
313 atomic_readandclear_int(volatile u_int *addr)
314 {
315 u_int res;
316
317 res = 0;
318 __asm __volatile(
319 " xchgl %1,%0 ; "
320 "# atomic_readandclear_int"
321 : "+r" (res), /* 0 */
322 "=m" (*addr) /* 1 */
(kgdb) backtrace
#0 doadump () at pcpu.h:231
#1 0xc05daef0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05db11d in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc0840583 in trap_fatal (frame=0xe50a1a54, eva=0)
at /usr/src/sys/i386/i386/trap.c:945
#4 0xc08407d0 in trap_pfault (frame=0xe50a1a54, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:858
#5 0xc0840cf3 in trap (frame=0xe50a1a54) at /usr/src/sys/i386/i386/trap.c:533
#6 0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#7 0xc083bc86 in pmap_remove_all (m=0xc150e9e8) at atomic.h:318
#8 0xc07e9544 in vm_fault (map=0xc38463c0, vaddr=684290048,
fault_type=1 '\001', fault_flags=Variable "fault_flags" is not available.
) at /usr/src/sys/vm/vm_fault.c:499
#9 0xc08406c0 in trap_pfault (frame=0xe50a1d28, usermode=1, eva=684290048)
at /usr/src/sys/i386/i386/trap.c:837
#10 0xc0840b5e in trap (frame=0xe50a1d28) at /usr/src/sys/i386/i386/trap.c:399
#11 0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#12 0x0804858c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"The most important decision in [programming] language design
concerns what is to be left out." -- Niklaus Wirth
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
Steven Hartland wrote: > Thanks Jeremy, from that we get:- > > i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 The important thing is the "chip" ID: 0x10c98086 The lower half is the vendor ID: 8086 is intel. The upper half is the device ID: 10c9 is the 82576 gigabit NIC. You can look up these numbers on http://pciids.sf.net for example. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: machdep.guessed_bootdev sysctl on i386
Simon L. Nielsen <[EMAIL PROTECTED]> wrote: > PicoBSD does not necessarily have awk (actually most likely doesn't > since awk is 'big'). cut could be used instead since it much smaller : > > mount | grep 'on / ' | cut -f 1 -d ' ' > > Perhaps somebody has a better way? Does PicoBSD have sed? If it does: mount | sed -n 's/^\([^ ]*\) on \/ .*/\1/p' Doesn't win a beauty contest, but saves one exec. (It could be done with ed, too, if there's no sed.) Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preferred Gigabit interfaces for -CURRENT
David Gilbert <[EMAIL PROTECTED]> wrote: > We're about to make the switch from 100M interfaces to GigE interfaces > for our transit routers ... which are FreeBSD-5.0 based SMP (Athlon) > boxes. Our current favorite card is the intel i82559-based fxp > cards. They handle the load best on our testing of 100M cards. > Remember that our load is large and small packets and that hardware > checksums are not a win (although hardware vlans are). As far as I know, all of the GigE cards do hardware checksums anyway. Those which support VLAN de/muxing in hardware are listed in the vlan(4) manpage and in the respective interface manpages (bge, em, gx etc.) -- I think most of them do, if not all. > So... I need to know what GigE chipsets I should test. I recently > tested Intel GigE cards ... with dismal results... less than half the > packets-per-second on the (otherwise) same hardware. Small packets > (as in DOS attacks) are a real concern here. > > I believe that someone here recomended Tigon III based cards ... but I > was recently looking through 5.0-RELEASE's hardware notes and couldn't > find any mention of Tigon III. That's the Broadcom BCM570x chipset (bge driver). It's only inofficially called "Tigon III" because it's based on the Tigon I/II from Alteon. Having said that -- We do have a bunch of Compaq DL360-G2 machines in production, each of which has two of those bge interfaces. We make heavy use of VLANs, and the performance is very good. However, we're running 4.7 (because they are production servers), and our packet profile is probably very different from yours (most of the traffic is NFS, HTTP, SQL queries and similar things). Regards Oliver PS: "a bunch" == about 20 of them, more to come. -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 issues
First of all, is this the right mailing list for issues with FreeBSD 5.0-Release? I apologize if it is not. I've installed it on an Athlon-500, and it's running quite well (except it seems a bit less performant than 4.x, but that's OK). However, I have two questions. 1. I have some shell scripts that make use of redirections with file descriptors (3>&1 and /dev/fd/3 etc.). Those worked under 4.x out of the box, but didn't work in 5.0, because there is no /dev/fd/3 in DEVFS. I solved this by manually mounting FDESCFS over /dev/fd -- is that the right solution, or is there a better way? 2. It seems that vmstat prints weird values: procs memorypage disks faults cpu r b wavm fre flt re pi po fr sr ad0 md0in sy cs us sy id 2 2 0 122848 23320 10 0 0 0 10 3 0 0 15852 0 1503 73 15 12 1 2 0 122848 22992 1 0 0 0 17 0 0 0 15911 0 1484 83 17 0 2 2 0 122848 22632 0 0 0 0 18 0 0 0 15916 0 1451 81 19 0 In particular, the "sy" (system calls) column is always zero, and the values in the "in" (interrupts) column are much too high. This machine is running with HZ=500, and "vmstat -i" reports a total interrupt rate of 628, which seems more reasonable. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
Alexander Leidinger <[EMAIL PROTECTED]> wrote: > Oliver Fromme <[EMAIL PROTECTED]> wrote: > > The patch adds an option -r to chown(8) and chgrp(1), which > > does pretty much the same as the -r option of touch(1) and > > truncate(1). Basically, it let's you "copy" ownerships and > > group memberships from one file to another, which is useful > > in scripts. > > I'm concerned about the used character: "-r" is similiar to "-R" Why exactly is that cause for concern? What character would you suggest instead? touch(1) and truncate(1) also use "-r". Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
David Wolfskill <[EMAIL PROTECTED]> wrote: > On Sat, Nov 16, 2002 at 12:29:20PM +0100, Oliver Fromme wrote: > > I've submitted a small patch (bin/45333) for both -stable > > and -current, but I haven't been able to test it under > > -current (due to lack of a spare machine). Would someone > > please give it a try and let me know if it compiles and > > works? > > Seems to for me (today's -CURRENT). Thanks! > I did take the liberty of removing the extraneous space on (the new) line > 151 (so its "if" lines up with those on lines 153 & 155), Oops, you're right, somehow there are spaces instead of tabs in that line (probably left over from copy&paste). > and of > replacing the 'usage:' on (the new) line 305 (chgrp's usage() message, > showing the second alternative invocation) with whitespace (to match the > pattern for chown). Right again, I missed that. > (If someone wants my diff, please let me know. > It's not sufficiently different from what Oliver put in his PR to > warrant spamming -current, as far as I'm concerned.) I've sent a small follow-up to the PR. > > The patch adds an option -r to chown(8) and chgrp(1), which > > does pretty much the same as the -r option of touch(1) and > > truncate(1). Basically, it let's you "copy" ownerships and > > group memberships from one file to another, which is useful > > in scripts. > > Makes sense. Only reservation I'd have -- and this may well be > unfounded -- is to be sure we're not introducing gratutitous > differences with respect to other implementations or to applicable > standards. I have no problem with functional differences that don't > break standards conformance (to the extent we claim it, anyway). I have checked a number of other operating systems including our brother and sister BSDs (Net- and Open-), Solaris and Tru64. There are no collisions nor similar functionality with different syntax. I also checked SUSv3 / POSIX, same result. On the other hand, GNU chown/chgrp (used under Linux) does have such functionality (what a surprise), _but_ only with a GNU-style long option: --reference=. There is no short single-letter option for it. Clearly, I decided not to introduce GNU-style long option into our chown/chgrp. ;-) > Hope this is useful. It is indeed, thanks! Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When do you plan 5.0-RELEASE?
Flag_reda <[EMAIL PROTECTED]> wrote: > On Sat, Nov 16, 2002 at 03:24:56PM +0100, Alexander Langer wrote: > [5.0-Release] > > It's currently shifted to December. The release schedule will be updated > > soon. > > really? > when, more or less? > > /me has to write 128kb of text in the next few days Write it with MS Word. You'll easily get a 128kb file within a few minutes. But seriously ... I don't think it's a good idea to invest major amounts of money and/or time into something that depends on the accuracy of a certain release date. Even -stable releases have been moved by several weeks in the past because of late show-stoppers. And 5.0-Release will not be a -stable release, so I expect it will not be particularly punctual. Also, remember that 5.0-Release already had been moved by one year (!) and now by another month. I think it's not completely unrealistic to expect that 5.0-Release might not happen in 2002. Disclaimer: I'm not an official release engineer etc., and I'm sure someone will tell me that I don't have a clue anyway. :-) Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Asking for tester (small patch to chown(8)/chgrp(1))
Hi, I've submitted a small patch (bin/45333) for both -stable and -current, but I haven't been able to test it under -current (due to lack of a spare machine). Would someone please give it a try and let me know if it compiles and works? The patch adds an option -r to chown(8) and chgrp(1), which does pretty much the same as the -r option of touch(1) and truncate(1). Basically, it let's you "copy" ownerships and group memberships from one file to another, which is useful in scripts. Thanks! Best regards Oliver PS: http://www.freebsd.org/cgi/query-pr.cgi?pr=45333 PPS: If you reply to the list, please do not Cc me. I do read the list. -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP system hangs on current, not stable
Pete Carah <[EMAIL PROTECTED]> wrote: > Maybe I need an NMI button (or does that work?) You can generate NMIs by shortening the first two pins of an ISA slot with a screwdriver (the two pins close to the back where the ISA slot covers are). This can also be done with PCI slots, if that board doesn't have an ISA slot anymore, but I don't know which pins (it's _not_ the first two pins), and it's a lot more difficult because the PCI pins are much smaller. Disclaimer: Don't sue me if you toast your board. :-) Do it at your own risk. Read the docs first. Check the pin assignment. Make your last will and testament first, etc. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: adding athlon xp to bsd.cpu.mk
David O'Brien <[EMAIL PROTECTED]> wrote: > On Sun, Oct 28, 2001 at 02:06:00PM -, cameron grant wrote: > > my system with dual 1.1ghz durons identifies as: > > > > CPU: AMD Duron(tm) MP Processor (1110.94-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x670 Stepping = 0 > > Wonder why you get the 'MP' and I don't: > > CPU: AMD Athlon(tm) Processor (1194.46-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 The string is programmed by the BIOS into the CPU. So it depends on the BIOS. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New features for -current
Riccardo Torrini <[EMAIL PROTECTED]> wrote: > Would be a great idea add /dev/uphoto and even better a sort > of photo-file-system, where read is mapped to download image, > unlink to delete and maybe create file to take a picture so > we can use ls, cp, rm and touch to access photo camera... Yes, great idea, Riccardo -- please do it. :-) However, there is no standard for accessing digital photo cameras via USB. Recently, some of them seem to comply with the mass storage protocol (BSD's umass driver), but the majority of them use proprietary protocols. Even the same vendor uses different protocols for different of his cameras. So, basically you would have to write a separate kernel driver for every camera. This isn't feasible. It is probably much better to handle these issues in userland code. As an example, you could have a look at the "oPhoto" tool which handles the Kodak DC240, DC280 and DC3400 under Free- BSD (and possibly also others, but _not_ the Kodak DC220, DC260 and DC265). These are all USB photo cameras. The tool is written in userland code and uses the generic ugen driver to access the camera, which works pretty well. If you absolutely want to access the images like a real filesystem (I don't think this would have any real advan- tage), you could wrap an NFS userland server around the code. Bloating the kernel with such stuff is a bad idea, IMO. Regards Oliver PS: oPhoto: http://www.fromme.com/ophoto/ -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lots of Linux zombies (mtvp)
Mikhail Teterin <[EMAIL PROTECTED]> wrote: > After watching some MPGs with the Linux binary-only mtvp (graphics/mtv > port) I noticed 40 zomby processes: Sorry, this is not really an answer to your question, but for playing MPEG files, I've found vlc and mplayer very useful, and in general better than mtv/mtvp. They're both in ports/graphics, too. They're opensource (i.e. no linux binaries necessary), and they even uses hardware scaling through either the xvideo extension or SDL (in ports, too), so requiring little CPU, even for fullscreen playback. (Personally I prefer mplayer. YMMV.) > root@aldan:~ (220) ps -alwwx | grep 68256 > 105 68256 1 0 96 0 00 - Z p10:00,00 (mtvp) This might be a strange idea, but have you tried to "kill -CHLD 1"? This wouldn't be a real solution, of course. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI??? was - Re: -current TCP performance hosed?
Geoff Rehmet <[EMAIL PROTECTED]> wrote: > On Sun, Sep 16, 2001 at 12:37:53PM +0200, Oliver Fromme wrote: > > Have you verified that the duplex setting of your network > > interface is correct? It should be set to half-duplex if > > the machine is connected to a hub. Don't trust autoselect. > > Check the collision LEDs at the card (if present) and at > > the hub during data transfer. If everything looks OK, try > > putting a different card into that machine. > > My ethernet card is definitely running half duplex. Also, > as I mentioned, as a client, the box behaves fine, but not > as a server. Well, duplex mismatch can result in asymmetric behaviour. It could be a problem with the transmit part of the driver. You didn't mention what kind of NIC and driver you use, IIRC. Maybe trying a different NIC could indicate whether this is a driver problem or something else. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI??? was - Re: -current TCP performance hosed?
Geoff Rehmet <[EMAIL PROTECTED]> wrote: > No, I can't say for certain when this started. In fact, reverting to a > kernel from June 27 still shows the same problem. > > However, I have done the following exercise, with three machines, > two of which sit on our internal LAN together, on the same hub, with > the third sitting on our public network (in our hosting room). > [...] > At this point, this seems, from the empirical evidence, to have nothing > to do with ACPI. This is probably a dumb question, but just to make sure ... Have you verified that the duplex setting of your network interface is correct? It should be set to half-duplex if the machine is connected to a hub. Don't trust autoselect. Check the collision LEDs at the card (if present) and at the hub during data transfer. If everything looks OK, try putting a different card into that machine. I'm running -current with some DEC clone NIC connected to a FastEthernet switch (running full-duplex), and there's no TCP performance problem. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
[broken quoting fixed] Kory Hamzeh <[EMAIL PROTECTED]> wrote: > Ted Mittelstaedt wrote: > > I've had a bit of experience with this sort of thing and I have > > to say that > > nobody should be running an open FTP server that allows uploading > > to anyone > > unless they are willing to take the time to monitor it - and I mean every > > day, preferably several times a day. > > [...] > > Yup, I had some jerk constantly fill up the filesystem of the ftp directory > until I finally disabled all uploads. The ethics of some people just amazes > me. If you absolutely need to have an anonymous upload directory, it is probably a good idea to disable ls and read-permission in that directory. That way people can upload things, but they can neither list nor download them without prior operator intervention. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
David O'Brien <[EMAIL PROTECTED]> wrote:
> > _But_ my vote would be for still having a "real" csh in
> > /bin, additionally. (And don't tell me that tcsh is a
> > real csh -- it's not, see below.)
>
> By chance have you looked at the csh source in the CSRG SCCS files?
> How about the tcsh sources from "day 1" in its CVS repository?
> Tcsh *is* a direct decendent of CSRG csh. Christos Zulas maintined the
> CSRG csh in the 4.4 days.
No doubt about that, but that's not the point. Did you
read what i wrote further down in my message (what I
referred to by "see below")?
"Our" csh still behaves differently like any /bin/csh on
any other system that I know, and can't be easily made to
behave like them.
When I wrote "real csh", I meant a csh which exhibits the
traditional behaviour and user interface ("look and feel",
if you prefer) of a csh. tcsh does not. Someone used to
work with a "real csh" simply can't be happy with tcsh,
especially if he has to change frequently between using
FreeBSD and other systems. It's a real PITA.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 24, 2001 at 11:10:53PM -0500, Matthew D. Fuller wrote:
> > So yes, there's a difference. But, on the flip side, I think that
> > the fact that it's been this long without anybody screaming majorly
> > (after the initial shakedown, of course) kinda sums it up.
Probably because it's just too late. During the initial
discussion, the voices pro and contra were about 50:50 (at
least that was my impression), and finally the pro ones
succeeded, probably because they had more "weight" (this
is not a democracy anyway). After the change was done and
committed, chances to revert it were even smaller.
I'm well aware that this discussion now is probably very
useless. I'd like to write down my concerns anyway, just
to show that there _is_ indeed "anybody screaming".
If you don't want to read my nagging, stop reading now. :-)
I'm not so much opposed to having tcsh in the base, and
even in /bin (I'm not using it anyway). Sure, there is
the "bloat" argument, but we also have perl in the base,
which is much more of a bloat. (Perl is another story.)
_But_ my vote would be for still having a "real" csh in
/bin, additionally. (And don't tell me that tcsh is a
real csh -- it's not, see below.) Those who voted for
replacing csh with tcsh probably haven't really used csh
as their login shell recently, otherwise they would have
noticed that it is not a full replacement.
> There are differences in defaults, yes, but are there differences
> which can't be fixed by setting options? That's what's being asked.
I think that a /bin/csh should behave like a traditional
/bin/csh by default already, without having to go through
the (large!) tcsh manpage in search for the right options.
FWIW, a few csh users have complained to me that the user
interface behaves completely different, e.g. filename
completion, entering of tabs, certain types of history
expansions ("!2foo") etc., and they haven't been able to
make it behave like a real csh using tcsh options. (If
someone knows, for example, how to make it accept a single
"Esc" for filename completion without a delay, please let
me know.)
I will probably just install the 4.4BSD csh over /bin/csh
to get rid of those complaints.
I for myself don't really care much, I don't use csh or
tcsh (anymore). In singleuser mode I definitely prefer
/bin/sh over those nowadays. But I think that users who
want a "real" (i.e. traditional) csh should be able to get
one, without having to get used to a user interface that's
different from all other systems (Solaris, Tru64, ...).
Sure, I could install it as a port (after I have found out
that such a port exists -- it's not documented anywhere),
but installing or copying the port into /bin isn't exactly
a clean solution.
Not having a real /bin/csh on a BSD system is like removing
/usr/games. Sacrilege. ;-)
Just my 2 Euro Cents.
Regards
Oliver
PS: Should we redirect this to -chat? Or perhaps better
yet, to private mail. (No Reply-To set, so it's your
decision, but please let me know because I'm not normally
looking at the -chat folder.)
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
Andrew Kenneth Milton <[EMAIL PROTECTED]> wrote: > Once it's in the Public Domain you have abandoned your claim to copyright. Actually, that is not possible, at least in some countries (including Germany, for example). If you're the author of some piece of software, you're the holder of the "Urheberrecht" (the rights that you have, being the author). You cannot get rid of your Copyright even if you wanted to. There is no notion of "public domain" in the law. Declaring the software to be "public domain" merely means that you attach a license to the effect that everyone can do anything with it without asking you, _but_ you are still the original author, with all associated rights that you have as such. Actually you don't even have to include a phrase like "Copyright (C) 2001 by John Doe", because it's implied. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: quick query
Paul <[EMAIL PROTECTED]> wrote: > sorry to bug this list with this question. I'd like to test the newer > ray(4) driver that's in -CURRENT. What snapshot should I install? Is > there anything else I should know before installing -CURRENT? (besides > what the "cutting edge" section of the handbook says) I just installed the latest snapshot available from current.freebsd.org (20010618, I think) and then went from there to the latest sources using CVSup. That was on Thursday evening. Buildworld etc. went without a problem, and the box (a dual Celeron-466) is running happily since then, with SMP enabled, Soft-updates and what-have-you. Of course you should read src/UPDATING and have an eye on this mailing list and on the commits. Regards Oliver PS: My reason to try out -current was the umass driver. I was hoping to get a USB-IDE box running, but it does not look like it's willing to work with FreeBSD. :( -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Brian Somers <[EMAIL PROTECTED]> wrote: >> If I'm not mistaken, the size of the environment is already >> taken into account by the xargs utility (subtracted from >> ARG_MAX). So this isn't an issue at all. > > Unless xargs runs a command with lots of arguments and that command > increases the environment size then tries to run another command with > the same arguments - bang (E2BIG). True, but that's certainly not xarg's fault (and it cannot be fixed in the scope of xargs). xargs has no way to know if the command will enlarge its environment, and by what amount. In such a case it's probably up to the script writer to chose a sensible value for xargs -s . Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Rodney W. Grimes <[EMAIL PROTECTED]> wrote:
> > Before anyone starts writing scripts, consider that {} will be
> > replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
> > stuff coming off the pipe. If your combined arguments plus
> > environment exceeds ARG_MAX execve(2) will give you E2BIG.
>
> No rain here, it is ARG_MAX - 2048:
> -s size
> Set the maximum number of bytes for the command line length pro-
> vided to utility. The sum of the length of the utility name and
> the arguments passed to utility (including NULL terminators) will
> be less than or equal to this number. The current default value
> for size is ARG_MAX - 2048.
>
> 2K would be a pretty big env, root default std is about 367 bytes.
>
> Yes, that is probably not a portable assumption to make, but it is
> far better than using non-standard options to xargs.
If I'm not mistaken, the size of the environment is already
taken into account by the xargs utility (subtracted from
ARG_MAX). So this isn't an issue at all.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Fix for union mount problem
Hi, Would someone please have a quick look at "bin/26498"? It's a trivial one-line patch for the libc that fixes an annoying bug that occurs when using union mounts (i.e. mount -o union, _not_ unionfs). More details are in the PR. It applies to both -current and -stable. Thanks! Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Dima Dorfman <[EMAIL PROTECTED]> wrote:
> I don't have a copy of SuSv2 or anything else that defines -I and -i,
http://www.secnetix.de/~olli/susv2/xcu/xargs.html
> but from what I can gather, -i is the same as "-I {}" and -I allows
> things like this:
Not exactly. The difference is that the option-argument to
-i is optional and -- if present -- has to follow without
whitespace after the -i. This is a violation of the common
utility syntax guidelines, but has been adopted by SUSv2
because it was widely implemented.
So ``-i'' is the same as ``-I {}'', and ``-i[]'' (no space!)
is the same as ``-I []''.
Unfortunately, when you use -i or -I, then each line from
stdin is used as a signle argument, and the utility is
invoked once for every line, unless I misunderstand what
SUSv2 is saying. :-(
$ cat test
foo bar
baz bla
$ xargs -i echo XXX '{}' YYY < test
XXX foo bar YYY
XXX baz bla YYY
$
> Does that mean everyone is blind and missed my arrogant cross-post of
> the amazingly short patch to do this, or are we just interested in
> discussing it and not testing the implementation? ;-)
I must have missed it, and I think it's at least a good
start. :-)
The patch looks good. At leat it would solve the problem
which this thread is about, although I think it doesn't
comply with SUSv2.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Brian Dean <[EMAIL PROTECTED]> wrote: > But extending cp does solve the problem. Only for cp. It wouldn't solve the problem for mv, ln and a bunch of other tools. Fixing it at _one_ place in xargs would solve all of that without touching a dozen tools. > [...] > This makes cp work with xargs; > > % cat ReallyBigListOfFiles | xargs cp -d target That's actually a bad example anyway, because you would use cpio in that case, not xargs|cp. It's also a bad example for using cat, but that's a different story. :-) cpio -dup target < ReallyBigListOfFiles Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jordan Hubbard <[EMAIL PROTECTED]> wrote: > From: Oliver Fromme <[EMAIL PROTECTED]> > > Not all users use /bin/sh. Scripts needn't be written > > in /bin/sh ... > > Actually, just to jump in and correct this, scripts *should* be > written in /bin/sh. It depends. I often happen to write zsh scripts, but only if I'm sure that they don't really have to be portable, and that I am the only one who will ever use them. When I was young, I also wrote a few tcsh scripts (*ouch*), but I discontinued doing that long ago. :-) I agree with you 100% that portable scripts should use /bin/sh and nothing else. And to come back on topic: Portable scripts also should _not_ assume that there are no limits on the length of shell commands. On the other hand, portable scripts can legitimately assume that xargs supports -i and -I, which ours doesn't. Regards Oliver PS: FWIW, I also write a lot of awk scripts, which is my favourite scripting language, but this is really getting off-topic ... -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
Paul Herman <[EMAIL PROTECTED]> wrote: > On Sat, 21 Apr 2001, Oliver Fromme wrote: > > I'm wondering why /bin/df is set-gid to the operator group > > by default. > > It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or > whatever) as user nobody with chmod 555 /bin/df. Ah, thanks for clueing me. :-) I didn't know that unprivileged users are supposed to be allowed to use df on non-mounted filesystems. I think I'll keep it at mode 555 on my machines. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/bin/df set-gid operator
Hi, This is probably the wrong list, but I have no idea where else to ask, and -current is also affected, so ... I'm wondering why /bin/df is set-gid to the operator group by default. I have tried to remove the s bit, and it is still working fine. Looking at the source code didn't give me a clue either. -1- Am I missing something? What? -2- If I'm not missing anything, then shouldn't the BINMODE line be removed from src/bin/df/Makefile? -3- Shall I send-pr a patch? :-) Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Sheldon Hearn <[EMAIL PROTECTED]> wrote: > On Sat, 21 Apr 2001 16:51:24 +0200, Oliver Fromme wrote: > > That can overflow your shell's command line limit (at the > > "for" command). True, our /bin/sh doesn't has such a > > limit, AFAIK, but there _are_ shells that do). > > That's actually my point. What's being proposed is a non-standard > extension to work around a problem on a system that already doesn't have > the problem. Maybe I didn't make myself clear enough. We _do_ have a problem. Not all users use /bin/sh. Scripts needn't be written in /bin/sh, and xargs can be used interactively, too (I use it a lot). Just because _our_ xargs works fine with _our_ /bin/sh doesn't mean there is no problem. And then there's the gross efficiency problem. Try these alternatives and compare how long they take: for i in `find /usr/ports -type f`; do cat $i >/dev/null done find /usr/ports -type f | xargs cat >/dev/null The latter is a hell of a lot faster. (The example uses "cat" just because it works with xargs.) By the way, the first (inefficient) approach could be rewritten like this: find /usr/ports -type f | while read i; do cat $i >/dev/null done This avoid the potential line limit problem, but of course it's just as inefficient. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Sheldon Hearn <[EMAIL PROTECTED]> wrote:
> On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
> > How do you do this in a script:
> >
> > cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
>
> for i in `find /path/to/source -type f`; do
> cp $i /path/to/dest/
> done
That can overflow your shell's command line limit (at the
"for" command). True, our /bin/sh doesn't has such a
limit, AFAIK, but there _are_ shells that do). Apart from
that it is extremely inefficient, because it runs a "cp"
for every single file. These are exactly the problems that
xargs is supposed to solve.
Actually I don't see any problem with Brian's approach
(provided that the -i option exists, of course).
xargs _does_ take the size of the environment into account,
as well as the size of all arguments, and it still leaves
much room (it only uses up to ARG_MAX - 2048 by default).
Oh by the way, in this particular example it is probably a
good idea to use cpio. This will even work with our xargs
(which doesn't support -i yet):
cd /topdir; find . -type f | cpio -dup /otherdir
should do exactly that job.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jens Schweikhardt <[EMAIL PROTECTED]> wrote: > You mean if bigfilelist list exceeds the -n limit of xargs (default 5000)? > Yes, you'll be surprised then. It was a bit of POLA violation for me when I > found xargs would by default use 5000 arg chunks and not all in one go. > I'd rather get rid of kern.argmax and the limitations of the exec familiy. > Yes, I'm dreaming :-) Certainly, it would cause a whole lot of other problems, the smallest of which would be that people would be starting to write non-portable scripts that rely on the feature that there is no ARG_MAX limit. By the way, the -i and -I options of xargs are specified in the SUSv2 standard, and I think it would certainly be a good thing to comply with that. At least it would be a whole lot better than hacking a non-standard option into cp which would solve the problem for one particular case only, while fixing xargs would solve the whole class of problems. Putting that option into cp seems rather GNUish to me, but not very UNIXish. :-) Just my 2 Euro cents. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
In list.freebsd-current Warner Losh <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> Sheldon Hearn writes: > : On Wed, 23 Aug 2000 13:36:56 +0100, Konstantin Chuguev wrote: > : > : > Just wondering: what is the reason of using /opt instead of /usr/local, > : > apart from Solaris influence? Do you use /usr/local for anything? > : > : NetBSD uses /usr/opt . It's a matter of taste. :-) > > NetBSD uses /usr/pkg. Just as a side note (I'm not a comitter)... At the university we use /rzdist/FreeBSD for historical reasons. That directory is distributed via rdist to several servers, and then exported via NFS to clients. Of course, there's also /rzdist/linux and others. /usr/local is only used for "real" locally installed software. It is true that there are quite a lot of ports that don't support PREFIXes different from /usr/local correctly. I know, I should have send-pr'ed all of them, but that would have taken me several days... I promise to do it next time I stumble across some, I promise. :-) Even more off-topic: On our Solaris boxes, we use /opt for external packages (such as those that come from Sun itself, like the compiler suite SUNWspro), and we use /usr/local for software that we install ourself manually, i.e. not from a ready-made package. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) Addresses will change soon!! If in doubt: www.fromme.com "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
In list.freebsd-current Kenneth D. Merry <[EMAIL PROTECTED]> wrote: > On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: > > On a vaguely related topic, after much searching I can't seem to see one > > way or the other if we can do a complete bit-by-bit copy of a cd with > > either cdrecord or burncd, though it's possible I'm looking in the wrong > > place. > > I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in > ports/audio) can do it as well. > > As far as getting an image, you can use dd to dump off an image of a CD if > it is a standard ISO9660 CD. (I've used that method to clone CDs before.) > > If it uses a blocksize other than 2048 bytes, though, you can't use dd with > the SCSI cd driver. > > There may be CD rippers that can pull the data off into an image, though. > I don't know for sure. Tosha can read tracks from CDs with 2352 byte blocks, for example VideoCDs. I'm using it sometimes to directly pipe the data into MpegTV to view VCDs under FreeBSD. (BTW, tosha can also read standard data tracks with 2048 byte blocks. While dd provides the same functionality, tosha has a few nice features such as a progress and ETA display, which might make it preferable over dd.) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) Addresses will change soon!! If in doubt: www.fromme.com "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about Kern/15436
Michael C. Wu wrote: > Will you consider looking at : > > http://dorifer.heim3.tu-clausthal.de/~olli/propellers/ > > http://www.freebsd.org/cgi/query-pr.cgi?pr=15436 > > It is an additional functionality and should not > pose a stability/tradition/POLA issue. > > Perhaps we can get this done in time for for 4.1-R? This would be great, but I doubt it will be in 4.1-R. Please remember that we're only 2 - 3 weeks away from the release date, and maybe just one week from the beta stage. The ``propellers'' code is not widely tested (although I'm using it for many months, as well as a few friends of mine, but I wouldn't call this a ``wide test''), so I'd consider it to be experimental. 5.0-current is the right place to put this code into. Whether it's appropriate to MFC it after a while is a different question, but this won't happen before 4.1-R, I'm sure. BTW, the code that I have (and which I submitted) is for 4.0-current (about half a year old), and there have been a few changes to syscons in the meantime. That means that the code has to undergo some changes before it can be committed. And right now I have almost _zero_ time to spend on that (I'm moving and changing jobs). Regards Oliver Fromme -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
Matt Heckaman <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Speaking of ISOs, where is the 4.0-RELEASE ISO, It doesn't exist yet. If I understood Jordan correctly, he wants to wait a bit after the release and let the dust settle a bit before creating the CD-ROM set for Walnut Creek. However, I've built a custom ISO image, maybe it's helpful for you. It's available from ftp7.de.freebsd.org in the directory /pub/FreeBSD/CD-ROM-images/4.0-RELEASE (please read the README file first). Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
Jeffrey J. Mountin <[EMAIL PROTECTED]> wrote in list.freebsd-current: > AFAICR, the one time that a gzip and bzip version were available the size > was not all that significant and there were promptly removed. That's true. Most of the files in the ISO images are already compressed, so trying to gzip it saves only a few percent. Also take into account that many people are downloading and recoding the images on Windows boxes, which don't have gzip by default. > However, if you consider the size of the file and the possibility of > corruption, then it should be archived with gzip and forget the compression > (gzip -1). Now it can be checked for errors. Jordan kindly provides MD5 checksums of the ISO images, which are much more reliable than gzip's checksums. > Another issue is the size. Many factors determine how quickly one can > obtain the ISO. It would be nice if it were broken into smaller > volumes. About 10-20 MB each would be good. That way should something > fail, there less time and bandwidth wasted should one need to start over. That would just make things more complicated, and there's no reason for that. That's what the "reget" command is good for -- no reason to start over at all. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NODESCRYPTLINKS=true doesn't work
Kris Kennaway <[EMAIL PROTECTED]> wrote in list.freebsd-current: > DES crypt links have a "higher priority" than MD5 crypt links - if you do > a make install in secure/lib/libcrypt or lib/libcrypt, each will overwrite > the libcrypt links of the other. The difference is that make world runs > secure/lib/libcrypt last, so the DES links win. So, as the name suggests, > unless you want no DES crypt links (keep the MD5 links, please!), you > don't use it. Ah, now I understand. Thankyou very much for the explanation. May I suggest that the above paragraph is added to the setting in etc/defaults/make.conf? The current comment in that file is not really helpful. At least not for me. :-) > "WANTDESCRYPTLINKS" is the historical behaviour which hasn't > changed. Are you sure? I think the historical behaviour was to _not_ touch the symlinks at all, which I thought was a very sensible and POLA-conforming default. I'm always using the DES-capable crypt lib (to be able to share passwords with Solaris boxes), and a "make world" never changed the symlinks. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NODESCRYPTLINKS=true doesn't work
Maybe I'm just too dumb... It's my understanding that the purpose of the ``NODESCRYPTLINKS'' option in make.conf is to prevent overwriting the libcrypt symlinks in /usr/lib. Well, it doesn't work. I cvsupped today in the morning (~ 9:00 UTC on Sunday), added NODESCRYPTLINKS=true to /etc/make.conf, "make buildworld", "make installworld", and couldn't log in anymore because the symlinks had been set to libscrypt (and I'm using DES passwords). I guess that's not how it's supposed to work, is it? Regards Oliver PS: Apart from that, all is working well. I had to compile the system without openssh, though. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
Peter Jeremy <[EMAIL PROTECTED]> wrote in list.freebsd-current: > I avoid the problem by structuring my paths along the lines of > $HOME/bin:/usr/local/bin:/usr/bin:/bin (everythere, not just on > FreeBSD). OK, I'll think I will do that (even though I didn't need it, until the /usr/bin/ssh problems appeared). However, this doesn't solve the problem completely. I also had to remove /etc/ssh. Somehow, /usr/local/bin/scp seems to pick up data from /etc/ssh and tries to invoke /usr/bin/ssh, no matter what. :-( I'm truly sorry I caused this lengthy thread. It was really not my intention to spread FUD. I stumbled over something that (I thought) could be a potential problem for 4.0-Release (and I still think so). I will re-install that machine from scratch and write down exactly what is going wrong. Maybe it has even been solved in the latest -current snapshot. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
(Posted & mailed according to Reply-To) Gary Jennejohn <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Oliver Fromme writes: > >As I said in my first message, it complained about a missing > >RSA library. (To reproduce the actual error message word by > >word, I'd have to install the whole stuff again.) > > you have to cvsup the secure stuff from internat. I did that and *sigh* As I wrote in a past message in this thread, i did not and cannot cvsup on that machine at all. I can only do binary installs (i.e. releases and snapshots) on that piece of hard- ware. That's what probably 95% of FreeBSD users do, anyway. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
Kris Kennaway <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Without still having seen the error message you were confused by, I can't > do much else to help. I can't think of a better way to explain how to fix > the problem than what's currently there. As I said in my first message, it complained about a missing RSA library. (To reproduce the actual error message word by word, I'd have to install the whole stuff again.) > > I can't cvsup on that -current box, it's too small for a > > "make world" (and probably too slow, too). I just downloaded > > the 2228-current snapshot and installed it. > > Well, the question then becomes: did you download the snapshot (including > the crypto (formerly called 'DES') collection) from a US server, or non-US > server? International people should be using the crypto collection from an > internationally-produced snapshot for maximum openssl performance. >From ftp7.de.freebsd.org which mirrors from current.freebsd.org. I always use those snapshots, for many years now, and it worked fine so far (even though I never had an RSA library). What about the Release? Will 4.0-R be offered in two variants, one for the US and one for all others, so they get a working ssh? As far as I know, releases were the same for everyone, so far. > > > Enough people wanted it in the base system > > > > For what reason? I'm sorry, I can't find anything in the > > archives which is answering my question. > > It is (very) useful to have out of the box, That applies to a real lot of software which is now in the ports. For example, lsof would be very useful to have out of the box. And netcat. And sudo. And pgp. And a few hundreds of others. One of the first things I always did after a fresh install was cd /usr/ports/security/ssh; make install && make clean, just like I did with a bunch of other optional ports which are not there "out of the box" (and shouldn't). Well, sorry for my grumbling, I'll just keep removing the non-functional /usr/bin/ssh from now on. :-) Regards, Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/16487: please apply newpcm fix
Seigo Tanimura <[EMAIL PROTECTED]> wrote in list.freebsd-current: > On Mon, 6 Mar 2000 01:22:41 +0100 (CET), > Oliver Fromme <[EMAIL PROTECTED]> said: > > Oliver> Would someone please (pretty please) have a look at kern/16487 > Oliver> and commit the trivial fix in it? It's just one line, and it > Oliver> makes AvanceLogic-100 soundcards work again. > > The logical ID of ALS100 conflicts with the one of CMI8330(mss), so we > also have to check the vendor ID. Could you please give it to me? It > is likely to be 0x00019305. (ALS110 is 0x10019305 and ALS120 is > 0x20019305, so...) pnpinfo says: Vendor ID ALS0001 (0x01009305), Serial Number 0x0100 Logical Device ID: @@@0001 0x0100 #0 But I think there is already a check for the vendor ID of the card, look at the beginning of sbc_probe() in sbc.c. So I think it's really sufficient to add that line to the array of logical IDs. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
Kris Kennaway <[EMAIL PROTECTED]> wrote in list.freebsd-current: > On Mon, 6 Mar 2000, Oliver Fromme wrote: > > the ports (yeah, stupid me), to no avail. It complained about some > > RSA library missing. > > Did you read the error message? Yes, I did, it was not helpful. In fact, it was confusing. > Perhaps you should. Perhaps reporting it > here would help someone to actually fix your problem instead of having to > guess. I do not have a problem, I fixed it myself after some struggling. Did you read my whole message? Maybe I was a bit unclear. Sorry for that. My question was just what I am expected to do, and whether removing /usr/bin/ssh is the suggested solution. > Hmm. Can you try cvsupping your src-crypto and src-secure collections from > another (non-US) cvsup server? I can't cvsup on that -current box, it's too small for a "make world" (and probably too slow, too). I just downloaded the 2228-current snapshot and installed it. > > Apart from my stupidness of not checking the location of the binary > > first -- what did I do wrong, and what's the recommended way of > > handling this? Am I supposed to rm /usr/bin/ssh each time I install a > > new release or snapshot? I can't believe that. > > Read /etc/defaults/make.conf Why? I didn't compile anything. > > By the way, _why_ is ssh in the base system now, and what is > > wrong with having it in the ports? I'm sorry if there was a > > "HEADS UP" on this list, then I must have missed it. > > Enough people wanted it in the base system For what reason? I'm sorry, I can't find anything in the archives which is answering my question. > I'm quite surprised you've missed any discussion of OpenSSH here though, > since it's probably been one of the most discussed topics here for the > past few weeks. Hm. Strange. Regards, Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kern/16487: please apply newpcm fix
Hi, Would someone please (pretty please) have a look at kern/16487 and commit the trivial fix in it? It's just one line, and it makes AvanceLogic-100 soundcards work again. On a related note (unfortunately I don't have a fix for this): The ALS-100 cards have a volume problem with newpcm. They're much too soft. Even if I push the mixer settings all the way to 100%, I have to turn the volume on the amplifier very high, which results in a lot of static and noise. I can literally hear every disk access and window movement through the speakers. It's horrible. :-( That did not happen with Luigi's "oldpcm": I could keep the amplifier at a moderate level, and the mixer was at about 60% to get decent audio playback -- no static, no noise. Same machine, same soundcard. Is this a known problem? I didn't find anything in the PR DB, so I should probably submit a PR about this. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ssh strangeness in -current...
Hi, I have upgraded a machine to the latest -current snapshot (it was running a -current from the end of January before). Every- thing went fine, except for one thing: ssh didn't work anymore. It used to work fine before. At first I was very suprised and had no clue what was going on. I couldn't imagine how the new -current base system could affect my ssh binary which had been installed from the ports long before. I even pkg_deleted it and re-installed it from the ports (yeah, stupid me), to no avail. It complained about some RSA library missing. Finally I got the great idea to type "which ssh", showing me that there now was a (non-functional) ssh binary in /usr/bin. I removed it, and everything started working again, picking up the ports version from /usr/local/bin. Apart from my stupidness of not checking the location of the binary first -- what did I do wrong, and what's the recommended way of handling this? Am I supposed to rm /usr/bin/ssh each time I install a new release or snapshot? I can't believe that. By the way, _why_ is ssh in the base system now, and what is wrong with having it in the ports? I'm sorry if there was a "HEADS UP" on this list, then I must have missed it. Regards Oliver PS: Just in case if it matters, I have USA_RESIDENT=NO in my make.conf. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: which(1), rewritten in C?
I'd like to add my 2 cents, too. I agree that "which" should be a shell-builtin, because it is dependant on how the shell will search and performe a command (it might be an alias, a shell function, or a shell-builtin, or a "normal" program). Personally, I use the zsh, and its "which" builtin has served me very well (zsh also supports "type" according to POSIX). Another useful command is "where", which prints all possible locations of a command, in order of preference (not just the first one like "which" does). Finally, I like the "path expansion" feature very much: an equal sign followed by a command name will expand to the full path of the command. For example, "vi =foo" is an easy way to edit the foo script, no matter where it is and where my cwd is, and "file =bar" tells me if bar is a binary, a shell script, a perl hack or whatever, without having to know where it is. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: connectivity problems with current.freebsd.org
Bill Swingle <[EMAIL PROTECTED]> wrote in list.freebsd-current: > On Mon, Jan 24, 2000 at 11:43:59PM -0600, [EMAIL PROTECTED] wrote: >> By chance, playing around with the fact that current.freebsd.org is an >> alias for usw2.freebsd.org, I found that usw3.freebsd.org (209.180.6.227) >> mirrors snapshots as well. Perhaps something should be added to the >> /snapshots readme.txt on ftp.freebsd.org about the fact that >> current.freebsd.org has mirrors. That said, I've gotten the same error >> from usw3 as from usw2. > > I can't really speak to your download problems but it should be noted > that usw2 and usw3 are in the same facility at USWest, in fact they're > probably in the very same rack as each other. Noting that this other > 'mirror' is available would not do much good as they both sit on the > exact same bandwidth. FWIW, we're mirroring the most recent snapshots at ftp7.de.freebsd.org. There's also a nice page listing all mirror sites of FreeBSD releases and snapshots: http://www.itworks.com.au/~gavin/FBSDsites.php3 Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
David O'Brien <[EMAIL PROTECTED]> wrote in list.freebsd-current: > On Sun, Jan 23, 2000 at 10:26:48AM +0100, Oliver Fromme wrote: >> >> Saving 10% or 20% on disk space is not worth wasting >= 10 times more >> CPU time than gzip. Disk space is cheap nowadays, but upgrading to a >> CPU that is 10 times faster is not. > > And just how do I increase the space on a CDROM??? Include another CD-ROM. > Go look how many port distribution files on your last CDROM set were in > bzip2 format -- there is a reason for that. I think that's because some people -- especially Linux people, as it seems -- think that bzip is ``new and cool''. :-) >> (I once tried to compress our FreeBSD ISO images with bzip2, >> just to compare the space savings with gzip. I aborted the >> experiment after 6 hours (!). gzip took about 30 minutes. >> Consequently, bzip2 was considered unusable and went into the >> trash can.) > > Am I the only one that uses UNIX as a multitasking OS? > nice the bzip2 process by 20 and background it. Geez. Then it would have taken even longer. Sometimes you have deadlines, and waiting a few hours longer is just not an option. (In this case I finally decided to not even gzip the stuff, because it saved only a few percent of space.) But this is getting off-topic. I think everyone is entitled to his own opinion about the usefulness of bzip2. But I have yet to hear a good reason why it should replace gzip in the base system of FreeBSD. Not that my opinion matters, though. :-) Using bzip2 for the FreeBSD distribution sets would increase the minimum memory requirement by 4 Mbyte (or about 2.5 Mbyte using the -s option of bunzip2, but which doubles decompression time). Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm problem --> patch --> problem
Hi,
I upgraded from an early December -current to a current -current
(CVSupped yesterday, buildworld took 16 hours). Works fine,
except that the soundcard (ISA PnP, Avance Logic ALS100+, SB16-
compatible) does not work anymore. It worked fine before.
(``Does not work anymore'' == it just blocks when I try to play
something, and half of the mixer settings aren't recognized
anymore. I can't get a single beep from the boxes. Yes, I do
have ``device sbc0'' in my kernel.)
Early December dmesg says:
pcm0: at port 0x220-0x22f irq 5 drq 5,1 on isa0
And current dmesg says:
pcm0: at port 0x220-0x22f irq 5 drq 5,1 on isa
Obviously, the card is probed as something completely different,
which is wrong. No wonder that it doesn't work.
The following patch fixes it, and the soundcard works just like
before, but...
--- src/sys/dev/sound/isa/mss.c.origThu Jan 13 07:11:32 2000
+++ src/sys/dev/sound/isa/mss.c Mon Jan 24 00:38:08 2000
@@ -1328,7 +1328,9 @@
static struct isa_pnp_id pnpmss_ids[] = {
{0x630e, "CS423x"}, /* CSC */
{0x0001630e, "CS423x-PCI"}, /* CSC0100 */
- {0x0100, "CMI8330"},/* @@@0001 */
+#if 0
+ {0x0100, "CMI8330"},/* @@@0001 */
+#endif
{0x2100a865, "Yamaha OPL-SAx"}, /* YMH0021 */
{0x1110d315, "ENSONIQ SoundscapeVIVO"}, /* ENS1011 */
{0x1093143e, "OPTi931"},/* OPT9310 */
--- src/sys/dev/sound/isa/sbc.c.origWed Jan 12 12:16:23 2000
+++ src/sys/dev/sound/isa/sbc.c Mon Jan 24 00:44:28 2000
@@ -202,6 +202,7 @@
{0x44008c0e, "Creative SB AWE64 Gold"}, /* CTL0044 */
{0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
+ {0x0100, "Avance Logic ALS100+"}, /* @@@0001 */
{0x0110, "Avance Asound 110"}, /* @@@1001 */
{0x0120, "Avance Logic ALS120"},/* @@@2001 */
... of course, now a real ``CMI8330'' would probably not be
detected correctly anymore. I don't have such a card (and I've
never heard of it before). If it really has the same device ID
as the ALS100+, we're in trouble, I guess.
BTW, with the above patch, my card is probed like this:
sbc0: at port 0x220-0x22f irq 5 drq 5,1 on isa0
sbc0: setting card to irq 5, drq 5, 1
pcm0: on sbc0
and works happily.
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
Garrett Wollman <[EMAIL PROTECTED]> wrote in list.freebsd-current: > If I may inject some possibly-irrelevant fact into this > discussion... gzip (or rather, the ``deflate'' compression algorithm > and the libz file format) has been adopted into a number of formal > standards. It's likely that it will remain with us for a long time. > For those of us who eschew bloatware, it continues to be entirely > adequate. I don't like bzip2 for the sole fact that it takes _ages_ to compress files, compared to gzip. Saving 10% or 20% on disk space is not worth wasting >= 10 times more CPU time than gzip. Disk space is cheap nowadays, but upgrading to a CPU that is 10 times faster is not. (I once tried to compress our FreeBSD ISO images with bzip2, just to compare the space savings with gzip. I aborted the experiment after 6 hours (!). gzip took about 30 minutes. Consequently, bzip2 was considered unusable and went into the trash can.) I'd vote for keeping things as they are: bzip2 is fine as a port. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: This mornings make world stops at alpm.4
Edwin Culp <[EMAIL PROTECTED]> wrote in list.freebsd-current: > ===> share/man/man4 > gzip -cn /usr/src/share/man/man4/ahc.4 > ahc.4.gz > make: don't know how to make alpm.4. Stop > *** Error code 2 > [...] > Delete src/share/man/man4/alpm.4 The committer who deleted (moved) alpm.4 forgot to update the Makefile. This fixes it: --- src/share/man/man4/Makefile.origMon Jan 17 16:13:00 2000 +++ src/share/man/man4/Makefile Sat Jan 22 20:00:38 2000 @@ -1,7 +1,7 @@ # @(#)Makefile8.1 (Berkeley) 6/18/93 # $FreeBSD: src/share/man/man4/Makefile,v 1.74 2000/01/17 15:13:00 asmodai Exp $ -MAN4= ahc.4 alpm.4 amd.4 an.4 atkbd.4 atkbdc.4 aue.4 blackhole.4 bpf.4 \ +MAN4= ahc.4 amd.4 an.4 atkbd.4 atkbdc.4 aue.4 blackhole.4 bpf.4 \ bridge.4 ccd.4 cd.4 ch.4 csa.4 cue.4 da.4 dc.4 ddb.4 de.4 \ divert.4 dummynet.4 faith.4 fd.4 fdc.4 fpa.4 fxp.4 \ gif.4 gusc.4 \ Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: shell problem
mouss <[EMAIL PROTECTED]> wrote in list.freebsd-current: >> Install bash (either from ports or a package). > > and before you ask why you cannot ftp to your machine, do not forget to add > the path above to /etc/shells. The FreeBSD port/package will do that automagically. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
Personally, I'd much prefer to simply use separator characters like this: -rw--- 1 olli olli 211,602,776 Nov 28 23:09 S1E1.mpg This makes it very easy to recognize the size, and you still have the exact number of bytes, not rounded. It's even possible to to respect the locale setting (LC_NUMERIC) and use the appropriate character as separator. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load spike strangeness
FreeBSD <[EMAIL PROTECTED]> wrote in list.freebsd-stable: >> FreeBSD <[EMAIL PROTECTED]> wrote in list.freebsd-stable: >> > Overclocking is *NEVER* recommended >> >> Neither is posting anonymously (without a realname). > > Since when does an E-mail address require a "realname"? It is not required, but it is a matter of good practice, politeness, and netiquette. It's a matter of being taken serious, and of encouraging people to communicate. This is not a security issue at all. > become required, I'd prefer to "unsubscribe" than to give that info out, as > would any other intelligent person. I suggest you check your e-mail security > information again before babbling nonsense. That's ridiculous. You're making a fool of yourself. You will not receive less spam when hiding your real name. And using a real name does not prevent you from creating a new account, if you think that's necessary. > Do > you also use you real full name on IRC? Yes, I do. For 5 years. And there is no reason to hide it. (I'm not a criminal who has to hide from the police or something like that.) > "LinSUX is only free if your time is worthless" While I'm at it: I don't like that quote either. :-) Goodbye Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load spike strangeness
FreeBSD <[EMAIL PROTECTED]> wrote in list.freebsd-stable: > Overclocking is *NEVER* recommended Neither is posting anonymously (without a realname). (Sorry -- Back to the topic.) I have to admit that I've seen the same symptoms, and I have no idea what's causing it. It happenes very irregularly (and rarely), but it clearly _does_ happen sometimes. It doesn't seem to be related to any particular hardware or FreeBSD ver- sion, I have seen it on both 3.x and 4.0-current boxes. On some machines it never happened at all (including some busy servers), at least not while I was logged in and watched it (it's possible that it happened without me noticing at all). It _seems_ to happen preferably when a long-time CPU hog has run (and terminated) recently, such as setiathome. The load goes up to 1.0 and stays there for some time (could be a few minutes, or an hour maybe even a few hours), then drops back to 0.0 for no apparent reason. During that period of load 1.0, there is no activity. CPU is 100% idle. There is no process that consumes any significant amounts of CPU time. The box feels fast and responds quickly to interactive work. vmstat looks perfectly normal (like an idle machine). I have come to the conclusion that it must be a subtle bug somewhere in the kernel's calculation of the load averages. I tried to track it down in the kernel sources, but without success. Since it didn't seem to have any ill effects, but just being a cosmetic problem, I didn't bother to investigate further. I have to admit that I wasn't even motivated to submit a PR. Yeah, shame on me. Oh by the way, I think it happened once even on an OpenBSD/ Alpha box (not sure though, it was a long time ago). Maybe it's a long-standing BSD bug, or just strange coincidence. Please excuse me for forwarding this to -current as well, but I think it's important enough, and -current is affected, too. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives?
Kenneth D. Merry <[EMAIL PROTECTED]> wrote in list.freebsd-current: > [...] >> PS: The email address that Ken mentioned isn't valid, please >> use <[EMAIL PROTECTED]>. > > Then why are you still using it? This is from the headers on your message: > > From: Oliver Fromme <[EMAIL PROTECTED]> I upgraded the hardware and OS of this box recently, and not everything is configured correctly yet (not enough time)... There _should_ be a valid Reply-To line in my email messages. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives
Alexander N. Kabaev <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Is that something to be expected? How to copy a complete CD-ROM image into ISO > file then? You can also use tosha to read a CD-ROM track to make an ISO image. It supports CD-ROM data tracks as well as audio and video (VCD) tracks. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives?
Kenneth D. Merry <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Also, you might want to try mailing Oliver Fromme > <[EMAIL PROTECTED]> (the author of tosha) and see if he > has any idea what it would take to get your drive to function. I'm reading this thread, and no, I have no idea. :-) To be honest, I've never heard about an "SAF" drive. If I had such a stubborn drive, I would start trying a bunch of "typical" parameter sets that are known to work with other drives, and then try to interpret the results. Maybe try to contact the vendor and ask for docs, but that's pretty much fruitless, as experience shows. If all else fails, make a brute-force attack on density codes... Jordan, if you can get that drive to work with tosha somehow, please let me know, so I ca add it to the regular tosha distribution. Regards Oliver PS: The email address that Ken mentioned isn't valid, please use <[EMAIL PROTECTED]>. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives?
Karsten W. Rohrbach <[EMAIL PROTECTED]> wrote in list.freebsd-current: > reading raw audio data off a cd with dd did never work for me... > anyway, it would be a good thing(TM) if there was a tool such as > cdparanoia under l*n*x that has all that fancy jitter and scratch > detection and removal (real goodd error correction) and this ones also > really fast (10x speed) when youre reading on a plextor drive (such as > my pxw4220t) or something else that has a native mode for extracting > audio. > > i think, theres a port of tosha available, but the last time i tried > this one it wouldnt work for me so i used the l*n*x box next to my > workstation... "Port of tosha"? Tosha is a native FreeBSD program. :-) BTW, it reads audio tracks off my Plextor drive at 20x - 24x speed. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal: Removing doscmd from the source tree...
Michael Lucas <[EMAIL PROTECTED]> wrote in list.freebsd-current: > Actually, several ports give you the option of building with or > without X support (i.e., SSH). It would be nice to have a USE_X11 > option in /etc/make.conf for doscmd as well as these ports, so you > don't have to specify it on the command line while building. > > Of course, I'd like a pony too. And a pink bike shed. Me too! :) I'm currently trying to fix the POV-Ray port. It could be built with and without X11 support, too, and it would be very useful to have a way to let the user choose. A USE_X11 knob in make.conf would be great. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors and AUTO_EOI
Doug White wrote in list.freebsd-current: > On Tue, 21 Dec 1999, Soren Schmidt wrote: > > It seems Dieter Rothacker wrote: > > > The solution for me was to recompile the kernel without AUTO_EOI1 and > > > AUTO_EOI2. > > > > Those options newer worked (for me at least) reliably with anything, could > > those that are seeing the hangs please check this ?? > > Although this isn't immediately related to ATA, I've found that Intel > L440GX+ boards *hate* AUTO_EOI_2 when running SMP. They freeze going into > multiuser mode. Took me quite a while to figure that out. I have always been using AUTO_EOI_1, but _not_ AUTO_EOI_2, and it has always worked very well. The comment in LINT about AUTO_EOI_2 sounds pretty suspicous, so I never even tried it: "it works for some clones and some integrated versions." That sounds to me like "it works on a very limited set of hardware (and if you're lucky)." AUTO_EOI_1 seems to be fine, though. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Steve O'Hara-Smith wrote in list.freebsd-current: > On 15-Dec-99 Oliver Fromme wrote: > > Alexander Langer wrote in list.freebsd-current: > > > gunzip has approx 106 kb, but you save about 50% per executeable. > > > > -r-xr-xr-x 1 root wheel 4648 Jan 28 1999 /usr/bin/minigzip > > It requires the 50Kb libz.so.2 though and some of libc. Only very few of those libs, though. I once had a (self- contained) gunzip.com for DOS that was about 5 Kbyte. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
syscons screenshot tool
Hi, As I mentioned in the "propellers" thread, I have a small tool that can be used to make screenshots of syscons VTYs. Here it is: http://www.fromme.com/syscons-screenshot/ There is a README with instructions, _please_ read it! Actually this is a quick hack, and the ioctl approach is a bit clumsy, so I haven't submitted it with send-pr yet. I will change the ioctl, clean the code up, write docs and submit the thing, unless someone else comes up with something better. I'm also under the impression that Mr. Syscons (Yokota?) is currently doing some design changes to syscons, so maybe I should wait until this is done, before submitting any further code. Regards Oliver PS: There is no need to Cc me, I'm on this list. However, if someone wants to mail me privately, please use the address [EMAIL PROTECTED] -- the host from which I'm sending this is not prepared to receive email, and tin doesn't enable me to change the From line. Sorry for the inconvenience. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Donn Miller wrote in list.freebsd-current: > On Wed, 15 Dec 1999, Warner Losh wrote: > [...] > > There is no placement management, no redirection of windows, no > > visibility management or anything of the sort in the X server. It > > But, if there's only one app running, then that app gets the focus. Only if that application has only one window (which is not the case for Netscape). The focus is a property that works on windows, not on applications. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Warner Losh wrote in list.freebsd-current: > In message <[EMAIL PROTECTED]> Oliver Fromme >writes: > : That's because X itself contains a very simple "windowmanager" > : functionality, which focuses the window beneath the mouse > : pointer. But when you have to access something which is behind > : another window, you lose. > > That's not entirely true. The X server does not contain a window > manager at all. It doesn't implement any of the ICCCM required for > window managers. Right, that's why I wrote it in "quotes". > There is no placement management, no redirection of windows, no > visibility management or anything of the sort in the X server. It > just has mechanisms which allow one to do these things. "Tools, not > rules," being the motto from long ago... Exactly. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Alexander Langer wrote in list.freebsd-current: > Thus spake Don 'Duck' Harper ([EMAIL PROTECTED]): > > fires up XFree86's VGA server. And it fits all this on one floppy. They > > do have two floppies, one for local CD/disk installs, and another for > > NFS/FTP/HTTP/SMB installs. > > So, I know it can be done. Is it worth the effort? I donno. > > Maybe they gzip the binaries and gunzip them into MFS before using > them. > > gunzip has approx 106 kb, but you save about 50% per executeable. -r-xr-xr-x 1 root wheel 4648 Jan 28 1999 /usr/bin/minigzip Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Sheldon Hearn wrote in list.freebsd-current: > On Tue, 14 Dec 1999 21:26:04 +0100, Oliver Fromme wrote: > > > I'm not yet 100% convinced that it would make sense to separate > > the propellers code into a module. Is 5 Kbyte of kernel code > > really that much of a problem? > > No, but think ahead, into a future where we use a teeny tiny kernel into > which we plug lots of modules. Sure, in that case, syscons itself should be a module, shouldn't it? Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
jack wrote in list.freebsd-current: > Today Oliver Fromme wrote: > > I'm afraid that wouldn't work. In order to run non-trivial X11 > > apps, you _will_ need a full-blown X server, including X libs. > > You'll also need at least a very simple window manager (while > > xclock would probably work without, Netscape would certainly be > > pretty unusable). > > I just tried only netscape in my .xinitrc and it worked fine. That's because X itself contains a very simple "windowmanager" functionality, which focuses the window beneath the mouse pointer. But when you have to access something which is behind another window, you lose. And as I wrote, the window manager is the smallest problem of his proposal. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Donn Miller wrote in list.freebsd-current: > Actually, that's not a bad idea. One idea I had was combining > syscons with XFree86 server code, so you always have a crippled X > server running without the bloat of a full-blown X server > running. I'm afraid that wouldn't work. In order to run non-trivial X11 apps, you _will_ need a full-blown X server, including X libs. You'll also need at least a very simple window manager (while xclock would probably work without, Netscape would certainly be pretty unusable). Although, the window manager would be the smallest problem of your approach... > One potential drawback is that it would probably bloat the > syscons code slightly. *ROTFL* :-)) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Andrzej Bialecki wrote in list.freebsd-current: > On Tue, 14 Dec 1999, Donn Miller wrote: > > I think another way (instead of ifdefs) would be to provide some > > hooks into syscons, so that the "propellers" code can be loaded > > or unloaded via kldload/unload. I'm not yet 100% convinced that it would make sense to separate the propellers code into a module. Is 5 Kbyte of kernel code really that much of a problem? Please note that 1. without the kernel option SC_PROPELLERS, none of the code gets compiled into the kernel. So someone who doesn't need the propellers and doesn't want the 5 Kbyte "bloat" simply doesn't include that option in his kernel. 2. the option should probably not be in GENERIC. 3. once you have the code in your kernel, you can arbitrarily enable and disable (hide) the propellers. When they're disabled, you get the full screen resolution back (25 rows or whatever). You can even enable them on some VTYs and disable them on others, if you want. So the only drawback is 5 Kbyte of kernel growth, once someone has included the option SC_PROPELLERS. Does this justify a rewrite of syscons to divide it into KLDs? Frankly, I don't think so. > Another way to customize various strings, colors and variables could be > via sysctl. It's easy e.g. to set up the "propeller" string via sysctl. Currently it uses ioctls, which is more appropriate for these things, IMO. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of moving files
Ben Rosengart wrote in list.freebsd-current: > On Tue, 14 Dec 1999, Matthew Dillon wrote: > > > I think at one time or another all of us have missed *something* in > > /usr that wasn't in /. For example, disklabel -e doesn't work without > > vi -- which is in /usr. > > Good example of something else that would be great to have in /bin. No, really bad example. # export EDITOR=ed # disklabel -e da0s1 759 _ Works perfectly well. But for chown, there is no functional equivalent in /bin or /sbin that I'm aware of. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Jordan K. Hubbard wrote in list.freebsd-current: > > Just in case somebody is curious, here's a screenshot: > > http://www.fromme.com/propellers/ > > That looks very interesting... It's just screaming for some kind of > mechanism which allows you to kldload the propeller code in as an > extention rather than linking it into the kernel. :) Actually, I was thinking about that myself. But the problem is that the code is very closely integrated into the existing syscons code (with a lot of #ifdef's, of course). I have never programmed a KLD before (though I will have a look into this when I have some spare time left), but it is my understanding that KLDs are appropriate for parts of the kernel which can be reasonably easy separated from the rest of the kernel. This is not the case for the propellers code. Well, it could possibly be done, but it would require some major design changes to syscons. On the other hand, the propeller code adds about 5 Kbyte to /kernel, which isn't that much. And of course, I'm not voting for putting it into GENERIC. By the way, is there interest in giving the "Print Screen" key an appropriate meaning, i.e. capturing a screenshot? I have a few patches for this to implement that, I'd just have to clean the code up and write a bit of documentation. The GIF on the above webpage was created that way (along with a small userland tool and netpbm). I'm just asking. If nobody cares, I will not bother putting more time and effort into this. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
I wrote in list.freebsd-current: > I have (long time ago) written some extensions to syscons, and > finally decided to clean them up, document and submit them. Just in case somebody is curious, here's a screenshot: http://www.fromme.com/propellers/ Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
2.1 (was: wd driver will be retired)
Anthony Kimball wrote in list.freebsd-current: > What I didn't like about CAM was that I lost my tape drive. Since I > had all my backups and archives on DAT, it felt like a bad thing. I don't think that's related to CAM. At least my crappy HP 1533A drive (DDS2) still works with CAM. > Which reminds me -- can anyone spare a 2.1 CD? Please send me private > mail, if so: I foolishly neglected to convert to CD, and now I can't > find 2.1 on the web anywhere. For example, you can find 2.0.5-Release and 2.1.7.1-Release at ftp7.de.freebsd.org, for example. See the "FreeBSD snap finder" at http://www.itworks.com.au/~gavin/FBSDsites.php3 Well, or check it out from the CVS repository. :) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
syscons extension: "propellers"
Hi, I have (long time ago) written some extensions to syscons, and finally decided to clean them up, document and submit them. (Being tired of updating and merging them every time a new FreeBSD release comes out...) The patches can be found in kern/15436, and it would be really great if they could be committed to -current before the feature freeze. There is no risk, because they completely depend on a single kernel option (SC_PROPELLERS) -- without this option, none of the new code gets compiled into the kernel. The attached patches implement an extension to syscons called "propellers" (activity indicators), along with a status line. It is very useful and convenient if you have to work without X for some reason. So far, everybody who has used these patches for an hour or two didn't want to miss them anymore. :-) Details can be found in the PR. Regards Oliver PS: If someone wants to contact me privately, please use the address <[EMAIL PROTECTED]>. The host in the "From:" line is not set up to receive email. Sorry for the inconvenience. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Memory leak in syscons?
(Replying to myself...) In list.freebsd-current I wrote (8 Dec 1999 10:02:39 +0100): > I'm not 100% sure, but I think I have found a memory leak in > syscons. The following patch should fix it. Would someone > please have a look at this? --> kern/15363 Regards Oliver PS: I have more patches for syscons, they will follow shortly... :) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Memory leak in syscons?
I'm not 100% sure, but I think I have found a memory leak in
syscons. The following patch should fix it. Would someone
please have a look at this? The diff is against this file:
src/sys/dev/syscons/schistory.c,v 1.5 1999/09/19 08:58:53
Regards
Oliver
--- src/sys/dev/syscons.orig/schistory.cSun Sep 19 10:58:53 1999
+++ src/sys/dev/syscons/schistory.c Wed Dec 8 09:53:33 1999
@@ -135,6 +135,7 @@
if (prev_history != NULL) {
extra_history_size += delta;
sc_vtb_destroy(prev_history);
+ free(prev_history, M_DEVBUF);
}
scp->history = history;
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm: Soundcard not recognized anymore
(Replying to myself...)
Oliver Fromme wrote in list.freebsd-current:
> I have today upgraded a machine from some 3.1-stable to the
> latest -current snapshot (19991204). Now the ISA PnP soundcard
> doesn't work anymore (it worked fine before, using the pcm
> driver). It is an Avance Logic ALS100+ card.
The following patch makes the card work again in -current:
--- dev/sound/isa/sb.c.orig Tue Dec 7 02:30:19 1999
+++ dev/sound/isa/sb.c Tue Dec 7 02:30:19 1999
@@ -1261,6 +1261,10 @@
u_int32_t logical_id = isa_get_logicalid(dev);
switch(logical_id) {
+ case 0x0100: /* @@@0001 */
+ s = "Avance Asound 100";
+ break;
+
case 0x0110: /* @@@1001 */
s = "Avance Asound 110";
break;
Can someone please just commit this trivial fix, or shall I
submit a PR?
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pcm: Soundcard not recognized anymore
I have today upgraded a machine from some 3.1-stable to the latest -current snapshot (19991204). Now the ISA PnP soundcard doesn't work anymore (it worked fine before, using the pcm driver). It is an Avance Logic ALS100+ card. This is from dmesg: unknown0: at port 0x220-0x22f irq 5 drq 5,1 on isa0 unknown1: at port 0x388-0x38f on isa0 unknown2: at port 0x200-0x201 on isa0 unknown3: at port 0x330-0x331 irq 9 on isa0 `pnpinfo` output is attached below. Please let me know if any further information is required to get this thing working again. I hope this is only a matter of a missing vendor ID or something like that... Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID ALS0001 (0x01009305), Serial Number 0x0100 PnP Version 1.0, Vendor Version 0 Device Description: ALS100 Media Audio Controller Logical Device ID: @@@0001 0x0100 #0 Device supports I/O Range Check TAG Start DF Good Configuration FIXED I/O base address 0x220 length 0x10 IRQ: 5 - only one type (true/edge) DMA: channel(s) 5 16-bit, not a bus master, , count by word, Type F DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Type F TAG Start DF Acceptable Configuration I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [not 16-bit addr] IRQ: 5 7 9 10 - only one type (true/edge) DMA: channel(s) 5 6 7 16-bit, not a bus master, , count by word, Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG Start DF Sub-optimal Configuration I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x10 [not 16-bit addr] IRQ: 5 7 9 10 11 12 15 IRQ: High true edge sensitive IRQ: Low true edge sensitive IRQ: High true level sensitive IRQ: Low true level sensitive DMA: channel(s) 0 1 3 5 6 7 8/16-bit, not a bus master, count by byte, count by word, Type F TAG End DF Logical Device ID: @H@0001 0x0101 #1 Device supports I/O Range Check FIXED I/O base address 0x388 length 0x8 Logical Device ID: @P@0001 0x0102 #2 Device supports I/O Range Check FIXED I/O base address 0x200 length 0x2 Logical Device ID: @X@0001 0x0103 #3 Device supports I/O Range Check TAG Start DF Good Configuration FIXED I/O base address 0x330 length 0x2 IRQ: 9 - only one type (true/edge) TAG Start DF Acceptable Configuration I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x2 [not 16-bit addr] IRQ: 5 7 9 10 11 12 15 IRQ: High true edge sensitive IRQ: Low true edge sensitive IRQ: High true level sensitive IRQ: Low true level sensitive TAG End DF End Tag Successfully got 30 resources, 4 logical fdevs -- card select # 0x0001 CSN ALS0001 (0x01009305), Serial Number 0x0100 Logical device #0 IO: 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 IRQ 5 0 DMA 5 1 IO range check 0x00 activate 0x01 Logical device #1 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #2 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #3 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 9 0 DMA 4 4 IO range check 0x00 activate 0x01 -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
Julian Elischer wrote in list.freebsd-current: > On Wed, 17 Nov 1999, Oliver Fromme wrote: > > Adam Wight wrote in list.freebsd-current: > > > x I like the -e option when I'm root and trying to debug things. I > > > x think that peter's fix seems to be ideal. You can find out about your > > > x own uid, but no one else's unless you are root. > > > > > > I agree, but anything that runs suid has to be excluded as well. > > > > FWIW, I'd be against removing or restricting -e at all. > > > > Programs that put sensitive data into environment variables > > (or expect the user to do that) are just _broken_. Removing > > or restricting the -e option encourages such brokenness. > > > > Just my 0.02 Euro. > > since the environment is supposed to be part of the address space > it is ssupposed to be private.. But it is not, and programmers should be aware of it. On all platforms on which I regularly work (*BSD, Solaris, DEC UNIX a.k.a Tru64) the environments of all processes are public. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
Adam Wight wrote in list.freebsd-current: > x I like the -e option when I'm root and trying to debug things. I > x think that peter's fix seems to be ideal. You can find out about your > x own uid, but no one else's unless you are root. > > I agree, but anything that runs suid has to be excluded as well. FWIW, I'd be against removing or restricting -e at all. Programs that put sensitive data into environment variables (or expect the user to do that) are just _broken_. Removing or restricting the -e option encourages such brokenness. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
Pierre Beyssac wrote in list.freebsd-current: > On Mon, Nov 15, 1999 at 02:27:10PM -0800, Matthew Dillon wrote: > > And, also, we need to get rid of the 'e' option to ps entirely. It's a > > major security hole. > > Not more so than option 'u', or even 'a', if you ask me. > > It's common knowledge under Unix that you shouldn't put anything > sensitive in the command line or the environment. When there's any > risk, the best option is to remove 'ps' alltogether, IMHO. Sorry for jumping in here... When looking for "old" processes on shell boxes, I often find myself using ps -e and grepping for the DISPLAY variable, in order to find out if it's an abandoned local process, or if it was redirected to some remote host. That's what I'd need ps -e for. or is there another, possibly easier way to accomplish that? Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
[EMAIL PROTECTED] wrote in list.freebsd-current: you wrote (9 Nov
1999 21:13:42 +0100):
> (101) netchild@ttyp2 > man -k adadadad
> cat: /etc/isdn/connect.parameters: Permission denied
> adadadad: nothing appropriate
>
> (102) netchild@ttyp2 > grep cat /etc/rc.conf.local
> spppconfig_isp0="`cat /etc/isdn/connect.parameters`"
Using command substitution in /etc/rc.conf{,.local} is NOT
officially supported. I think it should have always been
clear that there should _only_ be plain variable assignments.
That's probably just because you never know which programs
try to read them.
> Is this just my system or is man really reading rc.conf(.local)?
I think that's perfectly legal.
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: luoqi's aic driver problem
Ilya Naumov wrote in list.freebsd-current: > Chaintech 6BTM mainboard with Celeron 416A processor and 128 Mb of memory Please excuse me -- what is a "Celeron 416A"? Regards Oliver Fromme -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The eventual fate of BLOCK devices.
Jonathan M. Bresler wrote in list.freebsd-current: > > FWIW, I got unsubscribed, too. While I were at it, I sent a > > "which" command to the majordomo, and the result did not list > > me as a member of freebsd-announce and freebsd-security- > > notifications. When I tried to re-subscribe, it told me that > > I am already subscribed... > > > > Seems like majordomo is major buggy. ;-) > > youare subscribed to freebsd-announce as > [EMAIL PROTECTED] which oes not match the email > [...] Oh, I'm very sorry for the confusion. When I said "I", I really did not mean myself but the local newsgate (I prefer to read the lists via NNTP, which is very convenient). The newsgate is "[EMAIL PROTECTED]". I sent both the "which" and the "subscribe" commands under that address, when the problem occured that I described in my previous mail (see above). I'm pretty sure that I didn't do anything wrong. Here's the whole story: - I sent a "which" command from the newsgate account. - Got a response with about 30 lists to which that account is subscribed. - Compared those lists to the lists that the newsgate is prepared to handle (and to which it was once subscribed). - Noticed that three lists were missing: announce, arch, and security-notifications. - Sent "subscribe" commands for those three lists to the majordomo, again using the newsgate account. - Re-subscription to the -arch list was successful. For the other two lists, I received a notice that I (the newsgate account) was already subscribed. > this is not a majordomo bug. It is. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The eventual fate of BLOCK devices.
Nate Williams wrote in list.freebsd-current: > Interesting. It appears that somehow I got 'unsubscribed' from arch. > Not sure why, but in May I was subscribed, but I'm no longer subscribed. > > Did everyone get unsubscribed when it went idle? FWIW, I got unsubscribed, too. While I were at it, I sent a "which" command to the majordomo, and the result did not list me as a member of freebsd-announce and freebsd-security- notifications. When I tried to re-subscribe, it told me that I am already subscribed... Seems like majordomo is major buggy. ;-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
Jordan K. Hubbard wrote in list.freebsd-current: > > Anyway, all good to know. There are almost certainly more perl > > speakers than awk speakers these days, so it probably makes sense > > to do these things in perl rather than awk. > > I think that's sort of in the grey area. There are also many Hardened > Traditionalists(tm) like myself who don't know perl and have no > interest in learning it because everything they ever need to do can be > handled by sh, awk and sed and they spent many years gaining that > level of proficiency with them. We could color our ls and replace sh > with bash too, but sometimes there's value in retaining the simpler > traditions as you also go forward with the newer tools. :-) Not that anybody actually listens to me, but I have to say that I completely agree with Jordan. Knowing both perl and awk, I like awk a _lot_ better. It is definitely much easier to learn and to use. (You _have_ to learn it first, of course, but if you already know C, you know 90% of awk.) A lot of my scripts begin with #!/usr/bin/awk -f ;) In fact, I learned perl first and did quite a lot of things with it. However, when I became more familiar with awk, the deficiencies of perl became more and more obvious to me. So I started porting my old perl stuff: to sh, to awk, to C, or whatever seemed most appropriate. (I still have some perl scripts left, just because they work, and lack of time to convert, or because someone else wrote them without too much care, rendering them unreadable and unmaintainable -- a common problem with perl.) Just my 0.02 Euro... Regards Oliver PS: If you need something ported to awk or written in awk, just let me know. :) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
Mike Smith wrote in list.freebsd-current: > > Can you give me a few hints on what would be necessary to get the old > > driver to work with the new PnP? > > As has already been explained to you (you _do_ read these messages in > their entirety, right?), the old driver has been obsoleted. You need > to take the functionality that you want from the old driver and > implement it in the newpcm code. I don't think that would be the right approach. The functionality of the awe0 driver should be kept separate and not be integrated in the pcm0 driver. (After all, the awe0 driver has nothing to do with PCM.) > Since the AWE64 is already reported to work just fine with the current > generation sound code, Uhm, it is? I don't think so. My AWE64 doesn't work either with "newpnp", and I haven't seen a report from someone for whom it works. Except for the SB16-compatible PCM part of the AWE64, of course, which does work (at least I can play mp3 files). But the actual AWE part does not work. It did with the old code. > this sounds just a little hysterical to me. You > seem to have a slightly more specialised requirement that's not yet > being catered to that does require some more attention. Seems like I'm in the same situation as Donald. The "slightly more specialized requirement" is to get the AWE part of an AWE64 to work, which I think is the whole point of having an AWE64. (If I just wanted PCM playback, I'd buy a cheaper card.) I'm aware that -- instead of whining around -- I should start adapting the old awe0 driver to newpnp. Indeed I would give this a try if there was some documentation of the newpnp frame- work, but I haven't found any, and I don't have the time to find out on my own (this might seem lazy, but I do not regard C source code as "documentation"). Anyway. Downgrading that particular machine went fast and easy, and now everything works fine again. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
Just some numbers that I got with a small testsuite. This is the setiathome client running on an AMD Athlon-500 (K7), FreeBSD 4.0-current (as of 1999-09-18). Of course, I've used the same work unit for all tests. I also changed the code to stop after a certain amount of data has processed, because I don't want to wait some hours for each test to complete. ;-) -O1 302.72 real 301.96 user 0.28 sys -O2 315.20 real 314.42 user 0.18 sys -O3 320.01 real 319.23 user 0.35 sys -Os 315.99 real 315.19 user 0.35 sys As you can see, -O1 is fastest, the higher optimization levels are slower. I'm currently running a testsuite with a larger number of optimizer flags combinations, but it'll take a while. On a side note, I downloaded AMD's document about optimizing code for the Athlon, and I found out that gcc does a pretty poor job. :-( Unfortunately, I'm not an expert in writing compilers, and I don't dare to touch the gcc source code. After all, the compiler is one of the most critical parts of the system. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
Warner Losh wrote in list.freebsd-current:
> In message <[EMAIL PROTECTED]> "Matthew D. Fuller" writes:
> : OK:
> : #!/bin/sh
> : (cvs status | grep '^File:' | grep -v 'Status: Up-to-date$') 2> /dev/null
> ^^ -q
Hm, that variant does not display the directory names at all.
I'd like to propose the following variant. It's a bit longer
than my first proposal, but just as efficient (maybe even more
efficient, because it doesn't have to fork two greps).
#!/bin/sh -
cvs status 2>&1 \
| awk '/^File/ && ! /Status: Up-to-date$/ {
$1 = dir "/" $2;
$2 = "";
print;
}
/cvs server: Examining/ {
dir = $4;
}'
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
Darryl Okahata wrote in list.freebsd-current: > "Zach N. Heilig" <[EMAIL PROTECTED]> wrote: > > The application for the tests is mpg123. > > test mp3 playing time: 373 seconds. > [ ... ] > > 1) No Optimization > >225.08 real 224.30 user 0.23 sys > [ ... ] > > 2) -O3 -mcpu=i486 -march=i486 -fomit-frame-pointer -fschedule-insns > > -fschedule-insns2 > >141.92 real 141.43 user 0.10 sys > > What do these timings represent? As you say the mp3 playing time > is 373 seconds, but the "real" times vary, the timings don't appear to > be the playing/processing of the mp3 file. Probably something like this: time mpg123 -qt file.mp3 Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
Darryl Okahata wrote in list.freebsd-current: > In the interests of peace and harmony (;-), I'd like to submit the > attached perl script, which lists the status of cvs-controlled files. > In particular, it's very useful for determining which files have been > modified but not committed, like: > [...] Uhm... Maybe I misunderstand what your 100-line perl script does, but I use the following 3-line shell script instead: #!/bin/sh - cvs status | grep '^File:' | grep -v 'Status: Up-to-date$' true Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
[EMAIL PROTECTED] wrote in list.freebsd-current: > On Thu, 23 Sep 1999, The Hermit Hacker wrote: > > just curious, but what is the max setting that can be used to compile the > > kernel? > > Works rather nicely here with > > -O6 -mpentiumpro -march=pentiumpro -pipe -s -fexpensive-optimizations > -ffast-math -ffast-math shouldn't have any effect, because the kernel does not contain floating-point code. -ffexp-opt is already included in -O3 (which is the maximum -O value supported by the compiler), so it is redundant, too. The gcc optimizer is traditionally buggy. I wouldn't trust a system compiled with anything more than -O (especially on production servers). The higher optimization levels don't provide much of a speed improvement anyway, sometimes they make the code even slower. YMMV. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
Sheldon Hearn wrote in list.freebsd-current:
> On Sun, 12 Sep 1999 15:58:01 +0200, Oliver Fromme wrote:
> >
> > # The first command will fail on a handful of files that have their schg
> > # flags set. But it greatly speeds up the next two commands.
> > -rm -rf ${CHROOTDIR}
> > -chflags -R noschg ${CHROOTDIR}/.
> > -rm -rf ${CHROOTDIR}
> >
>
> Which sources are you looking at? That's not what I see in rev 1.85 of
> Makefile.inc1 .
/usr/src/release/Makefile (This thread is about "make release",
or did I misunderstand the subject line?)
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
Matthew Thyer wrote in list.freebsd-current:
> YES please fix this ridiculous inefficiency pointed out by Rod!
There's nothing broken, so there's nothing to fix (IMO).
> The current method of cleaning the build tree is to chflags -R and
> then rm -r which results in two full traversals of the entire /usr/obj
> tree which takes MUCH longer than attempting an rm -r first followed by
> a chflags -R and another rm -r.
Uhm, what are you talking about? The Makefile does exactly
that:
# The first command will fail on a handful of files that have their schg
# flags set. But it greatly speeds up the next two commands.
-rm -rf ${CHROOTDIR}
-chflags -R noschg ${CHROOTDIR}/.
-rm -rf ${CHROOTDIR}
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
John W. DeBoskey wrote in list.freebsd-current: > Well, from the amount of mail I've received, I obviously do not > understand the numbers from my tests, or I've not optimized my > filesystems correctly. > > time rm -rf /snap > 3214.20s real 2.29s user51.53s system (53 minutes) > > time ./snapclean >20.34s real 0.88s user 2.80s system (20 seconds) You should definitely use soft-updates. I don't like the idea that the release makefile could perform a newfs on some partition if some environment variable happens to be set either... I'd vote against the patch. And _if_ the patch gets included, it should be made a bit more sophisticated. For example, it should check whether soft- updates was enabled on the partition, and re-enable it after the newfs. Otherwise the whole make release could run slower than without the patch... Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
