Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!sdd.hp.com! news.cs.indiana.edu!tpbbs!charon.bloomington.in.us!sgberg From: sgb...@charon.bloomington.in.us (Stefan G. Berg) Newsgroups: comp.os.linux Subject: linux a real unix? Message-ID: <sgberg.27o4@charon.bloomington.in.us> Date: 24 Apr 93 22:41:10 EST Reply-To: sgb...@charon.bloomington.in.us (Stefan Berg) Distribution: world Organization: Not an Organization X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith Lines: 21 Don't take the subject line too seriously... :-) I was just wondering how linux compares to the commercial Unix systems you find in Sun's, HP's, etc... Reading all these postings about "ported blabla to linux", it seems that linux does not yet do too good in terms of compatibility. And how about in terms of efficiency? Seems that linux runs in very little memory, so it does seem to be more memory efficient than those commercial unix's, but how about speed? I would just like to hear a few comparing notes between these two rather different implementations (one costing thousands of $'s and the other one being free). Stefan -- ,-------------------------------------------------------, |Usenet sgb...@charon.bloomington.in.us Stefan G. Berg| |Internet sgb...@ucs.indiana.edu // AMIGA | |Bitnet sgberg@iubacs GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------'
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net! howland.reston.ans.net!usc!cs.utexas.edu!rutgers!igor.rutgers.edu! geneva.rutgers.edu!hedrick From: hedr...@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.os.linux Subject: Re: linux a real unix? Message-ID: <Apr.25.13.32.25.1993.4924@geneva.rutgers.edu> Date: 25 Apr 93 17:32:27 GMT References: <sgberg.27o4@charon.bloomington.in.us> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 82 sgb...@charon.bloomington.in.us (Stefan G. Berg) writes: >I was just wondering how linux compares to the commercial Unix systems >you find in Sun's, HP's, etc... Reading all these postings about "ported >blabla to linux", it seems that linux does not yet do too good in terms >of compatibility. And how about in terms of efficiency? Seems that linux >runs in very little memory, so it does seem to be more memory efficient >than those commercial unix's, but how about speed? At this point I think Linux is about as "compatible" as most of the commercial Unices. Porting depends upon the nature of the package. For simple software that sticks to ANSI C, you may not have to do anything. For more complex things, typically there's a configuration file or header file that defines the combination of features appropriate for each variant of Unix. So if nobody has built it for Linux yet, you've got to set that up. At this point Linux has a fairly good libc. The primary problems at the moment are in areas outside what I'd call the central core of Unix features: shared memory, IPC, etc. There's code for System V versions of that, but based on postings here it's not clear how stable it is. The few benchmarks that have been posted suggest that basic Unix facilities, e.g. fork and exec, are comparatively fast under Linux. I/O is going to depend upon which type of controller you use and which file system. There are a few commercial versions of Unix designed for use in server environments. They have been tuned to support multiple processors, intelligent disk controllers, etc. Linux can't provide competition in that area. For a typical system with an IDE disk, I think it does fine, and it sounds like with certain SCSI controllers it's OK as well (but I'm not up to date on SCSI support). I have a 486/33 with one IDE disk and a generic ET4000 SVGA controller. Until recently I had a Sun IPC on my desk at Rutgers, with two SCSI disks. I found that the overall "feel" was fairly similar. Certainly text scrolling in xterm was faster on the Sun (because it has hardware bitblt, and the ET4000 doesn't). Presumably use of an intelligent SVGA card (e.g. S3) would fix that. (I have compared detailed X benchmarks. The ET4000 actually does pretty well against the IPC until you get to things that involve working with areas. That's where intelligent display hardware helps. For my normal usage -- which is primarily with text -- scrolling is the main place where I see a difference. I have to say that I find the slow scrolling with an ET4000 annoying.) I also have the feeling that doing a compile in one window has a bit less impact on response in other windows on the Sun. This would make me suspicious of what would happen if you put a lot of people on a Linux system. The SLS distribution seems to include most of the standard free software that we make available to people on our Suns. But we've spent a fair amount of time collecting that software and setting it up for distribution on campus. A full SLS distribution would make a lot more interesting system than a Sun as it comes "out of the box". (In case you wonder about the past tense -- currently I have a SparcClassic. It is noticably faster than a 486/33, which should not be surprising given some basic information about the processors. It's possible that a 486/66 would be comparable.) I have to say that my experience with commercial Unix on Intel has not been encouraging. I had Microport SVr2 on a 286 for a couple of years. Linux is infinitely better, in features, reliability, and support. I've also used ATT's SVr4, but not enough that I want to comment on it in detail. Note that I haven't used any of the high-end Unix ports, e.g. SCO, Destiny, or Solaris. They would be more likely to have advantages over Linux for commercial users, though not necessarily for most of the current Linux user base. I think it's important not to oversell Linux, or people may be disappointed. I think it's a great system for home use, both for faculty and students. It has most of the the Unix software I use on Suns at Rutgers, and it performs very well. I know there are places that use it for commercial work successfully. I think if I had a small company and wanted to support somebody on the console and a couple of terminals, and I was developing my own software (i.e. I didn't need commercial database packages, etc.) I might consider it. But it's not the system I'd choose to support 50 timesharing users (we do have Suns used that way), nor is it one I'd use for our university-wide administrative database system. I don't see any reason to be apologetic about its capabilities. It does just as well as a delivery vehicle for software from the university/research community as commercial Unices do as delivery vehicles for commercial applications. Not everybody in the world wants to run TeX, Common Lisp, Interviews, etc. But enough do to provide a continuing place for Linux or similar systems.
Newsgroups: comp.os.linux Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!mv! jeck!smoke.marlboro.vt.us!jhood From: jh...@smoke.marlboro.vt.us (John Hood) Subject: Re: linux a real unix? References: <sgberg.27o4@charon.bloomington.in.us> Organization: Domestic Vorpal Bunny Breeder's Association Date: Mon, 26 Apr 1993 06:16:29 GMT Message-ID: <1993Apr26.061629.28118@smoke.marlboro.vt.us> Lines: 38 In article <sgberg.2...@charon.bloomington.in.us> sgb...@charon.bloomington.in.us (Stefan Berg) writes: >Don't take the subject line too seriously... :-) > >I was just wondering how linux compares to the commercial Unix systems >you find in Sun's, HP's, etc... Reading all these postings about "ported >blabla to linux", it seems that linux does not yet do too good in terms >of compatibility. And how about in terms of efficiency? Seems that linux >runs in very little memory, so it does seem to be more memory efficient >than those commercial unix's, but how about speed? In terms of porting stuff to Linux, it's fairly easy. No Unix system can be perfect in this regard, and Linux is about as good as any. In terms of features, Linux does well for a single-user system. It lacks a lot of features that make administration easier on multi-user or networked systems. Fine by me, so far. In terms of bugs, well, I've had a rough three weeks. (sigh) I moved all my stuff from a rock-solid, stone-age Xenix/386 system, and had a couple of weeks of tearing hair out because of things that couldn't be configured correctly, frequent kernel panics and various things getting minorly trashed. However, all those bugs are fixed now, and I just get the occasional dying process or file-system hiccup now. So, it's definitely not as stable as most of the commercial unices, but it's definitely usable. Linux has several problems and design limitations that make it a Bad Idea for a system with high or variable load just now, including a rather low limit on the number of open files and VM unfriendliness when your system starts running low on memory. I don't suggest it for more than, say, two or three simultaneous users. But it's great as a workstation-type system. --jh -- John Hood Cthulhu-- just imagine it! jh...@smoke.marlboro.vt.us
Newsgroups: comp.os.linux Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!doc.ic.ac.uk! uknet!cf-cm!cybaswan!iiitac From: iii...@swan.pyr (Alan Cox) Subject: Re: linux a real unix? Message-ID: <1993Apr26.173758.3666@swan.pyr> Organization: Swansea University College References: <sgberg.27o4@charon.bloomington.in.us> <1993Apr26.061629.28118@smoke.marlboro.vt.us> Date: Mon, 26 Apr 1993 17:37:58 GMT Lines: 28 In article <1993Apr26.061629.28...@smoke.marlboro.vt.us> jh...@smoke.marlboro.vt.us (John Hood) writes: > >In terms of bugs, well, I've had a rough three weeks. (sigh) I moved >all my stuff from a rock-solid, stone-age Xenix/386 system, and had a >couple of weeks of tearing hair out because of things that couldn't be >configured correctly, frequent kernel panics and various things >getting minorly trashed. However, all those bugs are fixed now, and I >just get the occasional dying process or file-system hiccup now. So, >it's definitely not as stable as most of the commercial unices, but >it's definitely usable. I've had no problems with a fairly heavily loaded non tcp/ip system, and minor hiccups (a reboot every 3 days or so) with a very loaded tcp/ip based system, as well as the odd annoying tcp/ip connection hanging > >Linux has several problems and design limitations that make it a Bad >Idea for a system with high or variable load just now, including a >rather low limit on the number of open files and VM unfriendliness Well it copes with 8 users in 4Mb of RAM ok. The number of open files is configurable and upping that solves that little problem. The VM unfriendliness is best dealt with using rlimit. I keep meaing to fix the system so that it never overcommits on memory, and ensures that the maximum it could be asked for is something like Swap + Physical - 128K Alan
Newsgroups: comp.os.linux Path: gmd.de!ira.uka.de!math.fu-berlin.de!unidui!easix!exnet2!exnet! dcs.ed.ac.uk!sct From: s...@dcs.ed.ac.uk (Stephen Tweedie) Subject: Re: linux a real unix? In-Reply-To: hedrick@geneva.rutgers.edu's message of 25 Apr 93 17:32:27 GMT Message-ID: <SCT.93Apr26181444@ascrib.dcs.ed.ac.uk> Sender: cn...@dcs.ed.ac.uk (UseNet News Admin) Organization: University of Edinburgh Dept. of Computer Science, Scotland References: <sgberg.27o4@charon.bloomington.in.us> <Apr.25.13.32.25.1993.4924@geneva.rutgers.edu> Date: Mon, 26 Apr 1993 18:14:44 GMT Lines: 58 In article <Apr.25.13.32.25.1993.4...@geneva.rutgers.edu>, hedr...@geneva.rutgers.edu (Charles Hedrick) writes: > At this point I think Linux is about as "compatible" as most of the > commercial Unices. ... The primary problems at the moment are in > areas outside what I'd call the central core of Unix features: > shared memory, IPC, etc. There's code for System V versions of > that, but based on postings here it's not clear how stable it is. The latest version does seem to be reliable; in fact, I would hope that it becomes a standard kernel feature soon. > I have to say that I find the slow scrolling with an ET4000 > annoying. Granted. > I also have the feeling that doing a compile in one window has a bit > less impact on response in other windows on the Sun. I have generally had the opposite experience, except for one thing - because (as you have already mentioned) X is a bit slower on Linux/ET4000 than on a Sun ELC, it gets disproportionately affected by heavy load. If you are running in text mode, Linux is *amazingly* responsive even while running a couple of parallel compilations. It is not the kernel but the speed of X which causes the apparent degradation in response when running X under load. > This would make me suspicious of what would happen if you put a lot > of people on a Linux system. A bigger concern would be the compile-time limits on the number of open files/inodes and the tasks limit in the kernel. > currently I have a SparcClassic. It is noticably faster than a > 486/33, which should not be surprising given some basic information > about the processors. It's possible that a 486/66 would be > comparable. Well, on compute-bound *integer* tasks, (the 486's fp performance is pretty poor,) my 486DX/33 runs my simulations faster than a SparcStation 1+, a SparcStation 2, a Sparc ELC or a SparcServer 10. I've done controlled, timed tests to do proper comparisons. > I think it's important not to oversell Linux, or people may be > disappointed. I think it's a great system for home use, both for > faculty and students. Indeed. People just have to realise that it is still developing - and rapidly. The installation and maintainence is pretty easy for a single user, but configuring X and setting up a network is *not* for the faint of heart. It is not desparately tricky, but you may need to be persistant. Cheers, Stephen Tweedie. --- Stephen Tweedie <s...@uk.ac.ed.dcs> (Internet: <s...@dcs.ed.ac.uk>) Department of Computer Science, Edinburgh University, Scotland.
Newsgroups: comp.os.linux Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!mv! jeck!smoke.marlboro.vt.us!jhood From: jh...@smoke.marlboro.vt.us (John Hood) Subject: Re: linux a real unix? References: <sgberg.27o4@charon.bloomington.in.us> <1993Apr26.061629.28118@smoke.marlboro.vt.us> <1993Apr26.173758.3666@swan.pyr> Organization: Domestic Vorpal Bunny Breeder's Association Date: Tue, 27 Apr 1993 05:24:11 GMT Message-ID: <1993Apr27.052411.637@smoke.marlboro.vt.us> Lines: 41 In article <1993Apr26.173758.3...@swan.pyr> iii...@swan.pyr (Alan Cox) writes: >In article <1993Apr26.061629.28...@smoke.marlboro.vt.us> jh...@smoke.marlboro.vt.us (John Hood) writes: >>... So, >>it's definitely not as stable as most of the commercial unices, but >>it's definitely usable. > >I've had no problems with a fairly heavily loaded non tcp/ip system, and >minor hiccups (a reboot every 3 days or so) with a very loaded tcp/ip >based system, as well as the odd annoying tcp/ip connection hanging >> >>Linux has several problems and design limitations that make it a Bad >>Idea for a system with high or variable load just now, including a >>rather low limit on the number of open files and VM unfriendliness > >Well it copes with 8 users in 4Mb of RAM ok. The number of open files >is configurable and upping that solves that little problem. The VM What are those 8 users *doing*? Using a BBS? Compiling X11r5? Big difference between the two :) Lurking just behind the open files limit is a limit on the number of open *inodes*, and that can't be pushed beyond 2^8 just now. 256 open files is not many for a Unix system. I really should have said "implementation limitations" rather than "design limitations." >unfriendliness is best dealt with using rlimit. I keep meaing to fix >the system so that it never overcommits on memory, and ensures that the >maximum it could be asked for is something like Swap + Physical - 128K The couple of times I've had my system go wedge itself, nothing larger than a kernel compile has been running. That was annoyingly large on a 4M system, but there was 16M of swap behind it. --jh -- John Hood Cthulhu-- just imagine it! jh...@smoke.marlboro.vt.us
Newsgroups: comp.os.linux Path: gmd.de!Germany.EU.net!mcsun!news.funet.fi!hydra!klaava!torvalds From: torva...@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: linux a real unix? Message-ID: <1993Apr27.120149.21183@klaava.Helsinki.FI> Organization: University of Helsinki References: <1993Apr26.061629.28118@smoke.marlboro.vt.us> <1993Apr26.173758.3666@swan.pyr> <1993Apr27.052411.637@smoke.marlboro.vt.us> Date: Tue, 27 Apr 1993 12:01:49 GMT Lines: 41 In article <1993Apr27.052411....@smoke.marlboro.vt.us> jh...@smoke.marlboro.vt.us (John Hood) writes: > >Lurking just behind the open files limit is a limit on the number of >open *inodes*, and that can't be pushed beyond 2^8 just now. 256 open >files is not many for a Unix system. Actually, there is no such limit at all. There is a implementation limit of 256 open files *per process*, but that should be no problem at all: most "real" unixes have the same (or even worse) limit. The main reason for the per-process open file limit is (a) the fd_set structure and (b) the fact that the task-structure gets hairy if you want truly dynamic nr of open files/process. As to the number of open files on a system-wide scale: no problem - just up NR_INODE to 1024 and NR_FILE to 768, and you shouldn't have any problem with that for quite a while. I already have patches that make this dynamic, but I'm worried about races, so I haven't actually used them yet. >I really should have said "implementation limitations" rather than >"design limitations." The reason for the small number of inodes in the default configuration of linux is two-fold: (a) it helps on machines with only 2MB of memory, and (b) the 'iget()' function is a piece of cr*p, and I haven't got around to code it more efficiently. I should add hashing to the inode structures, but right now it uses a simple linear search, and it's noticeable if you have 1024 inodes. This is another thing to be fixed with the dynamic code, but I just haven't got around to it. >The couple of times I've had my system go wedge itself, nothing larger >than a kernel compile has been running. That was annoyingly large on >a 4M system, but there was 16M of swap behind it. Sounds like a driver (or possibly hardware) problem. Hmm. It should work fine - every once in a while I limit my memory to 4MB and start up X11 + olvwm + a kernel compile just to check that the memory management works after any changes. It gets slow as molasses, but it shouldn't wedge. Linus
Newsgroups: comp.os.linux Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!howland.reston.ans.net! torn!nott!bnrgate!bnr.co.uk!uknet!cf-cm!cybaswan!iiitac From: iii...@swan.pyr (Alan Cox) Subject: Re: linux a real unix? Message-ID: <1993Apr28.083717.4010@swan.pyr> Organization: Swansea University College References: <1993Apr26.061629.28118@smoke.marlboro.vt.us> <1993Apr26.173758.3666@swan.pyr> <1993Apr27.052411.637@smoke.marlboro.vt.us> Date: Wed, 28 Apr 1993 08:37:17 GMT Lines: 28 To quote our machine:- 2:56pm up 9:20, 11 users, load average: 0.56, 0.48, 0.30 User tty login@ idle JCPU PCPU what zaphod ttys0 2:17pm 29 17 rlogin sunacm zaphod ttys3 1:29pm 1 19 17 (mw) anarchy ttys1 2:13pm 47 w luggy ttyp0 2:24pm 54 20 /usr/games/lib/nethackdir/nethac belgrat ttyp1 1:47pm 1:33 25 /usr/games/lib/nethackdir/nethac arthur ttyp2 1:50pm 1 arthur ttyp3 2:33pm 1 24 5 (csh) romana ttyp4 2:55pm 5 4 (mw) mimas ttyp5 2:40pm 2 12 (write) dick ttyp6 2:44pm 12 3 mw bbs ttyp7 2:47pm 9 (mw) It takes a couple of things - a reboot a day to clear hung sockets, which slowly take up file slots and a sensible rlimit. Getting decent performance also includes using a smaller shell than bash (vomit). If we had a small C compiler then then world would be a happy place indeed. As it is its down to software choice. GCC isnt the most computer friendly compiler on planet earth. Once the socket stuff is fixed properly the daily reboot should become unneccessary too. Alan