Linux-Misc Digest #135, Volume #20 Mon, 10 May 99 02:13:08 EDT
Contents:
Re: Boycott Intel on your own webpage (Jim Richardson)
Re: GNU reeks of Communism (Craig Kelley)
Re: Debian and 2.2.5 ("Cameron Spitzer")
SCSI Hardware Problem? ("Albert Wiersch")
Re: FreeBSD vs. Linux vs. Windows (Leslie Mikesell)
Re: KPPP and lock up problems. (Otik787)
Re: cdrecord thinks CD-writer is CD-ROM (Greg)
Some general info pls (John Embleton)
Re: program won't compile (Paul Kimoto)
Re: modem as faxanswering-machine ? (Rob Redburn)
Re: Where is best location of swap partition on a disk? ("Spud")
Re: a) Win98 b) SYS (Przem Kowalczyk)
mounting CD's burned on WIn9x with joliet extensions - bugs?? (Daniel T. Stoelting)
Re: 191.1.1.5 sent an invalid ICMP error to a broadcast (Jeff Liebermann)
Re: FreeBSD vs. Linux vs. Windows (Leslie Mikesell)
mounting freebsd fs in Linux (Arun Sharma)
Remote printing: no daemon present (Martin Schulz)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim Richardson)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.hardware
Subject: Re: Boycott Intel on your own webpage
Date: 10 May 1999 03:39:31 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 09 May 1999 15:47:27 GMT,
Murphy, in the persona of <[EMAIL PROTECTED]>,
brought forth the following words...:
>On 6 May 1999 13:39:22 -0500, [EMAIL PROTECTED] (Andrew Comech)
>wrote this little gem:
>
>>>When he says MAC addresses, he doesn't mean MACintosh, he means MAC
>>>address, as in ethernet address, the address that IP addresses are
>>>finally translated to. And he is right, since MAC addresses are more or
>>>less unique. A site could theoretically track these just as they could
>>>do with the hostid on a Solaris machine, or the Processor# in a PIII.
>>
>>Oops.
>>Anyways, IP addresses are dynamically assigned when you dial up from home,
>>so who cares (although a netmask 255.0.0.0 would be good).
>
>MAC addresses are the actual identifier of the Ethernet card, not the
>IP address of your machine. In fact these numbers are so unique that
>there is software out there that uses them as a means of registration.
>
>>That is, this would be jungles of methods and and contra-methods which enable
>>or disable PSN, where only brave [hackers] are able to overcome PSN in their
>>computers. Do we want to face all that in a year or two, or do we just keep the
>>voice up trying to avoid PSNs completely?
>
>Cry me a f'n river. If you don't like this PSN, then don't buy Intel.
>Personally, I could give a rat's ass about whether or not software
>distributes the serial number of my CPU. At worst, it'll have no
>effect on me, at best, if my machine ever gets stolen, I may be able
>to recover it.
>
Except of course, if you upgrade your machine, you lose the s/w and have
to reregister, and "prove" you bought the s/w in the first place. (again)
Or if you buy a new machine, or if you have to repair your machine in
a few ways.
A really poor licensing scheme, one that won't make it in the general mkt.
Kinda like being told that the audio cd you just bought, can't be played in
either your car, or home, but only one of them.
--
Jim Richardson
www.eskimo.com/~warlock
All hail Eris
"Linux, where do you want to go tomorrow?"
------------------------------
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.linux.advocacy,gnu.misc.discuss
Subject: Re: GNU reeks of Communism
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 05 May 1999 10:08:26 -0600
Andrew Carol <[EMAIL PROTECTED]> writes:
> > If vendors know the key to encode, then you do too (unless you posit
> > secret channels between Intel and every software vendor, which wouldn't
> > remain secret very long anyway).
> >
> > Or if they use public key crypto, you could create your own key pair,
> > give one key to the software vendor, and decrypt with the other.
>
> 1 - Person buys software which is encrypted by vender.
> NOTE - Vender may change keys frequently.
>
> 2 - Person registers software on-line.
>
> 3 - CPU provides ID of CPU to vender.
>
> 4 - Vender passes that to Intel via web channel.
Why not just use the CPU ID itself in some hash function?
No need to involve Intel in the mix.
Look at DiViX.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: "Cameron Spitzer" <[EMAIL PROTECTED]>
Subject: Re: Debian and 2.2.5
Date: 10 May 1999 04:11:44 GMT
In article <[EMAIL PROTECTED]>,
Kevin <[EMAIL PROTECTED]> wrote:
>
>I have taken the above into consideration... what other problems may cau=
>se
>the boot to drop around the partition check? =20
If the lilo.conf does not have a root= line, the zImage will
try to mount whatever partition was mounted as root on the machine
where it was compiled.
To re-educate an errant zImage, use rdev(8).
rdev zImage /dev/hda2
or whatever. If you don't give a device, rdev will tell you about your
zImage file.
Cameron
--
Spammers, beware.
------------------------------
From: "Albert Wiersch" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: SCSI Hardware Problem?
Date: Sun, 9 May 1999 23:11:54 -0500
Help! My SCSI drive started giving me an error.
Current error sd08:02: sense key Medium Error
It is a Micropolis Tomahawk 3391NS.
Is my drive fried or can I repair it? Please send a reply to me by email to
make sure I get it.
Any help is greatly appreciated.
Al
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD vs. Linux vs. Windows
Date: 9 May 1999 22:44:03 -0500
In article <7gusho$sgd$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>
>>>In this kind of situation, the hacks in inetd and sendmail to stop
>>>listen()ing for new connections is a good, cheap, effective solution.
>>
>>Hmmm, that reminds me. I've seen sendmail do some horrible things
>>when someone had a box configured to start a queue run every 30
>>seconds then sent something to a huge list of addresses.
>
>Fools can break anything.
>
>The standard sendmail load limiting mechanism first stops running the
>queue, and then at a higher load as measured by avenrun, turns off
>listen().
This one seemed not to limit the queue runs - at least not until
the system was at a point where I didn't have the patience to
wait for a prompt (probably hours).
>So use a non-linear function combining swap space, the avenrun load, and
>the number of processes of various kinds that you are running. For
>example, let each PERL script count itself in a file when they start and
>end and have apache watch the file, or make apache look through the process
>table every 30 seconds and count. Or add a system call that does the
>counting.
This sounds like more work than just completing the job.
An open/lock/read/write/truncate/unlock/close is going to be
slower than most CGI operations.
>The easiest hack for such special purposes might be to warp the kernel
>avenrun code compute exactly what you need and report it in the avenrun
>values. Then you would not need to change apache. The disadvantage of
>such a hack is that standard commands would report nonstandard measures
>of the system load, but that's also an advantage.
I've always blamed this on the extent that the VM system hides the
fact that you are about to make the system difficult to use. If
malloc() had a way to indicate 'you can have this if you really
want, but the machine has used half its swap space and is already
threshing badly' then programs might politely back off.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Otik787)
Crossposted-To:
alt.os.linux,apana.lists.os.linux.redhat,comp.os.linux.setup,linux.redhat.install
Subject: Re: KPPP and lock up problems.
Date: Sun, 9 May 1999 22:19:15 -0600
My linux box participates on a tcp/ip NT network so it already has all
the network settings. domain name, IP, etc... There are settings in
kppp to stop using the local DNS server once you connect. perhaps it
does something to the domain name as well?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> Try editing /etc/hosts and assign your system a proper name (instead of
> 'localhost.localdomain').
>
> It sounds like the dialup scripts are renaming your system for you,
> which breaks X.
>
>
------------------------------
From: [EMAIL PROTECTED] (Greg)
Subject: Re: cdrecord thinks CD-writer is CD-ROM
Date: Mon, 10 May 1999 00:25:53 -0500
> > When I try to write to my CD-writer with
> > 'cdrecord -v speed=2 dev=5,0 cdimage.raw'
> > it fails to write because it thinks the
> > device is a CD-ROM...
> Are you uasing the generic scsi device? for the first scsi it would be
> /dev/sga
No, I'm not sure what you mean by this. How
would I use the generic scsi device?
Greg
------------------------------
From: John Embleton <[EMAIL PROTECTED]>
Subject: Some general info pls
Date: Mon, 10 May 1999 12:43:54 +1000
This is a multi-part message in MIME format.
==============630F6C0230AAF89382FAD6BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can anyone tell me which of the available Linux commercial versions
(Suse, Redhat, Slackware, etc) is the closest to SVR4 Unix (most
compatible).
Regards
==============630F6C0230AAF89382FAD6BF
Content-Type: text/x-vcard; charset=us-ascii;
name="johne.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Embleton
Content-Disposition: attachment;
filename="johne.vcf"
begin:vcard
n:Embleton;John
x-mozilla-html:FALSE
url:icpdd.neca.nec.con.au
org:NEC Australia;ICPDD
adr:;;649 Springvale Road;Mulgrave;Victoria;3170;Australia
version:2.1
email;internet:[EMAIL PROTECTED]
title:Contractor
fn:John Embleton
end:vcard
==============630F6C0230AAF89382FAD6BF==
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: program won't compile
Date: 10 May 1999 00:25:19 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Greg wrote:
> checking for a C-Compiler... egcs
> checking whether the C compiler (egcs ) works... no
> configure: error: installation or configuration problem:
> C compiler cannot create executables.
>
> it then exits. I'm running PPC Linux 4.1 which is based
> upon Red Hat 5.0. egcs appears to be installed. Any ideas
> on what I should try to get it to compile?
Read the (end of) config.log. Make sure that binutils,
libc development, kernel headers (etc.) packages are
installed.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: Rob Redburn <[EMAIL PROTECTED]>
Subject: Re: modem as faxanswering-machine ?
Date: Sun, 09 May 1999 23:39:20 -0400
check out mgetty and vgetty
gus
peter wrote:
> anyone knows if there is some programm that makes my modem to a
> voice/fax-answeringmachine ?
>
> peter
>
> -----------------
> pilsl@
> ANTISPAM
> goldfisch.atat.at
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.sun.admin
Subject: Re: Where is best location of swap partition on a disk?
Date: Mon, 10 May 1999 03:38:53 GMT
In my experiences, it doesn't matter where you put your swap space. I
think once the processes have to page out to the swap file, the speed from
where it is on the disk is negligible.
>I was just reading the Linux partitioning mini-HowTo, and it says (in
section
>3.3):
>
> o Older disks have the same number of sectors on all tracks. With this
> disks it will be fastest to put your swap in the middle of the disks,
> assuming that your disk head will move from a random track towards the
> swap area.
>
> o Newer disks use ZBR (zone bit recording). They have more sectors on the
> outer tracks. With a constant number of rpms, this yields a far greater
> performance on the outer tracks than on the inner ones. Put your swap
on
> the fast tracks.
>
>Is it widely accepted that putting the swap area on the outer tracks really
>is best? It seems like the first statement (put swap in the middle of the
>disk) would be better because it would minimize the average distance
traveled
>by the disk-head mechanism when seeking from a random location to the swap
>area. Read/write speed may be faster on the outer tracks, but the heads
have
>to *get* to the tracks first, and I always thought that the latency to seek
>to a disk region was the biggest chunk of time expended for reading/writing
>small amounts of data. (But I can see this could be data-size dependent.)
>
>I'd be interested in finding out the opinions of knowledgeable people on
this
>point, and especially, pointers to any documents that explain this issue in
>more detail.
>
>--
>Michael Hucka, Ph.D. -- [EMAIL PROTECTED]
>GENESIS Development Group, Division of Biology, Caltech
------------------------------
From: [EMAIL PROTECTED] (Przem Kowalczyk)
Subject: Re: a) Win98 b) SYS
Date: 9 May 1999 22:06:13 GMT
Reply-To: [EMAIL PROTECTED]
Matthew Slowe in comp.os.linux.misc wrote:
>In article <[EMAIL PROTECTED]>, Przem
>Kowalczyk <[EMAIL PROTECTED]> writes
>>>What is the equivalent of the DOS 'SYS' command in Linux?
>>
>>There is no stright way to transfer system from hard disk to a floppy (I'm
>>guessing you want to do it).
>>
>>Przem
>>
>
>I wanted to essentially copy essential startup files from /dev/hda1 ->
>/dev/hdb1 *NOT* /dev/fd0
>
>Equivalent DOS: SYS c: d:
>
>And then proceed to copy everything else over aswell
The easiest way is to use cp (or cpio, tar) and simply copy date from one
drive to the other. Finaly, you have to inform kernel which is the root
partition (with rdev).
Przem
--
I forgot my shirt at the water's edge.
The moon is low tonight.
R.E.M
------------------------------
From: [EMAIL PROTECTED] (Daniel T. Stoelting)
Subject: mounting CD's burned on WIn9x with joliet extensions - bugs??
Date: Mon, 10 May 1999 04:32:05 GMT
Hello,
I think there is a bug when mounting CD's burned under WIn9x
by Adaptec Direct CD. The CD mounts perfectly but some file
sizes are incorrect. For example a large archive of Staroffice 5.0
which is +50 MB is shown to be only a few MB. Another example is
a mp3 file which is 7 mb is shown to be only 1 mb. mp123 plays only
the 1 mb of data fine. This problem was noticed only after
upgrading to RedHat 6.0 so it may or may not be associated
with it. Thanks for your attention to this matter.
-Dan
------------------------------
From: [EMAIL PROTECTED] (Jeff Liebermann)
Crossposted-To: comp.unix.sco.misc
Subject: Re: 191.1.1.5 sent an invalid ICMP error to a broadcast
Date: Mon, 10 May 1999 05:20:41 GMT
Reply-To: [EMAIL PROTECTED]
On 10 May 1999 01:47:23 GMT, "Peter Caffin" <[EMAIL PROTECTED]> wrote:
I like detective stories, interesting problems and guesswork.
>There are two Linux PCs
That's nice. Any particular flavour? Version? IP addresses? Clues?
>at the office, a number of Win95 PCs and a number
>of SCO UNIX PCs.
I didn't know that all SCO Unix versions were identical. Any particular
product or version? You must be trying to be intentionally vague. Does "a
number" mean anything specific? Are you a mystery writer?
>There's one SCO UNIX PC that's been causing error
>messages to pop up on my logs (and to the console) for ages.
Any particular one? My guess is 191.1.1.5 but it might be one of the
"other" SCO Unix PC's from your description. Hard to tell.
>We're trying to kill off a Novell Netware server here, and I really want
>to remove this as being a potential source of problems. Unfortunately, the
>owner of the box considers it "not his problem" (remind me to rant on
>a.s.r sometime).
Since you know about alt.tech-support.recovery, then I suggest you apply a
self-lart for blabbering this question. what does this unspecified version
of Novell Netware have to do with this? Is it running TCP/IP? Is it's
name stm0150? Is it broadcasting something that the SCO box would fail to
appreciate? Why should only one Linux machine complain?
>This is an example of what's appearing in my /var/log/messages on the main
>Linux server:
Oh, it's the "main" Linux server. Anything in syslog?
>May 6 11:40:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast
I'll assume that stm0150 is the main Linux server.
>May 6 12:25:20 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast
OK. Let's convert the error message from Linux into English. stm0150 sent
a broadcast. 191.1.1.5 (the unspecified SCO box) sent a reply via ICMP
that the Linux box failed to appreciate. The shopping list of likely
culprits are bootp, IPX/SPX SAP (server advertising protocol), DHCP server
announcements, and such. I'm really guessing as there's not enough info to
make a positive identification. Dive into /usr/adm/syslog ON BOTH MACHINES
and see if a protocol name or number is specified.
>May 6 13:16:52 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast
Whatever is doing this, repeats itself 5 or 10 times every 20 seconds.
Something on the Linux box is configured to do something on the SCO box and
fails to appreciate whatever the SCO box is returning.
>It *seems* to be patterned-ish, but, not.. Anyone from the SCO world (or
>the Linux world) have any suggestions on what might be causing this sort
>of behaviour?
SCO World and Linux World are both magazines. Why would you want a
magazine editor or publisher to answer your question?
> 191.1.1.5 is the SCO system.
Ummmmm, gee thanks. Out of curiousity, duz your company own 191.1.1.5 or
is this borrowed from someone? Is this network connected to the interknot?
Are the error messages continuous or only appear when connected to the
interknot?
Sigh. Another day, another guess.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD vs. Linux vs. Windows
Date: 9 May 1999 22:19:07 -0500
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>: So how do you pick the number which allows the maximum service when you
>: have a mix of normal httpd's which may be serving static files or perl
>: CGI's, and mod_perl httpd's which may or may not be connecting elsewhere
>: for an upredictable amount of time?
>
> You *don't*. It's an *air-bag*. If you're running a machine that
> close to the end of the system's resource limits as a normal event
> you've got *much* bigger problems then simply a few slow CGI
> programs.
Sure, that's what I said in the first place. Running at 50% capacity
at peak load would seem like you have a nice cushion, but when you
are doing 30 or more a second (probably not unusual these days) it
doesn't take much of a slowdown to stir up a problem.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: mounting freebsd fs in Linux
From: Arun Sharma <[EMAIL PROTECTED]>
Date: Mon, 10 May 1999 05:44:09 GMT
Hi,
I have a primary partition (/dev/hda3) dedicated to freebsd. Freebsd
has created its filesystems (/, /usr, /var) within this partion. After
reading the FAQs, I figured out that on my Redhat 6.0 system, I can
mount it as
mount -t ufs ufstype=44bsd /dev/hda3 /bsd
And it seems to work just fine. Now, how do I mount /usr and /var ?
My disk roughly looks like:
hda1 -> Win95
hda2 -> Linux
hda3 -> BSD
hda4 -> Extended (whole bunch of Linux partitions)
-Arun
------------------------------
From: Martin Schulz <[EMAIL PROTECTED]>
Subject: Remote printing: no daemon present
Date: 05 May 1999 19:02:27 +0200
When doing remote printing from linux box (a) to linux box (b), the
files to print get into the spool directory of (b) as they should, but
then stay there forever.
lpc tells me:
queuing is enabled
printing is enabled
1 entry in spool area
no daemon present
That is, lpd on (b) is not able to deliver the files to the printer;
lpd indeed runs on (b).
In /var/log/messages, I find:
May 5 17:47:43 iwr01 lpd[1350]: Can't create temp cfp file
May 5 17:47:43 iwr01 last message repeated 247 times
May 5 17:47:43 iwr01 lpd[1350]: sduplex: can't scan /var/spool/lpd/sduplex
OTOH, no problem when printing locally on (b) everthings works smoothly.
Any ideas? Is it a Bug? A Feature? A Permission problem ?
I am using redhat 5.2 and already updated lpr to lpr-0.35-1.
Thanks,
Martin.
--
Martin Schulz [EMAIL PROTECTED]
Uni Karlsruhe, Institut f. wissenschaftliches Rechnen u. math. Modellbildung
Engesser Str. 6, D-76133 Karlsruhe
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.misc) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Misc Digest
******************************
