Linux-Misc Digest #452, Volume #20 Tue, 1 Jun 99 19:13:08 EDT
Contents:
Re: Operating systems (The Ghost In The Machine)
Re: Can't compile kernal, Need help (Michael Gibson)
----------------------------------------------------------------------------
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: Tue, 01 Jun 1999 22:00:32 GMT
On 1 Jun 1999 12:37:05 GMT, Richard Kulisz <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>The Ghost In The Machine <[EMAIL PROTECTED]> wrote:
>>On 31 May 1999 09:54:19 GMT, Richard Kulisz <[EMAIL PROTECTED]> wrote:
>>> 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? :-)
>
>Not that I've heard. I'd be surprised if it wasn't a standard microkernel.
Me too. There's a piece in there -- Kernel32.Exe -- which is probably
the kernel proper; the rest is a bunch of DLLs loaded by -- somebody.
It's hard to tell, without the source.
>
>>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... :-)
>
>That's an old RFC made obsolete by CIDR; Classless Inter-Domain Routing.
>Basically, what makes a class A network class A is that the routing tables
>contain only a single entry for, say, 124.x.x.x. If you add an entry for
>124.101.x.x then you've just punched a hole in the CIDR block and now it's
>a bunch of class B networks with most of them having the same entry.
>
>Also, as far as the users/programmers are concerned, the IP space is flat;
>the structure is completely hidden from users.
That's probably a good thing. :-)
Especially since ipv6 is probably going to change the rules anyway.
>
>>>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:
^ sure
(in case no one's figured it out already -- sigh, I hate it when
I do that :-) )
>>
>>(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?
>
>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.
>Hurd translators only go from a filesystem to a program contained within
>that filesystem, portals go inside and outside. Also, Hurd translators
>are meant only as a kludge to help users while portals are a fundamental
>part of my design.
Hmm...are these "portals" an Abstract Factory, a Bridge,
a Chain of Responsibility, an Interpreter, or a Proxy? :-)
(Hmm...a Pattern-designe doperating system. I like it! :-) )
>
>Portals are more generic so it's possible to have nested filesystems.
>In fact, all filesystems end up nested inside of some other filesystem
>except for the RAM FS and exec FS (essentially a process table) which
>are both nested inside of themselves. One of the processes the exec FS
>is responsible for running is the exec FS itself, and the text of the
>RAM FS is obviously contained in RAM.
>
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.
Something I like to do on occasion -- and I'm probably not alone --
is to set up one system from another:
mount /dev/?? /target
mkdir /target/usr
mkdir /target/var
mount /dev/?? /target/usr
mount /dev/?? /target/var
I'm not sure if this is the "nesting" you're referring to (for
one thing, it doesn't allow for a ZIP file without a scratch
directory), but it's close. :-)
(There is a loop device that can allow for the mounting of files
on a directory using any file type; occasionally, one can examine
or build images of floppies this way, physically copying the
image file after dismounting it. It's an interesting, if hackish,
construct.)
>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.
>And if you want to
>upgrade the exec FS, you just add an entry for the new version at
>some point in the table before the last entry (with permission for
>an infinite time slice of course).
>
>>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.)
>
>This isn't sufficient. The reason multiple parents were eliminated
>in Unix is because it's a dumb but effective way to eliminate cycles.
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.
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.
The only issue is to prevent non-accessible subgraphs -- graphs
that cannot be reached from the root Inode. (The nodes of the
inclusion graph are the files and directories; the arcs are the
inclusion of a file or directory within a directory; this is one
reason why it's so often called a "directory naming tree", as the
graph is required to be a tree from the standpoint of directories only
in current Unix systems, and is usually a tree from the standpoint of
directories+files, since hard links are discouraged).
Cycles are not a problem.
[snip algorithm for checking]
The actual algorithm for checking accessibility is probably going to be
rather involved, I'm afraid, and may require maze traversal techniques.
One particularly simple, though time-intensive, method would be
the following, and would only be an issue when removing the triplet
(P,D,name) from its parent P.
[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.
[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.
The only checks required for entering a (P,D,name) record is to
ensure that P doesn't already have an entry for name. (If it does,
the OS can try to delete the existing entry, which may invoke
the above algorithm if the existing entry has subentries.)
This algorithm can be modified to construct an access path as well
for D; the access path thus found would in fact be the shortest possible,
at least from a graph traversal standpoint.
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.
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.)
>
>Also, it's much easier to think of it in OO terms where a link is an
>object class which implements permission attributes and message passing
>(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.
>
>>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?)
>
>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.
>but
>it took quite a bit of thinking to determine why not. You have to
>find all the portals going /into/ your filesystem; this is not hard
>since they're bidirectional so you can work back from a directory
>that contains all portals going /out/ of the filesystem. Then you
>just recreate them all in the new filesystem. A script could do it
>all; as long as there's a way to dismantle portals (this isn't
>something I planned for so thanks!).
>
>The primary portals (those directly connected) must be completely
>rebuilt. The secondary portals (those connected through another
>portal) only need to be half-rebuilt; the half inside of the new
>filesystem needs to be rebuilt.
>
>>>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. :-)
>
>:-) I'm not even sure what it optimized for.
Saleability! :-)
>
>>>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.
>
>I agree completely. I just think they're settled issues.
>
>>Persistence is fine, but what happens if you lose power?
>
>That's why you need a logging hard disk filesystem, so you can restart
>easily. Also, my design is orthogonally persistent; processes reside
>on the HD (or even CD-ROM) and the RAM just acts like a giant cache.
Except that the RAM is the bit that gets lost...
>
>>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.
>
>What is "Instant Start"?
My cynical side says that it's a marketing buzzword. The idea is to
reduce to near-zero the amount of time required for a system to
initialize, validate, and start its daemons -- if it has any --
and present itself as ready for use.
My other cynical side suggests that one possible implementation
is in fact to have a snapshot file of some sort; this file would
updated on a semi-regular basis, based on certain critical information
in memory (windows, disk files, and processes). The processes
themselves would have to support a form of restart (the PC would
be saved, as would the stack, heap, and registers, for each running
process -- in fact, if they do it right and no other changes occur
in the hardware, all that would have to be done is careful tracking
of the process blocks and a dump of the used pages of physical memory
(and very very careful initialization of swap space, as it
contains the rest of the info).
>
>>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.)
>
>Huh, that's pretty useless.
>
Yep, quite useless. A pity.
>>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.
>
>Practically, it's not an importat feature. But it's one of those
>super neat toys you can brag about; "geez, I haven't shut down my
>system since '83" or something like that. :-)
And it also could be useful for servers.
>
>>>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.
>
>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. :-)
>
>>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".
>
>This is also bad. What you're describing is a flat user-space;
>you establish a crypto key for some files and share it with the
>users who need it one by one. Users are a resource of a system,
>much more valuable than most other resources, and in that space
>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).
A new item created by the user would go into a
DefaultGroup; this DefaultGroup would in fact be an alias
to one of the user's Groups, or perhaps to the User himself.
(It is also possible that this would be a reference to another
user's Group -- a Group to which the current User would not
belong. Such would cause some interesting issues, though.)
>
>>>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.
>
>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.
The checking algorithm would determine if one of the following is true:
(1) The Acl(r) of the user requesting access contains the file.
(2) Each Group entry of the user requesting access is checked to
see if it contains the file.
(Similarly for (w) and (x).)
I don't mind being wrong. :-)
>
>>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.
>
>If all the disks are pulled out of the computer, it is /not/ possible
>to guarantee the data remains private.
Depends on where the key is, I would think. If it's on a floppy,
you'd need the floppy.
Mind you, I'm not sure I'd advocate this; floppies are not 100% reliable.
I would personally suggest a thin translucent rod, with light and
dark markings in such a way as to generate 1/2 of a public/private
key pair (the other half would be registered with the manufacturer
of the rod); that rod would be inserted into a device that would
be part of every computer.
Once the rod's inserted, the private key could be read at will.
As a technical issue, the private key must *never* be copied,
but always read from the key I/O subsystem (which would probably
look like a small block of memory, accessable only to a
trusted part of the system -- the part that decrypts or encrypts
data).
Of course, the public key can be copied every whichaway, and
this system is far from perfect (for example, envision a
private key reader which allows for duplication of the rod).
The key reader may have its own unique private key to forestall this.
And of course the populace is just currently intelligent
enough to write PIN numbers on the back of ATM access cards anyway...
sigh.
>
>>>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.
>
>Exactly. It should be possible to understand how the entire system works
>just by snooping around in it, not coding. An example is the /proc FS;
>it goes some way towards making Linux understandable but not enough.
>
>>Lose your power, lose any data. This is a feature of the computer
>>system, not the operating system.
>
>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. 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.
>
>>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.)
>
>If research into permanent RAM pans out, it won't be a problem anymore.
True.
>
>>Smalltalk is about as OO as one can get, IMO.
>
>Actually, it's possible to get a bit more OO than Smalltalk if you
>turn variables into objects; I heard that SELF does that but I don't
>know anything about it. The problem is that since variables are not
>objects, assignment is not a message thus you can't assign to any
>variables using a perform message. Example:
>
>"5 perform: #+ with: 3" is valid but
>"someVariable perform: #:= with: 4" is not valid
>
>Another thing is that objects can be represented by variables but
>messages cannot. There's a package for Smalltalk that allows you
>to write code that's just a string of variables. :-)
>
>Combining both you could have something like;
>
>Variable new: 'anObject';
> new: 'aMessage'.
>anObject := 5.
>aMessage := '+ 4'.
>anObject aMessage
>
>>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.)
>
>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... :-)
>
>>>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. :-)
>
>You, a process executing on some computer somewhere, are given a
>pseudo-variable, say 'files', which is bound by the interpreter to
>another object in the filesystem. You send messages along the file-
>system by sending
>
>files pass: <aMessage>
> to: '../network/tcp/richards_supercomputer.org/'
> ...
>
>>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.
>
>That's not a requirement for an OO language; Smalltalk has globals
>for system resources (eg, Transcript, Smalltalk).
>
>>Anything else must refer to an object.
>
>Or an integer or an array or ...
No, they'd be objects, too. That was one of the mistakes
(or possibly sacrifices) of Java...not everything is an object,
and semantics differ between objects and primitive types.
It's an ugly blot on an otherwise fairly usable language, IMO.
>
>> Obviously, that's not OO,
>>only a small part of it -- but it's a start.
>
>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. 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!)
>
>>>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.
>
>You do if you're the OS designer. My problem is that the virtual
>memory aspect of virtual address spaces is needed in the RAM-LOG
>module but that the protection domain aspect of those same virtual
>address spaces is needed only two levels higher.
>
> Virtual FS
> |
> Caching
> | |
> RAM-LOG HD-LOG
> | |
>RAM-physical HD-physical
>
>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.
Modern operating systems simply scatter physical pages all over memory;
the virtual address space is completely defined by the individual process.
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.
>The caching module
>finds segments (tries the RAM then the HD then CD-ROM). Finally, the
>virtual layer shows a useable filesystem to users. Processes are going
>to reside in the virtual layer almost exclusively, yet I need virtual
>memory at the log layer. And I'm not going to collapse all the layers
>by hand (even, possibly, not at all).
>
>>>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.
>
>But if you add an AI then what will the AI stare at? I rather think
>it will stare at pathnames. I know that I don't want to stare at icons.
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.
And current AI research is somewhat disappointing, with the exception
of neural nets.
I would certainly not want the AI to stare at icons -- whatever
an icon is, anyway; I've seen (at least) four implementations of an
icon, and all of them are mostly for the user's benefit.
[1] Mac is probably the cleanest. Its file system has multiple forks
per file; one of these forks -- the resource fork -- contains
a bunch of chunks, one of which is the icon declaration. I forget the
exact format thereof; the general format of each chunk is an
8-byte header (4-characters of name, 4 characters of length of
the chunk), followed by the chunk data, followed by some padding.
An application creating the file is responsible for putting
the right icon on the file. The Mac's filesystem is also
somewhat "strongly typed"; without special permutations,
a file can only be opened by the tool specified in the icon.
(There's probably a way around this using Command-something, however.)
[2] The Amiga is probably the simplest. Its file system is very
straightforward (files and directories; no special resource forks);
if a file or directory exists, and another file exists with the
name + ".info", the ".info" file is assumed to be in a special
format, which includes the tool, the position, and the picture
proper. Workbench recognizes ".info" files and displays them as icons.
Of course, this occasionally leads to broken functionality, as
.info files may be misspecified, or the object to which the .info file
refers may not exist, or may be the wrong type. But it's dead
simple to implement. :-)
Doubleclicking on an Amiga icon will fire off the tool specified
by that icon. Selecting a bunch of icons, one of them a tool,
then doubleclicking, will fire off that tool with an argument list
of those icons.
[3] As usual, Windows is the most complicated, and the most frustrating.
If an entry for the extension (the bit after the ".") exists
somewhere deep in the registry (I'm not sure where), that is
displayed, unless it's an .EXE (and possibly a .DLL) file, in
which case, the icon can be stored in a peculiar way within
the file itself; the file must be read to find this resource. That
is one reason why one will occasionally see a short delay between
the bringing up of the desktop and the drawing of some of the
actual shortcuts -- it's looking at the files to which those shortcuts
point and extracting the icons therefrom. Ugly!
(BTW: the shortcuts themselves are just .LNK files. Nothing
otherwise special about them, at least at the OS level; the
Internet Explorer is the one that interprets them. The Amiga
was similar in that respect; the user could edit ".info" files
if he really wanted to, but would probably not want to!)
[4] Unix icons are interpreted pretty much as the
presenter sees fit; if the presenter wants to go to the trouble
of checking the magic number of a file, it can; otherwise it
can either just go by extension, or be very generic and
represent everything as files, directories, or symbolic links,
with no attempts at being fancy. Or it can hack up a notion
that files with the +x flag set are scripts or executables,
and use a different icon for them.
None of these icon types would convey anything horribly useful
to an artificial intelligence program, with the possible exception
of the Mac (the AI proggie could look at the resource fork for
other chunks, if the program bothers to put anything else in there :-) ).
----
[EMAIL PROTECTED]
------------------------------
From: Michael Gibson <[EMAIL PROTECTED]>
Subject: Re: Can't compile kernal, Need help
Date: Tue, 1 Jun 1999 22:07:17 +0000
Crossposted-To: comp.os.linux.setup
On Tue, 01 Jun 1999, Spotillius Maximus aka \"Spot\" wrote:
>I've read the books and how to's and come up with the same error message
>when I issue the 'make config' command. It say's that the make command
>can't be found. I tried this on two systems with RedHat 5.2 and the same
>thing happens. 'make zImage, zdisk don't work either. I'm logged in as
>"root". What am i doing wrong? Thanks
If I remember correctly the make utilities are in the binutils RPM. If you
run glint under xwindows select the available button (make sure the cd is
inserted and mounted first <- If you installed off one) then find the package
named binutils.
------------------------------
** 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
******************************
