mmm@weitek.UUCP (Mark Thorson) (10/17/85)
It's become soooo fashionable to put down Unix. So why don't you ever hear
valid criticisms of Unix? You always hear chicken---- like:
1. It has cryptic command names. (So what? They work! Alias them if
you'd rather say 'search' to call 'grep'! What do you want, a menu-driven
shell? It would be easy to give you one if that'll put this stupid
criticism to rest!)
2. It has bad documentation. (Have you tried to read it? It is oriented
to working programmers so it does tend to be terse and easy to scan.
But if you need some one to hold your hand, there is an abundance of
books at your local technical bookstore. The books range from ultra-
beginner to advanced topics, specialized to generalized, verbose "user
friendly" to dry reference tomes. What do you want? Unix has been
described from every conceivable angle.)
3. It's a hack. (Dead wrong. Operating systems from the manufacturers are
hacked --- RSX11 for an extreme example. When I started using Unix ten
years ago, most multitasking operating systems were much larger. They
were also highly restrictive. Things like the command interface were
part of the OS. The SYSTAT program (in DEC parlance) was part of the OS.
The file copy program was part of the OS. The revolutionary thing about
Unix back in 1975 was that it only supported critical functions in the OS.
Everything else was a disc-resident program. Thus you could write your
own shell, your own SYSTAT, your own everything. And people did. Unix
in 1985 is encrusted with all kinds of cute additions. The Unix environ-
ment today is the OR function of everbody's ideas on how to 'improve' the
shell and the system utilities. BUT THE UNDERLYING ELEGANT STRUCTURE IS
STILL THERE. You can delete the extensions if you wish, but it's easier
to turn them off. When I was given my account on the Weitek VAX, the SA
had provided me with .cshrc and .login files that turned on most of the
cute features. Like the funny characters after the file names when you
do an 'ls'. I immediately deleted those files and logged back in.)
I'm not love-blind to the weaknesses of Unix. There ARE valid criticisms of
Unix, but you won't hear them from these pseudo-intellectual snobs.
1. Unix does not support the traditional scientific computing environment
well. This means compute-bound FORTRAN programs. If you want to program
in FORTRAN or if you want to run crunching FORTRAN programs like DRACULA,
get VMS. At Weitek we run one VMS machine solely for this reason.
2. Unix does not support the traditional business computing environment well.
This means sequential I/O bound COBOL programs. Unix does not even have
sequential I/O. It's random-access I/O is so fast that it is used to fake
sequential I/O. But it does not fake it as fast as the real thing. So
get an IBM computer if you want that (or look up a back issue of Computer
Graphics to see how Tom Farrin made Unix support true sequential I/O).
3. Unix security is eggshell-thin. In practice, Unix is usually run about
as securely as other OSes. But it is intrinsically easy to break. This
is one problem that Unix can't run away from. As Unix matures the other
problems will become less important, but this one will become more.
Mark Thorson (...!cae780!weitek!mmm)sommar@enea.UUCP (Erland Sommarskog) (10/24/85)
In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >It's become soooo fashionable to put down Unix. So why don't you ever hear >valid criticisms of Unix? You always hear chicken---- like: > >1. It has cryptic command names. (So what? They work! Alias them if > you'd rather say 'search' to call 'grep'! What do you want, a menu-driven > shell? It would be easy to give you one if that'll put this stupid > criticism to rest!) So you want me to find out what "grep", "awk" and the rest stands for, to see if if it's something useful and then rename it, filling my .login with kilobytes of alias. One basic problem with the cryptic names, is that you just grow tired and give a damn in the whole thing. Another point is the one-letter options Unix provides. I would say it's a quite inhuman task trying to remember but quite a few. What do you want me to do? Try to find out which I will be likely to use and increase the list aliases? Or should check "man" every time? Which takes an eternity because I have to scan the text until I find the options. (Compare VMS: You do HELP command, and there you have all qualifiers.) I could say more, but I'll summarize: You can call it chicken talk or whatever, but I insist on these points are so serious, that I refuse do anything on a Unix machine than writing News. >2. It has bad documentation. (Have you tried to read it? It is oriented > to working programmers so it does tend to be terse and easy to scan. > But if you need some one to hold your hand, there is an abundance of > books at your local technical bookstore. The books range from ultra- > beginner to advanced topics, specialized to generalized, verbose "user > friendly" to dry reference tomes. What do you want? Unix has been > described from every conceivable angle.) > Why should I have run around book stores to get good documentaion. I think it should come with the system. I think you should show some solidarity with us "chickens" who don't the same skill as you. > >I'm not love-blind to the weaknesses of Unix. There ARE valid criticisms of >Unix, but you won't hear them from these pseudo-intellectual snobs. > >3. Unix security is eggshell-thin. In practice, Unix is usually run about > as securely as other OSes. But it is intrinsically easy to break. This > is one problem that Unix can't run away from. As Unix matures the other > problems will become less important, but this one will become more. > >Mark Thorson (...!cae780!weitek!mmm) Yes, this an very severe problem. (Not only for Unix, but most other OS's are at least a little safer. Erland Sommarskog ----------------------------------------------------------------------- The company I work for is deeply involved in the Unix business. As you might guess, these views are perfectly my own.
herbie@polaris.UUCP (Herb Chong) (10/24/85)
In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >It's become soooo fashionable to put down Unix. So why don't you ever hear >valid criticisms of Unix? You always hear chicken---- like: >1. It has cryptic command names. (So what? They work! Alias them if > you'd rather say 'search' to call 'grep'! What do you want, a menu-driven > shell? It would be easy to give you one if that'll put this stupid > criticism to rest!) but then you are paying the price of compatibility. your commands and your documentation don't correspond. i switch between three different operating systems during a single day's work. renaming commands would play havoc with remembering what things do even though i have been using two of the systems for more than a year as a programmer and am considered an expert (but not a guru) on two of them. >2. It has bad documentation. (Have you tried to read it? It is oriented > to working programmers so it does tend to be terse and easy to scan. > But if you need some one to hold your hand, there is an abundance of > books at your local technical bookstore. The books range from ultra- > beginner to advanced topics, specialized to generalized, verbose "user > friendly" to dry reference tomes. What do you want? Unix has been > described from every conceivable angle.) which was fine in the good old days when dennis ritchie was the only one using the system or in the small group that worked on version 6. nowadays, there is a much larger user community and the average level of expertise is lower. as a user consultant when i was with the university of waterloo, i had to interpret the documentation for ordinary users on our 4.2 bsd system. about 10% of the manual pages were clarified locally and still most ordinary users couldn't understand what the documentation meant. all too often, i had to look at the source in order to figure out what was really going on. i was fortunate that i was priviledged enough to be able to look at it. i save said this many times on the net and i will say it again, the unix documentation was written to remind the person who wrote the program what everything does. it also happens that some of the time, an ordinary user can understand it and that most of the time, a system hacker or guru knew what was meant. >3. It's a hack. (Dead wrong. Operating systems from the manufacturers are > hacked --- RSX11 for an extreme example. When I started using Unix ten > years ago, most multitasking operating systems were much larger. They > were also highly restrictive. Things like the command interface were > part of the OS. The SYSTAT program (in DEC parlance) was part of the OS. > The file copy program was part of the OS. The revolutionary thing about > Unix back in 1975 was that it only supported critical functions in the OS. > Everything else was a disc-resident program. Thus you could write your > own shell, your own SYSTAT, your own everything. And people did. Unix > in 1985 is encrusted with all kinds of cute additions. The Unix environ- > ment today is the OR function of everbody's ideas on how to 'improve' the > shell and the system utilities. BUT THE UNDERLYING ELEGANT STRUCTURE IS > STILL THERE. You can delete the extensions if you wish, but it's easier > to turn them off. When I was given my account on the Weitek VAX, the SA > had provided me with .cshrc and .login files that turned on most of the > cute features. Like the funny characters after the file names when you > do an 'ls'. I immediately deleted those files and logged back in.) but it's not the underlying structure that people deal with. it's the interface that we see. do you really care that you could write your own shell to handle commands in your own prefered manner? maybe you do, but there are an awful lot of people who not only don't care, but would use any system as long as it got the job done and on time. the design of a system alone doesn't make it wonderful to use. multics is not bad, from what i hear, and the layered approach to design has been emulated by many other systems, but do you see many out there? >I'm not love-blind to the weaknesses of Unix. There ARE valid criticisms of >Unix, but you won't hear them from these pseudo-intellectual snobs. > >1. Unix does not support the traditional scientific computing environment > well. This means compute-bound FORTRAN programs. If you want to program > in FORTRAN or if you want to run crunching FORTRAN programs like DRACULA, > get VMS. At Weitek we run one VMS machine solely for this reason. it doesn't support the interactive environment very well either if you get larger. unix does not scale up well, and that's where many people are taking the design. they are running it on bigger and bigger machines and the fundamental algorithms used are beginning to chew up a larger and larger percentage of the CPU. admittedly, this is an implementation problem more than a design problem, but it's there. >2. Unix does not support the traditional business computing environment well > This means sequential I/O bound COBOL programs. Unix does not even have > sequential I/O. It's random-access I/O is so fast that it is used to fake > sequential I/O. But it does not fake it as fast as the real thing. So > get an IBM computer if you want that (or look up a back issue of Computer > Graphics to see how Tom Farrin made Unix support true sequential I/O). it's partly a function of hardware as well. tradition has it that all disk blocks are 512 bytes. this is fine on a smaller machine where there was only 64K to work with, the CPU and memory are slow, and so was the disk. you can make block sizes bigger, but still you have to live with hardware that doesn't understand it. 2K or 4K blocks make better sense on the machines of VAX size with 4M, 8M, or even 12M or memory. VM/CMS's file system is basically block oriented much like unix's (with certain restrictions) and yet I/O performance is almost an order of magnitude better in terms of byte/s. mind you, CMS never has to lock on I/O because the filesystem is private to each user. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... New net address -- VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa
christer@kuling.UUCP (Christer Johansson) (10/25/85)
In article <951@enea.UUCP> of Wed, 23-Oct-85 22:07:55 GMT sommar@enea.UUCP (Erland Sommarskog) writes: >In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >>1. It has cryptic command names. (So what? They work! Alias them if >> you'd rather say 'search' to call 'grep'! What do you want, a menu-driven >> shell? It would be easy to give you one if that'll put this stupid >> criticism to rest!) > >So you want me to find out what "grep", "awk" and the rest stands for, to >Another point is the one-letter options Unix provides. I would say it's >a quite inhuman task trying to remember but quite a few. What do you want me Decide for yourself what commands, switches etc you want. Ask your local guru if there is programs that do those things, then write your own commandinterpreter that forks and execls. You'll have to learn have to do the things you want done, but then you could forget them, and use your own shell. -- SMail: Christer Johansson EMail: {seismo,seismo!mcvax}!enea!kuling!christer OR Sernandersv. 9:136 christer@kuling.UUCP S-752 63 Uppsala Phone: Int. +46 - 18 46 31 54 SWEDEN Nat. 018 - 46 31 54
sommar@enea.UUCP (Erland Sommarskog) (10/25/85)
In article <839@kuling.UUCP> christer@kuling.UUCP (Christer Johansson) writes: > >Decide for yourself what commands, switches etc you want. Ask your local guru >if there is programs that do those things, then write your own >commandinterpreter that forks and execls. You'll have to learn have to do the >things you want done, but then you could forget them, and use your own shell. I knew that this argument would I show up, yet I didn't mention it my article to make it long. You know one thing, Christer? Those days I was a student, which wasn't very long ago, I had also had the time doing what I felt. These days I could have spent my time write command interpreters for Unix or VMS or ... you name it. I could continue in this way, but to keep it short: If I have to write my own command interpreter to use an operating system, then I refuse it. That is too much work. Specially when it implies the learning of a language which I consider as obscure, namely C.
jsdy@hadron.UUCP (Joseph S. D. Yao) (10/27/85)
In article <951@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes: >In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >>3. Unix security is eggshell-thin. In practice, Unix is usually run about >> as securely as other OSes. But it is intrinsically easy to break. ... >Yes, this an very severe problem. (Not only for Unix, but most other OS's >are at least a little safer. I can't believe that this bald statement has gone this long unchallenged. Most OS's, such as those put out by certain 3-letter corporations, are provably impossible to make at all secure in reasonable time. UNIX, on the other hand, has been chosen as the base for almost every non-Multics attempt at a provably secure OS. It has a lot of great security capabilities. Security, however, is mostly a matter of human behaviour. It doesn't matter what safeguards I put in the software if I leave the key in the machine, which is sitting in the hallway, and tape the super-user password on the console so I can remember what I changed it to ... five years ago. How many of you who complain about security enforce password aging? How many enforce passwords, for goodness' sake? [These are rhetorical questions, N O T a survey!] How many have changed the wizard password in sendmail.cf? How many have even removed Other and Group write permissions from /etc/passwd and properly use groups to separate users? I will say this in favour of the original position. Unix was originally written to be used in a trusted community, so it is delivered with a lot of protections off. But if people spent 1/10 the time fixing protections and tightening human security policies that they do complaining about Unix security, they would have little (if anything) to complain about. I hereby challenge anybody to hand me a Unix source system, and in a short time I will have it "reasonably" secure. (There is no such thing as "absolutely" secure.) You supply a (resonable) definition of "reasonable". [E.g., provable and multi-level are not reasonable, for a vanilla Unix, unless you want to put us on contract.] Even if you have put holes in the system, as long as you give me the original tapes (let's be reasonable!) I believe I can do this. I guess I should puncture my ego trip and say this challenge is addressed to the ordinary system manager such as those who made the above complaints. It's not addressed to the many people who are much cleverer in this area than I am, such as the people at ucla-security, any of the kernelised secure OS projects, MI#, Ft. Meade, Langley, Ken or Dennis or Brian or ..., or all those who taught me all I know but not all they know. But I would be willing to accept even a reasonable challenge from any of them, on the understanding that I know they will probably do something I can't find in a "short" time. I should also put a time limit on this, and accept only serious offers, because I am not going to spend all the rest of my life fixing security on Unix systems. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
bc@cyb-eng.UUCP (Bill Crews) (10/30/85)
> In article <951@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes: > >In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: > >>3. Unix security is eggshell-thin. In practice, Unix is usually run about > >> as securely as other OSes. But it is intrinsically easy to break. ... > >Yes, this an very severe problem. (Not only for Unix, but most other OS's > >are at least a little safer. > > I can't believe that this bald statement has gone this long > unchallenged. > UNIX, on the other hand, has > been chosen as the base for almost every non-Multics attempt > at a provably secure OS. It has a lot of great security > capabilities. Ouch! Hot flame! > Security, however, is mostly a matter of human behaviour. It > doesn't matter what safeguards I put in the software if I leave > the key in the machine, which is sitting in the hallway, and > tape the super-user password on the console so I can remember > what I changed it to ... five years ago. > > How many of you who complain about security enforce password > aging? How many enforce passwords, for goodness' sake? [These > are rhetorical questions, N O T a survey!] How many have > changed the wizard password in sendmail.cf? How many have even > removed Other and Group write permissions from /etc/passwd and > properly use groups to separate users? Agreed, of course. > I will say this in favour of the original position. Unix was > originally written to be used in a trusted community, so it is > delivered with a lot of protections off. But if people spent > 1/10 the time fixing protections and tightening human security > policies that they do complaining about Unix security, they > would have little (if anything) to complain about. You give too little weight to the significance of a closed system that must be opened versus an open system that must be closed. It is difficult to figure out exactly how all those doors need to be closed. > I hereby challenge anybody to hand me a Unix source system, and > in a short time I will have it "reasonably" secure. (There is > no such thing as "absolutely" secure.) You supply a (resonable) > definition of "reasonable". [E.g., provable and multi-level are > not reasonable, for a vanilla Unix, unless you want to put us on > contract.] Even if you have put holes in the system, as long as > you give me the original tapes (let's be reasonable!) I believe > I can do this. It doesn't matter if you can do this or not if system security isn't designed in such a way that people will tend to use it correctly. If security is insufficiently flexible, people will try to kluge their security. If kluging becomes a hassle, as it often does, people tend to refrain from messing with it. That's human nature. > I guess I should puncture my ego trip and say this challenge is > addressed to the ordinary system manager such as those who made > the above complaints. It's not addressed to the many people > who are much cleverer in this area than I am, such as the people > at ucla-security, any of the kernelised secure OS projects, MI#, > Ft. Meade, Langley, Ken or Dennis or Brian or ..., or all those > who taught me all I know but not all they know. But I would be > willing to accept even a reasonable challenge from any of them, > on the understanding that I know they will probably do something > I can't find in a "short" time. Getting a little chicken now, huh? :-) > I should also put a time limit on this, and accept only serious > offers, because I am not going to spend all the rest of my life > fixing security on Unix systems. > > Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} I don't intend to supply you with a challenge. I don't personally know a system that is ideally flexible in its security. Those that seem to come closest are those that define classes of resources and classes of users. Any resource can be in any number of classes, and any user can be in any number of user classes. Then, a mapping of user classes and resource classes can be made. These are often referred to as ACLs, or access control lists. The system as delivered has only one class of each, that of system administrator class and system resource class. It is then up to the system administrator to open up the rest of the system by including resources and users in classes and then creating ACLs. This isn't perfect, either, of course. And all this must sit atop something better that rwx. But that is another story. I'm not saying Unix security is so bad, but it seems to me your indignation is uncalled for. -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
scw@ucla-cs.UUCP (11/10/85)
In article <228@polaris.UUCP> herbie@polaris.UUCP (Herb Chong) writes: >In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >>It's become soooo [...] these pseudo-intellectual snobs. >> >>1. Unix does not support the traditional scientific computing environment >> well. This means compute-bound FORTRAN programs. If you want to program >> in FORTRAN or if you want to run crunching FORTRAN programs like DRACULA, >> get VMS. At Weitek we run one VMS machine solely for this reason. > This is mainly because there has been no reasonable FORTRAN compiler (f77 is a joke). Although I suspect that this is going to change. > >it doesn't support the interactive environment very well either if you get >larger. unix does not[...] an implementation problem more >than a design problem, but it's there. Can't really argue with this. > >>2. Unix does not support the traditional business computing environment well >> This means sequential I/O bound COBOL programs. Unix does not even have >> sequential I/O. It's random-access I/O is so fast that it is used to fake >> sequential I/O. But it does not fake it as fast as the real thing. So >> get an IBM computer if you want that (or look up a back issue of Computer >> Graphics to see how Tom Farrin made Unix support true sequential I/O). > >it's partly a function of hardware as well. tradition has it that all disk >blocks are 512 bytes.[...] lock on I/O because the filesystem >is private to each user. Don't forget that a 3380 is a WHOLE BUNCH faster that almost anything else around, (I mean as in ***WOW***!!!). In fact IBM has always (well at least since early S/360) been concerned about I/O bandwith, just for this reason. I mean who else has hardware such that their latest and greatest machine can run <some large number> 1401 emulators each running 50 times faster than the real thing, (can you see DEC supporting PDP-8 emulation on the 8600 so that people can run old PDP-8 accounting stuff?).
frodo@wcom.UUCP (James Scardelis) (11/17/85)
> it's partly a function of hardware as well. tradition has it that all disk > blocks are 512 bytes. this is fine on a smaller machine where there was > only 64K to work with, the CPU and memory are slow, and so was the disk. > you can make block sizes bigger, but still you have to live with hardware > that doesn't understand it. On System V, the physical block sizes are 1K. -- Jim Scardelis, SA {vax135,ihnp4}!wcom!frodo #include <favorite disclaimer>
campbell@sauron.UUCP (Mark Campbell) (11/25/85)
In article <942@wcom.UUCP> frodo@wcom.UUCP (James Scardelis) writes: > > On System V, the physical block sizes are 1K. Actually, System V doesn't define the physical block size of the system...that is a function of the hardware which System V is implemented upon. System V currently supports two logical block sizes: 512 and 1K. If the physical block size was 1K it would be difficult to efficiently support the 512 byte logical block size that is still supported (with FsTYPE = 3) in most versions of Unix System V. -- Mark Campbell Phone: (803)-791-6697 E-Mail: {decvax!mcnc, ihnp4!msdc}!ncsu!ncrcae!sauron!campbell
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/27/85)
In article <942@wcom.UUCP> frodo@wcom.UUCP (James Scardelis) writes: > On System V, the physical block sizes are 1K. Most releases of System V allow either 512 or 1024 or both LOGICAL block sizes on a per-file system basis. Physical block sizes are determined by hardware: usually 512, sometimes 128 or 256. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
herbie@polaris.UUCP (Herb Chong) (12/02/85)
In article <942@wcom.UUCP> frodo@wcom.UUCP (James Scardelis) writes: >> it's partly a function of hardware as well. tradition has it that all disk >> blocks are 512 bytes. this is fine on a smaller machine where there was >> only 64K to work with, the CPU and memory are slow, and so was the disk. >> you can make block sizes bigger, but still you have to live with hardware >> that doesn't understand it. > > On System V, the physical block sizes are 1K. as others have pointed out, my understanding of the VAX hardware is that the physical blocks for paging and stuff like that are 512 bytes. you can define larger LOGICAL blocks, but you still end up working with them as collections of units of 512 bytes. having larger logical blocks alone can improve system performance since you can make a bunch of I/O requests in a row. i don't know if disk controllers typically used with VAX hardware understand chained I/O commands as i know IBM 370 channels do. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa ======================================================================== DISCLAIMER: what you just read was produced by pouring lukewarm tea for 42 seconds onto 9 people chained to 6 Ouiji boards.
speaker@ttidcb.UUCP (Kenneth Speaker) (12/04/85)
In article <314@polaris.UUCP> herbie@polaris.UUCP (Herb Chong) writes: >In article <942@wcom.UUCP> frodo@wcom.UUCP (James Scardelis) writes: >larger LOGICAL blocks, but you still end up working with them as collections >of units of 512 bytes. having larger logical blocks alone can improve system >performance since you can make a bunch of I/O requests in a row. i don't know >if disk controllers typically used with VAX hardware understand chained >I/O commands as i know IBM 370 channels do. > > >Herb Chong... > Actually the Unibus and Massbus both have DMA mapping hardware. The system then sets up the map to "gather" (on output) or "scatter" (on input) the logically contiguous to physically dis-contiguous memory. On the VAXen I use with VMS, the cluster size used to write the paging file is 128 (512 byte) blocks, or 64K transfers. On output it can always do this. On page in, it depends upon how many of the blocks which are "near" one another on the page file can be utilized. If about half of the blocks in a cluster are needed, the other half can be mapped into the black hole, i.e., a single page reserved for that purpose. --Kne
rda@epistemi.UUCP (Robert Dale) (12/05/85)
In article <314@polaris.UUCP> herbie@polaris.UUCP (Herb Chong) writes: >In article <942@wcom.UUCP> frodo@wcom.UUCP (James Scardelis) writes: >>> it's partly a function of hardware as well. tradition has it that all disk >>> blocks are 512 bytes. >> On System V, the physical block sizes are 1K. > >as others have pointed out, my understanding of the VAX hardware is that the >physical blocks for paging and stuff like that are 512 bytes. AAAAAAAARGH! Look, PLEASE change the subject line if the topic of the message you're posting has moved away from what caused the posting in the first place: in the current instance, I'm sure I'm not alone in saying I found the "Unix from a snob's point of view" original postings interesting, but I'm NOT that interested in what the block size is on a UNIX machine. Sorry, but it's been one of those mornings ... Robert Dale ...!seismo!mcvax!ukc!cstvax!epistemi!rda