Linux-Development-Sys Digest #237, Volume #6 Fri, 8 Jan 99 16:14:21 EST
Contents:
Re: How to get Disk I/O rate (bps/sec) per disk ? (Richard Jones)
Re: Kernel 2.2.0-pre5 (compilation error) ("Harry")
Re: Why I'm dumping Linux, going back to Windblows (Iain)
Linux on a SparcBook 2 (Nico van Rossum)
Re: Registry for Linux - Bad idea (Johan Kullstam)
Re: disheartened gnome developer (Frank Sweetser)
Re: Linux v2.1.132 and 2940U/UW Scsi boot problems? (David T. Blake)
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: disheartened gnome developer (Adam P. Jenkins)
Init hangs on reboot (Bryan Hackney)
2.2.0-pre5 schedule_timeout: wrong timeout (TGAPE!)
i960 RP/RD driver (Neal Richter)
Re: Kernel 2.2.0-pre5 (compilation error) (Nathan Myers)
Re: Redefining time_t (Roger)
----------------------------------------------------------------------------
From: Richard Jones <[EMAIL PROTECTED]>
Subject: Re: How to get Disk I/O rate (bps/sec) per disk ?
Date: Fri, 8 Jan 1999 11:39:02 +0000
JiSook Kim <[EMAIL PROTECTED]> wrote:
: hi!
: How to get Disk I/O(bps/sec) per disk?
You can't read this from the kernel (AFAIK ...)
but you certainly can measure it approximately
using the /sbin/hdparm tool (see the -t and -T
options). If you want a more accurate benchmark
you might also want to do an Altavista search
for `bonnie'.
: functions or data file...
: or
: I want more information for /proc/stat file structure.
???
Rich.
--
- Richard Jones. Linux contractor London and SE areas. -
- Very boring homepage at: http://www.annexia.demon.co.uk/ -
- You are currently the 1,991,243,100th visitor to this signature. -
- Original message content Copyright (C) 1998 Richard Jones. -
------------------------------
From: "Harry" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.2.0-pre5 (compilation error)
Date: Thu, 7 Jan 1999 22:23:34 +0100
Christoph Egger wrote in message <[EMAIL PROTECTED]>...
>When I try to compile the Kernel 2.2.0-pre5, I get always an compiler
>error:
>
>ip_masq.c: In function '__ip_masq_in_get':
>ip_masq.c:544: �IP_MASQ_F_DLOOSE� undeclared (first use this function)
>ip_masq.c:544: (Each undeclared identifier is reported only once for
>each function it appears in.)
>ip_masq.c: In function �__ip_masq_out_get�:
>ip_masq.c:597: �IP_MASQ_F_DLOOSE� undeclared (first use this function)
>...
>make[3]: *** [ip_masq.o] Error 1
>make[3]: Leaving directory �/usr/src/linux-2.2.0-pre5/net/ipv4�
>...
>
>Because I don�t know which value IP_MASQ_F_DLOOSE should have, I can�t
>fix this problem.
>
Putting
#define IP_MASQ_F_DLOOSE 0x0010 /* loose dest binding */
in include/net/ip_masq.h let me compile the kernel.
--
Raphael Wegmann
[EMAIL PROTECTED]
------------------------------
From: Iain <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Fri, 08 Jan 1999 14:30:03 +0100
Reply-To: [EMAIL PROTECTED]
Don't worry if you can't remeber, it probably wasn't that important.
Iain.
<esc>
:qa!
Nobu Toge wrote:
> Joseph Coffman <[EMAIL PROTECTED]> writes:
>
> > vi sucks, and it always has. It should only be used in a
> > pinch, or by sadists. Anyone who has room in their head for
> > all the vi commands, has probably overwritten some important
> > "being human" information in the process of memorizing that
> > crap.
>
> Yeah, exactly my sentiment. Indeed, I do feel like I have overwritten
> some important being human info that way, and I can't quite
> recall what those things were <g>
>
> - Nobu Toge ([EMAIL PROTECTED])
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
------------------------------
From: Nico van Rossum <[EMAIL PROTECTED]>
Subject: Linux on a SparcBook 2
Date: Fri, 08 Jan 1999 15:10:02 +0100
Hello *
Does someone knows of Linux works on a SparcBook 2
and if zo, How can I install it or where can I find more info
Tanks in advance
Nico van Rossum
[EMAIL PROTECTED]
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 08 Jan 1999 09:25:40 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> Nice solution! That handles the new conventions on linux perfectly.
> Linux seems a bit more organized and better thought out than other
> unix implementations, well at least with regards to configuration.
>
> I would like one file that is higher up than than appconf.d that
> allows the location of appconf.d to be configured. My reasoning is that
> on other unix's the /etc area is in root is sometimes quite small, so may
> not be capabable of holding it. I can envisage other systems
> wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> ... I kind of like the linux way, but perhaps we should allow for
> the placement elsewhere.
put user application configuration in /usr/etc. place systems/boot
stuff in /etc. this mirrors the /usr/bin v /bin and /usr/sbin v /sbin
splits.
also, there's no need for the `conf.d' part. simply being part of
/etc means its a configuration file. the `d' can maybe stay but i
think that's redundant too.
if the application has *one* configuration file, it could be a
straight file under the appropriate etc directory. if the application
has more than one file, make a directory.
it it not so clear how to manage shared data, i.e., two applications
want the same data (e.g., bash and csh both want a default path. i'd
be nice to maintain one and have the other follow automatically).
perhaps links (hard or soft) would be useful.
> You definately nailed one of the problems though!!
--
johan kullstam
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 08 Jan 1999 10:09:24 -0500
[EMAIL PROTECTED] ("Bob Taylor") writes:
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] writes:
>
> [snip]
>
> >> if eveything is free, companies will close, and there will be no jobs.
> >
> > FUD.
>
> How so?
in this context, it is. it's the myth that if all software is made free,
there will be no jobs for any programmers anymore, because no one will pay
money for software. i'm sure the good people at redhat and cygnus would be
quite to dispute this, though.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Woody: What's going on, Mr. Peterson?
Norm: Let's talk about what's going *in* Mr. Peterson. A beer, Woody.
-- Cheers, Paint Your Office
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Linux v2.1.132 and 2940U/UW Scsi boot problems?
Date: 08 Jan 1999 07:20:46 -0800
[EMAIL PROTECTED] (M Sweger) writes:
>
> I see the Adapatec has agreed to help the Linux driver people out
>developing SCSI drivers for Linux. How is this going, particularly
>in resolving problems?
That is not really how it works. The Adaptec drivers, after the support
period started, were updated furiously. The newest 2.0.* series
drivers support all but the most recent BIOS from Adaptec. The
2.1.* kernel series is close behind. My stuff all works fine
on a 1-2 year old 2940 U2W card.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 07 Jan 1999 17:16:22 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> > > Maybe it should be store.conf or opStore.conf, hmm
> > >
> > > Thoughts?
> >
> > it should definatelly be a directory, /etc/appconf.d/ a lot of the redhat
> > systems have been doing this for packages like pam and logrotate. any app
> > that wants to interface with either of them simply places it's own config
> > file in the appropriate /etc/ subdir, and the package picks it up and runs
> > with it. so to get logrotate to work on your custom data file, you simply
> > need to create /etc/logrotate.d/mylogfile and logrotate will use it. much
> > easier to use (and esp to automate!!) than having a single config file with
> > multiple sections.
>
> Nice solution! That handles the new conventions on linux perfectly.
> Linux seems a bit more organized and better thought out than other
> unix implementations, well at least with regards to configuration.
thought about this a bit more, including how it might fit in with the
precedence issue. we should be able to simplify this into 4 main layers.
1 - global policies. these would be organization wide policies, nearly
always coming in from a centralized server in one fashion or another.
2 - system policies. these are policies that apply only to the local host
- file locations, resources availible, etc.
3 - user policies. these are the ones that the user has control of,
typically stored in a ~/.foo directory.
4 - applications defaults - whatever the compiled in defaults for that
particular application are.
global policies would be ones that universally apply to everyone in the
organization - such as the organization name, network configuration
information (for a sufficiently simply network), etc. most of these would
be marked as non-overridable. system policies would be ones dictated by
the administrator of that particular machine that may or may not apply to
other machines. first thing that comes to mind here would be local file
locations.
user polices are whatever the user has configured in their own private
configuration, and app defaults is exactly that - whatever default settings
the app ships with. hmm... this should also include /etc/opStore/<appname>
- this could allow the application to generate system wide defaults
settings at install time.
the top layers should have locations to define metadata, say,
/etc/opStore.d/opStore for the global and system,
/etc/opStore.d/<application> for the application level, and
~/opStore/defaults for the user level. assume that the levels are
consulted internally as listed above, 1 - 4. if an option is specified
multiple times, each time will overwrite the previous one, unless one of
the previous specifications has marked the options as immutable. each
level would be able to specify the exact locations/methods of where and how
to get it's resources, and what order *they* should be consulted in.
overall, this should result in a level of configurability that's just plain
silly =)
> I would like one file that is higher up than than appconf.d that
> allows the location of appconf.d to be configured. My reasoning is that
> on other unix's the /etc area is in root is sometimes quite small, so may
> not be capabable of holding it. I can envisage other systems
> wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> ... I kind of like the linux way, but perhaps we should allow for
> the placement elsewhere.
definatelly. all we really need to find is a single metadata config file,
which can then contain pointers to everything else.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Real theology is always rather shocking to people who already
think they know what they think. I'm still shocked myself. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Adam P. Jenkins)
Date: 7 Jan 99 22:18:32 GMT
In article <[EMAIL PROTECTED]>,
Perry Pip <[EMAIL PROTECTED]> wrote:
>But suppose you fork the code and create your own version called NavQt,
>distributed as patch+original. If your version becomes popular, Troll Tech
>can instantly include your patches in their version, making it part of
>thier *commercial* product, charging people money for the commercial
>version. You are not on the same level with them. You do not have equal
>rights, even to your own work, under the qpl. If you can accept that,
>that's fine for you.
>
>Redhat is spending $$$ on gnome development. But nowhere in the copyright
>or license does it say that they exclusivly own or control it. They are
>part owners of the copyright, and if you contribute a worthwhile patch,
>you become a part owner too. Redhat plans to make money selling service
>and support for gnome, which you can do as well.
>
>So there is a key difference in business model here. Redhat dishes out
>free software under GPL/LGPL and hopes to make money on service and
>support. Troll tech is trying to make money via license royalties. In this
>respect Troll Tech's business model has more in common with Microsoft than
>it does with Redhat.
>
>If your happy with Troll Tech's terms, and want to develop with Qt/KDE, go
>for it. If your happy with Microsofts terms, and want to develop with
>Visual Studio, go for it. I personally find Gnome/GPL/LGPL the least of
>the evils.
I think you give a pretty balanced overview here, but I think the
way you insinuate that Troll Tech and Microsoft are similar is
pretty disingenuous. The way I see Troll Tech is: they offer what
is arguably the best designed and best documented X toolkit available,
for free with source code for non-commercial development. In return
they get to use the patches submitted by users in their commercial
version. To me this seems like a good deal all around, but I
understand that others may not think so.
On the subject of comparing Troll Tech to Microsoft, it seems clear
to me from Troll Tech's history of listening and responding to
users' criticisms and demands, including non-commercial users, that
they care about supporting free software just as much as RedHat
does. However Troll Tech completely depends on sales and support
of Qt for their livelihood, so they can't afford to limit their
customer base to only businesses that want to sell Open Source
software. Therefore they need to use a different license than the
GPL. I'm sure there are cynics who will say that the only reason
Troll Tech releases the source code for Qt is so they can get the
patches people send in, but I think it's clear to anyone who has
worked with Qt and communicated with Troll Tech for a while that
their commitment to free software goes far beyond merely commercial
interests. Microsoft on the other hand is the epitome of pure,
unadulterated commercial interest, and shows no interest in, or
support for the free software movement, or its values.
Adam
--
Adam P. Jenkins
ajenkins at netway dot com
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Init hangs on reboot
Date: Fri, 08 Jan 1999 11:06:49 -0600
Reply-To: [EMAIL PROTECTED]
Hello.
I just put together an AMD k6-2, 333, and installed RH5.2 with the updates.
Init hangs on a simple reboot.
Init 0 : OK
Halt : OK
Reboot -f : OK
Init 6 or reboot : hangs after mess INIT: no more processes...
Anyone else seen this before I go digging into init. Thanks.
BH
--
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
* Failure teaches only what not to do next time.
*
* Would you trust your mission-critical computing to a company
* that sells stuffed toys?
------------------------------
From: [EMAIL PROTECTED] (TGAPE!)
Subject: 2.2.0-pre5 schedule_timeout: wrong timeout
Date: Fri, 8 Jan 1999 16:32:29 GMT
I've not been able to reproduce this yet; I'm not sure I want to.
I was having some problems with diald not running under 2.2.0-pre5. I
decided to try recompiling diald to see if it would help. I ran it, it
still died immediately. I then ran ./diald -daemon.
schedule_timeout: wrong timeout value f<something> from <something>
filled my screen. (I determined I'd write down the exact message after
I got it to reproduce.) I could switch consoles, but basically
everything was hosed. I remembered that I'd answered yes to the Magic
Sysrq, so I hit alt print-screen, and tried to remember a key. I
decided to kill all processes except for init. I remembered the wrong
key; I hit l instead. (I'm now going to make a patch to have make
config let you disable l.)
On reset, my computer couldn't work the IDE drives. I powered off,
waited 10s, powered up, and it failed at SCSI. I played around with it
a while, then powered off, pulled off the wide chain and powered up. It
rebooted. After booting all the way up, I halted the system, powered
off, reattached the wide chain, reseated the connectors on that chain,
rebooted, and it came up. I don't know if this bit of annoyance was
caused by the alt-printscreen-l or by the schedule_timeout.
After the system was up and running again, I decided to try and do it
again, though this time, I umounted most of my partitions first. (I did
not want to re-fsck 20 partitions again.) It was also with a different
kernel, as I'd recompiled and installed new kernel before playing with
diald. Strangely, ./diald appeared to work now. The difference in
kernel was only adding fbcon support. There was a bunch of fiddling
with the kernel, and the first kernel had gotten booted with modutils
from ancient times (slackware S3.1?), and the second time it was with
modutils-2.1.121.
I've now restored my linux/.config from the other kernel, and
recompiled, but I'm waiting until I get home to play with it more.
I've also decided that Tux needs to be configurable; he's cute, he's
adorable, he doesn't mess with my scrollback nearly as badly as in 125,
but he has to go, until you guys get him fully potty-trained. Even
then, I might prefer to have the memory (or does he get cleaned with the
other unused allocated kernel memory?)
Ed Grimm
------------------------------
From: Neal Richter <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: i960 RP/RD driver
Date: Fri, 08 Jan 1999 12:34:41 -0700
Hello,
Does anyone have any source out there for a device driver for any
kind of i960 RP/RD based PCI board?
I would appreciate any info anyone can provide!
Thanks
--
____________________________________
Neal Richter
Software Engineer
Salt Lake Digital Imaging
124 South 600 West
Logan, UT 84321
435-787-2803
435-787-2810 FAX
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: Kernel 2.2.0-pre5 (compilation error)
Date: 7 Jan 1999 16:19:57 -0800
Christoph Egger<[EMAIL PROTECTED]> wrote:
>When I try to compile the Kernel 2.2.0-pre5, I get always an compiler
>error:
>
>ip_masq.c: In function '__ip_masq_in_get':
>ip_masq.c:544: �IP_MASQ_F_DLOOSE� undeclared (first use this function)
>
This is fixed in the -ac1 patch. Look for /DLOOSE/.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Roger@localhost (Roger)
Subject: Re: Redefining time_t
Date: Fri, 08 Jan 1999 19:35:55 GMT
On 7 Jan 1999 19:11:07 GMT, [EMAIL PROTECTED] (H. Peter Anvin)
wrote:
>Wrong standard.
Oops!
--
Roger
------------------------------
** 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
******************************
