--------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00031 Date: 12/26/95 From: DARRELL BOWMAN Time: 11:30pm \/To: LAWRENCE GARVIN (Read 10 times) Subj: peristent internet connec //Just before the photon torpedoes from the Excalibur destroyed //his ship, LAWRENCE GARVIN bellowed about peristent internet connec: LG>It's called a leased line. :) DB> And they ain't cheap. LG>Depends. ISDN technology in Houston provides a 128K connection, with up to >512K throughput with hardware compression, at a monthly cost of about $55 >on a commercial tariff. LG>The hardware to make the connection can be had for under $3,000 both ends. My connection to the state network here, including rental on the router and DSU (I guess) is running about $750.00 a month for a 56K line. Excalibur Darrell Bowman Fidonet 1:3666/603 Internet bowmandl@smoky.dhr.state.nc.us darrell.bowman@f603.n3666.z1.fidonet.org * 1st 2.00 #6680 * AD&D Mistake #7: Taming a kill-crazed-mega-zombie. --- WILDMAIL!/WC v4.12 * Origin: High Tech Center BBS 21.6K USR/DST (1:3666/603.0) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00032 Date: 12/29/95 From: LAWRENCE GARVIN Time: 01:35pm \/To: JOHN POLTORAK (Read 10 times) Subj: Routers John Poltorak said in a message to Lawrence Garvin: JP>> I have both vol 1 & 2, but they are far too academic for me. I JP>> need something more practical. LG> Bad news, John. TCP/IP -is- academic. There's no easy way around it. :) JP> I would disagree. I got TCP/IP working *in spite of* Comer's JP> book. Working, definitely. I'm referring to UNDERSTANDING. :) JP> There is no real need to understand how it works to get it JP> working. No, but it sure will make it a hell of a lot easier when you have to troubleshoot it when it's NOT WORKING. JP> You don't need to know how a power station works to switch on a JP> light bulb! :-). But it does help to know where your circuit breaker box is when the CB trips. JP> I keep peeking at it every so often, and a few thing start JP> making sense, but only as a result of practical experience I JP> have acquired. Feel free to ask questions or initiate any discussions here that you would like. TCP/IP is as integral to Unix as vi is, and I'd be most willing to share my understanding with any who wish. I've finished through Chapter 13, and plan to finish the entire book by the end of the first week of January. (I'm on vacation -- I have an advantage >) And after some thought, I'm considering starting a TCPIP echo for the purpose of discussing anything/everything to do with the TCPIP protocols. Anybody have any thoughts? lawrence@garvin.hd.co.harris.tx.us --- * Origin: The Enchanted Forest | Houston, Texas (1:106/6018) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00033 Date: 12/29/95 From: LAWRENCE GARVIN Time: 01:39pm \/To: NEETI RAY (Read 10 times) Subj: X, Telenet, NFS, FTP Neeti Ray said in a message to Lawrence Garvin: NR> ftp.cdrom.com:/pub/SimTel/pub/msdos/nfs, check for NR> xfs??? or nfs-???. There's actually two different NR> shareware NFS clients available. Anyother SimTel mirror NR> will have it also. I've used xfs and it works quite well. NR> Kin Lau (gabe@io.org) Thanks Kin. I'll check it out! lawrence@garvin.hd.co.harris.tx.us --- * Origin: The Enchanted Forest | Houston, Texas (1:106/6018) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00034 Date: 12/29/95 From: LAWRENCE GARVIN Time: 01:59pm \/To: ALL (Read 10 times) Subj: Issues on Topic? Hello All! Just a reminder that this is the UNIX echo. I've been rather lenient with the OS comparisions, as long as they had something remotely to do with UNIX or comparisions to UNIX. But I guess I need to caution everybody about DOS vs Windows discusions that have nothing to do with UNIX. Let's keep it remotely on topic, please. :) lawrence@garvin.hd.co.harris.tx.us --- * Origin: The Enchanted Forest | Houston, Texas (1:106/6018) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00035 Date: 12/28/95 From: WILLIAM HAMBLEN Time: 09:04am \/To: BOB LIESENFELD (Read 10 times) Subj: Dirs Bob Liesenfeld, In a message on 26 December, wrote : BL> When I execute "cd /home/bob" I end up there OK. But if I am in BL> /home, and execute "cd /bob" I get an error message saying /bob is not BL> a directory. However, if I am in /home and I execute " cd \bob" I move BL> into the bob directory OK. What going on? "cd /bob" means change to the bob directory in the root ("/") directory. If you don't have a "bob" direectory in the root directory, you get an error message. "cd bob" means change to the bob directory in the current (".") directory. (The same as "cd ./bob".) A "\" is the shell escape character and if the character pair ("\b") isn't an escape sequence the shell recognizes, then the shell interprets it as being just the second character. The shell thinks "\bob" means the same as "bob". Bud ... * ATP/Linux 1.42 * The following tagline doesn't necessarily represent ... --- TSX-BBS (Multi-line 32-bit BBS) * Origin: The Nashville Exchange BBS 615-383-0727 (1:116/19) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00036 Date: 12/29/95 From: NEETI RAY Time: 12:47pm \/To: YOUSUF KHAN (Read 10 times) Subj: Linux Yousuf, YK>NR> Why are we stuck on GUI only for the future? Why YK>NR> would you need GUI for YK>NR> order-entry, reading email/news? If you drop the YK>NR> simple & *very efficient* YK>NR> text mode, the cost of *all* your terminals would skyrocket. Simple YK>NR> information exchange that can be done via a text YK>NR> interface on a *cheap* PC or YK>NR> dumb-term would now require an expensive machine. YK> YK>The GUI goes beyond just a prettier interface to do the exact same thing you YK>used to do. The GUI is an absolute stepping stone for the coming world of YK>object-oriented interface. That world came a long time ago. It's called NeXT. Do a search on GNUStep and see what you come up w/. YK>Here's an example, with today's e-mail systems, you don't have much beyond YK>text to worry about. But in the future, e-mail is drag'n'drop objects. Sound YK>files, movie clips, still pictures, all flowing forth automatically as you YK>read through the text -- because they are part of the text. Sounds like MIME and NeXTmail that exists *right now* on Unix systems. YK>With today's order-entry systems, you choose a part, figure out its part YK>number, and then you proceed to fill in its information on a generic order YK>entry screen; you may have to go to specialized screens depending on the part YK>you are describing. In the order-entry of the future, you choose a picture of YK>a part, which explodes into an order entry screen that is specific to that YK>part alone, no extraneous data entry, no switching back and forth between YK>specialized and generic screens for describing the same part. Can you tell the difference btwn a 3/8" nut and a 1/2" nut from a picture? I'd have a ridiculously hard time. If you'd ever done any order entry, you don't bother w/ descriptions, just part numbers. Catalogs are a different matter altogether, don't get them mixed up. YK>YK>With the DOS replacements, you've been able to YK>YK>achieve such things as OLE, YK>YK>SOM, etc. These are simplistically where entire YK>YK>applications are plugged YK>NR> into YK>YK>each other to create a bigger application. This sort YK>NR> of thing was difficult YK>NR> in YK>YK>DOS, and it is difficult in Unix. The DOS YK>YK>replacements have revolutionarilly YK>YK>step above DOS, but Unix has never had a revolution. YK> YK>NR> DOS *needed* a revolution... it's still stuck w/ YK>NR> 640k limits in a 16bit YK>NR> world. The only revolution/evolution Unix needs is more market/system YK>NR> compatibility. Dos, in trying to grow up, is looking more and more like YK>NR> Unix... witness OS/2 and WinNT. YK> YK>You miss the point entirely, the revolution in the DOS world isn't the YK>banishment of the 640K limit, nor the 32MB limit, nor the 540MB limit nor YK>whatever other limit you care to think about. The revolution is the move YK>towards object-orientation in every respect, from the programming code, to the YK>user interface, and everything else in between. YK>DOS already looked like Unix, that's exactly what they are trying to move away YK>from. They are moving away from the command-line, they are moving away rom YK>the piping, the redirecting, the inputting, and the outputting. YK> YK>In the end, nobody could care less if an operating system is 16-bit, 32-bit, YK>or whatever. Nobody could care less if operating system A can access more YK>memory than operating system B. Nobody could care less if operating system A YK>had paging but operating system B didn't. In the end, the only thing that YK>matters is how useable that operating system is. You confuse arcane technical YK>details with being the road to progress. All cars have steering wheels and accelerator pedals. The _guts_ of the machine dictates what it's good for. People *do* care what OS they're using when it has an effect. Don't confuse a *user* interface w/ the OS. The greatest thing about Unix is the ability to change personalities. You can have CLI's or GUI's, clients and servers all on the same machine(s). YK>The revolution that the DOS world is undergoing is barely even underway in the YK>Unix world -- objects. Read my first line...been there... done that. Kin Lau (gabe@io.org) --- * UniQWK v3.3a* The Windows Mail Reader --- QScan/PCB v1.17b / 01-0348 * Origin: FidoNet: CRS Online, Toronto, Ontario (1:229/15) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00037 Date: 12/29/95 From: NEETI RAY Time: 01:01pm \/To: RICHARD VOUT (Read 10 times) Subj: GNU Tar Richard, RV>-=> Quoting Neeti Ray to Yousuf Khan <=- RV> RV>What is tar short for or stand for? _T_ape _AR_chive(r). Kin Lau (gabe@io.org) --- * UniQWK v3.3a* The Windows Mail Reader --- QScan/PCB v1.17b / 01-0348 * Origin: FidoNet: CRS Online, Toronto, Ontario (1:229/15) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00038 Date: 12/29/95 From: NEETI RAY Time: 01:22pm \/To: LAWRENCE GARVIN (Read 10 times) Subj: Linux Lawrence, LG>Yousuf Khan said in a message to Lawrence Garvin: LG> LG>YK> There likely were people in there from the Xenix and OS/2 days, LG>YK> but the majority of it was headed up by Dave Cutler, an ex-DEC LG>YK> employee who had designed the VMS operating system for VAXes. LG>YK> It's an all new design probably owing more to VMS than to Unix; LG>YK> but even that's probably stretching it. LG> LG>Thanks for the gossip. I wasn't up to speed on that particular microbit. Never knew that WNT is just one letter off from VMS? W/ the same papa and all, this became folklore a long time ago, ranks right up there w/ the HAL & IBM thing. Kin Lau (gabe@io.org) --- * UniQWK v3.3a* The Solution for Multilingual Messages --- QScan/PCB v1.17b / 01-0348 * Origin: FidoNet: CRS Online, Toronto, Ontario (1:229/15) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00039 Date: 12/29/95 From: NEETI RAY Time: 02:04pm \/To: YOUSUF KHAN (Read 10 times) Subj: Linux Yousuf, YK>JP> Friday December 22 1995, Yousuf Khan writes to John Poltorak: YK> YK>.P>> I'm not getting drawn into a debate about Windows, but YK>.P>> will just say that you won't get very far trying to use YK>.P>> Windows if you delete DOS. And that even goes for Win95. YK> YK>YK> No, but similarly you won't get very far if you try to run Windows YK>YK> programs if you delete Windows. YK> YK>JP> This seems a little obvious. I'm not sure what the point is... YK> YK>To spell it out for you, your point was that Windows is not an OS, but DOS is. YK>My point is that Windows is very definitely an OS distinct from DOS because it YK>has its own set of apps that cannot operate on DOS alone. Windows is an OS YK>that is a superset of the DOS OS, but different nonetheless. Whether the YK>operating system builds itself around another previous operating system or if YK>it builds everything from scratch they are both valid operating systems. Hmm... that should qualify EMACs as an OS as well then :). Then again, many consider Dos to be a glorified bootloader. Windows, ie everything up to Win95 but not NT, is not an OS because it *has* to run as a Dos _process_. It's simply a very bloated OS addon, I still need my Dos drivers running under Dos so that Windows can see and use it. Windows is essentially a Dos application, just like WP, Lotus123 etc... This line is significantly blurred w/ Win95 where the difference btwn the Dos and Win portion is not very clear. As far as a comparison w/ the Unix world is concerned, think of the Motif API. It's more than just a look and feel, but in many ways is similar to MS-Win itself. Under Unix, you can build Motif as a shared lib and all your Motif apps will run just fine, or build them statically (think Netscape). MS-Win is like the Motif shared lib, just an API. If and when someone comes up w/ the Win API ported to Unix, you could take a MS-Win app and link it statically w/ the lib and it'll run on the appropriate Unix system. This is essentially how WINE (will) works, as a MS-Win api emulator. Kin Lau (gabe@io.org) --- * UniQWK v3.3a* The Windows Mail Reader --- QScan/PCB v1.17b / 01-0348 * Origin: FidoNet: CRS Online, Toronto, Ontario (1:229/15) --------------- FIDO MESSAGE AREA==> TOPIC: 176 UNIX Ref: CGZ00040 Date: 12/29/95 From: THOMAS MCWILLIAMS Time: 03:21pm \/To: JOHN POLTORAK (Read 10 times) Subj: OS/2 homomorphic to Unix John Poltorak, In a message on 13 December, to Yousuf Khan, wrote: > OS/2 has very little in common with DOS as far as the OS is concerned, > even though it may use the same commands. It is very much more like > Unix than DOS and has similar sophisticated multi-tasking and memory > management features. The essential difference between Unix and OS/2 is > that Unix is intrinsically multi-user and OS/2 is single-user. This is an astute and very insightful observation. The OS/2 kernel is extremely unix-like in structure and function. It is obvious that the designers of OS/2 were very familiar with the design of Unix, and they chose a unix-like structure upon which to implement OS/2. For evidence one may look at the fascinating book "The Design of OS/2" by H.M. Deitel and M.S. Kogan. Contrast it with Maurice Bach's classic "Design of the Unix Operating System". Under both Unix and OS/2 processes invoke kernel services by transitioning from user mode to kernel mode. In order to maintain integrity of global kernel data structures between multiple processes, neither classic Unix nor OS/2 kernels are preemptible when running in kernel mode. A context switch can only occur if the process in kernel mode is sleeping or blocked, or when transitioning back to user mode. So similar is the structure and operation of the classic Unix and OS/2 kernels that Deitel and Kogan apparently copied the OS/2 kernel process state transition diagrams directly and *verbatim* from Bach's "Design of the Unix Operating System". Those with access to these books should contrast the diagram of page 128 of Dietel and Kogan with that on page 31 of Bach. The function and structure of the kernels are so similar that an individual capable of observing the process flow and state transitions of either the OS/2 or Unix kernels would be hard pressed to note much difference. OS/2 can be thought of as a single user version of Unix without ownership and ownership permissions. OS/2 borrowed many features from Unix such as pipes, System V IPC, and hierarchically structured file systems. Obviously there is more to an operating system than the kernel. System calls, utilities, and file systems are are all part of the larger picture of what exactly constitutes an operating system. MSDOS and VMS influenced OS/2 is several areas such as utilities, executable formats, file naming conventions, and so on. Indeed, OS/2 was designed to be a successor to MSDOS and to run MSDOS programs. But at the kernel level we can confidently conclude that OS/2 is homomorphic to Unix. The designers of OS/2 chose the Unix kernel as guiding model upon which to implement OS/2. The relationship between the OS/2 kernel and Unix kernel designs is certainly stronger than the relationship of either one to VMS, NT, or MSDOS (note: at the *kernel* level). As a side note, the lack of support for preempting a process in the run state in kernel mode under OS/2 (see page 102 of Deitel) implies OS/2 marketing claims of being fully "multi-threaded" are somewhat exaggerated (to put it charitably). It also explains why SMP OS/2 has not appeared as of yet, in so much as SMP falls fairly cleanly out of fully preemptible kernel designs. For those interested in doing the design comparisons themselves, here is some bibliographic information: H.M. Deitel and M.S Kogan, "The Design of OS/2", Addison-Wesley, ISBN 0-201-54889-5 Maurice Bach, "The Design of the UNIX Operating System", Prentice-Hall, ISBN 0-13-201799-7 --- Maximus/2 3.00 * Origin: Enlightened Board (703) 370-9528 (1:109/615)