Linux-Development-Sys Digest #688, Volume #6 Fri, 7 May 99 19:14:06 EDT
Contents:
Re: Glibc rant ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: Any program can generate Gif or Jpg ("G. Sumner Hayes")
CVS server config ?? ("Poisseroux Hugues")
Re: pthreads: Need help setting realtime priority! ("Udo Giacomozzi")
Diamond S70 Sound Card Driver (Stephen Torri)
Re: CVS server config ?? (Robert Schiele)
Re: help on compiling glibc 2.1 (and texinfo and termcap and ugh..) (Modemch)
Call for Papers: 1999 Atlanta Linux Showcase (Jennifer Radtke)
Direct access to HD (Nils Henrik Lorentzen)
Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping (Craig Graham)
Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping (MW Ron)
Re: Glibc rant (Paul D. Smith)
Re: glibc-2.1 and incompatible apps ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: Re: Linux disk defragmenter (Adrian 'Dagurashibanipal' von Bidder)
PCI hot plug support (Jim Puthukattukaran)
Sony Vaio Motion Eye camera? ([EMAIL PROTECTED])
Re: Glibc rant (Lou Grinzo)
Re: Get client machine's IP-address (Aaron Leonard)
Re: Destructive Erase? (David B Anderson)
----------------------------------------------------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: 07 May 1999 11:19:44 -0400
>>>>> "Peter" == Peter Mutsaers <[EMAIL PROTECTED]> writes:
> Now we arrived at 2.1.x which is another painful (and unnecessary)
> transition. This shouldn't have been so since it is both the same main
> revision number (6) so there should be no compatability problems, yet
> still the hack of libNoversion (ugh) is necessary to fix a bit of the
> mess.
Although I was one of the people who complained, I must say that I'm not
so sure the problems I've encountered were really due to the 2.1 rather
than to the gcc->egcs change in the RedHat distribution.
> GNU libc makes you dependent on GNU, not always known for fast
This is a totally bogus argument.
> FreeBSD never had such problems since FreeBSD-core controls everything
> in the base system, inclusive the C library etc.
And I must admit that upward-compatibility is too easily dismissed in the
Linux world.
Stefan
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Any program can generate Gif or Jpg
Date: Fri, 07 May 1999 08:17:32 -0400
[This has nothing to do with linux system development.
comp.os.linux.misc seems like the most appropriate group, so I've
directed followups there]
Dove wrote:
> In Linux, is there any program or script can generate a Gif or Jpg
> chart according to some ASCII data?
Check out gnuplot. It's quite powerful.
There's no GUI afaik, so if you're coming from an MS-Windows background
you might be in for a bit of a shock.
-Sumner
------------------------------
From: "Poisseroux Hugues" <[EMAIL PROTECTED]>
Subject: CVS server config ??
Date: Fri, 7 May 1999 15:03:09 +0100
How to configure a server CVS on Linux Redhat 5.2 ??
if you have documentation or opererator mode on it, please mail me at
[EMAIL PROTECTED]
It's very urgent...
tanks.
Hugues
------------------------------
From: "Udo Giacomozzi" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: pthreads: Need help setting realtime priority!
Date: Mon, 3 May 1999 16:23:12 +0200
>Did you ever get a reply to this? I am way behind on the list. Anyway,
>here is some sample code to increase the thread priority. It is called
>from inside the thread and *must* be called as root.
>
> struct sched_param sp;
>
> // Let's bump up our priority
> mlockall(MCL_CURRENT | MCL_FUTURE);
> sp.sched_priority = 99;
> if(pthread_setschedparam(pthread_self(), SCHED_FIFO, &sp))
> perror("pthread_setschedparam");
>
That doesn't work too. :-(
I try to change the priority in 3 ways:
- before creating the thread (setting attributes)
- after thread has been created (pthread_setschedparam)
- and inside the thread itself
None of these ways work (all return OK). Priority still remains at 0
(SCHED_OTHER).
Does anyone have a C example so I can see how/if it works?
Regards
Udo Giacomozzi
--
* Email: [EMAIL PROTECTED]
* UIN: 17745247 (@pager.mirabilis.com)
------------------------------
From: [EMAIL PROTECTED] (Stephen Torri)
Crossposted-To: comp.os.linux.hardware
Subject: Diamond S70 Sound Card Driver
Date: Fri, 07 May 1999 19:38:45 +0100
I decided that one of the better ways to understand programming is to take
on a project. I have decided to learn about how to write a device driver
for my Diamond S70 sound card. So I bought the Linux Device Drivers book
from O'Reilly. I have begun to read it. I wanted to what the general
process is in creating a device driver? What technical information do I
need and how best to receive it?
I have begun to read up on my sound card (i.e. chipset, etc.) so I have
started. I am looking for some help from people who have written sound card
drivers for their own machines. Not requesting a hand out just some help so
I can contribute to Linux.
Stephen
------------------------------
From: Robert Schiele <[EMAIL PROTECTED]>
Subject: Re: CVS server config ??
Date: Fri, 07 May 1999 15:29:45 +0200
Poisseroux Hugues wrote:
>
> How to configure a server CVS on Linux Redhat 5.2 ??
> if you have documentation or opererator mode on it, please mail me at
> [EMAIL PROTECTED]
>
> It's very urgent...
> tanks.
>
> Hugues
Already tried "info cvs"?
Robert
------------------------------
From: Modemch <[EMAIL PROTECTED]>
Subject: Re: help on compiling glibc 2.1 (and texinfo and termcap and ugh..)
Date: 07 May 1999 13:52:15 -0400
"Vladimir G. Stanishev" <[EMAIL PROTECTED]> writes:
> The INSTALL file for glibc 2.1 lists a bunch of programs that are needed
> to compile (or configure) glibc 2.1 successfully. texinfo is one of
> those listed, and since my configure script was failing with a "one of
> your programs is missing or too old" message when it got to checking
> makeinfo (part of texinfo), I downloaded the texinfo package from the
> gnu.org to install it. The configure script for texinfo worked fine but
> teh compile was failing with a bunch of messages about "call to
> unreferenced tputs and tgets functions". the file that was making those
> calls was terminal.c and it had some conditional includes for
> termcap.h. I found from the gnu site that tputs and tgets are part of
> termcap, so what the heck, I downloaded that and went on to install it.
> that one worked fine and I installed it(./configure, make, make install
> - nothing else). after which texinfo actually compiled (same
> ../configure, make, make install). so I happily went back to glibc,
> typed ./configure adn damn it to hell it still didn't work. it fails
> with the same message, the only difference being that when it gets to
> checking makinfo, it says: checking for makeinfo - yes, instead of:
> checking for makinfo - no. The error message is right after that just
> as before.
configure usually creates a log file, which you can check to see exactly
where it's failing. It usually logs the exact test it ran that failed, but
if it doesn't, you can always change configure itself - it's just a shell
script.
--
Regards,
Modemch
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
From: [EMAIL PROTECTED] (Jennifer Radtke)
Subject: Call for Papers: 1999 Atlanta Linux Showcase
Date: Thu, 6 May 1999 22:04:03 GMT
=================================
3rd Annual ATLANTA LINUX SHOWCASE
October 12-16, 1999
Cobb Galleria, Atlanta, Georgia
http://www.linuxshowcase.org
=================================
The Atlanta Linux Enthusiasts, in cooperation with the USENIX Association
and Linux International, is pleased to announce the 3rd Annual Atlanta
Linux Showcase.
In 1999, the Atlanta Linux Showcase will feature three conference tracks
over three days with 40 speakers discussing the technical and business
issues concerning the Linux Operating System. In addition, an Exhibition on
October 14-16 with over 140 vendors, will showcase the latest industry
products for Linux. USENIX will sponsor a Tutorial program on October
12-13. With the attention Linux has garnered in recent months, we expect
over 4000 attendees.
ALS is a forum that brings together both experts and peers in our field. We
invite you to submit paper proposals to enhance the invited talks,
tutorials, and Birds-of-a-Feather sessions. ALS is seeking papers that
demonstrate Tools, Tutorials, or Case Studies in the areas of:
Kernel
Program Development
Networking
Applications
Business Solutions
Usability
Security
Unusual Applications
Important Dates for Submissions
Submission deadline: July 1, 1999
Notification to authors: July 15, 1999
Camera-ready papers due: September 8, 1999
Papers should contain 1500 to 5000 words. After acceptance, papers may be
edited for clarity and temporal changes until September 8, 1999.
Accepted papers will be shepherded through an editorial review process by a
member of the program committee.
Selected papers will be included in the Conference proceedings, distributed
to attendees and also be available from USENIX once the conference ends.
At least one author will present the paper at the Showcase. Paper
presentations will have approximately one hour including Q&A.
Financial assistance for speaker travel and accommodations is available.
ALS requests that if your employer or other sponsor can cover some or all
of these expenses, they do so. Speakers will receive free admission to the
Showcase and an invitation to the welcome dinner Wednesday evening.
Details of how and where to send submissions may be found at
http://www.linuxshowcase.org
------------------------------
From: Nils Henrik Lorentzen <[EMAIL PROTECTED]>
Subject: Direct access to HD
Date: Mon, 03 May 1999 17:08:57 +0200
Hi,
Is there a way in Linux to get direct access to the HD, ie.
raed sectors directly ?
I tried to open /dev/hdx, reading went fine
but trying to seek with lseek(file, SEEK_SET , offset) didn't work
for offsets other than 0, 1, and 2, it fails
with an Invalid Argument error. (I guess it seeks to
the start of each of my my partitions hda1/2/3).
Is there some other way to read the HD that provides
random access to the sectors ?
Nils Henrik
------------------------------
From: Craig Graham <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping
Date: Fri, 07 May 1999 20:47:32 +0000
Eric Hegstrom wrote:
>
> Andy Law wrote:
> > And will Metrowerks (or anyone else) _force_ you to buy an IDE?
>
> Yea they came by my office and held a gun to my head till I ordered it.
>
> Actually I did order it up last night. I used their environments many
> years ago at Apple (they had one of the first really good power-pc
> compilers). I liked their IDE (even though I still spent a lot of time
> in the venerable command line oriented MPW). Sorry! Sure, I may not use
I'd agree - we used Metrowerks compilers & IDE on our last Playstation
project. It also included the interface to GCC, although we never used
it.
It was a choice, and the nice environment made it for us. The
alternative
for those who don't write Playstation games, was the SN Systems
supported
release of GNU C, with their own assembler/linker backend. And MW won
that contest on ease of development on the project.
> it on my big development projects, but I'm not ashamed to say I am
> always looking for shortcuts and even if the company wasn't paying for
> it, $80 is not what I would call a big tool investment. Call me a whimp,
It's pin money compared to the cost of CodeWarrior for Playstation I can
tell
you (which is ten times that price - and still worth it).
> Eric Hegstrom .~.
Craig Graham.
------------------------------
From: [EMAIL PROTECTED] (MW Ron)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping
Date: Thu, 06 May 1999 18:02:57 -0400
In article <[EMAIL PROTECTED]>, Robert Wuest
<[EMAIL PROTECTED]> wrote:
My apology for not replying to this sooner, I normally would have seen
this within one day of posting.
>Is there any kind of demo or test drive version of this?
Not at the moment but we are working on it. If you buy from Metrowerks
there is a 30 day trial period but you'd lose shipping charges. If this
was for a group sale I'm sure something could be arranged. We do have a
web site video conference also.
please write me directly with any specific questions and again I apologize
for the delay in replying.
Ron
--
http://www.zdnet.com/pcweek/stories/news/0,4153,361176,00.html
Pro 4.0 C++ 30% edge in Tak benchmark over VC++ 6.0
METROWERKS Ron Liechty
"Software at Work" [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Glibc rant
Date: 07 May 1999 10:57:34 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Lou Grinzo) writes:
lg> As long as the Linux community takes this view--problems can be
lg> solved by recompiling, that's the benefit of getting the source,
lg> etc., the mainstream user community will forever be a mirage on
lg> the horizon.
The "mainstream user community" will not be upgrading to glibc 2.1 built
from source off the Cygnus ftp site--or if they are, they should know
what they're doing and they deserve what they get.
The "mainstream user community" will do like I do: buy a distribution of
Linux and when it gets upgraded, you upgrade. It's up to the distro
folks to handle all these gross issues. Why should mainstream users
care, any more than they care about the problems experienced by Windows
NT beta testers?
Sure, I have cutting-edge code on my system (like the projects I'm a
developer on) but the rest is stock--I don't have the time or energy to
recompile all that stuff.
I have no problem with the libc5->glibc conversion: I have both shared
libs on my system (Debian) and both libc5 and glibc apps run just ducky.
I fully expect that when a .deb for glibc 2.1 is available, it will also
install just fine and everything will continue to work as before.
What's the problem?
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 and incompatible apps
Date: 07 May 1999 12:29:40 -0400
>>>>> "David" == David T Blake <[EMAIL PROTECTED]> writes:
> 4) Install all glibc2.0 apps into /glibc20/bin
> Keep the glibc2.0 libraries in /glibc20/lib
> Put Shell scripts in place of the binaries. For the
> binary /usr/bin/foo, the shell script would read
> #!/bin/sh
> LD_LIBRARY_PATH=/glibc20/lib:${$LD_LIBRARY_PATH}
> /glibc20/bin/foo
I doubt you've tried this one: the /lib/ld-linux.so.2 that comes
with glibc-2.1 doesn't seem able to load libc.so.2.0.
Well, maybe it works on Debian, but at least I couldn't get it to work on
RedHat (which admittedly doesn't set things up as cleanly as Debian most of the
time).
Stefan
------------------------------
From: [EMAIL PROTECTED] (Adrian 'Dagurashibanipal' von Bidder)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Re: Linux disk defragmenter
Date: Fri, 07 May 1999 21:05:53 GMT
On 7 May 1999 01:32:37 -0500, [EMAIL PROTECTED] (Peter
Samuelson) wrote:
>[Anthony Ord <[EMAIL PROTECTED]>,
> on the Linux IDE driver's (vapor) bidirectional elevator algorithm]
>> The GPL doesn't prevent me from being too crap to do it...
>
>It does prevent you (not actually the GPL but the "no warranty" part
>that usually comes with) from complaining to anyone else if you can't
>or won't do it, though. (:
Obviously it didn't. (Prevent him, I mean). But it should prevent
anybody taking steps against anybody else after complaining didn't
change the situation.
--
Greets from over there
Dagurashibanipal
[EMAIL PROTECTED]
'What with our wounded who can't walk? We don't leave our own!'
'You're right, Captain. We'll take them. They're field rations'
-- Mary Gentle, 'Grunts!'
------------------------------
From: [EMAIL PROTECTED] (Jim Puthukattukaran)
Subject: PCI hot plug support
Date: 7 May 1999 20:49:29 GMT
Hello,
I'm looking for person(s)/group(s) that are interested in providing PCI HotPlug
support for Linux. I am very much interested and would like with other's of like
mind.
regards,
Jim
------------------------------
From: [EMAIL PROTECTED]
Subject: Sony Vaio Motion Eye camera?
Date: 7 May 1999 17:34:27 GMT
Does anyone know what this is, or what drivers I might
use for it?
Rich.
--
[EMAIL PROTECTED] BiblioTech http://www.postmaster.co.uk/
+44 171 384 6917 Unit 2 Piper Centre Premier European email service
http://www.annexia.org 50 Carnwath Road Original message content
London Copyright � 1999 Richard Jones
------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Subject: Re: Glibc rant
Date: Fri, 7 May 1999 18:29:19 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> [EMAIL PROTECTED] (Lou Grinzo) writes:
>
> >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >> This is really not a serious consideration in an open
> >> source system. Everything can be recompiled. A distribution
> >> upgrade was all that I required to be fully functional
> >> again. If I didn't want newer versions of everything, I
> >> could keep what I had. Anything that didn't work, I could
> >> recompile.
> >
> >As long as the Linux community takes this view--problems can
> >be solved by recompiling, that's the benefit of getting the
> >source, etc., the mainstream user community will forever be
> >a mirage on the horizon.
>
> That is life on the bleeding edge. If you want to be comfortable
> using closed source programs, you need to wait about as long
> as it takes the authors to keep up with the recompilation
> cycle.
>
> In Windows, you get upgrades months and months after problems
> are found. With linux you get them in hours if you are willing to
> recompile, or days if you are not willing to recompile.
>
> When you tie your hands by causing a significant dependency
> on a third party to recompile their apps for you, you have
> lost one of the biggest benefits of open source operating
> systems. A system that is part open, part closed, will always
> have significant problems compared to an all open system.
> You can whine about it till the cows come home, but the appropriate
> solution is to use only distributions that have been out for
> a year or so, and to live without the improvements that have been
> made in the meantime. It is just like dealing with any other OS
> vendor, except that you can see the improvements that have been
> made without being able to utilize them.
>
> --
> Dave Blake
> [EMAIL PROTECTED]
>
Sorry, but I don't see the connection you're drawing. I said that
the Linux community should not excuse preventable problems by relying
on the availability of the source, and you're telling me about the
downside of "being comfortable" with closed source programs. Those
are two completely disjoint issues.
The original thread had to do with the problems caused by glibc 2.1.
That should not have happened in open, closed, or any other kind of
source, and it shows that someone, somewhere, was asleep at the switch.
The fact that sufficiently knowledgable users can get around the
problem thanks to open source (at least in the cases I've seen
reported so far), is certainly a good thing. I'm sure we agree
there.
My point was not that open source was bad, but that people should not
use it as a magic wand to excuse any and all mistakes.
(You're right, of course, about what it's like waiting for fixes for
closed source software. I've been dealing with that problem for 20
years as a professional programmer, consultant, and writer. And that's
one of the reasons I'm getting involved with Linux and OS.)
Lou
------------------------------
From: [EMAIL PROTECTED] (Aaron Leonard)
Crossposted-To:
it.comp.linux.development,comp.os.linux.networking,comp.os.linux.development.apps,comp.programming,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.programmer,comp.unix.sco.programmer
Subject: Re: Get client machine's IP-address
Date: Fri, 07 May 1999 22:36:20 GMT
~ > > Does anybody know how can I get in a stand-alone C/C++ program, running
~ > > on a server machine
~ > > but started during a telnet/rlogin session, the IP-address of the client
~ > > machine that launched the
~ > > telnet session ?
~ > >
~ > > Obviously the program doesn't anything know about the client machine.
~ > >
~ >
~ > In unix all logins are recorded in the /etc/utmp file. You could find out
~ > the
~ > format (man utmp) of the file and read the IP address of the client which
~ > started current session(using current pty as the key) from it or use
~ > "system" system call to run a script which returns the IP address to an ENV
~ > variable and read it into the C code
~ >
~ > $who -R am i | awk { print $6 } /who with some option depending on the
~ > / implemetation should
~ > return the IP of
~ > /client that started the
~ > current session
~ >
~ > There should be a better way of doing it..any suggestions......
~
~ There is a more elegant way of doing it using "popen" in unix.
~
~ sid = popen("who am i | awk { print $6 }", "r"};
~
~ you can read the o/p from the stream sid - which will get you the IP add
~ of the client which launched the current session.
That's elegant eh? On a VMS/MultiNet system, you can just do a
$TRNLNM() (or getenv() if you will) on the SYS$REM_ID logical,
which directly gives you the client's IP address and TCP port
number in hex. I guess Unix has a different standard of "elegance".
Cheers,
Aaron
------------------------------
From: [EMAIL PROTECTED] (David B Anderson)
Subject: Re: Destructive Erase?
Date: 7 May 1999 17:12:50 GMT
In article <nOEY2.549$[EMAIL PROTECTED]>,
matthew gauthier <[EMAIL PROTECTED]> wrote:
>I'm trying to implement a destructive file erase, however, I'm at a
>loss as to the best way to insure that the same blocks are overwritten.
Depending on the operating system, it may be impossible.
There are operating systems which don't overwrite blocks at all,
but write new data into new blocks.
The last I used like that was Commander II, a timesharing
operating system on the SDS (XDS?) system 7? (follow-on to the
SDS 940 as I recall). Well, the last I am sure I used
that was like that... Was back in early 70's.
(having trouble remembering the names. The timeshare vendor
was Comshare (cannot remember proper capitalization/spelling
of that name either, sorry)).
In a Journaling file system
(which is a very similar notion) writes
may well go to new disk areas, leaving the old untouched.
SGI's xfs file system is an example of this.
If/when a journaling file system is provided on linux
your approach won't provide a guarantee there.
With linux ext2 I think you are safe if you do
fwrite over all the blocks, followed by fclose(), followed by sync().
>From the sync man page:
According to the standard specification (e.g., SVID),
sync() schedules the writes, but may return before the
actual writing is done. However, since version 1.3.20
Linux does actually wait. (This still does not guarantee
data integrity: modern disks have large caches.)
>Ie I use stdio and overwrite a file with an equal amount of data and
>close it, will the kernel put it on the same disk realestate at the
>next sync? Or am I going to need to work at a much lower level here?
>Any thoughts and pointers on where to start looking are appreciated, as
>are cc's, since my newsfeed sometimes drops articles.
Corrections/elaborations requested...
David B. Anderson [EMAIL PROTECTED] [EMAIL PROTECTED] http://reality.sgi.com/davea/
------------------------------
** 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.development.system) 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-Development-System Digest
******************************
