Linux-Misc Digest #470, Volume #20 Thu, 3 Jun 99 00:13:13 EDT
Contents:
Re: Dumped Redhat like a stale girlfriend...SuSE is for me (Paul Rowland)
Outlook calendar/scheduler (Graffiti)
MAIN BOARD CMI 8330 SOUND CHIP and Kernel 2.2.8 ("Adriano")
Re: Universal Serial Bus (Robert Lynch)
130 Fonts for WP 8 where? ("Donald E. Stidwell")
Re: Operating systems (The Ghost In The Machine)
Re: Java Development Kit for Linux (JuanValdez)
----------------------------------------------------------------------------
From: Paul Rowland <[EMAIL PROTECTED]>
Subject: Re: Dumped Redhat like a stale girlfriend...SuSE is for me
Date: Wed, 02 Jun 1999 14:34:48 -0400
J.H.M. Dassen (Ray) wrote:
>
> Paul <[EMAIL PROTECTED]> wrote:
> >I appreciate the publicity Redhat has given Linux, but I refuse to pay $70
> >for slick marketing and commercialism.
>
> You can check out places like www.cheapbytes.com and www.lsl.com for cheap
> distribution CDs.
>
> In any case, SuSE is IMO much more commercial than Red Hat. Red Hat's core
> system is free software; cheap CDs of it are available, and Red Hat
> contributes quite directly to free software development. Last time I
> checked, YaST (SuSE's setup utility) wasn't free software, which prevents
> folks like CheapBytes from offing affordable CDs.
>
> Ray (a happy Debian user and developer)
> --
> UNFAIR Term applied to advantages enjoyed by other people which we tried
> to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY,
> UNDERHAND and JUST LUCKY I GUESS.
> - The Hipcrime Vocab by Chad C. Mulligan
I thought we were all usin' Linux!!!!!! Getta Grep!!!
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Subject: Outlook calendar/scheduler
Date: 2 Jun 1999 11:20:51 -0700
Hi all,
Anyone know of a way I can access Outlook calendars and
schedulers under Linux? It's recently been mandated that I use it
@ work.
Currently, I'm looking at wine & vmware, but I'd prefer a
more "native" method if any exists.
(No, I'm not trying to access IMAP mailboxes).
Thanks!
-- DN
------------------------------
From: "Adriano" <[EMAIL PROTECTED]>
Subject: MAIN BOARD CMI 8330 SOUND CHIP and Kernel 2.2.8
Date: Tue, 1 Jun 1999 20:02:11 -0300
I wanna know how can I configure my CMI 8330 Sound Chip ( on board ) under
kernel 2.2.8 ?
Thanks
------------------------------
Date: Wed, 02 Jun 1999 20:02:52 -0700
From: Robert Lynch <[EMAIL PROTECTED]>
Subject: Re: Universal Serial Bus
Mauro Goretti wrote:
>
> I have only a question: can I use my USB mouse with LINUX? And how can I do
> it?
I ran across this looking at USB pages recently:
http://www.gweep.net/~sfoskett/linux/p3010-9.html
(see toward bottom of page.)
HTH. Bob L.
--
Robert Lynch-Berkeley CA [EMAIL PROTECTED]
http://www.best.com/~rmlynch/
------------------------------
From: "Donald E. Stidwell" <[EMAIL PROTECTED]>
Subject: 130 Fonts for WP 8 where?
Date: Wed, 02 Jun 1999 22:04:58 -0400
I have the full version of WP 8 and I can't find the alledged 130 fonts
anywhere. Only about a dozen were installed doing a full install.
Using the Font Installer doesn't find anymore fonts and I've looked on
the CD. I've searched DejaNews and no one seems to know the answer to
this question.
So last shot - where are the 130 fonts?
Thanks,
Don
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.linux.advocacy,gnu.misc.discuss
Subject: Re: Operating systems
Date: Wed, 02 Jun 1999 19:46:03 GMT
On 2 Jun 1999 04:03:31 GMT, Richard Kulisz <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>The Ghost In The Machine <[EMAIL PROTECTED]> wrote:
>>>I'll take c. :-) I've come up with a concept I call 'portals' that is
>>>somewhat like Hurd translators except that portals are bidirectional.
>
>>Hmm...are these "portals" an Abstract Factory, a Bridge,
>>a Chain of Responsibility, an Interpreter, or a Proxy? :-)
>
>Actually, portals are a class. :-)
>
>>(Hmm...a Pattern-designe doperating system. I like it! :-) )
>
>What do you mean by Pattern? If you refer to "design patterns" I
>don't see it ...
_Design Patterns: Elements of Resuable Object-Oriented Software_,
by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Published by Addison-Wesley.
It's a work for the clarification, proper use, and implementation
of various patterns in OO software. I'm not sure it's wonderfully
written, but it does contain some useful info. :-)
(I know Abstract Factories, Chains of Responsibility,
Visitors, and Singleton classes might be useful right off the
top of my head...)
>
>>Actually, doesn't Unix nest file systems anyway? :-)
>>
>>Any directory in Unix -- doesn't matter if it's empty or not --
>>is a potential mountpoint, with the possible exception of
>>good old '/', and even then, '/' is probably mounted upon
>>initial startup somewhere in that kernel.
>
>That's not the same thing. If you mount machine2 to /machine1/mountPoint
>then mount machine3 to /machine1/mountPoint/otherMountPoint, a user that
>also mounts machine2 on his own machine will not see machine3. Whatever
>mounts you make, they only exist on your own machine. In fact, unix mounts
>don't even exist in the filesystem you're mounting onto, they just exist
>in some mount table somewhere.
Linux behaves slightly different from classical Unices in that respect;
any mounts made within a Linux box can be exported. It's a
pecularity to Linux, admittedly.
Good point, though.
>
>>>The nesting of the exec FS inside of itself should make it possible
>>>to have run-time kernel upgrades. Instead of having a loop over all
>>>processes in the table, you iterate over them all and then the last
>>>process in the table is the exec FS itself but with permission to
>>>have an infinite time slice. So it's recursive.
>>
>>As a point of pedantry: one would hope that the recursion is done
>>in such a way as to not eat up stack space; this shouldn't be
>>a big problem.
>
>But that's why you learn about properly tail-recursive languages in your
>language paradigm class.
Yep.
>
>>Multiple parents are only an issue for directories, probably because
>>someone way back when required getcwd() and chdir("..") to return
>>a unique result. Multiple parents for directories would result in problems
>>with that; either one uses a symbolic link methodology and risk
>>losing the current directory when said directory is moved (easily
>>done in Unix today), or the first alternative (or possibly a random
>>alternative) is returned for "..", which could be very interesting.
>
>Losing the current directory is not an issue since file lookup does
>not start at the root but where the process is. You can only lose the
>current directory if it's deleted from underneath you; which should
>never happen if your shell has created a hard link to that directory
>(to use as a handle/fid).
>
>'..' should mean /last directory/ even if that last directory is down.
>So '..' should only have meaning for the shell.
And in some shells it does, in fact. If one does a 'pwd', one gets
the access path from the root that various 'cd' commands use (with
an optimization for '..'; it strips off the tail); '/bin/pwd' takes
the current directory and walks up to the root, then walks back down
looking for matching names/inode pairs. If one of the entries
used in 'cd' is a symbolic link, or if a directory is auto-mounted,
one will get different results. :-)
>
>>If one is willing to live with these issues, then one can have multiple
>>parents of directories.
>
>>>If you allow multiple parents then you have to figure out some other
>>>way to prevent cycles.
>>
>>It is not required to prevent cycles *at all*. As long as the directories
>>have an access path from the root, it's not much of an issue if there
>>are multiple pathnames for a directory.
>
>Multiple pathnames have nothing to do with cycles. The moment you accept
>multiple parents, you have multiple pathnames but you do not automatically
>have cycles.
No, but cycles in themselves are not harmful. It's merely a redundancy
in the information of the system; they generate an infinite number
of pathname representations for a given object, but are otherwise
harmless unless disconnected from the root -- in which case, they're
just garbage to be collected.
>
>If a is the parent of b and b is the parent of a then that's a cycle,
>and you *do* want to prevent that in order to guarantee that processes
>can exhaustively search the entire filesystem without getting into an
>infinite loop. Otherwise the process has to keep track of where it's
>been and it's a big ugly mess.
The algorithm given below does that very easily. It's not a problem.
>
>>The only issue is to prevent non-accessible subgraphs -- graphs
>>that cannot be reached from the root Inode.
>
>This is easy; if a directory has only children then it's deleted.
>It would be better if the condition were the lack of any parents
>but because of the way permissions work with sibling links, you
>might not be allowed to delete a sibling link in the directory you
>want to delete.
>
>>[1] Obtain a unique timestamp T.
>>[2] Set the current item C to be the filesystem root.
>>[3] Timestamp C.
>>[4] For every triplet (C,I,iname) contained by C:
>> [4.1] If (I=D) and ((C!=P) or (iname !=name)), then we've
>> found an alternate access path.
>> Exit the algorithm and allow the operation.
>> [4.2] If I has timestamp T, go to the next item;
>> we've done this one already.
>
>You're not using the fact that parent links are different from
>child links. They both respond to the isChild/isParent messages.
Parent links?
*What* parent links? That's redundant information; the proper way
of doing this is to set up a separate datastructure, and be able
to search for it two ways. The data structure is (P,C,iname);
P and C are internal Inode numbers, and iname is the name of
C inside of P.
The searches are for all triplets matching a given P, and
all triplets matching a given C. One could also add a third search,
for all triplets matching iname -- that would be useful if one
had no idea where a file was, but knew its name.
The first query takes care of all children within a parent;
the second takes care of all parents of a child.
It's a very common method of handling relational database
many-many relationships (in this case, an Inode can have many
Inode children, and Inode children can have many Inode parents;
one might consider it a self-cross).
(However, after further review, I may simply say neither parent
nor child, merely links, which have names. See below.)
>
>> [4.3] If I has subitems, push I on a stack for later perusal.
>>[5] If the stack is empty, then D has no paths other than (P,D,name),
>> and the operation is either disallowed, or the operation
>> goes through anyway and the entire subgraph to which D
>> points may disappear as well.
>>[6] Pop a new C and go back to step 3.
>
>>One could also contemplate a search for all parents of an object that
>>is about to be removed, and notify each of them to search for that object
>>and remove it.
>
>No need. Links are bidirectional.
>If you did an ls in /usr you'd get
>
>bin <creationTime> <readTime> <modifyTime> <mutateTime> notDeleted <size>
>...........
>
>and if you did an ls in /usr/bin you'd get
>
>thisWayUp <creationTime> <readTime> <modifyTime> ......
Ah...that's the problem. You'd get multiple listings, if
one were to do this (assuming ls -P lists all parents).
ls -lP
total ?
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 .
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 parent1
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 parent2
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 parent3
-rw-rw-r-- 1 ewill ewill 384 Jun 2 07:50 DataFile1.dat
-rw-rw-r-- 1 ewill ewill 384 Jun 2 07:50 DataFile2.dat
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 subdir1
drwxrwxr-x ? ewill ewill ? Jun 1 08:00 subdir2
There are some issues here that may be problematical.
First off...the (P,C,iname) is unidirectonal, although it can be
made bidirectional: (P,C,pname,cname), where C.pname is P, and
P.cname is C. In short, *two* entries are created in the InodeNaming
relation whenever an Inode is created, and both have to be named.
Once one does that, the file system ceases to be a tree, and
instead becomes a web -- not a problem, but can throw off some people.
In fact, in a case like that, one might as well dispense with
the notion of children and parents, and instead look at the issue
from a graph-theoretic standpoint, where Inodes dot the data
and Names dot the arcs, and a pathname is merely a series
of traversal specifications -- arcs from the starting point.
The arcs can be bidirectional -- and probably should be, to keep
people from geting lost. The starting points are the root, and
the current node.
A typical ls from /usr/bin might now look like this:
$ ls -l /usr/bin
total ?
drwxrwxr-x ? root wheel ? Jun 1 08:00 usr
-rwxrwxr-x ? root wheel ? Jun 1 08:00 vi
$ ls -l /usr
total ?
drwxrwxr-x ? root wheel ? Jun 1 08:00 X11R6
drwxrwxr-x ? root wheel ? Jun 1 08:00 bin
drwxrwxr-x ? root wheel ? Jun 1 08:00 local
$
and the InodeNaming relation would be left unchanged. As an
implementation detail, all names in a node C would be found by
first matching all (C,x,name) and then all (x,C,name) in
the InodeNaming relation.
There are two observations about this file structure:
(1) A path such as /usr/bin/usr is specifiable, and may interfere with
the desire to have another node named 'usr' in that location.
Not a major problem, but could be slightly confusing.
(The alternative would be to have unidirectional named links,
which would be even more confusing.)
(2) There are no directories as such. All nodes can have data,
and arcs to and from them.
>
>The only way to remove an object from the filesystem is to delete each
>and every parent link to that object. Having a parent link to an object
>means you own that object and an object can have multiple owners; so if
>the other owners want the object around then you don't have a right to
>remove it (unless they set permissions allowing you to do it or you are
>their superuser).
Partially correct; the only way to garbage-collect an object is to
delete each and every cross-link thereto, making the object
inaccessable. A garbage-collection scheme similar to ones used in
various LISPs, which simply requires that each and every
object be accessable from a single point (in our case, the root),
could be used, with the algorithm I detailed above. Timestamping
is essential so that no Inode is traversed twice; an alternative would
require a list, vector, or b-tree of Inodes, or Inode pointers, in
addition to the primary graph structure.
>
>>An optimization, employed by many Unices, is a count within each
>>object of how many parents it has. (Unix, however, screws it up slightly
>>by requiring counts for '.' and '..', which means every directory
>>has a count of 2, plus the number of subdirectories contained.)
>>A quick check of this count can indicate whether this object
>>has no more accessors other than the one being deleted and
>>act appropriately. (Note that a count > 1 doesn't mean one's
>>off the hook; one of the other accessors may be a child of the
>>item being deleted, which leads to a detached subgraph.)
>
>Which means you count only parent links.
Actually, I think I'll dispense with the notion of "parent" and "child"
altogether! :-) Inode nodes would know how many arcs are running
to them, and that's all they'd need. If that count runs to 0,
the Inode can be reused, and any data blocks attached to it would be freed.
(Actually, if the Inode is detached from the root, the whole subgraph
would be freed. Hmm....)
>
>>>(to other links and containers they're bound to). Also, a filesystem is
>>>characterized by its root link, not root directory, so it can be said
>>>that /all/ directories have a parent.
>>
>>It's not clear that all directories need a parent. Of course,
>>directories with no parents will in fact be inaccessable, except for
>>the root which is a special case anyway.
>
>If the root has no parent, then it too is inaccessible. The root is not
>a special case.
The root has to be a special case; someone has to know where it is! :-)
(One can simply have a convention that Inode 2 is the root; this means
of course that an auxiliary data structure can be used to search for
Inodes by internal Inode number.)
>
>>>It isn't an issue as long as you move all the users atomically
>>
>>Actually, that would be a very rare occurrence. More likely,
>>users will be moved one at a time, if they're moved at all.
>
>Impossible since there would be no way to reliably figure out what
>a user's domain is (in fact, if someone used encrypted directories
>then the filenames would be scrambled).
Hm...an interesting point, but this may break bidirectionality.
Is an arc of my graph one of your "portals"? If so, that would
make sense; a Portal (an Arc) would be nameable (though
it's far from clear that the name must be unique on both sides).
Does a Portal have a unique name across both its nodes, or not?
An interesting question, methinks....
>Even if you could, there's
>no way you would want to since you'd have to create portals to replace
>the hard links that you've broken. You *could* do it that way but it
>would be a pain in the ass. If you *had* to do it then you wouldn't
>even bother figuring out where a user is and some users would find
>their domains straddling both volumes.
Volumes are a physical representation; this is a logical.
Users straddle volumes anyway; quotas in particular are volume
specific but can incorporate many users.
>
>A much bigger issue is that a copy of a file is not the same as the
>original file. If the filesystem is a log then you're able to undo
>modifications to files (including deletion). But you can't do that
>with a copy of the file because it doesn't have the same history.
>If you copied the current snapshot of a filesystem to another volume,
>instead of the entire log, the users would be *very* pissed.
And inefficient as all hell, anyway. Thou Shalt Not Copy Data. :-)
>
>>>Why? Sharing and security shouldn't be incompatible; you just have
>>>to think very, VERY hard to find a design that hampers neither.
>>
>>I'm lazy. :-)
>>Do my thinking for me. :-)
>
>You have the makings of a fine system administrator. :-)
A BOFH, maybe. *evil grin* (Or would that be a BDFH? :-) )
Muahahahahaha.... :-)
>
>>>Structure Is Good. It must be possible to group and subgroup
>>>users at will. Further, since users are a resource, the OS must
>>>present an interface to users much the same as to every other
>>>interface in the system. Sharing data with a select user should
>>>be no different than creating a file in the appropriate place.
>>
>>One could contemplate a series of Groups items that, if it were
>>to contain a user, would allow for access of files that are
>>somehow associated with that group (it's not clear to me whether
>>the overhead of putting items actually owned by the group
>>within the Group would in fact be efficient enough -- yet).
>
>It's far simpler to just stick to filesystem semantics. A user is
>a directory and a group is a shared subdirectory. You can even make
>a subclass File called EncryptedFile though I'm going to have to
>think a lot about adding classes at runtime.
You'd have to; how else are you going to install applications?
(Besides, CORBA might be able to do most of the heavy lifting here.)
>
>>>You're wrong, that's completely unreasonable. If I have files
>>>somewhere, it should be possible (and easy!!) to share them with
>>>Alice but not Bob.
>>
>>Then place the files within one of the groups that contains Alice,
>>but not Bob, or place the files within the ACL(rwx) subentry of the User
>>structure, thereby allowing the appropriate access.
>
>What if you want to share the file with Alice, Carrie, Denise, Eric,
>Gerhard, Irene, Julie, Louise, Marc and Veronica but you only want to
>give Irene and Julie read access, and Gerhard can't get an account on
>your system because your sysadmin hates you ...
How does one share a file without read access? What a ridiculous concept,
unless the file is a pure executable. :-)
If Alice, Carrie, Denise, Eric, Gerhard, Irene, Julie, Louise, Marc, and
Veronica are part of one group (call it ExecutableGroup),
and Irene and Julie part of another (call it ReadableGroup), then
it's simple.
Assume that all users are logically stored within /User. (This
is the object sitting at the other end of the Arc named "User"
from the Root.) Assume that all groups are logically stored
within /Group.
Then one would have the graph as follows:
/User/Alice
/User/Alice/HomeDirectory
/User/Alice/Owns
/User/Alice/Access(R)
/User/Alice/Access(W)
/User/Alice/Access(X)
/User/Carrie
etc.
/Group/ReadableGroup/Irene
/Group/ReadableGroup/Julie
/Group/ReadableGroup/Access(R)/SharedFileItem
/Group/ExecutableGroup/Alice
/Group/ExecutableGroup/Carrie
/Group/ExecutableGroup/Denise
etc.
/Group/ExecutableGroup/Access(X)/SharedFileItem
(The names are a detail, admittedly, at this point.)
/World could contain all objects accessable by the world,
such that /World/Access(R) would contain all world-readable objects,
/World/Access(W) all world-writable objects (hopefully a
very small subset), and /World/Access(X) all world-executable
objects.
>
>ACLs are a very poor way to implement security. They don't use the
>normal (filesystem) interface and they don't scale well at all.
True. I prefer a grouping structure similar to that used in
modern Unices; the concept I have is an extension thereto,
which allows all groups to have a representation within the
File system (i.e., everything's visible in a uniform representation).
Assuming I've done it correctly; I'm not sure at this point.
>
>The way you create a group in my design is you make a directory in
>your domain,
What's a "domain"?
>the people who want access to it create parent links to
>a directory you left wide open to the public, then you move all the
>parent links (and actually, you see the child end of the parent-child
>links) of your friends from your 'drop-off' directory to the new
>directory. Bingo, now you have a group and any files in that directory
>are owned by everyone in the group. If you want to give someone access
>to a directory but not be an owner then you only let them make a child
>or sibling link. You can use the same process to merge groups, though
>kicking owners out is difficult (you have to start a new group).
>
>The beauty of this scheme is that it's entirely topological so you can
>visualize it in your head quite easily (assuming you can visualize in
>N dimensions).
>
>>>What I'm referring to is orthogonal persistence. You shouldn't need
>>>to save your work anymore than you need to do garbage collection;
>>>the OS should do it for you.
>>
>>Eh?
>>
>>Interesting notion, no explicit checkpointing.
>
>Actually, you'd still have checkpointing but only as an optimization.
>The system can automatically checkpoint every so often; the beauty of
>it is that the user/programmer doesn't have to.
>
>>I would hope that
>>this is augmented with a multi-level UNDO facility; otherwise it
>>won't be that useful for those of us that wipe out paragraphs and
>>then realize we don't have a backup copy of said paragraphs.
>
>Logs are good for undo.
Yes, that'll more or less work, actually. :-)
>
>>>The interpreter sends the message doesNotUnderstand to any object that
>>>fails to understand a message.
>>
>>Which can of course be overloaded to do anything one wishes.
>>
>>This could get interesting... :-)
>
>Oh, it is! :-)
>
>The usual doesNotUnderstand calls up the debugger. But if you're
>running a standalone system, you don't want some jerk to be able
>to stop it just by sending an incorrect message. So instead, you
>write your own doesNotUnderstand that figures out where the message
>came from and sends back an Error object back to the sucker.
Not unreasonable, actually. I'm not a Smalltalk expert by any means,
though.
>
>>>Java is not OO because you can access instance variables from outside
>>>of an object. There is absolutely no excuse for this.
>>
>>Only if the object decides to do so.
>
>It shouldn't be allowed the choice. I mean, what do you save by
>allowing it? You can bypass, or do away with, the get method. But
>the compiler automatically strips out the get method anyways!
>
>> I'm not sure I'd want to
>>implement public static() for what passes for an enumerated type
>>(actually, merely a set of integers) in a Java class.
>>
>>(I'll admit, it's not great design if you can modify them, though!)
>
>>>The physical layer module just serves out numbered disk blocks or pages.
>>>The Log layer serves out huge segments (around 20 MB).
>>
>>Presumably, the 20 MB is tunable, adjustable, or otherwise modifiable.
>
>Actually no, not unless you recompile. I don't know what size I'll settle
>on but that size will be it. Log segments are completely invisible to users
>and you want to fix the size to make it easy to find data. You also want
>the segments to be fairly sizable so that when a hard drive or CD writer
>writes them, the seeks are amortized (so that your throughput is higher).
>
>>Modern operating systems simply scatter physical pages all over memory;
>>the virtual address space is completely defined by the individual process.
>
>Surely a process doesn't get to select which pages it wants to use, no?
A process can lock virtual pages in memory, but that's about it.
Under certain circumstances, a process could ask for a special resource.
The Amiga, for example, had ChipRAM and FastRAM (ChipRAM was
accessible by the blitter/video/sound stuff, but was slow; FastRAM
was faster, but couldn't be accessed, etc.), the modern PC
could also have VideoRam and StandardRam.
Otherwise, it merely allocates virtual address space chunks (4K per page);
at some point the O/S translates them into physical address space
chunks, swap file chunks, or executable file chunks. And the O/S
puts them whereever it likes. (It doesn't matter for RAM;
but if a virtual block is consigned to swap space, accessing it
will be very slow, comparatively speaking.)
>
>>I'm not sure how scratch memory would be used in this system, either,
>>although it wouldn't be a hard stretch to implement malloc() by
>>extending a temporary file -- such was actually done in the past
>>on Apollo DOMAIN/Aegis systems.
>
>>It's possible for the AI to either stare at pathnames, or at Inodes,
>>depending on the structure of the operating system, and the
>>access methods allowed therein. (Ideally it would merely
>>stare at Data, and make sense thereof.)
>>
>>I can't say I know; there are some issues (e.g., do we strongly-type
>>filenames by extension, by "magic number detection", by an ACL
>>and/or typing entry in the Inode itself, or by some other mechanism?)
>>that may have to be addressed first.
>
>You type them by class and this class means something different from
>filesystem to filesystem.
Oh lovely. Goodbye shareware! Goodbye datasharing! Goodbye
installing software, period!
Goodbye computer viruses!
Say...that might be a *good* thing... :-)
(Or did you have in mind base classes that would be similar within
each system, and extension classes which differ from system to system?)
>To be useful, you should allow the making of
>new classes. But this also means you need a generic instance creation
>mechanism which I haven't spent any time thinking about.
>
>I haven't spent any time implementing classes since Smalltalk does it
>for me.
Does make it a lot easier... :-)
----
[EMAIL PROTECTED], who likes the C++ Standard Template Library
for similar reasons
------------------------------
From: [EMAIL PROTECTED] (JuanValdez)
Subject: Re: Java Development Kit for Linux
Date: Wed, 02 Jun 1999 19:00:03 GMT
Use the one from blackdown.org
On Tue, 1 Jun 1999 23:57:25 -0700, "Ted" <[EMAIL PROTECTED]>
wrote:
>Does anyone know if the Sun's JDK will work on Linux?
>
>-Ted
>
>
------------------------------
** 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.misc) 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-Misc Digest
******************************
