Linux-Misc Digest #586, Volume #24 Wed, 24 May 00 16:13:02 EDT
Contents:
Re: msie 5 for unix on linux (brian moore)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Zombies - help ("Art S. Kagel")
Re: linux system (Rod Smith)
Re: how to enter a bug report against linux? ("Peter T. Breuer")
Gnome graphical ppp dialer ? (Brian Moore)
Re: backup program ("Art S. Kagel")
Re: Need ideas for university funded project for linux (Donovan Rebbechi)
Re: sendmail relay??? (Bob Hauck)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: UPS from Compaq on linux (Erik Jan van Westen)
Re: how to enter a bug report against linux? (Leslie Mikesell)
Re: how to enter a bug report against linux? (Leslie Mikesell)
Re: Windows by Day, Linux by Night (Harlan Grove)
Re: How Microsoft inhibits competition & innovation (Mats Olsson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (brian moore)
Subject: Re: msie 5 for unix on linux
Date: 24 May 2000 18:56:17 GMT
On Wed, 24 May 2000 06:30:05 GMT,
h8te <[EMAIL PROTECTED]> wrote:
> i know there is msie 5 for unix, but does any one know if i can use it in
> linux , i dont think im the only one who has found msie 5 for unix on the
> microsoft site, am i? well any way if you know send mail to
> [EMAIL PROTECTED]
No. It's for Solaris on Sparc or HPUX on PA-RISC. Since you most
likely have Linux on x86, it won't run for you. (It doesn't run well on
either of the above, so it's not a great loss.)
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 24 May 2000 13:53:46 -0500
In article <[EMAIL PROTECTED]>,
Praedor Tempus <[EMAIL PROTECTED]> wrote:
>> I agree about the right to fork, but several free software licenses
>> (the X-Windows, and BSD licenses come to mind) allow people to make
>
>And the right to fork is good because...? Because it is GOOD to
>fragment
>software and libraries so that apps fail to work nicely?
Suppose the original author is hit by a beer truck and his relatives
sell all rights to the code to a video game manufacturer. Or
he just quits supporting it, or takes it a completely different
direction than the rest of the world wants to go.
Or you want it to work on hardware that he can't/won't support.
>So that if you
>want app A to work, built on a forked library, you have to install yet
>another version in addition to the original - or worse, replace the old
>with the new, probably/possibly breaking all your software based on
>the pre-forked libs?
Hey, just libc...
>I can't see the "right to fork" as a good thing. Forking is what killed
>the unix baby early on.
Hardly, it is mostly what kept it alive. However, in that case not
all the forks are what we are discussing since some of the branches
are complete rewrites because the original code did not allow
unlicensed forks.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
Date: Wed, 24 May 2000 15:12:15 -0400
From: "Art S. Kagel" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Zombies - help
You want to register a signal handler for SIGCLD (or SIGCHLD) and in that
function loop on wait3 (or waitpid with a pid of -1) with the NOHANG option
until it returns a zero or call waitpid with the pid you are looking to
have died.
You need to loop if there are multiple child processes since any SIGCLD that
arrives while the program is in the signal handler will be lost so multiple
children could be defunct when you receive the signal.
See: man wait3, man waitpid
Also see UNIX Network Programming by W. Richard Stevens.
Art S. Kagel
James Linder wrote:
>
> Hi
> I have a program that does some stuff ... forks ... execvp to run mpg123
> ... and continues processing. When mpg123 finishes it makes a zombie.
> My book says that the parent process must "wait" for a child, an un-waited
> for child makes a zombie.
> Can anybody tell me the proper way to
> a) run - fork - exec - and continue running
> b) check if a child process is still running. I am watching the pid in
> /proc but this does not disappear when the child zombies, so I can't tell
> when mpg123 is finished
>
> Thanks for any help
> James
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Rod Smith)
Subject: Re: linux system
Date: Wed, 24 May 2000 19:14:54 GMT
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
abdul-malik garnes <[EMAIL PROTECTED]> writes:
> what lexmark printer is compatible with linux os
AFAIK, all Lexmark laser printers are Linux-compatible, but few inkjets
are. Lexmark has produced a few PostScript inkjets that are
Linux-compatible, and some "speak" PCL, and so work through Ghostscript.
Most Lexmark inkjets use their own proprietary language for which no
Ghostscript driver is yet available, AFAIK. For specifics, check the
following web page:
http://www.picante.com/~gtaylor/pht/printer_list.cgi
--
Rod Smith, [EMAIL PROTECTED]
http://www.rodsbooks.com
Author of books on Linux networking & multi-OS configuration
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 24 May 2000 19:07:10 GMT
g'day john.
In comp.os.linux.misc John Hasler <[EMAIL PROTECTED]> wrote:
: Peter writes:
:> Report an interesting bug, and it'll be fixed in a jiffy.
: Known bugs are not interesting. It's hard to find out if a bug is known.
Lurking on the kernel list, or asking, tends to solve the problem.
Happens every day. Well, bugs crop up every two to three days.
Discussion about them goes on every day.
:> Boring bugs indeed will be forgotten.
: And then reported again by people who are not aware that they are known.
Bugs that are reported more than once begin to become interesting.
Even popular!
:> I believe that's known.
: If there was a kernel BTS you could easily know for sure.
It is very hard to locate or even describe a kernel bug. It takes quite
a level of expertise. As to known, well, I am not following the 2.3.99
development woes closely, but I'm pretty sure that scsi was completely
whacked no so long ago, and that nobody has quite brought it in sync.
In fact, now that I think about it, I did hear a few days ago that Doug
Ledford was working hard on fixing the aic7xxx family drivers so that
they'd stop spoiling the party. I got the impression that he had taken
a week off somewhere to do so ...
:> I believe that's known. I've seen several threads go past on the scsi
:> problem in 2.3.99 and above. Doug's working on it. Ask him!
: And waste his time with something you believe that he may already know
Waste his time? Doug's glad to respond to questions, as you know. It's
his code and he's interested in maintaining it! That's why his names's
up there. That's why he's working on it.
: about? I expect I would just get a testy reply telling me not to send in
: bugs with out researching them first.
You'll get a reasoned reply.
: I wrote:
:> ...was a kernel BTS I'd research the problem there and either test any
:> fix...
: Peter writes:
:> EH? Why don't you mail the maintainer?
: Anyone who imagines that he has found a new kernel bug should email a
: maintainer? How are the maintainers to get any work done?
Oh, don't worry about that. Are you being funny here? I can't see any
smileys! As you know, the kernel list delivers a thousand or so mails a
day. Everyone copes with that. It's a question of grepping the subject
and deleting.
:> That's debian practice too!
: Filing a bug via the Debian BTS does email the maintainer. Emailing a
: Debian maintainer without checking the BTS first will often get you
: directed to the BTS.
You'll be told if they think the bug is known, fixed, or due to debian
or the upstream maintainer. It's a prior filter to squeeze out 2
categories: bugs introduced by debian fork maintainers, and bugs known
by debian to have been passed on upwards already. Any unrecognized bug
due to the author WILL go back to the author, as you say. But this is
for applications .. kernel bugs are orders of magnitude harder to find.
That's because end-users don't know if it's an application or a kernel
error they're seeing. It is very rare for a kernel bug ever to be
reported as such by a luser.
:> As you know, you might get Alan's interest on that one too.
: what makes you think I know any such thing?
Because you are a reasonable person, and Alan is a reasonable person,
and it is reasonable that the combination of sound with anything would
interest Alan.
:> Make sure at least Doug knows about it.
: If there was a kernel BTS I could do so in a few minutes. I'm not willing
: to root about in an email archive, though: sound isn't that important to
: me. And I won't risk irritating the maintainer by being the 130th one to
: report a known bug.
: Besides, I don't know who 'Doug' is or why you assume that I know that this
: bug should go to him.
Because he's the named and registered author and maintainer of the scsi
driver in question. Is this posting a forgery?
: --
: John Hasler
: [EMAIL PROTECTED] (John Hasler)
: Dancing Horse Hill
: Elmwood, WI
Perhaps not.
Peter
------------------------------
From: [EMAIL PROTECTED] (Brian Moore)
Subject: Gnome graphical ppp dialer ?
Date: 24 May 2000 15:08:36 -0400
Reply-To: [EMAIL PROTECTED]
I just reinstalled Redhat on a new disk and I can't find the little
Gnome app I used to use to dial up a ppp interface. Does anyone
know which rpm it is in? I've forgotten the name of the thing, but
it used to appear under the "Internet" menu. It's very simple,
just brings up a box where you select an interface and click to
bring it up or down.
--
Brian G. Moore, School of Science, Penn State Erie--The Behrend College
[EMAIL PROTECTED] , (814)-898-6334
------------------------------
Date: Wed, 24 May 2000 15:17:47 -0400
From: "Art S. Kagel" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: backup program
BRU is excellent. I have four drives with two partitions each (one DOS one
ext2) comprising about 7GB and needing 3-4 volumes on my tape drive. I
tried several backup products and tried to roll my own. BRU took the job
in stride all the others choked somehow or other.
Art S. Kagel
Mail List1 wrote:
>
> Which backup program is the best for LINUX?
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 24 May 2000 15:19:11 -0400
On Wed, 24 May 2000 11:14:50 -0600, Praedor Tempus wrote:
>And the right to fork is good because...?
Because if the maintainer abandons or neglects a project, someone else
can pick it up. However, while "the right" to fork is a good thing,
that doesn't mean that gratuitous forking is a good thing.
ESR talks about this kind of thing and uses the phrase "promiscuous
theory, puritan practice", I think the essay is "homesteading the noosphere".
Some examples of "good" forks include egcs ( which I believe has been handed
back to the FSF. egcs-c++ is a vast improvement over g++ ) and x-emacs.
> Because it is GOOD to
>fragment
>software and libraries so that apps fail to work nicely? So that if you
Like I said, the fact that the right to fork is a good thing doesn't
mean that forking for the sake of it is a good thing.
>the unix baby early on. It is brought up as a fear of something that
>could possibly kill linux (for general use...but then, there are
The fragmentation that exists within Linux has very little to do with
forking. THe main problem is that there is a lack of standardisation
on versions of the different APIs.
>I would like a nice, clear explanation of why forking should be
>considered >good.
Your confusing "the right to fork" with forking itself. The right to fork
is one that should be exercised judiciously.
>Standards
>make coder's lives easier, make user's lives easier. SOME things should
The main problem at the moment ( at least wrt Linux ) is not about forks,
but it's about failure of the distributors to use the same versions of
core components such as glibc, the compiler, and other shared libs.
As far as the developers are concerned, there is not much difficulty writing
code that will compile on any Linux distribution. Also, KDE and GNOME make
writing for multiple distributions or even UNIX flavours pretty easy.
Basically, you can use "GNOME" or "KDE" as your target platform. If you
use glib data types or QT classes and the KDEsupport stuff, you usually don't
really need to worry about the peculiarities of your target platform.
However, failure to
standardise on lib versions, compilers and package managers makes
releasing binaries for multiple distributions a bit of a pain.
--
Donovan
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Subject: Re: sendmail relay???
Reply-To: hauck[at]codem{dot}com
Date: Wed, 24 May 2000 19:08:17 GMT
On Wed, 24 May 2000 13:51:58 -0400, Dennis Marshall
<[EMAIL PROTECTED]> wrote:
>I'm trying to configure sendmail to relay mail from another domain, but
>I'm unsure what to change to accomplish this.
Visit <http://www.sendmail.org/>. Look at the FAQ.
--
-| Bob Hauck
-| Codem Systems, Inc.
-| http://www.codem.com/
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 24 May 2000 14:23:59 -0500
In article <[EMAIL PROTECTED]>,
Praedor Tempus <[EMAIL PROTECTED]> wrote:
>>
>> Yes, which does nothing to damage the code that continues to
>> be available.
>[...]
>
>But it leads to PRECISELY the problem that exists on the Windoze side of
>the PC that is generally agreed to be bad.
How does it lead to that?
Please show where Windows has even used any available
and well tested code, or how the existance of such code has
ever led them to do anything. (The Win2k/kerberos business
may be a first).
>M$ produces extensions to
>some standard. Because they are big, powerful and influential AND
>provide tools that MANY use that then utilize these
>alterations/extensions,
>creating software/web pages, etc that incorporate these extensions,
>they lock out alternatives.
Why do you imagine that the alternative of starting from scratch when
writing this cruft intended to lock you in would be better in
any way for any of us?
>There is no reason to assume, magically, that M$ could not and would not
>succeed in doing so (if they wished) with BSD-based/non-GPL software.
>They have the right to extend it and break it and not release the
>alteration.
Just as they have the right to write from scratch an even
worse alternative.
>Many people would use it (a RELATIVELY small core of
>hardcore linux/bsd users are not significant in the big scheme so
>THEIR refusal to go along is irrelevant in the larger market) and
>break intercompatibility...hmmm...just like in the windoze world.
Yes, but, being well tested, it would not cause everyone as
much trouble.
>BSD licenses vs GPL or LGPL, would foster this sort of thing. There
>just isn't (yet) a big boy on the block like M$ taking advantage of
>his weakness in the licensing scheme.g
Beg your pardon? Just about every player in the internet market
started with BSD code. I contend that we are all better off
as a result.
>I ask for someone to defend this ability when it comes to BSD-style
>licenses while at the same time railing AGAINST the practices of
>M$ in a similar manner. They are doing what a BSD license permits.
The kerberos/domain control extension deserves to be railed against
because it give monopolistic control over enterprise authentication
and access control, not because it extends a standard.
>They make a practice of code forking to force users to use THEIR
>solutions rather than a competitors...but in the BSD license world
>this would be a good thing, fully supported by "the community"?
>
>I honestly ask why this is not hypocrisy because I really don't see
>why it isn't?
Before you go too far down this road, ask yourself if you would
be better off if Sun had been unable to use BSD code, or if NFS
would have ever been done if the company had been forced to donate
their work instead of being able to choose which parts to contribute.
Or would X have ever been done if the companies that funded the
work had not been able to incorporate it into their own proprietary
products?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Erik Jan van Westen <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.setup,nl.comp.os.linux.installatie,nl.comp.os.linux.overig
Subject: Re: UPS from Compaq on linux
Date: Wed, 24 May 2000 21:00:24 +0200
In nl.comp.os.linux.overig Kees van Veen <[EMAIL PROTECTED]> wrote:
> Hello ALL,
> Is there anybody out there who allready configured an Compaq UPS
> (T1000h) on his linux box ??
> I am having trouble, I get every time a BATTERY-LOW msg. The problem is
> probebly the deamon, I tried upsd, genpowerd end others...
> I use Debian Slink release 4/5
Je zult even uit moeten zoeken bij wie de betreffende ups vandaan
komt. Compaq maakt ze imho niet zelf. Je hebt goede kans bij het
vroegere fiskars, is overgenomen, nieuwe eigenaar is overgenomen.
Weet dus de naam niet meer.
Normaal is ook wel ergens te vinden hoe de ups zijn informatie
kwijt wil. Dat varieert van 1 of 2 lijnen van de seriele poort
omhoog of omlaag trekken tot echte volledige seriele comm. At
random programma's proberen zal niet gauw tot resultaat leiden,
mede omdat deze programma's geconfigureerd zullen moeten worden.
Dus: gebruik een zoekmachine.
EJ
--
Linux 2.2.15 on a pentium 233 MHz
Hi, I'm a signature borg virus. You are now assimilated :)
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 24 May 2000 14:39:19 -0500
In article <8gh98u$iqj$[EMAIL PROTECTED]>,
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>
>:> Report an interesting bug, and it'll be fixed in a jiffy.
>
>: Known bugs are not interesting. It's hard to find out if a bug is known.
>
>Lurking on the kernel list, or asking, tends to solve the problem.
>Happens every day. Well, bugs crop up every two to three days.
>Discussion about them goes on every day.
This is fine for the handful of people who are working to solve
current bugs. It is not so fine for the millions of people who
are trying to work around what should be well understood bugs
in released versions.
>:> Boring bugs indeed will be forgotten.
>
>: And then reported again by people who are not aware that they are known.
>
>Bugs that are reported more than once begin to become interesting.
>Even popular!
This is irrelevant to someone whose system has to work now.
>It is very hard to locate or even describe a kernel bug.
Again, a correct description is only relevant to a couple of
people. The rest of the world just needs to know what circumstances
break what thing, how to avoid it, and when it is fixed so they
can stop taking those measures to avoid it.
>: And waste his time with something you believe that he may already know
>
>Waste his time? Doug's glad to respond to questions, as you know. It's
>his code and he's interested in maintaining it! That's why his names's
>up there. That's why he's working on it.
It should never be necessary for a developer to tell someone else
how to work around bugs. That is the real reason that bug tracking
systems exist - to give the developers time to fix bugs instead
of discussing them.
>: Anyone who imagines that he has found a new kernel bug should email a
>: maintainer? How are the maintainers to get any work done?
>
>Oh, don't worry about that. Are you being funny here? I can't see any
>smileys! As you know, the kernel list delivers a thousand or so mails a
>day. Everyone copes with that. It's a question of grepping the subject
>and deleting.
And this is the list that you are suggesting that end users or
administrators would use to see if a bug is already known?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 24 May 2000 14:43:43 -0500
In article <8ggs4l$[EMAIL PROTECTED]>, <ggq15$[EMAIL PROTECTED]> wrote:
>> The openness of Linux is a plus in this area,
>>but the lack of a central and official repository for bug tracking
>>and status is a big minus.
>
>we dont need no freek'ng central bug tracking for linux kernel. if
>you have a problem, search the web or ask Alan Cox or post a question
>on a linux news group (there are tones of 'em).
Bug tracking systems usually have an 'official' maintainer so you
can tell the correct answer if there is one. For some reason the
newsgroups seem to be full of idiots these days, speaking for
no one but themselves.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Harlan Grove <[EMAIL PROTECTED]>
Subject: Re: Windows by Day, Linux by Night
Date: Wed, 24 May 2000 12:37:46 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Simone Paddock) wrote:
>For whatever reason, a great many Linux and UNIX users
>spend a lot more time working with Windows than they might
>like, or like to admit.
<snip>
>Find out why and how at:
>http://windows.oreilly.com/news/byday_0500.html
<snip>
I read through this article, and there's not much there.
Some excerpts:
"... We created the equivalent of "man pages" for every
user level program and other major user interface features
of the system."
I was unaware the man page format was the ideal form of
documentation. GNU man pages are mostly no longer
maintained, with GNU commands now described in Info pages.
Well, Windows does have WinHelp and HTML 'manuals' in a
hypertext format similar to GNU's Info pages. So man pages
look like one step backwards.
"1. The name and path of the executable, so you can run it
from the command line (either a DOS shell, or in Windows
98, the new address toolbar, or if you have a third party
product like MKS Toolkit, which brings UNIX utilities to
Windows, a korn shell). No need to pick through 5 layers of
menu to run Solitaire any more...just type sol in the
address toolbar."
Gosh. As if anyone familiar with Gnome or KDE couldn't
figure out that filenames may differ from GUI menu entries,
and as if anyone familiar with linux symbolic links
couldn't figure out Windows shortcuts.
"2. Any related files or directories. (One of the things
you quickly learn is that many key UI features in Win95 and
Win98 are controlled by the contents of some key system
directories. Change the contents of those directories, and
you change the system more quickly than using Microsoft's
graphical configuration tools.)"
Renaming /lib or changing files in it with only cp, mv and
rm would be an equally expedient way of altering the
behavior of a linux system with similar consequences, too.
I haven't read the sample chapters, but if they're anything
like what's on the web page cited, this book falls way
short of O'Reilly's usual standards. No surprise they're
desperate to drum up sales.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: [EMAIL PROTECTED] (Mats Olsson)
Crossposted-To: comp.lang.java.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: How Microsoft inhibits competition & innovation
Date: 24 May 2000 20:02:45 GMT
In article <#W6p80ax$GA.273@cpmsnbbsa09>, Ermine Todd <[EMAIL PROTECTED]> wrote:
>In this case, I have to agree with you 100%. Part of the justification,
>interestingly enough, from MS for the original development of OS/2 was to
>deal with this very issue of how the API had grown in sometimes less than
>efficient manner (re: downright awkward).
>
>However, legacy issues will be with us forever - case in point: one of the
>limiting factors on the size of the solid rocket boosters in the space
>shuttle was the (thru a moderate concatenation of history) width of horses
>behinds. The reason is that the segments are transported on railcars, which
>has to go thru a tunnel cut for the width of the track that was based upon
>the historical width in England, that was based upon the width of the wagons
>that ran on the roads (and fit the ruts therein) built by the Romans (2000
>years ago) who designed it this way based upon the how wide a wagon would
>fit behind two horses - hence, the measurement of the width across their
>backsides.
It's a beatiful story. Unfortunately, its an urban legend.
http://www.urbanlegends.com/misc/railroad_gauge.html
/Mats
------------------------------
** 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
******************************
