Linux-Development-Sys Digest #843, Volume #6 Fri, 18 Jun 99 01:14:06 EDT
Contents:
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: TAO: the ultimate OS (Graffiti)
Installing Linux ("Sid Ghosh")
Re: Configuration Manager for Linux (Christopher Browne)
Re: TAO: the ultimate OS (Christopher Browne)
Re: TAO: the ultimate OS (Christopher B. Browne)
Linux uid limits! ("Roberto P.Martins Jr.")
Re: TAO: the ultimate OS (void)
Re: the ultimate OS (Christopher B. Browne)
Re: TAO: the ultimate OS (Terry Murphy)
----------------------------------------------------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 17 Jun 1999 23:37:53 GMT
Konstantin Koll ([EMAIL PROTECTED]) wrote:
: Hello,
: I just read your theoretical paper about "Tao". It reads interesting, and is NOT
: theroretical at all: Tao is alive and already working. Friends and me have been
: working on an OS that does exactly what you think "Tao" should do. The name of
: that OS is "DESKWORK" and is ready to be shipped in July 1999.
: Take a look at http://www.deskwork.de/WELCOME.HTML to see screenshots and learn
: more about it.
btw I hit the web page and looked into deskwork.. "nice work dude",
and lots of solid code/interface in place!! I commend/congratulate
you.. your enthusiasm is infectious<g> maybe everyone out here
bludgeoning me about not having code can go hit your web site and download
it<g>
that said, I have absolutely no idea why you think your OS has anything to
do with what I wrote about.. that it is "Tao alive & working, does exactly
what I think Tao should do".. huh?!?!?!?
that said, well anyway, keep the good work<g>
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
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 16:48:51 -0700
In article <7kac2l$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
[snip]
>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.
I didn't mean a /kern/vm ish interface. From what he posted, it looks
like he's saying:
"All comptuers are made from silicon. Therefore, we just let the silicon
have capabilities to clean the windows, wash the sink, and write our thesis
for us."
"How?"
"By adding new functionality to silicon."
It doesn't look like he's saying there will be an interface that's a
filesystem. :-)
(Of course, I could have mis-read it, but from what he's saying, I doubt
it. :-)
-- DN
------------------------------
From: "Sid Ghosh" <[EMAIL PROTECTED]>
Subject: Installing Linux
Date: Thu, 17 Jun 1999 17:02:58 -0700
I have got a question for the Linux wizards out there:
The standard method for installing Linux in Win/Dos environment
is to partition the hard drive, and use one partition for Linux.
Is it possible to use a removable disk ( ex. IOMEGA 100/120 Mb)
exclusively for Linux, to boot from and store and retrieve data/files.
With my limited search I have not found any reference to such
possibility in the published discussions.
Any help will be greatly appreciated.
Sid Ghosh
Design Assistance
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Configuration Manager for Linux
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Jun 1999 01:20:09 GMT
On 11 Jun 1999 15:56:31 -0500, Jonathan Abbey <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>| [...]
>| It would nonetheless be a sly idea to add in some CORBA hooks,
>| perhaps publishing the IDL equivalent to whatever RMI is providing.
>| (I must confess unfamiliarity with RMI.)
>
>Agreed. I chose RMI because I wanted guaranteed ubiquity in the Java
>space so that we could deploy the Ganymede client on different kinds
>of machines (Win32, UNIX, Mac) throughout the lab.
>
>One problem with CORBA is that it only supports passing the CORBA
>primitive types over the wire, whereas Ganymede currently depends on
>serialized object trees for queries and the like in a few places.
>Some interface refactoring would be required to support CORBA, but
>that will probably be effort well spent.
CORBA allows passing around "sequences," which essentially represent
arrays of structures. I'm not sure if that's sufficient or not...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/corba.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Jun 1999 01:20:08 GMT
On 11 Jun 1999 22:07:25 +0100, Bruce Stephens
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
>
>> ok,ok!! but I must ask again-- please focus on one particular aspect
>> of what I am proposing, perhaps which you feel is simultaneously
>> most desirable/infeasible.. and I'll attempt to elaborate!!
>
>How can we? Your essay is a wishlist---there's not enough detail to
>guess what the difficult bits might be.
>
>"Objects" seem to be central, so one idea might be to flesh out what
>an object is supposed to be.
>
>How are objects represented in memory and on disk? How are they
>versioned? How might an object A access specific versions of an...
That starts taking it to the "concrete" perhaps to quickly.
The more critical question is that of what ontology the object system
represents.
If the object system can't represent the things that need to be
represented, then it doesn't matter *one bit* how it is implemented.
Nor does the object model matter (including such things as message
passing, genericity, multiple dispatch, data hiding, static typing..).
More critically, there's little point to implementing *any* object
system if there isn't a clear picture of what the ontology of the base
object set is supposed to be.
--
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." -- Doug Gwyn
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/languages.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Jun 1999 02:53:51 GMT
On Thu, 17 Jun 1999 23:33:27 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> posted:
>Stefaan A Eeckels ([EMAIL PROTECTED]) wrote:
>: 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.
>
>totally disagree. only if it makes the system more cumbersome or
>inefficient. the idea is not to build in file types into
>the OS, but to have the OS understand different file types
>and know how to manipulate them, in a way that is much
>more systematic/streamlined than mere file extensions.
... And if this is all that you were wanting, then implementing a new OS
is utterly unnecessary, as all you need to do is to construct a table of
methods to go along with /etc/magic, and write a "dispatcher" that uses
those methods to invoke the appropriate programs based on the joining
of /etc/magic with (let's say) /etc/magic.methods.
What you're talking about, namely the notion of having something
fundamentally better than extensions, is *ALREADY THERE.* It need only
be *used.*
>: 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".
>
>OK, OK, I see what is going on here after a bit. a lot of ppl are
>assuming
>that I am advocating putting everything in the kernel. but the key
>reason they are concerned about this is the idea that the kernel
>is what runs in memory all the time, and is not unloaded or loaded
>on demand like other apps or utilities. I'm totally in favor of an
>extremely minimal kernel for efficiencies sake. but I think existing
>OS utilties can be much better integrated into the OS rather than
>just sitting outside of it and called up by the user manually
>as needed.
Then you don't still don't get it.
Facilities don't have to be in the kernel in order to be automatically
dispatched.
>: 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.
>
>the best analogy I can consider is windows DLLs. they are part of
>the OS and application programs. they are loaded and unloaded.
>yet there is a very poor system of knowledge/integration about where the
>DLLs are on a system. they are woven together with paths and
>assumptions. incompatibilities with versions etc. programs
>install them wherever they want.
>installation of one program can clobber another's
>DLLs.
... And applying this understanding to Linux would achieve us DLL
chaos?
>a DLL is a "quasi object" in my opinion. the DLL can allocate
>memory and write to that state. an application is a quasi-object..
>it can allocate memory and write to that state.. both have a set
>of operations they perform & and interface, although with an
>app it is usually through the GUI.
>
>DLLs so obviously ought to be managed by the OS or an
>OS like utility similar to a registry system.
And this relates to Linux how?
--
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 free software today?..."
------------------------------
From: "Roberto P.Martins Jr." <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Linux uid limits!
Date: Fri, 18 Jun 1999 00:15:28 -0300
Hi!
I've been wondering how many user accounts a single linux box could
support. And taking a look at /usr/include/pwd.h, the header file with
functions and data structures to handle and create user accounts, I
found that uid is defined as unsigned int. Is it true? If true, I could
have "only" 65535 users! How very big sites, offering web space and
email like Geocities and Xoom, handle million user accounts?
--
Roberto P.Martins Jr.
mailto:[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Lab/9636
ICQ #12393737
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 18 Jun 1999 04:06:24 GMT
On Thu, 17 Jun 1999 23:33:27 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>
>DLLs so obviously ought to be managed by the OS or an
>OS like utility similar to a registry system.
You mean like ldconfig?
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 Jun 1999 02:53:58 GMT
On Thu, 17 Jun 1999 23:46:19 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> posted:
>: If it "hasn't been explored then":
>
>: a) What do you call Cowan's research? Evidently it must not represent
>: an exploration of the concept.
>
>its a research project.. hasn't made its way into a production/popular
>OS. I'd also say it is really only a beginning of exploration
>into the idea from what I can tell.
Ah.
So in your view a definition of "exploration of concepts" would require
as one of its components the notion of "implementation in a popular OS."
>: b) What evidence can you muster to support your contention that the idea
>: is actually of benefit ("will have very powerful benefits")? If it
>: hasn't been explored, then nobody knows if it is of any value or not.
>
>1st you argue with me that it has been explored, and now you argue
>with me that it hasn't been explored.. maybe I'm just paranoid but
>somehow I get the feeling that everyone is out to get me out here<g>
You claimed that the concept hadn't been explored. If it hasn't been
explored, then there can't be any evidence that it could conceivably
be of benefit. Unless your definition of "explored" is sufficiently
vacuous as to be incompatible with common understanding of the term,
as clearly seems to be the case.
>Cowan himself states the tangible reward of the system.. perhaps you
>missed it..<g> he said it does very well on some basic benchmarks.
>that's the point.
You're making vacuous agreeable statements...
>I'm not saying this is the holy grail.. I'm saying its a valuable
>idea that ought to be pursued/integrated more into the OS. do
>existing OSes do it? not really. is this proof it is not useful
>or valuable? not really.
There's no proof yet that the idea is forcibly worthwhile. I
don't think Crispin would disagree *too* strongly with that claim;
it can take more than one experiment to establish that a technique
will be worthwhile in practice.
There may, for instance, be some disadvantage to the technique that has
not yet been uncovered.
A possible such disadvantage would be that it could prove to be extremely
complex to integrate the technique into the OS. We cannot be certain
that this is the case; it can only be determined by examining the
technique in detail in the context of a well-specified system architecture.
With "TAO," this is obviously lacking.
(On the other hand, with Douglas Schmidt's TAO system, the source code
is *quite* available. Not that it bears any relevance here.)
>this reminds me of the way processors never had memory caches
>or multiple instruction pipelines or other incredibly complex
>features just a few years ago. me saying
>a few years ago that both would be very useful features in the
>near future and ought to be pursued would have met with great
>ridicule right? "it's too complicated. what evidence do you have
>it is worthwhile? it takes too many gates" etc...
If you've got a few billion dollars to spend on implementation, then
it's certainly reasonable to examine such techniques. In the absence
of anything more than vacuous claims to the effect that "we should
do this" with a severely underspecified system, I would agree with
the notion that the process is of questionable value.
>more philosophizing to myself: (since nobody seems to be listening<g>)
>the crowd of "flameurs" that is ganging up on me out here is asking
>for the impossible. the ideas I write in the essay, as one poster
>stated, "are at the pinnacle of software engineering". they
>necessarily lack immediate proof & instantiation.
The Apollo project, which took men to the moon, did not use "pinnacle"
technologies; it developed fairly well-understood technologies to build
spacecraft to perform a severely challenging task.
Linux has had success for similar reasons; there are few, if any,
things about Linux that represent "pinnacles" of software engineering.
It uses well-understood technologies to accomplish its ends.
Projects that sit at that "pinnacle" have an *enormous* risk of failure.
They are, indeed, unlikely to succeed, because sitting at that "pinnacle"
means running with a very significant risk that the project is downright
*impossible.*
>they are on the horizon. they are not under our noses. I cannot put what
>is on the horizon under anyone's nose as all the "flameurs" are demanding of
>me, unless they have an exceedingly long nose<g>
Any significant architecture project seeks first to build a prototype or
"model." Nobody is demanding more than is demanded of any other
architectural project of such ambition.
--
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 free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 18 Jun 1999 04:27:51 GMT
In article <7kadij$6gp$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>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.
On the contrary. You are making the grave mistake in considering
that anything "newer" is "a step forward". In reality, Unix has
set the computer industry back thirty years (and counting, of course).
The only reason Unix was so massively commercially successful, was
precisely because it was so minimally functional -- it was so easy to
port because it didn't actually DO anything interesting. In the
workstation boom of the early to mid '80's everyone and their mother
made their own workstation and they ported Unix to it -- it was much
cheaper to pay a few hackers to port an existing system to the machine,
than to pay some professional engineers to design a serious system.
The whole Unix "small is beautiful" philosophy won out for business,
not technical reasons.
In fact, many of the mainframe features that Unix original "rebelled"
against have crept back into the system -- ACL's, for example, or
file locking. Only they are much more kludgy and non-standard and
non-functional than they are on the real systems. Mandatory locking,
for example, is all but non-existent on Unix. Some systems have it,
some don't, and you have to go through kludgy chmod sequences to
turn it on. But then it still only works in special circumstances;
it won't work over NFS for example. Real systems such as VMS and
even Windows NT have no problem with simple concepts such as this.
Then there is the problem of a record based file system. Since Unix
doesn't know about anything but bags of bytes, there is no concept
of records. Users have to resort to kludgy things such as seeks. Not
so useful when you know the key of the record you want. Then there's
record locking. Some Unix's may let you lock portions of files (not
mandatorily of course though), but that seems very roundabout to locking
a record. The basic Unix filesystem is so inefficient for databases that
many database vendors have to implement their own filesystems. Again,
real operating systems, such as VMS, have no problem here.
Adding real file attributes and file types to Unix would be a great
idea. Even though most people these days use their Unix machine like
they do a Windows based pee-cee, file attributes will never become
a force in Unix, because it couldn't fit into POSIX without some serious
kludging. Had POSIX been a real API to begin with, there wouldn't be
a problem.
-- Terry
------------------------------
** 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
******************************
