Linux-Misc Digest #434, Volume #20 Mon, 31 May 99 15:13:14 EDT
Contents:
Re: first/second/third world (The Ghost In The Machine)
Re: Printing from SuSE 6.1 ([EMAIL PROTECTED])
Leafnode Problem: SEGMENTATION FAULT (Alan Fried)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.linux.advocacy,gnu.misc.discuss
Subject: Re: first/second/third world
Date: Mon, 31 May 1999 15:07:21 GMT
On 31 May 1999 09:54:19 GMT, Richard Kulisz <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>The Ghost In The Machine <[EMAIL PROTECTED]> wrote:
>>- what are the objectives that should go into the design of a modern
>> computing system (which includes the operating system(s), but which also
>> includes such things as applications which many people are going to
>> be interested in, such as spreadsheets, games/game support, and
>> word processing/typesetting)?
>
>I was going to get into it but I didn't know how much ranting you
>would tolerate. :-)
>
> NO SYNTAX!
>
>You want uniform name spaces. Every possible interface of your OS
>has to look exactly the same as every other interface. You should
>be able to create a process the same way you create a file, the
>same way you create a network connection, the same way you create
>a window; it all depends on which object you're talking to.
An interesting way of looking at it; I agree. That would be
very OO, IMO.
>
>In order to achieve this, you must carefully design your uber-
>interface so that every imaginable and unimaginable device on the
>planet can be modeled using it. Naturally, your interface must be
>supremely obvious (in retrospect) so you'll never get any credit
>for the years of effort that went into it unless you're a shame-
>less self-promoter.
>
> Microkernels are obsolete
>
>Instead of providing a minimal set of abstractions which other people
>can use to create even more abstractions, provide a /complete/ set of
>abstractions (the uber-interface) and make sure they can be adapted
>to any situation.
Hmm...isn't that what NT does, now? :-)
>
> Structure is Good
>
>The namespaces should have structure. Like a filesystem, not like the
>space of IP addresses.
The space of IP addresses has some structure; take a look at the
relevant RFC (the exact number escapes me at the moment);
class A networks are 24-bit, class B are 16-bit, class C are 8-bit,
if memory serves. Of course, it gets messy as the class A gets
subdivided into 256 class B's, and then the class B's get similarly
subdivided into class C's, and most people don't read RFC's anyway... :-)
>
> Private doesn't mean Disconnected
>
>Files in a directory are local to it, but they're not disconnected from
>every other directory of the world. Avoid Plan 9's idea of disconnected
>name spaces at all cost. In fact, the more connected the better.
I'm not quite I understand this. Are you referring to:
(a) soft links -- links specified by a pathname?
(b) hard links -- links specified by an internal inode number (i.e.,
two pathnames map to the same object)?
(c) something totally other?
>
> Allow multiple parents
>
>Countless ugly kludges (eg, symbolic links, union directories) have been
>invented to make up for the lack of multiple containment. Don't bother;
>do it the Right Way.
Not a bad idea...but to do that, you'll need to restructure the relation.
The old relation was something like:
[1] File (name, inode, dirinode)
[2] Directory (name, dirinode, dirinode)
[3] Symbolic link (name, path)
in other words, files and directories are owned by directories. But...
if we do it this way, it works better:
[1] File (inode, etc.)
[2] Naming (inode, name, inode)
[3] Root (inode) [this one can be implied; for example, the traditional
value of the root inode in many Unices is '2']
Given a pathname, one can work to the data wanted by working
through the Naming() relation, starting at Root().
It turns out Linux already does this, more or less; the namespace and
the inode space are independent of each other. Of course, every
object must have at least one name, unless it's temporary.
(I hope you understand my babbling; one way of organizing data is
through use of a relational database -- not necessarily using SQL --
and to use relations filled with attributes.)
>
> Who owns a File?
>
>Directories own files. Oh wait, /users/ own files. But that must mean
>that users are directories. Bingo you have capabilities!
Interesting idea, that. But what happens if one has to move all one's
users to another volume? Does that change the users?
(Would volumes even be an issue?)
>
>>- what are the tradeoffs that go into a modern operating system,
>> and which branches are optimized for? For example, one rather
>> notable tradeoff might be ease of use versus raw performance,
>> or maybe ease of porting versus raw performance. I don't know for
>> sure.
>
>A lot of OSes have optimized for raw performance so don't bother;
>it's like reinventing the wheel.
And a lot of them have not. For example, Windows NT. :-)
>
>A lot of ease of use and ease of porting has to do with elegance and
>modularity. Let the compiler break the modules, or if it doesn't then
>write a translator that does, but do *not* do it by hand.
I can agree with that. Obviously, the less done by hand, the better.
>
>>- same question, except for the whole modern computing system.
>>
>>Some examples of criteria that may be of interest. These objectives are
>>not simultaneously achievable -- the idea is to pick the ones that are
>>most important. (It's also possible that these are better addressed
>>by specific applications, anyway -- the OS in that case shouldn't
>>get in the way, and, in the best case, help by providing hooks to
>>allow an application to do things quickly, safely, and simply.)
>>
>>- ease of use
>> * graphical user interface
>> * commands that make sense, and options that make sense
>> * command line editing
>> * graphical / command line mapping that makes sense
>> * other interfaces, such as a "brain plug-in", an eye position
>> reader, sound recognition, and foot pedals
>
>You seem to be thinking in terms of features.
Perhaps I am. However, these are features that IMO make sense.
A computer system has to do something useful, or it won't be saleable.
Some of the things it needs to do is display information, input information,
store information, and process information.
The processing and storage are internal, except for backups.
The input and output are user-related -- or perhaps other-computer
related as well.
>
>> * disk
>
>> > backup and restore
>
>Persistence is the way to go.
Persistence is fine, but what happens if you lose power?
Admittedly, I would love to see Linux modified to have a snapshot file,
which is read in upon startup if the system crashes. There are some
issues in this (chief of which is how to prevent corruption), but
Win2000 is promoting "Instant Start", and I strongly suspect that
a variant of this method will be used in order to get the computer going.
Note that X has some hooks for this -- but it's pretty clear nobody really
takes much advantage of them. (All X does is store the argument line
of the invoking program -- and the invoking program has to store it
itself.)
>
>You didn't mention;
> run-time kernel upgrades!
I'm not sure it's important. However, it depends on the usage of
the system; if the system is 24/7 hot, then run-time kernel upgrades
(for well-tested kernels, I might add!) would be important; however,
for the usual consumer, a certain amount of downtime would be
acceptable.
>
>>- reliability
>> * internal consistency, so that it doesn't crash
>> * defense against external hack attempts
>> * defense against hardware failures, unexpected hardware behavior,
>> and hardware changes
>
>>- privacy
>> * private data should remain private
>> * multiuser data system that allows for retrieval and modification of
>> only that data for which the user is authorized
>
>You mention security issues a lot, but what about shareability issues?
>Too often, some twit will use security as an excuse for a fascist policy
>the users don't want. It shouldn't even be possible for the syadmin to
>prevent the sharing of data.
It shouldn't be possible for hackers to mess up the system, either.
Impasse, methinks.
I will note that with cryptography, the critical information can be
encrypted. Share the encrypted version all you want; won't do much
good unless you can get at the private key, which IMO should
be stored in a magnetic card nearby, physically disconnected from
the machine, or some similar method that's not always "live".
>
>The system shouldn't just protect users from each other, it should
>allow consenting users to do whatever they want with each other.
It shouldn't protect users from each other at all, then.
Not unreasonable, as long as the system itself is protected.
>
>> * techniques that allow the private data to remain private even if
>> the disk is physically removed from the computer and examined in
>> another computer unit
>
>This is not even possible unless the disk contains only a part of the
>software.
Depends on the organization of the system. In my system, for example,
I have many disks, only one of which is dedicated to the operating system.
The rest are for data.
>
>>>Unix is a very old and obsolete design.
>>
>>How is it obsolete, exactly?
>
>Not persistent, not OO, not uniform, not comprehensible,
Comprehensible? How is it not comprehensible? You may need to
do a little code-grokking, to be sure -- is that what you're complaining
about? -- and I agree some of that code is pretty twisted in there.
>doesn't allow
>multiple logical containment. That last may seem like a small thing but
>only because you get used to the restriction. I've looked for ways that
>multiple containment could help me and there are just so *many* that
>it's pissing me off to no end.
>
>>It certainly is a quirky, but very reliable design; can't find much
>
>The implementation is reliable. The design, not at all so. Lose your
>power, lose your data; what's reliable about that?
Lose your power, lose any data. This is a feature of the computer
system, not the operating system.
The computer system must implement persistence; the operating system can
then take advantage of it. A relatively simple way is to put sufficient
battery power in the computer proper to take care of any outages;
that way, should main power go out, the memory doesn't get scrambled.
(Modern dynamic RAM, however, has some problems with this concept.)
A simpler way is to buy a UPS -- but that just means the power,
from the computer system's standpoint, never goes out.
>
>>fault with that. And it's very object oriented, if you think about it;
>
><hysterical, maniacal laughter>
Well, it is. :-)
Of course, even the best OO system has to be eventaully built on
non-OO microprocessors. Or did they convert machine language to
C++ when I wasn't looking? :-)
(Actually, a machine language could be OO, too. It just has to abstract
part of the data. VAX wasn't too bad at this; an operand could be
immediate, absolute, or indexed; the instruction, which was specified
as a single bytecode, didn't really care.)
>
>>when a program opens a pathname, the program doesn't particularly care
>>whether it's a file, a tape device, a CD-ROM, or a teletype/serial device,
>>at least for the open and read. (It's not a perfect OO, though.)
>
>It's all a matter of perspective; how high your bullshit threshold has
>been set by experience. My first language was Smalltalk (and this choice
>of a first language was deliberate) so my bullshit threshold is very,
>*very* low.
Smalltalk is about as OO as one can get, IMO. I can't say I've worked
with it, but dynamic messaging (and either silent discarding of messages
or the throwing of an exception on receipt of a bad message -- I don't
remember which -- is not a bad idea. It simplifies things later on.)
>
>Also, just opening a file is not very OO. It has to do with the fact
>that if you're walking a filesystem with an fid (the Plan 9 scheme)
>then you can only talk to one class of object; an fid. What you /want/
>to talk to is files, directories and whatever subclasses someone has
>made in their filesystem implementation. But to do that you have to
>junk the concept of fids and thus of opening a file. Instead of giving
>messages to an object that walks the filesystem (very imperative), you
>give a message to an object within the filesystem and tell that object
>to pass the message along to your intended recipient.
You have to *find* the object first. :-)
>
>>So what would be the ideal paradigm?
>
>I'm a big fan of OOP and Smalltalk so my answer is predictable. :-)
Only to someone who fully understands OOP and Smalltalk, perhaps. :-)
I'm a C++ man, myself (and yes, I know, it's not OO -- it's a tool
that might be able to make somewhat OO programs, with a huge amount
of discipline).
>
>> (And I'm not even all that sure
>>that software engineers -- I have been in the field for about 17 years --
>>understand OO design! I certainly can't say that I understand all of
>>its nuances, either, but I will state that C++ STL is a nice step forward.
>
>Hummm, C++ is not OO. Neither is Java.
C++, I'll agree with. Not sure what you mean about Java; I will
merely note that a true hacker can write Fortran in any language. :-)
The only globals in Java's namespace are the classes themselves.
Anything else must refer to an object. Obviously, that's not OO,
only a small part of it -- but it's a start.
>
>>And, as a reminder...the perfect O/S doesn't exist anyway. Look at
>>Windows NT. It's won. Look at Windows 95, 98, and the about-to-be
>
>Actually, it's lost. There is no market for Windows NT. High end
>servers? Unix. Web servers? Linux. Games? Windows 95. What's left?
Erm...good question! Perhaps I should have said Windows 95, instead. :-)
>
>>Linux looks hopeful, and it's getting there. But it is obsolete as
>>it stands -- at least according to you. (I'm not sure at this point.)
>
>Obsolete (Linux) is better than actively harmful (Windows).
But it's still obsolete.
>
>>>The big problem is that in order to make a novel design, you have to be
>>>a complete neophyte about implementation details; so you don't come to
>>>the job with any preconceptions limiting your vision of what's desirable.
>
>>OK. Are you a neophyte? :-) Let us see the objectives for an ideal OS,
>>IMO.
>
>I am a /complete/ neophyte as far as implementation details go. I
>finished all the high-level design before I picked up my first book
>on OSes. I'm learning about implementation now but the project is
>already slowly heading out of the design phase; just a wee problem
>in how to best exploit virtual memory.
Virtual memory? One doesn't exploit it; one doesn't even see it.
This might be considered an OO concept, or it may not, but a
virtual memory address is the only address a program can generate.
That virtual memory address, when it is encountered by the microprocessor,
can point to any of the following:
[1] physical memory
[2] swap space, that needs to be brought into physical memory
[3] zero-page memory (the old Block Storage Space, IIRC, for us
Unix old-timers :-) ).
[4] nothing -- i.e., it's a bad pointer
[5] in some cases, a buffer and/or control register for an I/O card;
x86 mainly uses this for ROM BIOS interface code, stored on the
card. On a processor such as the 680x0, it's all memory-mapped I/O.
(One does have to be suitably privileged.)
Pretty OO, if you ask me -- although far from perfect. :-)
>
>>An ideal OS would be completely transparent to the user and
>>would do away with almost all limitations (e.g., "256 character filename
>>limit") and probably with filenames proper as well, or at least make
>>filenames merely an option; it would be fast, fast, fast in retrieval
>>and update of data (and metadata), and would allow for queries such as
>>"give me the file describing back in ... oh, about March... what my
>>financial status and/or plans were, and then update it". This is of
>>course an extremely vague specification -- and yet the computer
>>should be able to handle it without difficulty!
>
>Sorry to disappoint you but my design doesn't deal with anything of
>the kind. Besides, I don't think AI has to be built into the OS proper.
Well, naturally. It's *your* design. This is *my* set of ideals. :-)
I was expecting them not to match, anyway.
However, I highly doubt that anyone is going to want to stare at
pathnames for the rest of their life; judging from my admittedly
limited experience with the Web and Web development (I know how
to write HTML :-) ), most users would rather search by content anyway.
>
>>It should also be able to update from other computers outside of itself,
>>and transmit selected information based on user-given critera to
>>requesting computers.
>>
>>Definitely blue-sky!
>>
>>I'm not sure if the Hamilton 95 thread which wandered through a newsgroup
>>or two is still available on DejaNews, but it might -- in a very
>>tongue-in-cheek manner -- specify what we are most fed up with in
>>so-called "modern" ("obsolete") operating systems, and indicate what
>>we desire in the next generation or the generation+2 of operating systems.
>>
>>I do have to agree that the state of the art IMO is about as elegant with
>>respect to operating systems (and computer software development in general)
>>as leather belts and steam engines were some 100-150 years ago in
>>durable goods manufacturing. I'm not at all sure on how to improve
>>it yet. C++/STL is a good start, but we've a long way to go.
>>Java might even be better...I don't know yet, but there was one
>>testimonial which suggested that a traditional C++ solution would have
>>taken 4 times as long.
>
>That isn't saying much. :-)
Who knows? We haven't switched over to Java, yet.
>
>> Python? Eiffel? Even good old Prolog?
----
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Printing from SuSE 6.1
Date: 31 May 1999 14:41:24 GMT
> I'm having problems with the stair-stepping text effect when
> printing ascii text files from SuSE 6.1. With RedHat they have
Usually everything is set up correctly after using the printer setup
function in yast. If this didn't work for your printer you can edit
/etc/apsfilterrc
Look for the variable PRINT_RAW_SETUP_PRINTER if it is commented out delete
the 3 character. The string should contain \033&k2G.
This is only true for PCL-Printers (usually HP)!!! And it is only true, if
you are using apsfilter. But I bet both is the case for you...
hope it helps
Philipp
--
Dr. Philipp Pagel
Dept. of Cellular and Molecular Physiology
Yale University
------------------------------
From: [EMAIL PROTECTED] (Alan Fried)
Subject: Leafnode Problem: SEGMENTATION FAULT
Date: Mon, 31 May 1999 15:08:40 GMT
[EMAIL PROTECTED] (Michael Perry) wrote:
>On Sat, 29 May 1999 18:30:22 +0000, Steve <[EMAIL PROTECTED]> wrote:
>>
>>Thanks guys.
>>
>>I'll give it a try.
>>
>>Steve
>Check out leafnode also. Makes almost any newsreader an offline reader. I
>use it on a laptop which I travel with.
>
>Works great here!!
>
Now that we're on this topic. I have been using leafnode on and off, sorry
to say more off than on and used it recently and found that when I typed
fetch -vvv, I get no such command so I can't send out my responses. Does
anyone have any clues why this is happening?
I read the doc file and it appears I did every thing I was supposed to.
Well almost, one problem is that I did not have the fetch file!!!!
So I reinstalled that file from a backup and now I get the error message
segmentation fault
Anyone know what that is about?
Thanx in advance
Alan
------------------------------
** 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
******************************
