pgd@bbt.se (P.Garbha) (06/09/90)
In article <4664@minyos.xx.rmit.oz> s892024@minyos.xx.rmit.oz (Richard Muirden) writes: >In article <300007@hpspcoi.HP.COM>, darko@hpspcoi.HP.COM (David Arko) writes: >> >> Yes, It does seem that SCO Unix 3.2.0 has a bug with 'w' and 'uptime'. >> Maybe it will be fixed in 3.2.2 > >And under Xenix 286 2.3.2 "w" used to give me a seek error but uptime >worked just fine. I have yet to test this under the new version of >Xenix I have for the 386 (2.3.2). > And under Xenix 386 2.3.1 "ps" used to give me seek error (until i made a binary patch to the program), but "w" and "uptime" works allright. Another case is fsck, which just silently dies when trying to check my system disk. No error message, no nothing. This only makes me wonder what kind of programmers SCO are keeping. Obviosly they cannot produce working code, and in addition manages to screw up those programs which happend to be working before they got their hands on them.
wht@n4hgf.uucp (Warren Tucker) (06/11/90)
In article <1990Jun9.135124.16301@bbt.se> pgd@bbt.se (P.Garbha) writes: >This only makes me wonder what kind of programmers SCO are keeping. >Obviosly they cannot produce working code, and in addition manages to >screw up those programs which happend to be working before they got >their hands on them. Obviously, you have little or no experience in producing large software systems :-) :-/. I would leave that as enough said, since those who have had such experience would understand the one liner. However, for you I will elaborate: Since your kernel came up and you created users and loged on, a great deal must be right. In fact, the w and uptime programs are minor, minor problems compared with those persisting with many other systems in the world, from UNIX 386 implementations to multi-million dollar systems. As for fsck, bleat all you want, but you can get around the rare root partition fsck wont handle at startup by answering the Root file system [has problems] fix? with no. Go to single user state. Do a fsck -rr /dev/root and it will do the work. You may or may not have to reboot when fsck terminates. Conversation appreciated, flame > /dev/null. --------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht%n4hgf@gatech.edu Any perceptible delay will eventually get on your nerves. --Bob Hyers
daveh@marob.masa.com (Dave Hammond) (06/11/90)
In article <1990Jun9.135124.16301@bbt.se> pgd@bbt.se (P.Garbha) writes: > >And under Xenix 386 2.3.1 "ps" used to give me seek error (until i >made a binary patch to the program), but "w" and "uptime" works >allright. Another case is fsck, which just silently dies when trying >to check my system disk. No error message, no nothing. > >This only makes me wonder what kind of programmers SCO are keeping. >Obviosly they cannot produce working code, and in addition manages to >screw up those programs which happend to be working before they got >their hands on them. Whoa there, bud. I am not a SCO-vangelist, however I respect a reasonably competant product. I have made my living managing/programming Unix on Intel machines for over 5 years. I have run SCO on hardware ranging from Everex parts stuffed into a no-name box to brand-name machines from Compaq, HP and IBM. I have also run ISC ix/386, Venturcom Venix, IBM Xenix, Altos Xenix, Tandy Xenix and MWC Coherent, all on Intel machines. They all have problems, some worse than others. For production environments I still recommend and install SCO. Before you go maligning the SCO staff, check out your hardware for components which are not supported or kernel configuration limits which are obviously exceeded. -- Dave Hammond daveh@marob.masa.com uunet!masa.com!marob!daveh Flames to me (screw /dev/null, I can take the heat :-)
jeffl@comix.UUCP (Jeff Liebermann) (06/11/90)
In article <715@n4hgf.uucp>, wht@n4hgf.uucp (Warren Tucker) writes: > In article <1990Jun9.135124.16301@bbt.se> pgd@bbt.se (P.Garbha) writes: > >This only makes me wonder what kind of programmers SCO are keeping. > >Obviosly they cannot produce working code, and in addition manages to > > As for fsck, bleat all you want, but you can get around the rare root > partition fsck wont handle at startup by answering the Partial extract from sosco!~/SLS/info file. List of SCO Support Level Supplement files available for transfer using UUCP xnx120.Z 29488 ps seek Supplement xnx120.ltr 1164 version 2.3.0 - 2.3.1 n386 xnx124.Z 25598 fsck Supplement xnx124.ltr 1422 version 2.3.0 - 2.3.3 386AT xnx126.Z 20040 Delayed Boot xnx126.ltr 1191 version 2.3.1 386AT xnx129b.Z 540291 386 UUCP binaries, rev. B xnx129b.ltr 4915 version 2.3.0 - 2.3.2 n386 I believe one or more of these will solve some of the complaints. At this time, there seem to be no fixes for w or uptime. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # (408)336-2558 voice (408)429-0483 digital pager CIS:73557,2074 # PC REPAIR & RF DESIGN. uunet!comix!jeffl pyramid!vdx!comix!jeffl # universe!milky_way!solar_system!earth!na!us!uunet!comix!jeffl
pgd@bbt.se (P.Garbha) (06/11/90)
In article <715@n4hgf.uucp> wht@n4hgf.UUCP (Warren Tucker) writes: >Obviously, you have little or no experience in producing large >software systems :-) :-/. I would leave that as enough said, since >those who have had such experience would understand the one liner. >However, for you I will elaborate: Since your kernel came up and >you created users and loged on, a great deal must be right. In fact, >the w and uptime programs are minor, minor problems compared with >those persisting with many other systems in the world, from UNIX 386 >implementations to multi-million dollar systems. In fact i DO have quite some experiences of computer programming. Probably not as much as you though, since i only had been working with computers for 15 years. :-) Besides i complained about the "ps" program, not w and uptime. Someone else was complaining about w and uptime. ps is quite important if you have 20 incoming lines and you are system manager for that system. "I would leave that as enough said, since those who have had such experience would understand the one liner." :-) I have not seen the source code for the xenix ps, but i have seen the binary code. The program sometimes used to say "seek error", when running it. (It was ALWAYS saying seek error on an emacs-process) The fix was to remove the error check after a lseek(). After that it works. After a lseek() you expect something like: if (lseek(....) == -1) error("Seek Error"); But instead i found some kind of dibbling with the low byte of the returned value. > >As for fsck, bleat all you want, but you can get around the rare root >partition fsck wont handle at startup by answering the > Root file system [has problems] fix? >with no. Go to single user state. Do a fsck -rr /dev/root >and it will do the work. You may or may not have to reboot >when fsck terminates. I am sorry if i said that it was on the root partition fsck failed. It is not. It is on another partition. The program dies after 15 seconds without any message, except for the "***** checking blocks and sizes ****" message. Now, fsck is not an essential program either, since the system runs without it (if you patch away the "dirty" bit in your "rc" file). But i would for sure appreciate to have it working. This way we can aliminate 90% of the programs of unix as "not essential", and therefore they need not to be working. "We have more important things to fix than non-essential programs" :-) ps. i am soon moving from Xenix 2.3.1 to 2.3.2, hoping that it is working better.
pgd@bbt.se (P.Garbha) (06/11/90)
In article <2672BA95.6696@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes: > >Whoa there, bud. I am not a SCO-vangelist, however I respect a >reasonably competant product. > >I have made my living managing/programming Unix on Intel machines for >over 5 years. I have run SCO on hardware ranging from Everex parts >stuffed into a no-name box to brand-name machines from Compaq, HP and >IBM. I have also run ISC ix/386, Venturcom Venix, IBM Xenix, Altos >Xenix, Tandy Xenix and MWC Coherent, all on Intel machines. They all >have problems, some worse than others. For production environments I >still recommend and install SCO. > >Before you go maligning the SCO staff, check out your hardware for >components which are not supported or kernel configuration limits which >are obviously exceeded. > I really love that phrase "check out your hardware for components which are not SUPPORTED". It is a good "catch-it-all" for problems. "Of course it is not working, because you use the Y-brand component, and on page 736 of the installation manual, at bottom of the page, we clearly state that only X-brand components are supported" :-) Considering the big noice about the com.unix.sco newsgroup, and the comments i got on my text, i do think that there are quite some SCO-vangelists here. It is obviously a hot issue. To SCO or not to SCO -- that is the question. :-) Still, many programs (which are working on other unix-systems) have bugs introduced on Xenix. For example, the c-compiler cannot compile a bigger program without giving a "compiler bug" or two (i have switched to gcc). sdb sometimes crashes on programs, sometimes give error messages. Some working programs does NOT work when compiled with gcc and libc. Some of the buggy essential programs are: getty, login, fsck, ps. Of programming tools: cc, sdb, make, sh I cannot remember all the programs i have found bugs in, it is so common. The kernel works quite nicely, though, so by replacing all programs with the GNU (or BSD) equivalents, you get quite a nice operating environment. (Oh, i forgot the buggy serial port driver... But i don't use that one either.) An its non-compability...... Anyone who have taken a few programs from the net knows that only very small programs work without being patched. Has anyone tried to port smail 3.1? Good luck! Hint: don't try it with cc, and use the -lmalloc switch, and it works somehow. Actually, don't try any bigger program without gcc and gdb. If you think that it is resonable that getty, login, fsck, ps, cc, sdb, make, sh, vpix, (and others) does not work properly, vote YEA for sco, if you think not, vote NJET for sco. It would be interesting to know what experiences others have of other-brand unix-type operating systems. Can it possibly be the fact that all PC- operating systems are not properly working? (When is the GNU-kernel coming. I am missing it so much)
rogerk@sco.COM (Roger Knopf 5502) (06/12/90)
In article <1990Jun11.071618.209@bbt.se> pgd@bbt.se (P.Garbha) writes: >I am sorry if i said that it was on the root partition fsck failed. It >is not. It is on another partition. The program dies after 15 seconds >without any message, except for the "***** checking blocks and sizes ****" >message. Now, fsck is not an essential program either, since the >system runs without it (if you patch away the "dirty" bit in your "rc" >file). But i would for sure appreciate to have it working. Rightly so as fsck is essential. Request xnx124 from sco!support to get the fix for this. All fixes are listed on our SOS support system and many are downloadable (including this one, I think). -- Roger Knopf <standard disclaimer applies> SCO Consulting Services uunet!sco!rogerk or rogerk@sco.com "...and he's got bare feet, too." 408-425-7222 (voice) 408-458-4227 (fax) --Charley Watkins
chip@tct.uucp (Chip Salzenberg) (06/14/90)
According to pgd@bbt.se (P.Garbha): >Anyone who have taken a few programs from the net knows that only very >small programs work without being patched. Has anyone tried to port >smail 3.1? Good luck! I did the port of Smail 3.1 to Xenix/286. I've used it under Xenix/286 and Xenix/386. In fact, I just sent a message to the author using Smail 3.1. And I compiled them all using Xenix cc. SCO has problems, true. But in my experience, overall quality control isn't one of them. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>