Linux-Misc Digest #457, Volume #20 Wed, 2 Jun 99 01:13:13 EDT
Contents:
Re: WordPerfect 8 (J. Otto Tennant)
Re: Operating systems (Richard Kulisz)
Re: NT the best web platform? (Marc Slemko)
Re: X-TrueType Server ("rob")
Re: Normal user can't mount floppy on RedHat 6.0..why???? (John Wilger)
Re: Decent Partition Sizes?? (Otavio Exel)
Trying to install linux (Serial # 0)
----------------------------------------------------------------------------
Subject: Re: WordPerfect 8
From: [EMAIL PROTECTED] (J. Otto Tennant)
Date: Wed, 02 Jun 1999 03:51:31 GMT
/gf/ <[EMAIL PROTECTED]> writes:
>It turns out WordPerfect 8 is not really enjoyable
>as crippled as it is.
>Before I go ahead and buy the full version, does it allow
>to make the pull-down menus bigger? My eyes have problems
>reading the menu entries.
Um, I'm not certain to what you refer.
I think I have a full version, purchased through "Egghead."
The screen fonts seem to be less than wonderful, but they are at least marginally
readable.
Even with my new tri-focals (which do not allow me to read agate type), I don't find a
problem with the "pull-down" menus.
>Thanks!
>--
>gianfranco accardo
>gfa2c ibm.net
> @
--
J.Otto Tennant [EMAIL PROTECTED]
Forsan et haec olim meminisse juvabit.
Charter Member of the Vast Right Wing Conspiracy
------------------------------
From: [EMAIL PROTECTED] (Richard Kulisz)
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.linux.advocacy,gnu.misc.discuss
Subject: Re: Operating systems
Date: 2 Jun 1999 04:03:31 GMT
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 ...
>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.
>>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.
>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.
>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.
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 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.
> [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> ......
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).
>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.
>>(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.
>>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). 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.
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.
>>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. :-)
>>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'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 ...
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.
The way you create a group in my design is you make a directory in
your 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.
>>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.
>>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?
>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. 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.
------------------------------
From: Marc Slemko <[EMAIL PROTECTED]>
Crossposted-To: comp.infosystems.www.servers.unix,comp.os.linux.advocacy
Subject: Re: NT the best web platform?
Date: Thu, 20 May 1999 04:32:45 GMT
In <7hvi1f$b2v$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Benoit
Goudreault-Emond) writes:
>Then again, NT caches files as well, so the OS cache should be about
>equivalent. However, the webserver knows better what to cache (or so one
>would think), so it might reserve away memory that would be used for caching
>some other stuff. IIS does that, AFAIK, but Apache doesn't. Hence my
>comment.
In fact, the OS is really the thing that knows the best about caching and
that is by far best suited to cache things.
For a benchmark with a fixed relatively small set of files, you can often
(but not always) get the best performance by simply caching the contents
in memory in your web server.
In more complex and more real world situations, when you have to
have a balance between various uses of memory, larger data sets, etc.
that is what a good VM system does for you. In addition, it lets you
more easily (in some cases) avoid copys when doing IO if it is from
kernel memory to the network.
Now, you still can use a cache (eg. file descriptor cache), but caching
the data isn't necessarily the thing to do.
------------------------------
From: "rob" <[EMAIL PROTECTED]>
Subject: Re: X-TrueType Server
Date: Tue, 1 Jun 1999 21:54:11 -0600
I don't really understand the body of your post but from the
subject line I suggest doing a web search of xfstt.
rob.
Dmitry Melanchenko wrote in message <[EMAIL PROTECTED]>...
>Help me to set up the Subj.
>All the manuals say about some .../xc directory. Where it?
>
>Dimity
>mailto:[EMAIL PROTECTED]
>
------------------------------
Date: Wed, 02 Jun 1999 00:19:17 -0400
From: John Wilger <[EMAIL PROTECTED]>
Crossposted-To:
linux.redhat.install,linux.redhat.misc,comp.os.linux,comp.os.linux.questions,comp.os.linux.setup,comp.os.linux.x
Subject: Re: Normal user can't mount floppy on RedHat 6.0..why????
This is a multi-part message in MIME format.
==============C1343B61C6A51436DC9F30F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Marlon Deerr wrote:
>
> I just recently installed RedHat 6.0 and when I log in as a regular user
> and attemp to use my floppy drive with the floppy icon on the desktop, I
> get an error message stating that only root can mount the floppy.
>
> How do I get around this problem as I do not wish to log on a root all
> the time just to use my floppy drive. This never happened to me when I
> was using RedHat 5.2.
>
> Thanks!
Use linuxconf. It has an item in there entitled "Access a Local Drive".
This will give you a table of all partitions set up in fstab and will
let you configure different options for them such as "User Mountable".
==============C1343B61C6A51436DC9F30F9
Content-Type: text/x-vcard; charset=us-ascii;
name="jwilger.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Wilger
Content-Disposition: attachment;
filename="jwilger.vcf"
begin:vcard
n:Wilger;John
tel;home:(513) 761-8424
x-mozilla-html:FALSE
url:http://w3.one.net/~jwilger
adr:;;570 Wellesley Ave.;Cincinnati;OH;45224;USA
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;0
fn:John Wilger
end:vcard
==============C1343B61C6A51436DC9F30F9==
------------------------------
From: [EMAIL PROTECTED] (Otavio Exel)
Subject: Re: Decent Partition Sizes??
Date: 2 Jun 1999 02:52:51 GMT
Reply-To: [EMAIL PROTECTED]
> azfar wrote:
> :I will be giving some 3.8GB to Linux and rest to Win32.
> :I need to know what are the decent partition sizes
> :Would someone suggest ones?
Ian Briggs <[EMAIL PROTECTED]> wrote:
>
> It all depends on how you use your system, but FWIW these are the sizes
> I'm currently using on a 3.1GB drive:
> swap 128MB
> / 400MB 9% full
> /usr 1500MB 60% full (with /opt linked to /usr/opt)
> /var 300MB 15% full (with /tmp linked to /var/tmp)
> /home 740MB 19% full
> so I'll probably end up reducing / and /var to 100MB each, and increasing
> /usr to 2GB.
one thing I never quite understood: what's the point in having /var in a
separate partition? /var to me is a mistery! it is highly volatile (thus
prone to get trashed in a power faillure), keeps important things like
/var/spool/mail and /var/state and also unimportant things like
/var/spool/squid and /var/spool/news!
any clues for a not-so-newbie?
--
Otavio Exel /<\oo/>\ [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Serial # 0)
Subject: Trying to install linux
Date: Wed, 02 Jun 1999 04:46:24 GMT
Reply-To: [EMAIL PROTECTED]
Trying to install linux
Hi !
I have been trying many times to install linux on a intel 386 with 4
Mo RAM !
But i never work !
i have tried ;
- kheops
- red hat 5.1 French version
- mandrake 5.3 french version
but the install always stop when it says :
found compressed RAM disk at block 0
Can someone help ?
Please answer at [EMAIL PROTECTED]
------------------------------
** 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
******************************
