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
allbery@ncoast.UUCP (Brandon Allbery) (01/04/88)
As quoted from <1495@osiris.UUCP> by mjr@osiris.UUCP (Marcus J. Ranum): +--------------- | 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 ? +--------------- He also comments on "too big and too slow". Too big? Maybe -- if you want System V or 4BSD. Anyone for Minix? As for "too slow": I've seen slow UNIX systems. Then again, I'll bet he tested it on either an ACS986 or a VAX; the former would be slow running almost anything (8086's be not fast) and the latter's architecture just isn't suited to UNIX. While I've seen slow UNIX systems, I've also seen some pretty fast ones -- such as the 3b1 I'm using as a terminal to the Plexus P/35 which does a d*mned good job for the load on it. And a P/60 measured with the SysV load average daemon runs as fast with a load average of 5.5 as it does with a load of 0.5. (I never saw it go any higher, even with 20-25 active users in a database which is as computation- intensive as it is disk-intensive. [I should know: I wrote the computation parts.]) UNIX in ROM? Where was JEP when BYTE ran its review of the HP150? (That machine was a bit ahead of its time. But imagine one crossed with a Sun 3/50....) OS/2? See my .signature. As far as another poster's comment about Jerry doing an about-face wrt. UNIX vs. SideKick et al, consider that before the 386 UNIX was pretty much wasted on those little boxes. Certainly, my MS-DOS-based ITT XTRA (8088) was much faster than the Xenix ACS586/986 (8086), and also faster than 80286 Xenix boxes. Those two processors just couldn't handle multitasking. -- Brandon S. Allbery, Moderator of comp.sources.misc {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery PS/2: Half a computer. OS/2: Half an operating system for half a computer.
rwa@auvax.UUCP (Ross Alexander) (01/04/88)
In article <6952@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: > As quoted from <1495@osiris.UUCP> by mjr@osiris.UUCP (Marcus J. Ranum): > +--------------- > | From Jan BYTE: (Jerry Pournelle) {use your 'p' key if you really want to see this...) > He also comments on "too big and too slow". Too big? Maybe -- if you want > System V or 4BSD. [... excellent rebuttal to too slow elided here ...] And as for too big, fooey. Mass storage is getting cheaper much faster than even the BSD un*x's are getting bigger. Jerry is still in love with z80's, for crying in your beer! Of course he thinks everyone needs multiple cpu's. From what I've seen of his articles, if he had spent 1/2 the cash on one decent machine of the sun/3 (or equivalent, I'm not bigoted (much)) class as he has on umpteen-thousand tinkertoys, he'd be miles ahead. Ross Alexander, Sr Systems Programmer & Bottlewasher @ Athabasca University alberta!auvax!rwa
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.
plocher@geowhiz.UUCP (John Plocher) (01/05/88)
>even the BSD un*x's are getting bigger. Jerry is still in love with z80's, >From what I've seen of his articles, if he had spent 1/2 the cash on one >decent machine of the sun/3 (or equivalent, I'm not bigoted (much)) class >as he has on umpteen-thousand tinkertoys, he'd be miles ahead. A few years ago I was working for a company which sold S-100 CompuPro systems (For their time they were good, solid iron - too bad they didn't bother to learn how to use dynamic memory - when did you last price 2 Mb of 100ns Static Ram? :-) Anyways, as I was saying, I dealt with Compupro stuff and was mildly amused by Jerry's fanaticism for their systems. Later, while at a trade show talking with some people near the CompuPro booth I mentioned that Jerry was rather opinionated about computers - at which point someone from the booth said "Yea, Jerry is an asshole, but he's *our* asshole!" I still chuckle whenever I read one of Jerry's computer "reviews" :-) Besides, everyone knows that he doesn't ever buy PC stuff - companies just send him software and hardware to demo in the hopes he will write about it in one of his columns! Ps. Smile when you read this It's a joke, you hear? A *joke*! -Foghorn Leghorn -John
GUTHERY%ASC%sdr.slb.com@RELAY.CS.NET (guthery%asc@sdr.slb.com) (01/05/88)
OS/2 does things UNIX doesn't. It's benefited from 15 years of learning and research. SIGOPS shouldn't close its doors. What's the big deal? Sun tried for both threads and dynamic linking and blew it. There's a message there.
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
dsill@NSWC-OAS.arpa (Dave Sill) (01/06/88)
>OS/2 does things UNIX doesn't. And vice versa, I'm sure. I don't think OS/2's capabilities are a superset of unix's. >It's benefited from 15 years of learning and research. But is unproven. Unix has the benefit of over 15 years of learning and research as well as debugging and enhancing. It's been the subject of intense scrutiny at the source code level. OS/2, on the other hand, is untried and unproven. It is a proprietary operating system for one class of microprocessor. Its source code is not, and probably never will be, available. ===== The opinions expressed above are mine. "Damn it, wine is liquid food!" -- Robert Mondavi
mwm@violet.Berkeley.EDU (My watch has windows) (01/06/88)
> OS/2 does things UNIX doesn't. Any OS designed in the last five years that doesn't do things Unix doesn't has problems. Unless it was designed to be a Unix-or-similar clone, of course. But then it's probably got other problems. >> But is unproven. Unix has the benefit of over 15 years of learning >> and research as well as debugging and enhancing. It's been the >> subject of intense scrutiny at the source code level. That's 15 years of debugging and enhancing by a diverse set of people, of varying abilities and styles. While the semantics of most of the enhancements is clean, the same cannot be said for the code. And some of the enhancements look like something slapped on the side of the system. A clean OS designed & written with the lessons learned since Unix was first written has been needed for a while. But a Unix rewrite is a non-trivial effort, and not liable to happen. So I look for some new OS to displace Unix. The replacement will have to include replacements for most/all of the Unix utilities, have the same basic semantics for many operations, and be at least as portable. That isn't OS/2. <mike
erict@flatline.UUCP (eric townsend) (01/06/88)
In article <6952@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: | As quoted from <1495@osiris.UUCP> by mjr@osiris.UUCP (Marcus J. Ranum): | +--------------- | | 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 ? | +--------------- Ok, so I'll flame about the wrong thing on the wrong board. =:-> OS9, from Microware, is multi-tasking, ROM-able, and very, very, usable. There have been many posts about 680x0 based OS9 on usenet, I'm surprised it hasn't been brought up. I'd rather have an OS9 based 68020/881 box, with 5 terminals, than our 5PC-AT LAN at work. As it is now, there are three of us using the LAN and we fight over the 2 extra terminals. It takes 2 PC-s to recompile the Soft.Arch. and your code at the same time! :-> Whiney Flame Off. -- J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007 'Girls play with toys. Real women skate.' --Powell Peralta ad.| 'Hey, watch I disclaim all responsibility for others' ignorances. | me ollie this <whump>'
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...al@gtx.com (0732) (01/07/88)
As quoted from <1495@osiris.UUCP> by mjr@osiris.UUCP (Marcus J. Ranum):
->+---------------
->| 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 ?
->+---------------
->
Oh no, Pournelle on the UNIX bandwagon? Is the the Death knell of UNIX?
----------------------------------------------------------------------
| Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
| {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
----------------------------------------------------------------------
"UNIX? Nosireebob, I'm waiting for it to come out on an S-100 machine with
8-1/2 inch floppies."eric@hdr.UUCP (Eric J. Johnson) (01/07/88)
In article <11129@brl-adm.ARPA> mwm@violet.Berkeley.EDU (My watch has windows) writes: >A clean OS designed & written with the lessons learned since Unix was >first written has been needed for a while. But a Unix rewrite is a >non-trivial effort, and not liable to happen. So I look for some new ^^^^^^^^^^^^^^^^^^^^^^^^ Wrong. a Unix rewrite is already in the works. This was mentioned by Bill Joy at the December Sun Users Group Convention in San Jose. The new 'enhanced' version of System V will be rewritten from scratch in C++. The slide he showed had all the major flavors of Unix being merged back into one product. Does anyone have any more information on this? -- ------------------------------------------------------------------------------ -- Eric J. Johnson UUCP: eric@hdr.UUCP CIS: 72460,11 BIX: ericj -- -- HDR Systems, Inc. Other UUCP paths: codas!hdr!eric ugn!eric -- ------------------------------------------------------------------------------
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
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
greywolf@unicom.UUCP (When love and skill work together, expect a masterpiece.) (01/09/88)
In article <170@hdr.UUCP> eric@hdr.UUCP (Eric J. Johnson) writes: > >Wrong. a Unix rewrite is already in the works. This was mentioned >by Bill Joy at the December Sun Users Group Convention in San Jose. >The new 'enhanced' version of System V will be rewritten from scratch >in C++. The slide he showed had all the major flavors of Unix being >merged back into one product. > A rewrite in C--? Gads, that sounds like an absolute nightmare... is C really going down and something else taking its place? The least they could do if they were going to rewrite UNIX is to try and truly integrate the best of both worlds (i.e. BSD & System V). (Each has its own good points and drawbacks as I am sure most well-educated programmers are aware. The problem with integrations is they end up integrating the drawbacks and forgetting about the good points...) Does C-- follow the ANSI standards? Where is the UNIX world going?? -- " <- (2 dots) :: / | \ ...sun!{pixar,island}!unicom!greywolf Roan Anderson, Local Guru :: : | : (which doesn't say much) :: : /|\ : war: Invalid argument. (Gov't dumped) :::::::::::::::::::::::::::::::: =_|_= ::::::::::::::::::::::::::::::::::::::
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
uhclem@trsvax.UUCP (01/09/88)
<> >/*Written 10:35 am Jan 7, 1988 by phri.UUCP!roy in comp.unix.wizards */ > > > 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. Great sounding idea, as the EEPROM has "infinite" read cycles and about 10,000 bit-changing write cycles. Problem is, the things are expensive. Look in your Allied catalog at the XICOR 2102, which is a 64 x 4 bit EEPROM. Price, $6.95. Okay, its from Allied, so the chip may be available from the maker for $1. But that is not even 64 bytes, it is 64 nibbles. 1K byte would cost you $32. There are more dense EEPROM's available (I just happened to know the price of that one), but the price per byte doesn't decline fast enough. EEPROM to store 200K of kernel code is going to cost a few military-style dollars. <Just my opinion.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem
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!wcsgwyn@brl-smoke.ARPA (Doug Gwyn ) (01/09/88)
In article <232@unicom.UUCP> greywolf@unicom.UUCP (When love and skill work together, expect a masterpiece.) writes: >Does C-- follow the ANSI standards? It's C++, thank you, and there is no ANSI standard for C++. If you mean, can a C++ implementation conform to the proposed ANSI C standard, then it cannot, since (among other things) it preempts additional keywords. I recall Bjarne saying that once the ANSI C standard has been adopted, he'll consider making changes to C++ to bring it more into line as a superset of ANSI C. By the way, C++ is definitely a better systems implementation language than C, from a technical viewpoint. I'm a bit skeptical about such a reimplementation of UNIX, however, because I think we're going to see a lot of old bugs reappear.
davy@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
bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) (01/10/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. I thought of that, but then why have a read-only root at all? Sounds like all you're left with is the ability to say, without complete dishonesty, "I have a read only root", sin of omission. I think what we have here (in general, not this note) is hacker's fever. The reason you'd ROMify the unix root is because you want a version that has several advantages (can't trash it) AND you specifically were confident that people (probably turnkey users, not hackers) did not want to change anything. I suppose you could rearrange some configuration stuff, symlinks is as good as any (or a different mechanism entirely, some stuff just won't live on root anymore, at least as we know it, a few critical facts might get read in at boot from a single file, like a default server host if that's a thing.) Could be hard-coded into an editable /etc/rc file script I guess. Anyhow, the point is, either you want it or you don't. Too much compromise (like a zillion symlinks) seems to obviate any advantage pretty quickly. It seems academic to me, I can't see any huge need that can't be solved in some other way, except perhaps a true turnkey or process control type application where it's just supposed to do the same thing over and over again every day and no one wants to touch it, or at least considers touching it a major enough event that changing a chip is reasonable (can you say "ROM upgrade"?) I know that the Mac has this huge rom with everything in it but I'm not quite sure why they think that's a good idea other than perhaps it helped them hit some cost goal, the thing still crashes at the drop of the hat and doesn't even reboot or do anything intelligent, just sits there with a cute system bomb message waiting for the user to do something (if you're lucky, sometimes it just sits there catatonic.) Sounds a little like "romifying is the answer...what's the question?" Except, like I said, in a few special applications of a machine. Like Ron Natalie pointed out you could mount a root disk read-only with some not-so-drastic changes. Then they'd just get to trash /usr... -Barry Shein, Boston University
aglew%fang@gswd-vms.Gould.COM (Andy Glew) (01/10/88)
..> / in ROM
Barry Shein (paraphrased) says that he cannot see the advantage of
having / be symlinks to stuff on ROMdisk -- because, since / is still
writable, the advantage of not being able to trash a ROMdisk / is
lost. (Please correct me if I've misunderstood).
Consider, though, that the probability of hardware errors is usually
proportional to the amount of space occupied.
The system I'm on right now has a 16M /. It has 1406 inodes used.
Now, if this / consisted only of 1K symlinks, it would occupy just about
2M. So the chances of a hardware error trashing / have been decreased
8 times!
Of course, some types of software errors are proprtional to the volume
of the namespace, not the volume of the objects named; so the chance
of this error hasn't been changed; eg. rm /*. However, software errors
that result in writing *into* rather than *onto* files have been
eliminated.
And, if the default image of the symlinks is in ROM, and can be loaded as
if from scratch and then repatched...
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?
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.mash@mips.UUCP (John Mashey) (01/10/88)
In article <232@unicom.UUCP> greywolf@unicom.UUCP (When love and skill work together, expect a masterpiece.) writes: >In article <170@hdr.UUCP> eric@hdr.UUCP (Eric J. Johnson) writes: >> >>Wrong. a Unix rewrite is already in the works. This was mentioned >>by Bill Joy at the December Sun Users Group Convention in San Jose. >>The new 'enhanced' version of System V will be rewritten from scratch >>in C++. The slide he showed had all the major flavors of Unix being >>merged back into one product. >A rewrite in C--? Gads, that sounds like an absolute nightmare... >is C really going down and something else taking its place? The least >they could do if they were going to rewrite UNIX is to try and truly >integrate the best of both worlds (i.e. BSD & System V). (Each has its >own good points and drawbacks as I am sure most well-educated programmers >are aware. The problem with integrations is they end up integrating the >drawbacks and forgetting about the good points...) >Does C-- follow the ANSI standards? >Where is the UNIX world going?? Many of us have used the "Darwinian Selection" model of UNIX evolution for years; a) A new "standard" version of UNIX appears. [creation] b) Everybody takes it, adds extensions, changes to meet local needs. [mutation] c) After a while, people notice the chaos of having multiple versions that differ more than necessary, and there is a struggle to breed together the multiple versions, saving the good genes. [selection] d) Then, "a" happens again. This happened, in modest ways, for several years inside Bell Labs. It happened in a big way inside the Labs around 1977-1980, when upper management realized UNIX was critical to many projects, but varied randomly more than needed. There was a big, explicit effort to crunch together: stuff from research UNIX, USG, PWB, Columbus, etc. The BSD vs V thing is no different, although many people, especially those who aren't old-timers, seem to treat as a unique event. The natural state of UNIX, ever since it escaped from Lab 127 is; a) There are a bunch of features and interfaces that everyone agrees on. Those are "genes" that have been around a long time. b) There are a bunch of features where not everyone agrees on, but there are only a few ways that people do it, often for historical reasons. c) There are some things, especially those near the edge of the state of the art, or for applications that are more special-purpose, where no one agrees on anything, and it's mass chaos. Over time, items in b) turn into a), and c) turn into b), and new things appear in category c). The BSD vs V thing is in the b) turning into a) category right now. One has to ask if the proposed ATT+Sun V+BSD: a) will be the first such animal? [no: many other people already have heavily-merged versions right now. Look at, for example, HP/UX, among many.] Saying that the combined version will finally "end the BSD-V war" is one of the more amazing things I've seen: a lot of us thought that most people were ending the war by themselves anyway: take a look at the number of System-V based systems that have: sockets, BSD TCP/IP, BSD or other file systems, long pathnames, better signals, c-shell, etc, etc, OR the number of BSD-based systems that pass SVID, have shared memory, semaphores, etc, etc. b) can look a LOT different from what you'd expect? [how: AT&T is saying that people investing in SYS V code on 386s and 3Bs will be OK, and Sun is saying that SunOS user's will be OK also, and both are saying it will be POSIX-compatible and X/Open-compatible. Regardless of what's on the inside, it can't afford to break too many things on the outside.] Anyway, I don't see why integrations usually save the bad, and forget the good. I've been involved in several rounds of that in UNIX-land, and it usually hasn't been true. [If you think some yukky things got included, you should have seen some of the truly amazing things that got left out or cleaned up.] Also, there are enough reasonable BSD+V or V+BSD hybrids around to offer existence proofs. Now that AT&T is actually, finally, blessing the idea that it might be OK to include BSD features, maybe we can all be shipping our hybrids and not have to worry about whether or not it's heresy to have added sensible BSD features. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) (01/10/88)
From: Andy Glew <aglew%fang@gswd-vms.gould.com> >Barry Shein (paraphrased) says that he cannot see the advantage of >having / be symlinks to stuff on ROMdisk -- because, since / is still >writable, the advantage of not being able to trash a ROMdisk / is >lost. (Please correct me if I've misunderstood). Hmm, perhaps I misunderstood, then you misunderstood what I misunderstood... I thought the idea was that the ROM file system would have symlinks to the writable disk files so they could be changed, like editing an rc file or replacing with a newer /bin/sh (ie. the data was on disk, the symlinks in ROM.) I suppose at worst we've revealed yet another two cases to be considered though the original issue, what does it really buy you, remains at question. -Barry Shein, Boston University
nate@cpocd2.UUCP (Nathan Hess) (01/12/88)
In article <1261@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >Many of us have used the "Darwinian Selection" model of UNIX evolution >for years; > a) A new "standard" version of UNIX appears. [creation] > b) Everybody takes it, adds extensions, changes to meet local > needs. [mutation] > c) After a while, people notice the chaos of having multiple versions > that differ more than necessary, and there is a struggle to > breed together the multiple versions, saving the good genes. > [selection] > d) Then, "a" happens again. And, indeed, "a" will recur yet again in the history of UNIX evolution when GNU hits the disks... (sometime this year?) Any guesses as to how much of BSD and how much of SysV GNU will incorporate? Anyone know for sure? Cheers, --woodstock -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!cpocd2!nate <domainish> : nate@cpocd2.intel.com ATT : (602) 961-2037
spuhler@hpisoa2.HP.COM (Tom Spuhler) (01/12/88)
>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 I don't know what all would need to write to root while single user, and what would happen if they (?) couldn't, but "what if" (you've seen the commercial) there were two /etc directores. One would be a minimal subset on the read only FS and there would be a link from /etc to say, /letc. This copy would be used in single user mode and the like. Another, full copy would be kept on another FS and would be mounted on /etc when the normal mounts occur (going to init 2, for example). Now all the stuff in /etc would be available and things would go on from there. The single user /etc would still be accessable via /letc. Something that comes to mind is how do you modify your /etc/checklist (or BSD equiv.) when it's on CD ROM. Actually, this would seem to have even more potential as a method to unload a bunch of the stuff in /etc off root...hummmm... Tom spuhler, Hewlett Packard Systems Performance Laboratory
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!davidkam@hpcvlx.HP.COM (Keith Marchington) (01/23/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). > Not really. The Integral would create the file system in RAM disk at boot and then go out and look for all of the appropriate ROM 'disks' out in its address space. The address space was divided into 7M RAM, 1M I/O, and 8M ROM if I remember correctly. Any appropriate ROM disks were consolidated into /rom. The rest of the above info is essentially correct. >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. > Granted, such a file system would not fit into normal RAM. But using the Integral scenario, such a thing would be quite possible. >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. > Exactly! >(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 >---------- Keith Marchington Hewlett-Packard Corvallis, Oregon
gandalf@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