mjr@osiris.UUCP (Marcus J. Ranum) (01/01/88)
From Jan BYTE: (Jerry Pournelle) "I must say that as I watch the OS/2 story unfold, I do begin to wonder: if UNIX is ever made stable enough to be put in ROM, so that you don't need a guru to maintain the system, there's less and less reason why it won't catch on. I think of little that OS/2 promises that you can't do with UNIX; and now that American Management Systems has developed the long-mythical user-friendly UNIX shell, who knows ? However, UNIX isn't going anywhere without a major backer. The obvious major backer is AT&T, a company with deep pockets, brilliant engineers and designers, and a monopolist's attitude toward marketing. Think how different the world would have been it, a few years ago, AT&T had bought Apple Computer for its marketing savvy. At one meeting someone wryly observed that if AT&T would copy-protect System V UNIX, within 6 months it would be so widespread that nothing would be able to stop it. Actually, I suppose the most probably outcome is that a year after OS/2 comes out, there will be as many OS/2 users as UNIX users, after which both will continue in parallel and and without actually competing. UNIX is growing slowly, and OS/2 charging ahead; but while that's the probable event, it's by no means inevitable. After all, the main objection to UNIX was that it's too big and too slow - and that applies just as strongly to OS/2." Now, see, all these weenies and office managers who read BYTE take Jerry as gospel truth... I wish he'd go back to cheap sci-fi. --mjr(); -- Once, there was NO fun... This was before MENU planning, FASHION statements or NAUTILUS equipment... Then, in 1985.. FUN was completely encoded in this tiny MICROCHIP... It contains 14,768 vaguely amusing SIT-COM pilots!!
wolf@well.UUCP (Dwight Leu) (01/02/88)
In article <1495@osiris.UUCP>, mjr@osiris.UUCP (Marcus J. Ranum) writes: > From Jan BYTE: (Jerry Pournelle) > > "I must say that as I watch the OS/2 story unfold, I do begin to > wonder: if UNIX is ever made stable enough to be put in ROM, so that you > don't need a guru to maintain the system, there's less and less reason why > it won't catch on. I think of little that OS/2 promises that you can't do > with UNIX; and now that American Management Systems has developed the > long-mythical user-friendly UNIX shell, who knows ? ... I ran into Jerry at Hackers 3.0 in October, and had some fun discussing his views on UNIX and OS/2. I started off by mentioning an article I'm putting together for Microtimes, entitled ""Pournelle's Tyranny", dealing with the advantages of multi-user software, versus his first law ("One user, at least one CPU"). It was the first time I've seen him at a loss for words (for about 60 seconds). Please note that I like and respect him highly; I just take exception with some of his views. Anyway, we had a great discussion during the Sunday brunch. And I was surprised by how open he was to consider the advantages of UNIX. In fact, he gave me a quote that he said I could use: "I've seen OS/2, and I think UNIX is going to win by default!". So I believe Jerry is slowly coming around to UNIX. I see it as just a matter of time. -dwight- Dwight H. Leu ihnp4!amdcad!uport!dwight V.P. Engineering well!wolf Microport microsoft!sco!ucscc!uport!dwight 408-438-8649 bix: dleu Microport BBS: 408-438-6567 408-438-6687 (login: bbs) "INSERT YOUR PITHY QUOTE HERE!" And Happy Holidays!
chip@killer.UUCP (Chip Rosenthal) (01/02/88)
In article <1495@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: >From Jan BYTE: (Jerry Pournelle) > "I must say that as I watch the OS/2 story unfold, I do begin to >wonder... I think of little that OS/2 promises that you can't do with UNIX... This is the same guy who a few months back wrote that he couldn't see any reason why somebody would want multi-tasking. SideKick works just fine. Arrrrrgh. -- Chip Rosenthal chip@vector.UUCP | But if you want to sing the Dallas Semiconductor (214) 450-0400 | blues, then boy you better {texsun,codas,ihnp4}!killer!vector!chip | learn how to lose.
rick@pcrat.UUCP (Rick Richardson) (01/03/88)
> From Jan BYTE: (Jerry Pournelle) > > "I must say that as I watch the OS/2 story unfold, I do begin to > wonder: if UNIX is ever made stable enough to be put in ROM, so that you I gave up Byte years ago. Pournelle should stick to SF. Why would you want to put *Anything* into ROM (on a PC). Stability? Yeh... we got it ... the bugs are stable, they're in ROM. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) seismo!uunet!pcrat!rick
ron@topaz.rutgers.edu (Ron Natalie) (01/04/88)
Give him a break, he's just now coming around to 16 bits. One of his early pronouncements was that 16 bits would never catch on for personal computers. Eight bits was all the average user could deal with. -Ron
kempf@hplabsz.HPL.HP.COM (Jim Kempf) (01/05/88)
In article <442@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > > I gave up Byte years ago. Pournelle should stick to SF. Why would > you want to put *Anything* into ROM (on a PC). Stability? Yeh... we got it ... > the bugs are stable, they're in ROM. Actually, Hewlett-Packard manufactures a luggable which has Unix and lots of the Unix tools in ROM. The advantage is that you don't need a hefty chunk of disc space to hold them. The luggable used to be called the Integral PC, since it has an integrated Thinkjet printer, but I think they renamed it when it was retargetted to the firmware development market. It was a nice machine, at the time, the smallest Unix box available. Now, the AT clones, Atari ST and Amiga outclass it for general purpose computing. I agree with your opinion on Pournelle and Byte, though. Jim Kempf kempf@hplabs.hp.com Usual Disclaimer
eli@haddock.ISC.COM (Elias Israel) (01/05/88)
Re: Jerry Pournelle says Unix has a chance. Yea, I chuckled when I read the comment about Unix doing just about everything that OS/2 does. Wise up, folks. Unix is a real operating system that provides source-level compatibility between widely differing platforms. OS/2 is an IBM ploy to sell you yet another toy operating system by mimicking a real OS on a hardware platform that is ill suited to anything but micro-computing. 1/2 :-) Seriously, I think that Pournelle underestimates both the potential market and the utility of Unix for the small business. The idea about putting it into ROM is interesting, though; I've heard it expressed before. It certainly would be nifty to boot up a machine in only a few seconds. Besides, wouldn't it be nice to have a root file system that you *couldn't* trash? Elias Israel Interactive Systems Corporation Boston, MA ..!harvard!ima!haddock!eli Disclaimer: This is a personal comment. This posting does not necessarily represent the opinion of the Interactive Systems Corporation.
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/05/88)
In article <2126@haddock.ISC.COM> eli@haddock.ima.isc.com (Elias Israel) writes: | ... | Seriously, I think that Pournelle underestimates both the potential | market and the utility of Unix for the small business. The idea about | putting it into ROM is interesting, though; I've heard it expressed The HP Integra (sp?) has SysV in ROM. | before. It certainly would be nifty to boot up a machine in only a few How long does you system take?? I would be surprised to see a boot (after normal shutdown) take a full minute on a personal system. I assume only a few hundred MB of disk. | seconds. Besides, wouldn't it be nice to have a root file system that | you *couldn't* trash? Serious question here... I would love such a root f/s. But I assume that the root would have to be read only if it were in ROM, and I'm not sure about mounting a writeable f/s on a read only f/s. For some reason I get the impression that this couses problems, although I know you can do it. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mjr@osiris.UUCP (Marcus J. Ranum) (01/07/88)
There would be a few problems with making UNIX ROM-only - at least
the root file system: there are all the various files in /etc that do
benefit from the occasional change.
I also see making parts of UNIX (sh ?) in ROM as a bad idea since it
tends to greatly increase the development/repair/evolution time. If we had
to unplug chips and bring an engineer in every time there is a PTF for a
part of a system, it would cost someone too much somewhere, and the changes
would never get made. I can cite the PC as an example... As soon as you
start offloading parts of your software onto the hardware, you trade speed
for flexibility.
Suppose I create an intelligent disk controller with the UNIX fast file
system in the controller - suppose it hangs off the ethernet and understands
NFS so that it can be a "nodeless disk" or some such - now suppose NFS changes,
or there is a bug in my implementation. If I expect my customer to pay for my
engineer to come fix it - it'll never sell. If I expect to be able to afford
many upgrades, I'll be out of business in no time. The only places that can get
away with shenanigans like that are monsters like IBM - where they have such
a hold on their buying public that they can just say "pay for this, willya ?"
--mjr();
--
------------------------------------------------------------------------------
...ich bin in einem dusenjet ins jahr 53 vor chr...ich lande im antiken Rom...
einige gladiatoren spielen scrabble...ich rieche PIZZA...greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/07/88)
In article <1497@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: > There would be a few problems with making UNIX ROM-only - at least >the root file system: there are all the various files in /etc that do >benefit from the occasional change. Difficult, yes, but not impossible. For a long time, the Air Force supported a Unix system with a read-only root -- they wanted to have a simple recovery proceedure in case of a failure to boot. This was prior to the hardening of the filesystem, so a failure to boot was a real problem -- any crash while modifying the root could cause it. To always be able to just load the root from tape and boot was a blessing. > I also see making parts of UNIX (sh ?) in ROM as a bad idea .... >If we had to unplug chips and bring an engineer in [for every fix] ... >it would cost someone too much somewhere, .... Possible -- but instead of ROM chips, how about a CD-ROM? A compact disk is more than 500 megabytes, the drives are getting cheaper every day, and the disk is very inexpensive to replace -- and the users could replace it themselves. It's possible that the generic personal computer of the future will routinely have a CD-ROM inside it to provide all of the "standard" features that people are beginning to expect in their machines. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
aglew@ccvaxa.UUCP (01/08/88)
..> UNIX in ROM
Several people have expressed worry about the maintainability,
or vulnerability to bugs, of UNIX in ROM.
The appropriate way to use ROM is as a library, with, perhaps,
minimal glue code. All calls to ROM routines should be via a
dispatch table which ROM loads into RAM. The dispatch table can
then be patched, perhaps to pint to new RAM code for bug fixes.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have nameserver
aglew@gswd-vms.gould.com - if you don't
aglew@gswd-vms.arpa - if you use DoD hosttable
aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
ihnp4!uiucdcs!ccvaxa!aglew - paths may be more dependable
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.roy@phri.UUCP (Roy Smith) (01/08/88)
The proposal is to put Unix (the kernel and/or root file system) in
ROM. The problems are that it's hard to change and there may be problems
with mounting a writeable filesystem on a read-only root.
As for the first problem, why not use eeprom? It's non-volitile,
so you get almost-instant boots, but you can still write in it if you have
to under program control for updates.
As for the second problem, I doubt it's a problem. We mount (via
NFS; maybe this doesn't work for local disks) lots of rw file systems on a
ro /usr. Works fine; don't see any reason it shouldn't work for a ro root.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016ron@topaz.rutgers.edu (Ron Natalie) (01/08/88)
CD ROM roots would be bad because CD ROM's are blindingly slow. A write protected root is easy, we built such a system at BRL but after we did it we couldn't find anything good to use it for. 4.2 BSD would run for a few hours with a read only swap partition as well. -Ron
honey@umix.cc.umich.edu (Peter Honeyman) (01/08/88)
imagine a root partition that consists of a zillion symlinks, initially pointing to the rom disk. to change /bin/sh, just change the symlink. macintosh toolbox calls operate on a similar principle. peter
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/09/88)
In article <17309@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >CD ROM roots would be bad because CD ROM's are blindingly slow. Currently true. But don't take the current state-of-the-art as an intrinsic limit. They'll get faster. >A write protected root is easy, we built such a system at BRL but >after we did it we couldn't find anything good to use it for. Yes, a write-protected root is a trivial one-line change to the kernel. But that's not what we were considering; it still needs to have the functionality of a normal root -- that is, all the things in /etc could still be "updated," for example; but how this could be done is not clear. The Air Force kernel moved all modifiable files off the root file system, but it was a maintenance nightmare to keep track of all the programs that knew about the modifiable files and fix them every time there was a new release. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
cdl@mplvax.nosc.MIL (Carl Lowenstein) (01/09/88)
In article <17309@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >CD ROM roots would be bad because CD ROM's are blindingly slow. Yes, but all you really want to do is reload the fast-disk root file system from the CD ROM once in a while, like when you re-boot everything. -- carl lowenstein marine physical lab u.c. san diego {ihnp4|decvax|ucbvax} !sdcsvax!mplvax!cdl
kurt@hi.unm.edu (Kurt Zeilenga) (01/09/88)
In article <1972@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: >Yes, a write-protected root is a trivial one-line change to the kernel. But >that's not what we were considering; it still needs to have the functionality >of a normal root -- that is, all the things in /etc could still be "updated," >for example; but how this could be done is not clear. The Air Force kernel >moved all modifiable files off the root file system, but it was a maintenance >nightmare to keep track of all the programs that knew about the modifiable >files and fix them every time there was a new release. >-- >-- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd We use symbolic links from /etc to /usr/etc so that root is "static". Could you use them instead of modifying files? -- Kurt (zeilenga@hc.dspo.gov)
wcs@ho95e.ATT.COM (Bill.Stewart) (01/09/88)
In article <3100@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
: The proposal is to put Unix (the kernel and/or root file system) in
:ROM. The problems are that it's hard to change and there may be problems
:with mounting a writeable filesystem on a read-only root.
A long, long time ago, in a laboratory not very far away, when we might
have still been the Phone Company, I met a laptop UNIX machine that was
hoping to be given the name 3B1. It had UNIX in ROM, an LCD screen,
a WE32000 chipset, and a case that looked suspiciously like a TI745.
It never became a product; the economics weren't right, LCD, RAM, and
the 32000 were still too expensive and the marketing people weren't
sure if they could sell it. It was wonderful anyway, even if it did need AC.
: As for the first problem, why not use eeprom? It's non-volatile,
:so you get almost-instant boots, but you can still write in it if you have
:to under program control for updates.
The ROMs lived in a pod that clomped on the back, and were easy
to change, though a realistic physical design would probably put them
inside. EEPROM might be a nice alternative, though for safety it might
be worth adding a backup ROM in case youtrash the EEPROM.
: As for the second problem, I doubt it's a problem. ...... ro /usr.
Minix takes the rather nice approach of making root a RAM disk. You
can get a writable root even though the files come from ROM.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcsdavy@ea.ecn.purdue.edu (Dave Curry) (01/09/88)
In article <1972@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: >Yes, a write-protected root is a trivial one-line change to the kernel. But >that's not what we were considering; it still needs to have the functionality >of a normal root -- that is, all the things in /etc could still be "updated," >for example; but how this could be done is not clear. The Air Force kernel >moved all modifiable files off the root file system, but it was a maintenance >nightmare to keep track of all the programs that knew about the modifiable >files and fix them every time there was a new release. >-- >-- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd BSD symbolic links could handle this, for the most part. Symlink all the modifiable files like /etc/passwd, etc. out to /usr/etc or something. Then you only have to mung a few files which try to do something different if the file is a symbolic link. --Dave
jesup@pawl19.pawl.rpi.edu (Randell E. Jesup) (01/12/88)
In article <28200084@ccvaxa> aglew@ccvaxa.UUCP writes: >Several people have expressed worry about the maintainability, >or vulnerability to bugs, of UNIX in ROM. > >The appropriate way to use ROM is as a library, with, perhaps, >minimal glue code. All calls to ROM routines should be via a >dispatch table which ROM loads into RAM. The dispatch table can >then be patched, perhaps to pint to new RAM code for bug fixes. Sounds like the Amiga sharable libraries. Consists of a library base (returned by OpenLibrary); jmp vectors at negative offsets; a library node, public data, and private data at positive offsets. At boot, these are built in ram from the roms, where the routines live. You can also have ram-resident libraries that can survive re-boot if they checksum correctly. You can change a library entry via SetFunction(). // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup
rdavis@sushi.UUCP (01/12/88)
> >>CD ROM roots would be bad because CD ROM's are blindingly slow. > > > >Currently true. But don't take the current state-of-the-art as an intrinsic > >limit. They'll get faster. > > According to "CD-ROM: The New Papyrus" by Microsoft Press, faster data > transfer from CD-ROMs is unlikely because the frequency of the data starts > to approach the frequency of the servo mechanisms used to keep the optics > on track and in focus. How about if you have more than one read (laser) on the same CD? Maybe you could read the same track n different sectors, or read n tracks at a time? I don't know how possible this is, considering the CD doesn't spin at a constant rate. PS: I'm not an EE or a CD expert. I just had an idea...
ronald@csuchico.EDU (Ronald Cole) (01/13/88)
In article <2126@haddock.ISC.COM> eli@haddock.ima.isc.com (Elias Israel) writes: >The idea about putting it [the Unix kernel] into ROM is interesting, though; >I've heard it expressed before. It certainly would be nifty to boot up a >machine in only a few seconds. The HP Integrated Personal Computer I had an opportunity to play with had the kernel and the root file system in ROM. I am sure that the code was copied to RAM before the kernel started executing, though. Very fast booting. >Besides, wouldn't it be nice to have a root file system that you *couldn't* >trash? Ah, the only gripe I had with the machine was that I couldn't (I might not have had enough of the documentation to figure it out, anyway) make it boot from the 7908 hard drive I had connected to the HPIB port on the back. -- Ronald Cole | uucp: ihnp4!csun!csuchico!ronald AT&T 3B5 System Manager | PhoneNet: ronald@csuchico.edu California State University, Chico | voice (916) 895-4635 "... and if you don't like it, you must lump it." -Joseph Smith
irf@kuling.UUCP (Bo Thide) (01/17/88)
There are machines with UNIX in PROM! One is from Hewlett-Packard.
The name is "HP Integral PC" and it has been on the market for several
years. I has UNIX in ROM and includes a floppy disk drive, Inkjet
printer/plotter, mouse graphics display all in one package the size of
the now Compaq portable. We had two and liked them so much (they're
truly professional PCs and are *much* better than IBM/PCs which we
consider to be hobby machines) that we just bought our third to
supplement our other UNIX workstations/minis. We also bought the new
PROM from HP which includes lots of goodies. Spectron Corp. makes SCSI
disks for the Integral PC and we've also orderer that. This disk
mounts under the Integral PC box - very neat!
I'm surprised how ignorant many of you seem to be about products like
these, people who say they have used it don't even know the name of
it. Why is it so? I've also noticed that most of you are familiar
with workstations from Apollo and Sun but don't know that HP also makes
such boxes (we have several). Is HP so much smaller on the US market
than over here in Europe or what?
I'm curious to know.
-Bo
--
>>> Bo Thide', Swedish Institute of Space Physics, S-755 90 Uppsala, Sweden <<< Phone (+46) 18-300020. Telex: 76036 (IRFUPP S). UUCP: ..enea!kuling!irfu!btpeter@sugar.UUCP (Peter da Silva) (01/17/88)
> In article <3100@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > The proposal is to put Unix (the kernel and/or root file system) in > ROM. The problems are that it's hard to change and there may be problems > with mounting a writeable filesystem on a read-only root. The HP Integral handled this by copying the ROM to RAM at boot time, and keeping the file system in a RAM disk. It's also the first system I know of in which the RAM disk is allocated and freed as needed (the second is the Commodore Amiga). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/21/88)
In article <1410@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >The HP Integral handled this by copying the ROM to RAM at boot time, and >keeping the file system in a RAM disk. It's also the first system I know of >in which the RAM disk is allocated and freed as needed (the second is the >Commodore Amiga). Um, the read-only file system being discussed is over 500 megabytes; I doubt that it will fit in the RAM of many home computers. On the other hand, I could believe that interesting portions of it could be read into RAM (like the directory tree) so that lookups would be fast; this is one way to help alieviate the high seek time. (I didn't know that RAM: was ever freed; I thought that only VD0: and VDK: did that.....) -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
david@geac.UUCP (David Haynes) (01/21/88)
In article <3470@umix.cc.umich.edu: honey@citi.umich.edu (Peter Honeyman) writes:
:
:imagine a root partition that consists of a zillion symlinks, initially
:pointing to the rom disk. to change /bin/sh, just change the symlink.
:
:macintosh toolbox calls operate on a similar principle.
:
: peter
Better yet, just make *conditional* symbolic links. Then you can change
from system to system, from language to language with nary a trace of
difficulty. (but overhead? wow!)
-david-
--
David Haynes
Geac Computers International Inc.
UUCP: {mnetor|yetti|utgpu}!geac!davidgandalf@russell.STANFORD.EDU (Juergen Wagner) (01/23/88)
Conditional symbolic links would be not as bad as some people think they are. With NFS, you can have file systems shared among different architectures (VAX, Sun, ...). This inherits the problem of binaries being incompatible between systems. If a user logs in to host A (which is, say, a VAX/8700), and he/she writes some general programs, the same user will be in big trouble if he/she logs in to host B (which might be a Sun3). Of course, in this case, the search path could be setup such that it points to the correct binary directories (that's what I am doing now), but there is still a problem with machine-dependent Makefiles, data files (e.g. fonts), etc. So, as a conclusion, symbolic links conditional upon the architecture of the actual machine one is using could be very helpful. Juergen Wagner, gandalf@Russell.Stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA Disclaimer: The opinions expressed herein are those of my cat. -- Juergen Wagner, gandalf@Russell.Stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA
schwartz@gondor.cs.psu.edu (Scott E. Schwartz) (01/24/88)
In article <1897@russell.STANFORD.EDU> gandalf@russell.stanford.edu (Juergen Wagner) writes: >Conditional symbolic links would be not as bad as some people think >they are. With NFS, you can have file systems shared among different >architectures (VAX, Sun, ...). Agreed. In fact, Apollo supports conditional links and they work fine. Maybe sun could be talked into adding them to SunOS? -- Scott Schwartz schwartz@gondor.cs.psu.edu
rpd@M.GP.CS.CMU.EDU (Richard Draves) (01/24/88)
In fact, Vice (a file system developed at the Information Technology Center here) implements conditional symbolic links. The string @cputype gets substituted by the machine type of the client requesting the file. This feature is very useful. Rich
lawitzke@eecae.UUCP (John Lawitzke) (01/25/88)
in article <1999@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd.UUCP says: > Um, the read-only file system being discussed is over 500 megabytes That's strange, the root partition on my VAX8600 takes only ~5.25MB of disk space. I'd like to see a UNIX system in which the root partition is 500MB. That would make the /usr partition on the order of 2.5gigabytes. I shudder to think about the size of the user area......... > On the other hand, I could believe that interesting portions of it could be > read into RAM (like the directory tree) so that lookups would be fast If you knew anything about UNIX internals, you'd know that alot of the info on the disk is kept in memory. (Think, what does the 'sync' command do?) Take a look at the paper "The Berkeley Fast File System" that usually comes in the supplemental docs or take a gander through "The Design of the UNIX Operating System" by Maurice Bach. On another note, how about dropping this topic? I think we've kicked a dead horse quite enough. -- j UUCP: ...ihnp4!msudoc!eecae!lawitzke "And it's just a box of rain..." ARPA: lawitzke@eecae.ee.msu.edu (35.8.8.151)
henry@utzoo.uucp (Henry Spencer) (01/26/88)
> ... I'd like to see a UNIX system in which the root partition is 500MB.
Probably SunOS 4.0. Or 4.4BSD.
--
Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henrygreg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/26/88)
I normally don't respond to articles like this, but this one exceeded my threshhold of irritation about people who post without bothering to find out the background or thinking about what is being discussed. >in article <1999@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd.UUCP [sic] says: >> Um, the read-only file system being discussed is over 500 megabytes That's me, responding to a thread that described current technology that copied a read-only file system into RAM so that it could be manipulated. I was refering to another thread, where the possibilities of using a CD-ROM as an integral component of a future desktop-sized computer were being discussed. In article <5696@eecae.UUCP> lawitzke@eecae.UUCP (John Lawitzke) writes: >That's strange, the root partition on my VAX8600 takes only ~5.25MB of >disk space. I'd like to see a UNIX system in which the root partition is >500MB. That would make the /usr partition on the order of 2.5gigabytes. >I shudder to think about the size of the user area......... \I/ didn't say anything about it being a root partition -- where did you get that idea? I was talking about providing \all/ of Unix on a "file system" (in the abstract sense; that is, a place where files are kept -- obviously, it should look like a Unix file system to a user program, but that doesn't mean it has to be a \Unix/ file system), so that it would include not only all of what is normally found on the root, but also the programs, utilities, games, demos, and whatever. Even that wouldn't fill 500Mb of a CD-ROM, so there's room left for lots more. >If you knew anything about UNIX internals, ... [remainder of ad hominum > comments deleted] ... Sigh. In the first place, none of what you said had any relevance to using memory as an organized special-purpose cache, specifically containing the directory tree, as opposed to a generalized buffer cache that \happens/ to contain pieces of the directory tree. We're talking about how to optimize access to a unit with a half-second seek time and a slow transfer rate. Permenently allocating a piece of memory so that only one seek is required to access a file seems like a reasonable idea. And in the second place, sirrah, I have been hacking Unix kernels for over fifteen years. My credentials in this area include the infamous "Greg Noel Hack," well known to anyone who has been in the field for a while. Snotty remarks and gratuitous insults are not the way to win friends and influence people. >On another note, how about dropping this topic? I think we've kicked a >dead horse quite enough. You should have taken your own advice. If you don't find our speculations about the future intriguing, as I do, you are welcome to ignore them. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
earl@mips.COM (Earl Killian) (01/28/88)
Conditional symbolic links sound a little strange to me. How about instead the following idea from the ancient past: The ITS operating system had both symbolic links and things called translations. Symbolic links were more heavily used, but you could do cute things with translations, which were essentially per-process renamings. The best way to describe ITS translations to the Unix community would be to say they were a per-process sed script applied to every filename passed to the kernel. As such you can modify a filesystem (from your perspective at least) that you don't have access to. This very general facility could replace lots of special-purpose hacks. Suppose you wanted to change rm. Adding an alias, or an rm command in your path doesn't suffice because some scripts etc. say /bin/rm. So you add s|^/bin/rm$|/user/me/bin/rm| to your translation list. The csh ~ hack could be done by having s|^~|/user/me|, and then it wouldn't be limited to csh command lines. The system V TMPDIR environment variable would be unnecessary. Etc. etc.
jay@splut.UUCP (Jay Maynard) (02/06/88)
In article <1988Jan25.232820.27097@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > > ... I'd like to see a UNIX system in which the root partition is 500MB. > Probably SunOS 4.0. Or 4.4BSD. ...or SVr4 (or will it be SVI? SVII? Only AT&T knows for sure. :-) (equal time mode off) -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. The opinions herein are shared by none of my cats, much less anyone else.
bzs@bu-cs.BU.EDU (Barry Shein) (02/07/88)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) In article <1988Jan25.232820.27097@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > > ... I'd like to see a UNIX system in which the root partition is 500MB. > Probably SunOS 4.0. Or 4.4BSD. For what it's worth we have a Sun3.4 server here which had an overflowing root partition. Systems started cleaning it up to no avail. The reason it still appeared full was something arcane (I forget, but it was a result of a full restore, some error.) When we cleared that up we find that the system is currently running just fine and df reveals: Filesystem kbytes used avail capacity Mounted on /dev/xy0a 7735 2855 4106 41% / Strange...but true... -Barry Shein, Boston University