[SLUG] Just thinking.
I use cdparanoia to rip an audio track. I store it as AudioA.wav. I use cdrecord to burn the track. I rip the burned track and store it as AudioB.wav. I'd like to compare the files to see what sort of job I've made. a) Is there a Linux programme to do this? b) Would anyone care to speculate on what I'd find? Regards, Bill Bennett. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] SCO vs Hurd?
Good afternoon, In the current climate of conflict, I start to think about long term strategies in case of a worst case scenario. Specifically, I'm wondering what's happening with Hurd. Any success stories? Is it actually viable? Worth the trouble of installing? Nick -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] SCO vs Hurd?
It's getting there. Slowely mind! I installed it on my laptop and it was fairly painless. I think it two goes but apart from that it seems to work quite well. I used the debian distro (which I would guess is the only one), apt works so life is good :-) The main problem I have is that X doesn't work on my machine as I need agpart and this is isn't supported on the hurd. You might want to have a look at http://hurd.gnufans.org/ rgh On Mon, 2003-06-30 at 18:00, Nick Croft wrote: > Good afternoon, > > In the current climate of conflict, I start to think about long term > strategies in case of a worst case scenario. > > Specifically, I'm wondering what's happening with Hurd. Any success stories? > Is it actually viable? Worth the trouble of installing? > > Nick -- "It is possible to make things of great complexity out of things that are very simple. There is no conservation of simplicity" -- Stephen Wolfram Richard Heycock <[EMAIL PROTECTED]> tel : 0410 646 369 key fingerprint : 909D CBFA C669 AC2F A937 AFA4 661B 9D21 EAAB 4291 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
grip. It's part of GNOME. rgh On Mon, 2003-06-30 at 17:43, Bill Bennett wrote: > I use cdparanoia to rip an audio track. I store it as AudioA.wav. > > I use cdrecord to burn the track. I rip the burned track and > store it as AudioB.wav. > > I'd like to compare the files to see what sort of job I've made. > > a) Is there a Linux programme to do this? > > b) Would anyone care to speculate on what I'd find? > > Regards, > > Bill Bennett. -- "It is possible to make things of great complexity out of things that are very simple. There is no conservation of simplicity" -- Stephen Wolfram Richard Heycock <[EMAIL PROTECTED]> tel : 0410 646 369 key fingerprint : 909D CBFA C669 AC2F A937 AFA4 661B 9D21 EAAB 4291 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
On 30 Jun, Oscar Plameras wrote: > The reason is as follows: > > Number of IPV4 addresses = 255*255*255*255 * 50 bytes (your allocation) >= 4,228Mb * 50 = > 202,280MB A cache isn't a complete copy. You store what you allow room for, and fall back to your normal mechanism if the entry isn't in the cache. You use LRU typically after the cache fills. This is all very standard stuff, and it's the technique that Solaris uses to get good performance. So I can't see why Linux couldn't do the same. The only trick I see is invalidating entries in the cache that are continually being used, during a period when its address changes. The solution would seem to be simply to invalidate the old entry when the DNS server is told of the address change in the normal course of events. luke -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
On Mon, 30 Jun 2003 [EMAIL PROTECTED] wrote: > On 30 Jun, Oscar Plameras wrote: > > The reason is as follows: > > > > Number of IPV4 addresses = 255*255*255*255 * 50 bytes (your allocation) > >= 4,228Mb * 50 = > > 202,280MB > > A cache isn't a complete copy. You store what you allow room for, and > fall back to your normal mechanism if the entry isn't in the cache. > You use LRU typically after the cache fills. > > This is all very standard stuff, and it's the technique that Solaris > uses to get good performance. So I can't see why Linux couldn't do the > same. It's quite straight-forward to implement a DNS cache on linux -- run bind on the box. Isn't this going in circles? For some reason people wanted to get the cache off the box. Personally I haven't found that removing bind gives a performance benefit (quite the opposite), but different systems use resources in different combinations, so YMMV. Andrew -- No added Sugar. Not tested on animals. May contain traces of nuts. If irritation occurs, discontinue use. --- Andrew McNaughton In Sydney Working on a Product Recommender System [EMAIL PROTECTED] Mobile: +61 422 753 792 http://staff.scoop.co.nz/andrew/cv.doc -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
On 1 Jul, Andrew McNaughton wrote: > It's quite straight-forward to implement a DNS cache on linux -- run bind > on the box. Isn't this going in circles? For some reason people wanted > to get the cache off the box. > > Personally I haven't found that removing bind gives a performance benefit > (quite the opposite), but different systems use resources in different > combinations, so YMMV. Actually, I gather that Linux's implementation of some part of the email address handling (perhaps the DNS lookups or the reverse lookups or something), was orders of magnitude more inefficient than the same handling under Solaris. If you're interested, I can get more precise info from work tomorrow. luke -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] Can you trust rpm when it reports multiple bash installs?
I thought it would be good to run apt-get on an old RH 6.2 system here, too. I installed and ran the appropriate version of apt-get for RH 6.2, and it reported that there were multiple versions of bash installed. I checked, and it does look like there's a problem: # rpm -qa | grep bash bash-1.14.7-22 bash2-2.03-8 bash2-doc-2.03-8 bash-1.14.7-23.6x Fair enough, I thought, we don't need that old 1.14 version: [EMAIL PROTECTED] luke]# rpm -e bash-1.14.7-22 error: package bash-1.14.7-22 is not installed How strange. Perhaps the rpm database needs rebuilding? [EMAIL PROTECTED] luke]# rpm --rebuilddb [EMAIL PROTECTED] luke]# rpm -qa | grep bash bash-1.14.7-22 bash2-doc-2.03-8 bash2-2.03-8 bash-1.14.7-23.6x [EMAIL PROTECTED] luke]# rpm -e bash-1.14.7-22 [EMAIL PROTECTED] luke]# rpm -qa | grep bash bash2-doc-2.03-8 bash2-2.03-8 bash-1.14.7-23.6x Okay, that's looking better. But if I try to remove version 1.14.7-23.6x I get many, many errors: # rpm -e bash-1.14.7-23.6x error: removing these packages would break dependencies: bash is needed by info-4.0-5 bash is needed by etcskel-2.3-1 bash is needed by sysreport-1.0-3.2 /bin/bash is needed by MAKEDEV-2.5.2-1 /bin/bash is needed by XFree86-3.3.6-20 [etc. etc.] How can I check to see whether there really are two versions of bash installed? The idea of doing a forcible erase and then discovering that /bin/bash really has gone fills me with dread. There is only /bin/bash - no other bash on my PATH on this old machine. How can I guarantee that using rpm to uninstall an apparently duplicate bash won't trash the installation? # rpm --version RPM version 4.0.2 luke -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
> I use cdparanoia to rip an audio track. I store it as AudioA.wav. > > I use cdrecord to burn the track. I rip the burned track and store it as > AudioB.wav. > > I'd like to compare the files to see what sort of job I've made. > > a) Is there a Linux programme to do this? Sure, run md5sum on the two files, like this: $ md5sum jdub* 43418bbfc74efc6b94397e427cd3fa32 jdub-face.base64 5c926bcaeeb89add1c4edabffbaca22b jdub.png If the md5sums match, then they have exactly the same content. > b) Would anyone care to speculate on what I'd find? I doubt they'd come out exactly the same, but that's just a guess. If you end up doing it, please share the results! :-) - Jeff -- Get Informed: SCO vs. IBMhttp://sco.iwethey.org/ "If you want to start a debate on a subject, however, all that seems to be necessary is to involve perennial target Richard Gooch." - LWN -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
> It's quite straight-forward to implement a DNS cache on linux -- run bind > on the box. Isn't this going in circles? For some reason people wanted > to get the cache off the box. > > Personally I haven't found that removing bind gives a performance benefit > (quite the opposite), but different systems use resources in different > combinations, so YMMV. Yes, Oscar suggested removing BIND, but it doesn't make sense to me. It's not that CPU/disk intensive when being used as a cache, so removing it is more than likely just going to increase mail spool queue times, rather than alleviate resources to allow the MTA to work better. If BIND is running as an authoritative DNS server for a very busy domain, it's a different kettle of fish. But I couldn't imagine that being the case from the original email. - Jeff -- Get Informed: SCO vs. IBMhttp://sco.iwethey.org/ http://www.xach.com/debian-users-are-beatniks.html -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
On Tue, Jul 01, 2003 at 02:26:41AM +1000, Jeff Waugh wrote: > > > > I use cdparanoia to rip an audio track. I store it as AudioA.wav. > > > > I use cdrecord to burn the track. I rip the burned track and store it as > > AudioB.wav. > > > > I'd like to compare the files to see what sort of job I've made. > > > > a) Is there a Linux programme to do this? > > Sure, run md5sum on the two files, like this: > > $ md5sum jdub* > 43418bbfc74efc6b94397e427cd3fa32 jdub-face.base64 > 5c926bcaeeb89add1c4edabffbaca22b jdub.png > > If the md5sums match, then they have exactly the same content. To a very high degree of probability, but there is a chance they could be different. Other simple checks: ls -l # check the length (size) diff # will tell you if they differ diff -a | less # will show you where they differ (in binary) > > b) Would anyone care to speculate on what I'd find? > > I doubt they'd come out exactly the same, but that's just a guess. If you > end up doing it, please share the results! :-) I'd expect no difference, or small differences. cheers, Woody -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Can you trust rpm when it reports multiple bash installs?
rpm -ql bash | grep bin rpm -ql bash2 | grep bin You'll probably find you do indeed have two bashs installed, one that 6.2 originally came with, one newer (bash2), each with seperate binaries. I think you should be able to get rid of bash2 and its dependencies. Mike __ Mike MacCana ConsultantRHCE, MCSE, MCP+I Cybersource: Providing Quality IT Professional Services for 11 Years Specialists in Unix/Linux, TCP/IP and Web Application Development Level 4, 10 Queen St, Melbourne. Ph : 03 9621 2377 Fax: 03 9621 2477 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Can you trust rpm when it reports multiple bash installs?
On Mon, Jun 30, 2003, [EMAIL PROTECTED] wrote: > How can I guarantee that using rpm to uninstall an apparently > duplicate bash won't trash the installation? I tend to try to upgrade (-U flag) to the newer version. An RPM upgrade will upgrade to the new version, rather than install a second version when you use the -i flag. (If you pass --oldpackage to rpm, you can even "upgrade" to an older version of a package, handy if you've grabbed something unstable from rawhide and want to downgrade). If you successfully upgrade to a newer version and you didn't force the upgrade, you've got a pretty good chance that the installation is fine. -Mary -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Can you trust rpm when it reports multiple bash installs?
On Tue, 1 Jul 2003, Mary wrote: > On Mon, Jun 30, 2003, [EMAIL PROTECTED] wrote: > > How can I guarantee that using rpm to uninstall an apparently > > duplicate bash won't trash the installation? > > I tend to try to upgrade (-U flag) to the newer version. I should add that luke is begging the question: bash2 can coexist fine alongside bash (giving you features of bash2 yet allowing apps that need earlier versions to have their dependencies satisfied) - that's why its called bash2. So yeah - of course you can trust rpm :) Mike -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] Debian BF24
Hi All, We have a server with Adaptec's 39320D SCSI card, but there isn't any modules for it in the bf24 install. The module is aic79xx.o If I wanted to compile it myself, where can I get the bf24 source, or do I just compile from another linux-2.4.18 source? Cheers, Scott -- Scott Ragen Support Manager/IT Administrator Roadtech Systems www.roadtechsystems.com.au PH: +61 2 9807 3516 FAX: +61 2 9808 5294 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
How about 'cmp' That's what its for! -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Debian BF24
yes you use the linux-2.4.18 source but you install the kernel-headers for 2.4.18-bf2.4 all I did was copy the contents of the headers directory to kernel-source-2.4.18 > Hi All, > We have a server with Adaptec's 39320D SCSI card, but there isn't any > modules for it in the bf24 install. > The module is aic79xx.o > If I wanted to compile it myself, where can I get the bf24 source, or do I > just compile from another linux-2.4.18 source? > > Cheers, > > Scott > > -- > Scott Ragen > Support Manager/IT Administrator > Roadtech Systems > www.roadtechsystems.com.au > PH: +61 2 9807 3516 FAX: +61 2 9808 5294 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Can you trust rpm when it reports multiple bashinstalls?
On Mon, 2003-06-30 at 22:37, [EMAIL PROTECTED] wrote: > I thought it would be good to run apt-get on an old RH 6.2 system here, > too. I installed and ran the appropriate version of apt-get for RH 6.2, > and it reported that there were multiple versions of bash installed. > > I checked, and it does look like there's a problem: > > # rpm -qa | grep bash > bash-1.14.7-22 [...] > bash-1.14.7-23.6x At a guess I would say that that means one of those was force installed to overcome a "package x conflicts with package y" error. I don't actually know what RPM does in such cases (since I avoid them like the plague), but it does then beg the question of which package actually owns the files. Mary's suggestion of using the -Uvh command instead of -i is a good one. IMHO you should always use U unless you really, really, really want to be sure that you're installing rather than upgrading (the only situation I can think of where this is beneficial is kernels -- I never want to uninstall my old kernel before I know the new one boots). > [EMAIL PROTECTED] luke]# rpm -e bash-1.14.7-22 > [EMAIL PROTECTED] luke]# rpm -qa | grep bash > bash2-doc-2.03-8 > bash2-2.03-8 > bash-1.14.7-23.6x > > Okay, that's looking better. > > But if I try to remove version 1.14.7-23.6x I get many, many errors: You probably can do that if you upgrade all the packages in your system. I've only got bash 2.05. I imagine that what it is telling you is true though, that the packages in question do rely on bash 1. I would do rpm -ql bash and rpm -ql bash2 to see what files they both have. It may well be that bash2 has a bash2 binary you use to run it. At some point you'll upgrade to a bash-2 (note the dash, not bash2) package, which will upgrade the bash-1 package you have installed and you'll be back to "normal". And bash 2 is exciting stuff - it has arrays :) > # rpm --version > RPM version 4.0.2 I suspect you'll get prompted to do this at some point, but I highly recommend rpm 4.2. It's way fast. HTH James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] Apache, Samba, Logs and updates
Morning All, I would like to tail my logs without interruption during the day, but am having some problems. I run apache and samba on a particular server - when I am logged into this machine and tail -f [the apache] error_log, I am auto disconencted every 10-15 minutes with no error. There is a firewall between myself and the server which I think must drop idle sessions (I do not have administration of that particular firewall). Instead I am trying to log the apache errors to my local directory on the server which is a samba shared folder. I then access the share from this windows 2000 machine and tail -f error_log from the dos prompt. However, for some reason this file never updates in my local tail, hence I can never see the errors appearing. (Tail doesn't see changes in the file untill I open/close the file [say, in notepad] and then start a tail again.) The file itself is updating correctly on the server. Samba version 2.2.8a Apache 1.3.27 C:\>tail -V tail 1.0 created by Jorgen Bosman Any ideas? I'm all outmaybe smb updates slowly? Cheers, .will "This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please destroy it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Central Sydney Area Health Service." -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
On Mon, 2003-06-30 at 17:43, Bill Bennett wrote: > I use cdparanoia to rip an audio track. I store it as AudioA.wav. > > I use cdrecord to burn the track. I rip the burned track and > store it as AudioB.wav. > > I'd like to compare the files to see what sort of job I've made. Well, if I were you I'd convert your ripped .wav files to something like raw audio data -- .wav is a generic format that has all sorts of bizaare variants, but mostly I'd suspect suble differences in the header which render your comparison useless (unless it comes out the same :)). They can for example record free form comments, which from a cd ripper might record the date and time of the rip. There is also some padding which happens on the end of cdaudio tracks. I'm not sure if you get that in the ripped file or not. I assume it would be the same for both the source and the target disks, but I'm really not sure. I'm not actually up to date on audio formats atm. .raw seems like a safe bet to me. Then using diff or something to compare the files. Maybe even vimdiff, so you can see if the errors are at the very start or end (since those errors are meaningless manifestations of protocol). HTH James. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Debian BF24
[EMAIL PROTECTED] wrote on 01-07-2003 11:05:18 AM: > yes you use the linux-2.4.18 source > but you install the kernel-headers for 2.4.18-bf2.4 > all I did was copy the contents of the headers > directory to kernel-source-2.4.18 > Thanks Kevin, I have tried that (I am on the unstable dist if that make any difference), but I am getting errors when trying to "make dep" The error I get is: fork.c:558: error: conflicting types for `kernel_thread' /root/linux/usr/src/kernel-source-2.4.18/include/asm/processor.h:432: error: previous declaration of `kernel_thread' fork.c: In function `kernel_thread': fork.c:570: error: structure has no member named `task_dumpable' fork.c:571: error: structure has no member named `task_dumpable' fork.c:574: warning: implicit declaration of function `arch_kernel_thread' fork.c:577: error: structure has no member named `task_dumpable' make[2]: *** [fork.o] Error 1 make[2]: Leaving directory `/root/linux/usr/src/kernel-source-2.4.18/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/root/linux/usr/src/kernel-source-2.4.18/kernel' make: *** [_dir_kernel] Error 2 Sounds like the headers are incompatible with kernel-2.4.18 (atleast in unstable tree). Cheers, Scott > > Hi All, > > We have a server with Adaptec's 39320D SCSI card, but there isn't any > > modules for it in the bf24 install. > > The module is aic79xx.o > > If I wanted to compile it myself, where can I get the bf24 source, or do I > > just compile from another linux-2.4.18 source? > > > > Cheers, > > > > Scott > > > > -- -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Debian BF24
Hmmm it should work. what I did while I was in /usr/src/kernel-headers-2.4.18-bf2.4 was cp -rf include ../kernel-source-2.4.18 I don't know why you could have gotten the error. But this is what I had to do so that I could install nvidia drivers other wise the standard header files in the kernel would not have worked. could also be the version of gcc you are running I have gcc (GCC) 3.3.1 20030626 (Debian prerelease) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > [EMAIL PROTECTED] wrote on 01-07-2003 11:05:18 AM: > > > yes you use the linux-2.4.18 source > > but you install the kernel-headers for 2.4.18-bf2.4 > > all I did was copy the contents of the headers > > directory to kernel-source-2.4.18 > > > Thanks Kevin, > I have tried that (I am on the unstable dist if that make any difference), > but I am getting errors when trying to "make dep" > > The error I get is: > fork.c:558: error: conflicting types for `kernel_thread' > /root/linux/usr/src/kernel-source-2.4.18/include/asm/processor.h:432: > error: previous declaration of `kernel_thread' > fork.c: In function `kernel_thread': > fork.c:570: error: structure has no member named `task_dumpable' > fork.c:571: error: structure has no member named `task_dumpable' > fork.c:574: warning: implicit declaration of function `arch_kernel_thread' > fork.c:577: error: structure has no member named `task_dumpable' > make[2]: *** [fork.o] Error 1 > make[2]: Leaving directory > `/root/linux/usr/src/kernel-source-2.4.18/kernel' > make[1]: *** [first_rule] Error 2 > make[1]: Leaving directory > `/root/linux/usr/src/kernel-source-2.4.18/kernel' > make: *** [_dir_kernel] Error 2 > > Sounds like the headers are incompatible with kernel-2.4.18 (atleast in > unstable tree). > > Cheers, > > Scott > > > > Hi All, > > > We have a server with Adaptec's 39320D SCSI card, but there isn't any > > > modules for it in the bf24 install. > > > The module is aic79xx.o > > > If I wanted to compile it myself, where can I get the bf24 source, or > do I > > > just compile from another linux-2.4.18 source? > > > > > > Cheers, > > > > > > Scott > > > > > > -- -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Debian BF24
[EMAIL PROTECTED] wrote on 01-07-2003 11:32:38 AM: > Hmmm it should work. > what I did while I was in /usr/src/kernel-headers-2.4.18-bf2.4 > was > > cp -rf include ../kernel-source-2.4.18 > Yes, Very weird I tried the stable, and make dep works, but checksum.h brings up a lot of warnings, then make bzImage brings up this error: In file included from ksyms.c:50: /root/linux/kernel-source-2.4.18/include/asm/checksum.h: In function `ip_fast_csum': /root/linux/kernel-source-2.4.18/include/asm/checksum.h:73: error: parse error before "movl" /root/linux/kernel-source-2.4.18/include/asm/checksum.h:75:17: invalid suffix "f" on integer constant /root/linux/kernel-source-2.4.18/include/asm/checksum.h:82:17: invalid suffix "b" on integer constant /root/linux/kernel-source-2.4.18/include/asm/checksum.h:90:13: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h:105:17: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h: In function `csum_fold': /root/linux/kernel-source-2.4.18/include/asm/checksum.h:106: error: parse error before "addl" /root/linux/kernel-source-2.4.18/include/asm/checksum.h:108:17: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h:121:13: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h: In function `csum_tcpudp_nofold': /root/linux/kernel-source-2.4.18/include/asm/checksum.h:122: error: parse error before "addl" /root/linux/kernel-source-2.4.18/include/asm/checksum.h:126:9: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h:128: error: `__x' undeclared (first use in this function) /root/linux/kernel-source-2.4.18/include/asm/checksum.h:128: error: (Each undeclared identifier is reported only once /root/linux/kernel-source-2.4.18/include/asm/checksum.h:128: error: for each function it appears in.) /root/linux/kernel-source-2.4.18/include/asm/checksum.h: At top level: /root/linux/kernel-source-2.4.18/include/asm/checksum.h:128: error: parse error before ')' token /root/linux/kernel-source-2.4.18/include/asm/checksum.h:161:17: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h: In function `csum_ipv6_magic': /root/linux/kernel-source-2.4.18/include/asm/checksum.h:162: error: parse error before "addl" /root/linux/kernel-source-2.4.18/include/asm/checksum.h:173:17: missing terminating " character /root/linux/kernel-source-2.4.18/include/asm/checksum.h:176: error: `__x' undeclared (first use in this function) /root/linux/kernel-source-2.4.18/include/asm/checksum.h:176: warning: no return statement in function returning non-void /root/linux/kernel-source-2.4.18/include/asm/checksum.h: At top level: /root/linux/kernel-source-2.4.18/include/asm/checksum.h:176: error: parse error before ')' token /root/linux/kernel-source-2.4.18/include/asm/checksum.h:176: error: parse error before "__u32" make[2]: *** [ksyms.o] Error 1 make[1]: *** [first_rule] Error 2 make: *** [_dir_kernel] Error 2 Slaziar:~/linux/kernel-source-2.4.18# gcc --version gcc (GCC) 3.3 (Debian) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Cheers, Scott -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
From: <[EMAIL PROTECTED]> > On 30 Jun, Oscar Plameras wrote: > > The reason is as follows: > > > > Number of IPV4 addresses = 255*255*255*255 * 50 bytes (your allocation) > >= 4,228Mb * 50 = > > 202,280MB > > A cache isn't a complete copy. You store what you allow room for, and > fall back to your normal mechanism if the entry isn't in the cache. > You use LRU typically after the cache fills. > Just a point of clarification: Cache is structrured data, or data list, or list, kept in CPU MEMORY all the time and maybe used by a software to locate other informatioin or to manipulate information. Database is structured data, or data list, or list, kept in DISK STORAGE and maybe used by a software to locate other information or to manipulate information. http://www.acay.com.au/~oscarp/disclaimer.html http://www.acay.com.au/~oscarp -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Opinions sought: Exim vs Sendmail
On Tue, 1 Jul 2003, Oscar Plameras wrote: > From: <[EMAIL PROTECTED]> > > On 30 Jun, Oscar Plameras wrote: > > > The reason is as follows: > > > > > > Number of IPV4 addresses = 255*255*255*255 * 50 bytes (your > allocation) > > >= 4,228Mb * 50 = > > > 202,280MB > > > > A cache isn't a complete copy. You store what you allow room for, and > > fall back to your normal mechanism if the entry isn't in the cache. > > You use LRU typically after the cache fills. > > > > Just a point of clarification: > > Cache is structrured data, or data list, or list, kept in CPU MEMORY > all the time and maybe used by a software to locate other informatioin > or to manipulate information. > > Database is structured data, or data list, or list, kept in DISK STORAGE > and maybe used by a software to locate other information > or to manipulate information. This is simply not true. A cache may be kept on disk, and commonly is. eg Squid caches to disk because the overhead of disk retrieval is less than the overhead of repeating the network retrieval. Also, a database may in some cases be implemented as an in-memory structure, although this is sufficiently unusual that you should always be clear about what you're talking about if you wish to avoid the assumption that it is disk-based. Andrew McNaughton -- No added Sugar. Not tested on animals. May contain traces of Nuts. If irritation occurs, discontinue use. --- Andrew McNaughton In Sydney Working on a Product Recommender System [EMAIL PROTECTED] Mobile: +61 422 753 792 http://staff.scoop.co.nz/andrew/cv.doc -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
[SLUG] openmosix
I have another prob with openmosix, for the life of me I cannot work out why it will not start. I keep getting an invalid configuration error when starting. Any ideas anybody, my .map file is below Cheers, # openMosix CONFIGURATION # === # # Each line should contain 3 fields, mapping IP addresses to openMosix node-num\ bers: # 1) first openMosix node-number in range. # 2) IP address of the above node (or node-name from /etc/hosts). # 3) number of nodes in this range. # # Example: 10 machines with IP 192.168.1.50 - 192.168.1.59 # 1192.168.1.50 10 # # openMosix-# IP number-of-nodes # 1 192.168.200.1 10 Lyle Chapman Pre-Press Supervisor Torch Publishing Co. 47 Allingham Street, Condell Park 2200, NSW, Australia (02) 9795 (02) 9795 0096 -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
Many thanks to the people who replied to my posting. It was prompted by my getting cdparanoia and cdrecord to produce a disc. (Never mind the sarcasm, it was a major miracle. My next project is to raise the dead.) cdparanoia's propaganda says that it will "fix" small problems on a disk. All well and good. But having ripped an audio track, fixed or not, it has to be burned, ie., what with "translation" to .wav, software to send this file to the burner and the burning process itself, there is room for error(s). We do not live in the best of all possible worlds. Hence my enquiry. In my case, ripper and burner are not the same instrument, although even if they were, the argument remains unchanged. There are also these thoughts: even if errors *are* shown to exist, they may not amount to much, human hearing being what it is and if they *do* amount, I may not be able to do much about them. I will, however, post what results I get. Thanks again, Bill Bennett. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
Re: [SLUG] Just thinking.
On Tue, Jul 01, 2003 at 03:23:29PM +1000, Bill Bennett wrote: > Many thanks to the people who replied to my posting. > > It was prompted by my getting cdparanoia and cdrecord to produce > a disc. (Never mind the sarcasm, it was a major miracle. My next > project is to raise the dead.) > > cdparanoia's propaganda says that it will "fix" small problems on > a disk. All well and good. But having ripped an audio track, > fixed or not, it has to be burned, ie., what with "translation" > to .wav, software to send this file to the burner and the burning > process itself, there is room for error(s). We do not live in the > best of all possible worlds. > > Hence my enquiry. In my case, ripper and burner are not the same > instrument, although even if they were, the argument remains > unchanged. There are also these thoughts: even if errors *are* > shown to exist, they may not amount to much, human hearing being > what it is and if they *do* amount, I may not be able to do much > about them. Here's a strategy: I think the CD standard is meant to be fault tolerant - a story I've heard is you should be able to drill a 5mm hole in a CD and not notice the difference in quality. So if CDparanoia can't read a small part of your CD for some reason, it will make up something in the gap (e.g. blank space). Clean your CDs before you rip them. If you do find differences or the copied CD is noticably worse or are just curious: get CD paranoia to rip 5,10, or 100 copies (depending on how much you care and how much time you have) and see if they are all the same. something like this: for i in (*.wav); do for j in (*.wav); do cmp $i $j; done; done; will output any differences. My script does every comparison twice, but it is very simple. Do this to the original and the source. Try multiple CD-ROM drives if you can. If you get say 10 copies, 6 are the same as each other and the other 4 are all different to each other, the burn one of the 6 good copies. (and delete the other 9 copies) cheers, Woody > > I will, however, post what results I get. I will be interested in this too! cheers, -- Woody -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
