Linux-Development-Sys Digest #840, Volume #6 Thu, 17 Jun 99 08:14:16 EDT
Contents:
Re: install glibc-2.1.1 in slackware (Andreas Jaeger)
Informix SE for Linux for free ("Pascal Ferrari")
' LF -> CR/LF ' to be added to printtool (Aaron)
Can Linux Boot and Run without a BIOS? ([EMAIL PROTECTED])
Re: ftape4.02 with new kernel 2.2.5-15 (almost) (Huib Wouters)
Re: TAO: the ultimate OS (Alexander Viro)
Re: core dump problem? (Alex Rhomberg)
Re: Informix SE for Linux for free (Malcolm Beattie)
Re: TAOs: Much to do about nothing? (Paolo Torelli)
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: core dump problem? ("Thomas Steffen")
Re: TAO: the ultimate OS (Konstantin Koll)
----------------------------------------------------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: install glibc-2.1.1 in slackware
Date: 17 Jun 1999 07:43:12 +0200
>>>>> y chen writes:
> Hi, there,
> I finally compile gcc-2.1.1 in my linux box.
> I dare not make install because some problems:
> (1) "make check" report erfl and ieee754 are not
> implemented when checking math lib.
That's ok.
> (2). ./configure fail to guess my host type, I do not
> know why.
I'd advise to investigate this. Check config.log what's broken.
> My linux originally is slackware 3.6 ( kernel
> 2.0.36) but I upgrade it to kernel-2.2.9.
> and glibc-2.0.8 , latest egcs. There are quite
> a lot old libc hanging aroud in /usr/lib.
> Is this going to cause problem?
If they're installed properly[1] - no.
> Any advices?
Andreas
Footnotes:
[1] See the glibc2 HowTo or the glibc2 FAQ/INSTALL documents.
P.S. Followup-To cold.system
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: "Pascal Ferrari" <[EMAIL PROTECTED]>
Subject: Informix SE for Linux for free
Date: 17 Jun 1999 06:57:58 GMT
How could I get the free Informix SE for Linux package (for non commercial
use) that Informix software allowed to download from its Web site a few
monthes ago?
Thank you for your help.
Pascal Ferrari
------------------------------
From: Aaron <[EMAIL PROTECTED]>
Subject: ' LF -> CR/LF ' to be added to printtool
Date: Wed, 16 Jun 1999 08:19:44 -0800
what file and where would i add the line " LF -> CR/LF" for
printing.
i printed a test page and it reads as follows.
" If this is all you see, try enabling ' LF ->CR/LF'
translation in printtool.... ".
I am trying to print to a HP LaserJet 5Si/SiMX printer on a
network.
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
------------------------------
From: [EMAIL PROTECTED]
Subject: Can Linux Boot and Run without a BIOS?
Date: Tue, 15 Jun 1999 11:10:15 GMT
Can Linux boot from chaos and run, without a BIOS?
regards
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Huib Wouters <[EMAIL PROTECTED]>
Subject: Re: ftape4.02 with new kernel 2.2.5-15 (almost)
Date: Thu, 17 Jun 1999 09:38:59 +0200
This is a multi-part message in MIME format.
==============51A725AF2E85B10F095BB848
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
bill davidsen wrote:
>
> In article <[EMAIL PROTECTED]>,
> Huib Wouters <[EMAIL PROTECTED]> wrote:
>
> | This file contains the lines:
> |
> | /lib/modules/2.2.5-15/misc/ftape.o:
> | /lib/modules/2.2.5-15/misc/zftape.o: /lib/modules/2.2.5-15/misc/ftape.o
> |
> | So zftape.o depends on ftape.o.
> |
> | Now I try to load these two modules:
> |
> | /sbin/insmod ftape.o
> | /sbin/insmod zftape.o
> |
> | Loading the first module works fine. But loading the second it complains
> | about "unresolvved symbols". However, these symbolds ARE resolved since
> | these are present in ftape.o.
> |
> | Anyone can help? What am I doing wrong when loading the modules?
>
> Using insmod. Try 'modprobe zftape' and see if all your problems go
> away. Since there's a tool for loading dependent modules use it.
>
> Note: if you still get missing symbols, they are really missing, or you
> have the dependancies wrong.
>
> --
> bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
> The Internet is not the fountain of youth, but some days it feels like
> the fountain of immaturity.
I tried using modprobe but I still get the missing symbols. I checked
the source of ftape.o and the symbols presumably missing are really
there.
==============51A725AF2E85B10F095BB848
Content-Type: text/x-vcard; charset=us-ascii;
name="huib.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Huib Wouters
Content-Disposition: attachment;
filename="huib.vcf"
begin:vcard
n:Wouters;Huib
x-mozilla-html:FALSE
org:-
version:2.1
email;internet:[EMAIL PROTECTED]
title:-
adr;quoted-printable:;;Beukelsdijk 103B=0D=0A3021 AE;Rotterdam;;;the Netherlands
x-mozilla-cpt:;0
tel;home:+31-10-4763778
tel;work:+31-251-498593
fn:Huib Wouters
end:vcard
==============51A725AF2E85B10F095BB848==
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 17 Jun 1999 04:36:37 -0400
In article <7ka1h4$16t$[EMAIL PROTECTED]>,
Graffiti <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>[snip]
>>when I envision an object system, I am really imagining, partly,
>>a new kind of file system that has more attributes associated with
>>each file than the existing small set, such as time stamps etc.
>>or at least this is one way to imagine what I am talking about
>>for ppl who are stuck attempting to understand
>>the essay in terms of existing systems.
>
>Umm..... so you're gonna implement the prcess scheduler with files?
>And memory management? And fiddle w/ the PCI bus, move data from
>a SCSI controller to the nic, etc all with a filesystem?
Erm, wait. Memory management is one of the things that *can* be done
via filesystem. In a totally different sense than one implied by our
clue-challenged friend, but it *can* be done. MULTICS did that.
>>the objects I envision are essentially files with additional
>>structured information & intelligence.
>>for example the file can have embedded links to
>>other files. so a source file could have a link within it,
>>i.e. a reference, to the object file.
And if you want to compile it with different flags, then you are
doing what? Ditto for situation when the object file is supposed to live
on tmpfs and the source - on something read-only (at least persistent).
There is one nasty problem with such schemes: you are losing
general-purpose tools. You are adding a lot of (arbitrary) constraints
on the state and it makes the system *very* rigid. Check the history of
grammar-oriented editors for programming languages. Yes, one cannot produce
a syntactically incorrect program with them. But once you've used a
general-purpose editor you've lost (actually they usually store the file
as a production tree, so you can't use normal editors at all). They are
*very* inconvenient - they operate on restricted domain (e.g. "all
syntactically correct C programs" instead of "all sequences of characters")
and all operations you can perform should map that domain into itself.
And they tend to be extremely unnatural. Once you had exported the thing
into the wider domain you can use more natural operations, but importing
it back into the original domain is terribly hard (and not always doable
at all).
You end up with a bunch of special tools for each task where the
normal system gets out with the small set of general-purpose tools that can
be combined together. Any additional structure is a burden. In each case
it is a tradeoff and the choice depends on situation in question.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Date: Thu, 17 Jun 1999 11:33:52 +0200
From: Alex Rhomberg <[EMAIL PROTECTED]>
Subject: Re: core dump problem?
Josef M�llers wrote:
>
> Kong Tae Young wrote:
> >
> > I have just upgraded to RedHat 6.0(kernel 2.2.9 ), and my program ,
> > which
> > generates segmentation fault error intentionally, doesn't generate
> > core dump file
> > when segmentation fault error happens.
> >
> > I want to generate core dump file when a process goes wrong.
> > Especially core dump file's good tool for debugging.
check with ulimit -a (in bash)
make sure that the current directory is writeable and there is space on
the disk
> If you definitely need to core dump, you might consider using abort(),
> however the manual doesn't specify that it dumps core, or write a value
> to virtual address 0, whcih, again, is implementation dependent.
To dump core, my programs send themselves nice signals:
kill(getpid(), SIGSEGV) or
kill(getpid(), SIGFPE)
There are some more that should generate core dumps
HTH
Alex
------------------------------
From: [EMAIL PROTECTED] (Malcolm Beattie)
Subject: Re: Informix SE for Linux for free
Date: 17 Jun 1999 09:40:06 GMT
In article <01beb88e$6f67e820$b210fac1@gateway>,
Pascal Ferrari <[EMAIL PROTECTED]> wrote:
>How could I get the free Informix SE for Linux package (for non commercial
>use) that Informix software allowed to download from its Web site a few
>monthes ago?
See
http://www.informix.com/linux/
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Oxford University Computing Services
"I permitted that as a demonstration of futility" --Grey Roger
------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAOs: Much to do about nothing?
Date: Thu, 17 Jun 1999 11:40:45 +0200
Reply-To: [EMAIL PROTECTED]
The Ghost In The Machine wrote:
>
> On 16 Jun 1999 10:56:15 GMT, Donal K. Fellows <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> >The Ghost In The Machine <[EMAIL PROTECTED]> wrote:
> >> Brian McGroarty <[EMAIL PROTECTED]> wrote:
> >>> /me stands the bed on end...
> >>> Nor are rooms. ;)
> >>
> >> Yeah, but unless the bed has straps on it (or one is in a space
> >> station with zero gravity), how is one going to get *into* the bed
> >> and *sleep* in it?
> >
> >Nobody said anything about *using* the bed! You're changing the
> >specification at runtime...
>
> *LOL*
>
> [.sigsnip]
>
> ----
> [EMAIL PROTECTED] -- are you sure you didn't mean "sleeptime"? :-)
Guys? I was trying to be serious... and all the comments I get are about
a trivial example which has almost no relevance to the discussion.
If my posts are that dumb, I'd rather like someone to say "they're
dumb", and please include a reason.
(and uhm, a bed as a filler for a room sounds neat ;)
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
To those who can see the truth to those who can still have
feelings
to those who still have the courage to live in this evil world.
.no.regrets.
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 17 Jun 1999 09:02:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
>
> well, I find it quite amazing that so many ppl are focusing on
> my defn of "object oriented" as a key deficiency of the post.
It is - and furthermore, this elaboration of yours proves
that we were right: your idea of objects isn't compatible
with the "object" in "object oriented".
> ok, ok!! uncle!! it all seems so obvious to me, but
> let me elaborate on this somewhat.
>
> when I envision an object system, I am really imagining, partly,
> a new kind of file system that has more attributes associated with
> each file than the existing small set, such as time stamps etc.
> or at least this is one way to imagine what I am talking about
> for ppl who are stuck attempting to understand
> the essay in terms of existing systems.
More attributes *alone* doesn't cut it. And no, I'm emphatically
*not* trying to map your concepts on existing systems.
Because the essential part of OO (as I understand it) is to
unite data and methods, the true OO environment needs to support
these "objects".
A UNIX-like OS knows of only three types of files,
directories, special (device) files, and normal files,
structureless amounts of bytes. An executable is just a normal
file with the execute bit set. It's the responsibility of the
programs to structure the data, not that of the OS. This is in
stark contrast to older OSes, who *do* carry a lot more attributes
per file, and can distinguish between index-sequential, random-
access, and sequential-access file (to name but a few possible
file structures).
So pulling knowledge of file structures (be it indexes or links)
into the OS is not a step forward, but a return to good, old,
mainframe concepts.
> now it is a trivial observation that every OS is composed entirely
> of source files.
This sentence proves that it is *you* who is stuck in traditional
concepts - a truly OOOS would not be composed of files. It would
be composed of objects...
> the objects I envision are essentially files with additional
> structured information & intelligence.
> for example the file can have embedded links to
> other files. so a source file could have a link within it,
> i.e. a reference, to the object file.
Now if you'd said that the object would have a reference to the
source, you'd have made sense. And yes, most compilers *do* place
a link to the source file in the object (just fire up gdb and
you'll see what I'm talking about ;-).
> essentially the idea is that the OS understands all the links
> between different files. so when I pull off an application off
> the computer, the OS understand what files are associated
> with it because of all the built-in-references. the OS keeps
> these current and handles the other administrivia associated
> with it all.
But this is a lousy way to structure a system. You place too
much inside the OS, if, and only if, you're talking about the
kernel when you say "OS". If the OS is the combination of a kernel
and programs (utilities, compilers etc), then what you describe
already exists. As a general rule, only put in the kernel what
really cannot be done in user space. And BTW, you *do* realize
that a shared library is a common service, loaded only once,
and available to all programs that use it, but running in user
space. The file structuring services you talk about should be
implemented as shared libraries, not as kernel modules (to use
a Linuxism).
If you want this "structuring" inside the kernel, you essentially
"close" the system to new ideas and understandings, because for
each new "link", you'd need to change the OS. The power of the
UNIX approach is that you can do anything you want, as long as
you can do it with a bucket of bytes...
> when I say "object" perhaps the way to understand it is
> "superfile". anything that is now a file can be turned into
> a Tao object. the dif is that the Tao system understands all
> the different file formats as part of the OS, and how to
> convert them between each other, etc. of course Tao objects
> are far more than merely files, but to eventually get to
> this point B, I'll start at this point A.
This is not good enough - you'll need to clarify how they
are "far more" than files. You've indicated that they are
files with additional attributes (which?) and "links".
Neither of these make your files objects, or even just OO.
> hence concepts like "make" and "compilation" are built into
> the OS.. a dependency tree support is built into the OS and
> for more operations than merely compilation. for example,
> creating a graph from spreadsheet data is a kind of
> abstract compilation (quite similar to the way that object
> code is created from source code) that the system can understand.
Jeepers creepers - the OS becomes the application. Vladimir,
in Linux, "make" and "cc" *are* "built into the OS", they're
just not "part of the kernel". And you know what, this is
exactly as it should be.
> hence, Tao can be completely "object oriented" because all
> existing OSes are built out of files. QED <g>
Go read Andrew Tanenbaum's "Structured Computer Organization"
before you embarass yourself.
Please, pretty please.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Subject: Re: core dump problem?
Date: 17 Jun 1999 13:22:06 +0200
>>>>> "Kong" == Kong Tae Young <[EMAIL PROTECTED]> writes:
Kong> I have just upgraded to RedHat 6.0(kernel 2.2.9 ), and my
Kong> program ,
Kong> which generates segmentation fault error intentionally,
Kong> doesn't generate core dump file when segmentation fault
Kong> error happens.
you should consider
assert(0);
imho it is the most portable way of coredump or getting you into the
debugger. you can extend it to assert(!"some fault description"). be
warned though that asserts have no effects in production versions (if
NDEBUG is defined). so depending on what you want to do abort() might
be the better choice.
this is OT, but i know no better newgroup for it... maybe comp.lang.c
--
linux, linuctis - f, das beste Betriebssystem ;-)
------------------------------
From: Konstantin Koll <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 17 Jun 1999 13:07:02 +0200
Reply-To: [EMAIL PROTECTED]
> Eh? No directories, no CLI... And authors obviously consider that as good
> features. Oh, well... What's much worse - no compilers, no description of API
> (and AFAICS no source that could be used to figure out said API). So
> development of any software for it is possible only if somebody will bother
> to *disassemble* the thing and look how it works. Wonderful. Do you really
> intend to keep it *that* closed? IIRC the last who tried that was Apple back
> in early 80s... Or you had simply preserved DOS API? Then you would have to
> run everything in VM86... Could you elaborate on that? You know, VM86 and PM
> really differ - different instruction sets, segmented vs. flat memory... So
> that piece of information is rather critical.
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
1. Yes, DESKWORK does not have any directories. We found out that this is one
point most "newbies" don't understand. They save a file, and don't find it
the next day because it got lost in some obscure directory. So - your data
is saved in a flat file structure, allowing retrieval sorted by file type,
or other criteria like date of creating, its name... You may find this a
bit strange, but ask someone not familiar with computers about this.
2. The whole code of DESKWORK is linked together in an EXE-file of ~750 KB.
Uses cannot add or modify ANY code at this point. You're right about this:
there are now compilers, linkers, programming languages at this point. This
is because we've just finished all the other stuff like file system, drivers
and some software. Over time, we'll continue to add software like a web
browser, TCP/IP and so on (hey, we're just 4 guys... and don't work 10 hrs a
day on DESKWORK !)
However, I don't know whether it would be wise to add languages: user
programs
could violate the integrity of the system (viruses) or may not be compliant
with
the "look and feel" of the original system... Yes, yes, I know what you
think,
an OS should handle this. This paragraph is meant just as a collection of
thoughts about it. The question of adding third-party apps and adding a
compiler
has not been decided yet. Along with this goes the API, of course.
By the way, apps are not external user programs in the traditional sence (at
least, not all apps). Games and other parts of DESKWORK are loaded, executed
and
terminated - like DOS, Windows, whatever.
Many "apps", however, care about data (images, texts...). They implement an
interface with methods like "load", "show", "delete"... They need to be
registered
by the OS itself, so data files of that specific type find the right code to
"get
handled". These are all issues that need to be considered when adding a
"programming
language".
3. DESKWORK implements its own DPMI-host. DESKWORK runs in TRUE protected mode,
but
does not employ any "flat memory". To this point, 64 KB segement limits has
not
been a big problem. Also, cutting large areas of memory into 64 KB chunks
reduces
the external memory fragmentation. DESKWORK does not use any paging, so an
address
a program gets stays that address.
Of course, these details get VERY interesting when one would be able to
program
DESKWORK apps.
4. DESKWORK is not quite intended as a replacement for Windows, but to supply
certain
users fast and reliable apps they need (e.g. scientific simulations for
schools
that only have some 386 computers). They don't really care about programming
DW,
but they want an OS that offers "ease to use" and high performance.
Best regards,
Konstantin Koll
------------------------------
** 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
******************************
