Linux-Development-Sys Digest #310, Volume #6 Wed, 20 Jan 99 09:13:55 EST
Contents:
Re: Non-*nix OS built on linux kernel? (Christopher B. Browne)
Re: disheartened gnome developer (Christopher Browne)
Re: disheartened gnome developer (Navindra Umanee)
Re: iso9660: time-stamp mismatch/bug? (Tony Silva)
Re: Why I'm dumping Linux, going back to Windblows (Derek Bem)
Re: disheartened gnome developer (John Hasler)
Re: Will 2.2.x support removable medias better? (Johan Kullstam)
Re: K6-400 "kernel paging request" errors ("David R. Bergstein")
Re: starting a debugger from within the application that you would like to debug
(Bjorn Reese)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: Non-*nix OS built on linux kernel?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Jan 1999 03:18:16 GMT
On Tue, 19 Jan 1999 20:45:30 -0500, Sam Robb <[EMAIL PROTECTED]> posted:
>Just curious about this... are there any 'odd', special purpose, or
>other (non-unixlike) OS's built on top of the Linux kernel, or any
>similar offerings?
>
>I know there are various special-purpose flavors of BSD & Linux
>out there, but I'm more interested in finding out if anyone's ever
>used the services provided by a Linux/BSD/whatever kernel
>specifically to avoid hardware issues.
There are periodically proposals floated on comp.lang.lisp to use
Linux as a "substrate" to support a Lisp Machine.
Unfortunately, someone always then proceeds to start thinking about what
cool things could happen if more and more Lisp got pushed into the kernel,
which thereby requires that they put their efforts into kernel hacking
rather than leaving that to Linus and crew and actually building things
*atop* the LM.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Jan 1999 02:01:31 GMT
On Tue, 19 Jan 1999 15:17:43 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>> Red Hat theoretically could, but since it would have such adverse results,
>> it is reasonable to treat it as if it can't happen.
>
>If Red Hat ever issues a IPO (is that the word for the stock going public?)
>then it may very well happen. After all, a public company has a legal duty
>to do whatever improves the value of stock. Going proprietary may be seen as
>such a thing.
>
>In fact, stockholders could sue Red Hat for *not* going proprietary.
>
>Once again, I say this not because I believe it will happen, just to show that
>things are not so black and white.
It is *guaranteed* that the day that Red Hat pulled such a stunt,
thousands of Linux users would start a boycott of Red Hat Software.
If taking such action would result in substantial bad publicity, and
would result in important people in the Linux community recommending
*against* the use of Red Hat's software, then this would hurt sales.
Stockholders could sue Red Hat for taking these actions that would:
b) Cause bad publicity, and
a) Hurt their sales.
Bad publicity that hurts sales is *not* something that you want shortly
after doing an IPO.
Remember that there *are* reasonable substitutes that may be obtained
with minimal added cost. If Red Hat were to hike prices substantially,
people can buy SuSE or Caldera or Debian CDs. Or Mandrake, for that
matter, which is "latest Red Hat + KDE."
>> And until that much-sought-for "QPL" license arrangement gets finalized, it
>> is *not* true that "Troll Tech can't get any worse."
>
>It *is* true, because for Troll Tech to change their license they need my
>vote, or Matthias Hoelzer's, and they ain't getting them if the new license
>is going to be worse.
>
>Of course you need not believe me, but I know my intentions, and I can make
>a very educated guess on Matthias' so I can say that with a straight face :-)
Fair enough.
--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts
<[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Navindra Umanee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 20 Jan 1999 11:18:19 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Wow, your previous post was full of lies and I'm the one who FUD's.
>
> Lies?? You're the one who posted non-equilivent code examples with what
> apperaed to me the specific intention of discrediting Gtk. That was FUD.
My mistake, which I tried to correct by making the code more
equivalent! In any case, feel free to compare single lines of Qt code
and GTK C code. In any case, feel free to post equivalent snippets of
code.
>> I didn't say GTK was ugly,
>
> You said the code was ugly.
No, I said the *C* code was ugly and I didn't even intend to single
out GTK from the various toolkits. Why do you feel the need of
wrongly rephrasing everything I say? What's the point of that if not to
FUD?
> Then you ommitted the comments from both sources, replacing them
> with your own opinions.
The reason I removed the comments is because it seemed to make the
code even longer and uglier. I gave you the URLs in *both* cases,
Perry.
Does any of this change the look'n'feel of the code? Does C code not
suffer from trying to enforce some kind of OO on top of it?
> David is comming from the perspective of is own experiences writing code. You
> seem to be making sweeping generalizations. What code have you written with
> Qt??
Nothing I'd like to mention to you.
>> Way to go, Perry Pip. If there's anyone FUDing here, it's you.
>> Followups set to .advocacy.
>
> No, your not going to get off that easy. It's pretty obvious from the other
> two posts you sent this morning you have a pretty strong grudge againsts FSF,
> GNU, GPL, Redhat, Gnome etc. etc. And your usenet posting history at dejanews
> verifies it. You're the one who's putting out the FUD.
This is completely false. If you have a strong desire to put words in
my mouth, at least have the decency to waste other people's time only
in .advocacy.
FSF --> No grudge there. Just pointing out your naive assumptions
about one organization over another. This is where you paint
the FSF to be a saintly organization and Troll some form of
potential evil entity.
GNU --> What about GNU? I use it all the time.
GPL --> Not the innocent license some make it out to be and many have
mistakenly used it. But I have no personal grudge.
Red Hat --> I don't even use Red Hat but I advocate Red Hat all the
time. ~a navindra & ~g concordia.general & "red hat" on
dejanews for the most recent time I did this.
Gnome --> Sure, I didn't/don't like the political ickiness, initial
anti-KDE propaganda and all that stuff. But I hold no
grudge and I, in fact, like many of the things I've seen in
GNOME from a non-political point of view.
So Perry, obviously you are not a person who wants to be taken
seriously. Sorry, but I'm quickly losing interest in this subthread
of yours and I'm sure others are too. Screaming FUD and then lying
yourself doesn't get you anywhere interesting.
-N.
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
< http://www.cs.mcgill.ca/~navindra/editors/ >
------------------------------
From: [EMAIL PROTECTED] (Tony Silva)
Subject: Re: iso9660: time-stamp mismatch/bug?
Date: 19 Jan 1999 16:26:05 -0500
Does the Linux VFAT support not honor the timezone database symlink
/etc/localtime and thus require the environment variable TZ instead,
contrary to the strong wishes of the glibc folks? If so, may I be so
bold as to suggest starting a dialog between the glibc folks and the
Linux VFAT folks? The information below shows why I believe that the
problems I'm seeing simply cannot be fixed by reconfiguration that I
can do myself. I'm pretty sure I've read all of the relevant FAQs and
man pages, too.
I did a few experiments using RedHat 5.2 Linux to list a VFAT file
that was created under Win95 at 1:16am US/Eastern time (standard,
not daylight-savings) on Jan. 12, 1999. Just as the glibc FAQ
warns, when I set TZ to EST5EDT (or EST or EST5), VFAT dates are
displayed incorrectly, off by 5 hours (EST's offset from GMT):
silvat@lorber> echo $TZ
EST5EDT
silvat@lorber> ls -l --full /vfat/c/tmp/daylight_savings3/01_16_nextday.win95
-rwxr-xr-x 1 silvat prod 4 Mon Jan 11 20:16:34 1999
/vfat/c/tmp/daylight_savings3/01_16_nextday.win95
silvat@lorber> date
Tue Jan 19 14:06:34 EST 1999
silvat@lorber> echo $TZ
EST
silvat@lorber> ls -l --full /vfat/c/tmp/daylight_savings3/01_16_nextday.win95
-rwxr-xr-x 1 silvat prod 4 Mon Jan 11 20:16:34 1999
/vfat/c/tmp/daylight_savings3/01_16_nextday.win95
silvat@lorber> date
Tue Jan 19 14:07:09 EST 1999
silvat@lorber> echo $TZ
EST5
silvat@lorber> ls -l --full /vfat/c/tmp/daylight_savings3/01_16_nextday.win95
-rwxr-xr-x 1 silvat prod 4 Mon Jan 11 20:16:34 1999
/vfat/c/tmp/daylight_savings3/01_16_nextday.win95
silvat@lorber> date
Tue Jan 19 14:07:37 EST 1999
Curiously, when I set TZ to EDT, VFAT dates are displayed
correctly (but note that the displayed system time, which should
be 2:07pm, is now wrong):
silvat@lorber> echo $TZ
EDT
silvat@lorber> ls -l --full /vfat/c/tmp/daylight_savings3/01_16_nextday.win95
-rwxr-xr-x 1 silvat prod 4 Tue Jan 12 01:16:34 1999
/vfat/c/tmp/daylight_savings3/01_16_nextday.win95
silvat@lorber> date
Tue Jan 19 19:07:51 EDT 1999
The thing that puzzles and bothers me is that when I try to be a
good citizen and follow the advice of the glibc FAQ
(/usr/doc/glibc-2.0.7/FAQ) by unsetting TZ and relying on
/etc/localtime instead, Win95-created dates are once again
displayed incorrectly by Linux VFAT (again, off by 5 hours),
though thankfully the displayed system time is ok:
silvat@lorber> echo $TZ
TZ: Undefined variable.
silvat@lorber> ls -l --full /vfat/c/tmp/daylight_savings3/01_16_nextday.win95
-rwxr-xr-x 1 silvat prod 4 Mon Jan 11 20:16:34 1999
/vfat/c/tmp/daylight_savings3/01_16_nextday.win95
silvat@lorber> date
Tue Jan 19 14:09:43 EST 1999
During all of the experiments above, my RedHat 5.2 setup had
/etc/localtime pointing to US/Eastern. /usr/bin/tzselect tells me
that my timezone should be set to America/New_York. This is
equivalent to US/Eastern (note the matching inode numbers below),
so I never changed /etc/localtime:
silvat@lorber> ls -li /etc/localtime /usr/share/zoneinfo/localtime
/usr/share/zoneinfo/US/Eastern /usr/share/zoneinfo/America/New_York
2151 lrwxrwxrwx 1 root root 30 Jan 12 00:09 /etc/localtime ->
/usr/share/zoneinfo/US/Eastern
106076 -rw-r--r-- 3 root root 1250 Oct 13 05:30
/usr/share/zoneinfo/America/New_York
106076 -rw-r--r-- 3 root root 1250 Oct 13 05:30
/usr/share/zoneinfo/US/Eastern
67086 lrwxrwxrwx 1 root root 22 May 17 1998
/usr/share/zoneinfo/localtime -> ../../../etc/localtime
So it looks like I will continue not to set TZ and live with VFAT
dates that are off by 5 hours under Linux. Alas.
For the record, my hardware clock uses local time, not GMT, since
my PC boots either Linux or that brain-dead OS known as Windows95:
silvat@lorber> cat /etc/sysconfig/clock
UTC="no"
ARC=false
Here are the relevant excerpts from /usr/doc/glibc-2.0.7/FAQ:
3.3. Where are the DST_* constants found in <sys/time.h> on many
systems?
{UD} These constants come from the old BSD days and are not used
anymore (libc5 does not actually implement the handling although the
constants are defined).
Instead GNU libc contains zone database support and compatibility code
for POSIX TZ environment variable handling.
4.3. When I set the timezone by setting the TZ environment variable
to EST5EDT things go wrong since glibc computes the wrong time
from this information.
{UD} The problem is that people still use the braindamaged POSIX method to
select the timezone using the TZ environment variable with a format EST5EDT
or whatever. People, read the POSIX standard, the implemented behaviour is
correct! What you see is in fact the result of the decisions made while
POSIX.1 was created. We've only implemented the handling of TZ this way to
be POSIX compliant. It is not really meant to be used.
The alternative approach to handle timezones which is implemented is the
correct one to use: use the timezone database. This avoids all the problems
the POSIX method has plus it is much easier to use. Simply run the tzselect
hell script, answer the question and use the name printed in the end by
making a symlink to /usr/share/zoneinfo/NAME (NAME is the returned value
from tzselect) from the file /etc/localtime. That's all. You never again
have to worry.
So, please avoid sending bug reports about time related problems if you use
the POSIX method and you have not verified something is really broken by
reading the POSIX standards.
While we're talking about the the glibc FAQ, I have a couple of
suggestions for it (which I will also forward to its maintainers):
1. Add the sentence "The Zone database is preferred over the TZ
environment variable (see Question 4.3)." to the end of
Question 3.3.
2. Change "People, read the POSIX standard" to "People, if you
insist on using TZ instead of the timezone database (see
below), read the POSIX standard".
3. Include a URL or other reference to the particular POSIX
standard for those who insist on using TZ or must use it,
e.g., current Linux VFAT users (?).
4. Change "making a symlink to /usr/share/zoneinfo/NAME (NAME is
the returned value from tzselect) from the file
/etc/localtime" to "making a symlink /etc/localtime pointing
to /usr/share/zoneinfo/NAME (NAME is the returned value from
tzselect)".
-- Tony
--
Tony Silva tel: (508)766-4121
Bose Corporation FAX: (508)820-9522
The Mountain, M/S 234 Internet: [EMAIL PROTECTED]
Framingham, MA 01701-9168 [EMAIL PROTECTED]
------------------------------
From: Derek Bem <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Wed, 20 Jan 1999 22:54:00 +1000
Emile van Bergen wrote:
...
> Oh. So reading the man page as it is prevented you from learning
> something which you could have learned if it were written in the same
> latin characters, but with color and indexes. I see.
>
> (Or did I just fall for a quite funny ironic remark? ;-)
Oh. So form does not matter, how the material is presented is not
relevant. All those Universities doing research on HOW to teach are
wasting their time -- WHAT to teach, yes, but HOW -- does not matter.
Print 500 pages long manual, 7pts Courier will do just fine, forget the
index and illustrations.
Is it a new or unusual concept to admit that BOTH aspects are important?
DB
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Wed, 20 Jan 1999 02:27:19 GMT
Marius writes:
> First Church of Appliantology
Sacred washing machines?
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
Subject: Re: Will 2.2.x support removable medias better?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 19 Jan 1999 22:05:59 -0500
[EMAIL PROTECTED] writes:
> With 2.0.x and removable medias you have to care about mount/umount or
> use mtools if the media has a FAT fs.
>
> supermount addresses this issue in older kernels. Now I wonder how 2.2.x will
> care for removable media?
>
> Ideally, I would want to be able to flip in a media (Floppy, CD, ZIP,
> whatever) and use it right away without mount or umount. It should be allowed
> to remove the media whenever the activity light is off.
i use tar. really! that's what tar is for.
tar cvf /dev/fd0 [files ...]
no mounting required. unfortunately microsoft operating system are
utterly incapable, but i can share disks between linuxen and sun
sparcstations as easy as you please.
if i *have* to deal with a dos format floppy i just use mtools. fat
is such a lame filesystem i don't want to clutter my kernel with it.
--
Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: "David R. Bergstein" <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: K6-400 "kernel paging request" errors
Date: Wed, 20 Jan 1999 08:13:13 -0500
If it helps at all, I am also seeing similar paging request errors under
linux 2.0.36 with an AMD K6-200 and 128MB RAM. I will need to change
my syslog.conf to obtain a dump next time it happens (will post).
[EMAIL PROTECTED] wrote:
>
> Suffering from an unstable system.
> K6-400 (stepping 12), Motherboard FIC PA-2013 (VIA MP3),
> 256 MB Ram (PC-100), (the board allows to downclock the RAM to 66 Mhz, what I
> did),
> AGP Matrox G200, 2 SCSI-Controller, EATA-DPT (only Disks)
> and ncr53c825 (DDS-3, CDROM ).
> RedHat 5.2 Kernel 2.0.36 and I tried as well all 2.2.0-preXX. the last
> 2.2.0-pre7ac2.
> The system keeps chrashing.
>
> I am trying to fix the system now since christmas. Getting frustrated....
>
> Any ideas, suggestions??
>
> Thanks in advance
>
> Mario Dix
>
> This is from 2.0.36:
>
> Unable to handle kernel paging request at virtual address e8f7ce98
> current->tss.cr3 = 083ac000, %cr3 = 083ac000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00125af0>]
> EFLAGS: 00010202
> eax: 28f7ce98 ebx: 08c30814 ecx: 00000400 edx: 00000025
> esi: 00000814 edi: 00067831 ebp: 00000400 esp: 0313de68
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process tar (pid: 3707, process nr: 53, stackpage=0313d000)
> Stack: 08c3f398 00067831 00000814 00000002 00000000 00000025 0012702d 00000814
> 00067831 00000400 0313df18 00002484 00000000 0dfddf00 00067831 00000814
> 00000100 08c3f498 036c0814 00000000 08c3f498 08c3f418 036cf918 0313df14
> Call Trace: [<0012702d>] [<001274af>] [<0011d25c>] [<0011d341>] [<0011d6b4>]
> [<00123c70>] [<0010a941
> >]
> Code: 39 38 75 24 66 39 58 04 75 1e 39 68 20 74 22 56 e8 17 f9 ff
> Unable to handle kernel paging request at virtual address e8f7ce98
> current->tss.cr3 = 041b8000, %cr3 = 041b8000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00125af0>]
> EFLAGS: 00010202
> eax: 28f7ce98 ebx: 00080814 ecx: 00000814 edx: 00000025
> esi: 00000814 edi: 00086831 ebp: 00000400 esp: 0313dddc
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process tar (pid: 3708, process nr: 53, stackpage=0313d000)
> Stack: 00086831 03130814 00000400 00086831 08975818 00000025 00126352 00000814
> 00086831 00000400 00086831 0313def4 001d25a0 00086831 00000001 00154cec
> 00000814 00086831 00000400 00000000 00086831 00000001 0df16b00 00000400
> Call Trace: [<00126352>] [<00154cec>] [<0015534c>] [<001555d5>] [<00153905>]
> [<00156845>] [<0012c414
> >]
> [<0011d7f2>] [<00123deb>] [<0010a941>]
> Code: 39 38 75 24 66 39 58 04 75 1e 39 68 20 74 22 56 e8 17 f9 ff
> general protection: 0000
> CPU: 0
> EIP: 0010:[<00125af0>]
> EFLAGS: 00013286
> eax: 88f0e018 ebx: 0dbf0811 ecx: 00000400 edx: 0000008c
> esi: 00000811 edi: 002f889d ebp: 00000400 esp: 0ee6be8c
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process X (pid: 384, process nr: 4, stackpage=0ee6b000)
> Stack: 0dbff898 002f889d 00000811 00000001 00000000 0000008c 0012702d 00000811
> 002f889d 00000400 0ee6bf3c 00000004 00000000 0dfdc800 002f889d 00000811
> 00000100 0dbff918 00000811 00000000 0dbff918 0015638b 0df10400 0ee6bf38
> Call Trace: [<0012702d>] [<0015638b>] [<001274af>] [<0011d83e>] [<0011d91d>]
> [<00123c70>] [<0010a941
> >]
> Code: 39 38 75 24 66 39 58 04 75 1e 39 68 20 74 22 56 e8 17 f9 ff
> general protection: 0000
> CPU: 0
> EIP: 0010:[<00125af0>]
> EFLAGS: 00010286
> eax: 88f0e018 ebx: 06850811 ecx: 00000400 edx: 0000008c
> esi: 00000811 edi: 0000689d ebp: 00000400 esp: 04c02e60
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process m4 (pid: 3762, process nr: 47, stackpage=04c02000)
> Stack: 06851b18 0000689d 00000811 00000001 00000000 0000008c 0012702d 00000811
> 0000689d 00000400 04c02f10 00000044 00000000 0e321c00 0000689d 00000811
> 00000100 06851898 06850811 00000000 06851898 00154ee1 06851518 04c02f0c
> Call Trace: [<0012702d>] [<00154ee1>] [<001274af>] [<0011db3f>] [<0011dc39>]
> [<0011b1f7>] [<0011b0f4
> >]
> [<00111b48>] [<00111a2c>] [<0011414e>] [<0010aaa4>]
> Code: 39 38 75 24 66 39 58 04 75 1e 39 68 20 74 22 56 e8 17 f9 ff
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
David R. Bergstein
Systems Engineer and Blues Musician
Rockville, MD
===========================================================================
[EMAIL PROTECTED] [EMAIL PROTECTED]
SE & Blues Musician Home Page Heart of Blue - Playin' the Blues for
You!
http://www.erols.com/dbergst http://heartofblue.com
===========================================================================
------------------------------
From: [EMAIL PROTECTED] (Bjorn Reese)
Subject: Re: starting a debugger from within the application that you would like to
debug
Date: 20 Jan 1999 12:57:47 GMT
Chris Clark ([EMAIL PROTECTED]) wrote:
> What I did was write a function called "dump_self_stack" which did
> something like this:
Two examples which does this can be found at
http://www.imada.ou.dk/~breese/debug/stacktrace.c
http://www.imada.ou.dk/~breese/debug/attach.c
The former generates a stacktrace, and the latter attaches a
debugger which you can use interactively (it's a bit of a dirty
hack though.)
------------------------------
** 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
******************************
