Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest110
2024-02-19 00:24:15 -05:00

598 lines
24 KiB
Plaintext

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Sat, 3 Sep 94 06:13:07 EDT
Subject: Linux-Development Digest #110
Linux-Development Digest #110, Volume #2 Sat, 3 Sep 94 06:13:07 EDT
Contents:
Re: Future of linux -- the sequel (Larry Pyeatt)
Re: ext2fs corruption in 1.1.47-48 (Marino Ladavac)
Strange kernel version information (Anders Ostling)
Re: Strange kernel version information (Anders Ostling)
Re: Linux console to SCO comp. prob (Jonathan Noel Tombs)
Re: Future of linux -- the sequel (Donald Becker)
Re: Unix, Unicode, and internationalization (Markus Kuhn)
ext2fs floppy/82077 corruption with 1.1.49 (Gary Paul Gortmaker)
Re: Kernel change summary 1.1.45 -> 1.1.46 (Steve DuChene)
scancode terminal support (was:Re: Linux console to SCO comp. prob) (Keith Smith)
Re: Linux console to SCO comp. prob (Keith Smith)
Re: Linux console to SCO comp. prob (Keith Smith)
----------------------------------------------------------------------------
From: pyeatt@cervesa.cs.colostate.edu (Larry Pyeatt)
Subject: Re: Future of linux -- the sequel
Date: 2 Sep 1994 19:24:17 GMT
In article <346dki$g5d@news.u.washington.edu>, mike@wavelet.apl.washington.edu (Mike Kenney) writes:
|> In article <3456g5$1ekr@yuma.acns.colostate.edu>,
|> Larry Pyeatt <pyeatt@CS.ColoState.EDU> wrote:
|> >
|> >Compare the price/performance of processors and Intel comes out to
|> >make the worst processors in existence. PowerPC chips provide twice
|>
|> I have to disagree here. The price/performance of a Pentium PC is
|> quite good (especially if you're running Linux :-).
You are talking at the system level. I was talking at the processor level.
What makes Pentium SYSTEMS cost effective is:
1) volume and vendor independence
2) Pentium systems in general:
a) have lower resolution/slower video hardware
b) have smaller hard disks
c) have less RAM
Do not confuse processor with system. The Power Macintosh
uses a totally new and different processor from any of its
predecessors and yet runs the SAME software and OS, and
delivers much greater price/performance. The same can be
done with the IBM style PC, although vendor independence
may turn out to be a hindrance.
Configure a Pentium system which is identical to an SGI
Indy and they will have very similar price/performance,
even though the Pentium PROCESSOR is more expensive
than the MIPS processor.
Here is a Pentium Machine which is configured similar to a
$6500 Indy:
99MhZ Pentium PCI bus motherboard $2500
32Meg RAM $1000
#9 GXE Level 12 video card $ 500
ViewSonic 17 Monitor $1000
Keyboard, 1.44M floppy, mouse, serial $ 300
400Meg SCSI disk $ 350
BusLogic SCSI controller $ 350
Soundblaster $ 100
Case and Power Supply $ 100
Ethernet adaptor $ 200
CCD camera $ ???
Operating system $ ???
-----
$6400 minumum
Note that, at the price shown, the PC will not do full motion video or
capture images, nor will it be as fast overall as the SGI.
|> One of the most important benefits is vendor independence, I can buy
|> spare/replacement parts from anyone ... no need to purchase a
|> maintenance contract. This was the big selling point for us, at one
|> time our research group was paying $35k/year in maintenance on 4
|> minicomputers.
I am not advocating buying workstations. I am advocating replacing the
PROCESSOR in the PC. There are now VL bus (and soon PCI) motherboards
with RISC processors. These motherboards use inexpensive PC components.
Why stick with the overpriced/underperforming Intels. Sure, DOS
compatibility. Well, I don't use DOS or Windows, so that is not an
issue for me. Maybe it is for some.
------------------------------
From: lan_lada@rcsw52 (Marino Ladavac)
Subject: Re: ext2fs corruption in 1.1.47-48
Date: Thu, 1 Sep 1994 09:36:26 GMT
mlord@bnr.ca (Mark Lord) writes:
: In article <shalafi.778344293@zetor.clinet.fi> shalafi@clinet.fi writes:
: >mlord@bnr.ca (Mark Lord) writes:
: >
: >>In article <33vqh0$nrn@bigblue.oit.unc.edu> jem@bittyblue.oit.unc.edu writes:
: >>>Hi,
: >>>
: >>>I've been having problems with files being corrupted under (at least) 1.1.47
: >>>and 1.1.48 on an IBM/vp DX266 with 64Mb RAM and an Maxtor MXT-50 IDE disk
: >>>with 16 sector multiple mode enabled. I would suspect the mult. mode but
: >>>I ran it in the past with no corruption.
: >>...
:
: >I've have the same problem. I have a 486DX2/66 and an Adaptec 1542CF
: >with a Seagate disk.. As far as I know, I haven't turned a multiple
: >mode on. (In fact, I'd like to know how to do that. Somebody mail me?)
:
: Ah. A SCSI system with similar symptoms. That makes it unlikely
: to be IDE-multiplemode related, or for that matter, IDE or SCSI specific.
: Thus, odds are improving that it is a filesystem problem.
: (multiple-mode is for IDE *only*).
:
: >When a file is corrupted, it has perhaps 8, perhaps 10 (I never made
: >a note about it) corrupted characters. They're placed so that EVERY
: >OTHER character is corrupted with an uncorrupted character between.
:
: Mmm.. a potentially good clue, if you can reproduce it and then
: post a real example, with the exact byte offset within the file
: carefully noted.
: --
: mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
I have had the same problems while using teh 1542CF with 1.0, 1.0.9 and
1.1.11. Eventually I've tested the thing by directly writing to one
of the partitions on the SCSI drive (50 MB of incrementing chars written,
then read, and the offending char's printed.) Some of the bits (usually
only one per byte) get lost (inverted.) It happens both on writing
and reading. I suspected a problem with 1542CF (driver or the cable) but
it may not be. I have had no problems (knock wood :) on the same machine
while using IDE drives (1.0, 1.0.9, 1.1.11, 1.1.45.) I shall have to
check the behavior when only the card supplies the SCSI termination power,
and when the drive is passively terminated (the drive, Adaptec and the
cable live very happily in another machine devoted to OS/2 and DOS.)
/Alby
--
Proof by Intimidation:
"I'm bigger, therefore I'm right."
noone@nowhere.in.particular
------------------------------
From: anos@elmrd6.ineab.ikea.se (Anders Ostling)
Crossposted-To: comp.os.linux.help
Subject: Strange kernel version information
Date: 2 Sep 94 19:07:29 +0200
Hi all
I have spent most of today with applying patches 36 -- 45 on my Linux
systems. No problems except the new asm-i386 directory. Strange problem
until i read the latest faq...
Anyway, my ../linux/Makefile and my ../linux/tools/version.h both agrees on
V1.1.45. Regardless of this, my system says 1.1.35 after reboot (both in the
boot message, login message, uname -a and /proc/version). So where on earth is
that number coded in ? Does not really matter, but it's annoying to see 35
when I know it's 45...
/Anders
--
+-------------------------------------------------------------------------+
| Internet anos@ineab.ikea.se |
| _ _ Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling |
| \ \ \ IKEA Northern Europe AB, Sweden |
| _/ _/ _/ |
+-------------------------------------------------------------------------+
------------------------------
From: anos@elmrd6.ineab.ikea.se (Anders Ostling)
Crossposted-To: comp.os.linux.help
Subject: Re: Strange kernel version information
Date: 2 Sep 94 20:59:53 +0200
In article <1994Sep2.190729.46@elmrd6.ineab.ikea.se>, anos@elmrd6.ineab.ikea.se (Anders Ostling) writes:
> Hi all
>
> I have spent most of today with applying patches 36 -- 45 on my Linux
> systems. No problems except the new asm-i386 directory. Strange problem
> until i read the latest faq...
>
> Anyway, my ../linux/Makefile and my ../linux/tools/version.h both agrees on
> V1.1.45. Regardless of this, my system says 1.1.35 after reboot (both in the
> boot message, login message, uname -a and /proc/version). So where on earth is
> that number coded in ? Does not really matter, but it's annoying to see 35
> when I know it's 45...
>
Just to avoid misunderstandings; yes, I did a complete rebuild between each
patch (make dep && make clean && make zlilo), and got new /vmlinuz images
from each build. Makes it even more strange, yes ? :-)
> /Anders
>
> --
> +-------------------------------------------------------------------------+
> | Internet anos@ineab.ikea.se |
> | _ _ Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling |
> | \ \ \ IKEA Northern Europe AB, Sweden |
> | _/ _/ _/ |
> +-------------------------------------------------------------------------+
--
+-------------------------------------------------------------------------+
| Internet anos@ineab.ikea.se |
| _ _ Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling |
| \ \ \ IKEA Northern Europe AB, Sweden |
| _/ _/ _/ |
+-------------------------------------------------------------------------+
------------------------------
From: jon@obelix.cica.es (Jonathan Noel Tombs)
Subject: Re: Linux console to SCO comp. prob
Date: 2 Sep 1994 13:17:14 +0200
In article <DMW.94Aug29102738@prism1.prism1.com>,
> No, there are real problem when it comes to Linux's keyboard handling.
>What I (and many other people) want is to be able to replace SCO with Linux
>and not have the other people notice. Sure, I could use WPTERM to set up an
>entry for Linux's console, I've done it many times for other terminals. But
>I don't *want* a sperate entry for Linux. And I *can't* make an exact duplicate
>for the SCO keyboard layout because Linux does not support enough key
>combinations re: function keys. That is, SCO supports FKEY, S-FKEY, C-FKEY,
>and C-S-FKEY. I want (and NEED) Linux to do this as well. Also, the keys that
>Linux sends out are far too long for what they need to do and still be
>unique. This causes problems with our in-house software because we use a
>tree-based keyboard table to speed up recognition and we have a fixed
>maximum size per fkey string we can handle. Yes, we could increase it, but why?
what is the problem with the linux keymaping. I can generate 16 different
characters/sequences per key as far as I am aware. linux seems to
supports all shift/control/alt posabilities.
What is it that SCO can do that linux not? Or is it just you haven't
bothered using loadkeys and the default map defines some sequences as
the same.
Jon.
------------------------------
From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Subject: Re: Future of linux -- the sequel
Date: 3 Sep 1994 01:00:09 -0400
In article <347u51$2ev5@yuma.acns.colostate.edu>,
Larry Pyeatt <pyeatt@cervesa.cs.colostate.edu> wrote:
>Here is a Pentium Machine which is configured similar to a
>$6500 Indy:
OK, I'll bite into this flame-fest.
>99MhZ Pentium PCI bus motherboard $2500
Errr, that's a little overpriced. Most places don't put the P100 parts in
their price lists, but I've seen P90 PCI motherboards for under $1200.
>32Meg RAM $1000
72 pin SIMMs, same for both. This is a little unfair, since Linux systems
use less memory than the SGI for most tasks. Try running the SGI window
system with 8M of memory -- I've run Linux+X with 4M.
>#9 GXE Level 12 video card $ 500
You can get accelerated PCI video cards starting at $125. $200 will get 2M
of video memory for 1200x1024x8 resolution. Price is very non-linear past
that point. A major advantage is that you can choose which aspects of the
system are important enough to pay extra for.
>ViewSonic 17 Monitor $1000
Perhaps a little high -- nice 17" monitors are around $850, and sleazy ones
are $600. Monitors sold into the high-volume PC market tend to be priced
more aggressively than similar monitors in the workstation market.
>Keyboard, 1.44M floppy, mouse, serial $ 300
Ackkk! You really are over estimating here. You can get all this for under
$100. There are some very nice keyboards for under $30 (although few under
$20 qualify as "nice" :->).
>400Meg SCSI disk $ 350
Same everwhere. On a PC-type system you have the *option* of lower cost
IDE disks, which can perform quite well in one-drive systems. Say, $269 for
540M?
>BusLogic SCSI controller $ 350
NCR PCI SCSI-2 controllers are $70. The $1300 P90 motherboards have it
built in.
>Soundblaster $ 100
>Case and Power Supply $ 100
As low as $40. I prefer a smaller case. Will your Indy let you put in the
nine disk drives that some $100 cases will?
>Ethernet adaptor $ 200
Erk! Where are you getting these numbers? As low as $33, but plan on
spending just under $100 for a PCI or VL bus one. Any how will you upgrade
the Indy next year, when 100Mbs ethernet becomes common?
>CCD camera $ ???
>Operating system $ ???
> -----
> $6400 minumum
That's just way more than a reasonable Linux box will cost.
>Note that, at the price shown, the PC will not do full motion video or
>capture images, nor will it be as fast overall as the SGI.
That's true. I think the new SGI full motion thumbnail video is a really
great toy, and their demo is amazing. If I wanted to do that kind of video
work, I would get an SGI. But for many other kinds of work the Linux system
would do as well or better, and be much less expensive.
--
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
------------------------------
From: mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Re: Unix, Unicode, and internationalization
Date: Thu, 1 Sep 1994 09:39:10 GMT
Reply-To: mskuhn@cip.informatik.uni-erlangen.de
rob@pe1chl.ampr.org (Rob Janssen) writes:
>Some time ago, there was a thread about this here. Someone had great
>plans, and I think he even made the Linux console support Unicode.
Well, I started such a thread in the kernel mailing list a few months
ago and I wrote a patch that allows the console to understand UTF-8.
But this patch only supported the IBM character set subset of Unicode
and no new glyphs were defined. I can mail this old patch to anyone
interested, but it has only been tested against late pre-1.0
kernels. I still have plans for a font cache support in the console
that will automatically load those 256 (perhaps even 512) characters
that are currently needed in the VGA font memory. But unfortunately,
I don't even have Linux hardware at home currently, so this project has to
wait until this is fixed first ... ;-) Ask me in 2 months again.
There are also rumours that someone in Australia is working on a
Unicode capeable xterm version, but I don't know any details.
Who knows more?
BTW: various information about Unicode, UTF-8, etc. is available on
ftp.uni-erlangen.de:pub/doc/ISO/charsets/.
Markus
---
Markus Kuhn, Computer Science student -- University of Erlangen,
Internet Mail: <mskuhn@cip.informatik.uni-erlangen.de> - Germany
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>
------------------------------
From: gpg109@huxley.anu.edu.au (Gary Paul Gortmaker)
Subject: ext2fs floppy/82077 corruption with 1.1.49
Date: 1 Sep 1994 14:56:16 +1000
This may shed some more light on the floppy corruption reported
earlier. This only seems to happen with the more advanced floppy controller
(reported as a "post-1991 82077") and _not_ the standard 8272A based
controllers. (The 82077 can be found on the more expensive SCSI cards
such as the aha-154X, buslogic cards, AMI-FastDisk, etc.)
This is guaranteed to demonstrate the problem on 82077 based systems.
I have verified it on two systems with 82077 chips on cards from
different manufacturers. I know it did so on 47 and 48, as well as 1.1.49,
but can't vouch for how far it goes back. I sent this to the KERNEL
channel, but I think the mail-server ate it. :-(
1) mke2fs a floppy
2) mount it and copy a big (~500k) file to it (or several files)
3) unmount it but _don't_ eject it
4) run "e2fsck -vrf /dev/fd0" --- it will come up clean (reading the cache)
5) eject it and immediately stick it back in (set disk change flag)
6) Repeat step 4 -- you will get most of the blocks in the above file(s)
being marked as "not in use".
Also, a notebook that now claims to have an 8272A (but printed the message
"floppy: FIFO enabled" with the 1.1.3X kernels) also exhibits this
corruption. The same notebook could not even use the floppy for
kernels 1.1.42 --> 45 (the ones that used the faster 720k step rate)
I could not get the same sequence to produce the corruption with a
standard 8272A based FDC.
Perhaps we should have a way in which the 82077 can be used as a
bog standard 8272A (like it was in kernels < 1.1.23) until all the
enhanced FIFO features of the 82077 are sorted out.
bool 'Floppy FIFO support for 82077' CONFIG_FDC_FIFO n
Paul.
------------------------------
From: s0017210@cc.ysu.edu (Steve DuChene)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 1 Sep 1994 10:08:33 GMT
Russell Nelson (nelson@crynwr.crynwr.com) wrote:
: More spelling fixes (I before E except after C or when pronounced like
: an A as in neighbor or weigh, unless it's spelled weird).
I find all these spelling errors and their subsequent correction
extremely humorous. I am a terrible speller also and it's nice
to see even Linus(?) or other developers have the same problems.
Then to go to the trouble of patching them while still trying to do
kernel development is amazing!
--
| Steven A. DuChene sduchene@cis.ysu.edu or s0017210@cc.ysu.edu
| Youngstown State University | Computer Science / Math / Mech. Eng.
|They all laughed at Albert Einstein. They all laughed at Columbus.
|Unfortunately, they also all laughed at Bozo the Clown.
------------------------------
From: keith@ksmith.com (Keith Smith)
Subject: scancode terminal support (was:Re: Linux console to SCO comp. prob)
Date: Fri, 02 Sep 94 03:15:22 GMT
It would be nicer if the scancode support for the keyboard was
integrated so that it could be used by the dosemu program, and/or
scancode terminals on serial lines. Oh, like SCO has <GRIN>.
--
Keith Smith aka Digital Designs keith@ksmith.com
5719 Archer Rd. Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-2201 All 28K/14K Modems (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ... 14K-V.32/28K-V.34/28K-V.34
------------------------------
From: keith@ksmith.com (Keith Smith)
Subject: Re: Linux console to SCO comp. prob
Date: Fri, 02 Sep 94 03:23:01 GMT
In article <DMW.94Aug29102738@prism1.prism1.com>,
David Wright <dmw@prism1.prism1.com> wrote:
> The SCO keyboard layout & functionality is so standard that many
>dumb terminals even have a setup to emulate it. It is NOT something that
>should be lightly tossed aside.
In fact, on all my wy150 terminals I redefined all the programmable keys
to match the SCO console. If Mohammed can't come to the mountain ...
New terminals from Wyse and ADDS support SCO console native. They also
support SCANCODE mode and/or "pc-term" mode. The ability to pass
scancodes raw into an application is awesome. SCO Unix's ability to
translate serial line scancodes into ASCII/ANSI sequences is a definate
Big time help when trying to do some of the stuff we do, (IBM S/36
emulation).
If you want Linux to emulation SCO _for REAL_ you set the bar pretty
high indeed. SCO has eliminated MANY of the "little small problem"'s
and issues in it's rather pricey OS. The Rumor mill says the upcomming
SCO release is going to raise the bar even quite a bit higher. We'll
see what happens.
--
Keith Smith aka Digital Designs keith@ksmith.com
5719 Archer Rd. Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-2201 All 28K/14K Modems (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ... 14K-V.32/28K-V.34/28K-V.34
------------------------------
From: keith@ksmith.com (Keith Smith)
Subject: Re: Linux console to SCO comp. prob
Date: Fri, 02 Sep 94 03:38:54 GMT
In article <CvCIAE.H7B@hscsol.attmail.com>,
Stephen Harris <hsw1@hscsol.attmail.com> wrote:
>David Wright (dmw@prism1.prism1.com) wrote:
>: and C-S-FKEY. I want (and NEED) Linux to do this as well. Also, the keys that
>: Linux sends out are far too long for what they need to do and still be
>
>What is too long about the Linux fkeys? Errm, F8 sends ESC[19~
>Seems entirely reasonable and standard with the VT keyboards (LK201).
Oh vomit. The Fkey sequences under linux really suck. They would be
GREAT if they followed a contiguous pattern, but they don't do that. I
don't care what DEC did. A suggestion would be something like:
\E[{fkey number}#
so f1 = \E[1#
f2 = \E[2#
...
f999 = \E999#
Which brings us to ...
>: unique. This causes problems with our in-house software because we use a
>: tree-based keyboard table to speed up recognition and we have a fixed
>: maximum size per fkey string we can handle. Yes, we could increase it, but why?
>
>Then your program is WRONG! Making *any* assumption about the length of
>keyboard strings, terminal escape sequence etc etc is WRONG WRONG WRONG!
Sure, throw away the dusty deck.
>
>: The SCO keyboard layout & functionality is so standard that many
>: dumb terminals even have a setup to emulate it. It is NOT something that
>
>And the defulat Linux keyboard is so standard because it emulates a dumb
>terminal.
Well, sortof anyway. I should say mostly.
'Splain where F22 is on a VT100 will ya?
>Please look at an DEC LK201(?) keyboard sometime and the sequences that the
>VT220 VT320 VT420 etc all send out - ie probably the most common keyboard
>sequences in existence!
Hahahahahahahahahahahahaha!
Behind the wierd PC keyboard ....
The Wyse/Adds/ADM/Televideo/Hazeltine/etc ad nauseum terminals are WAY,
WAY, WAY more comman than _any_ DEC terminal. I'd be willing to bet
Wyse has sold more WY-50's than DEC has sold VT terminals combined.
The WY-50 uses a CTRL-A leadin with characters from the ASCII chart
starting with '@' == 1 and work their way up the ASCII chart IN ORDER,
following the character with a CR.
The WY-50 was sort of the standard from which all other's after were
defined. And I might add the WY-50 is one BLIND FAST terminal for
screen response, largely because of the laconic control sequence set,
albeit a tad cryptic.
I have _NEVER_ seen a consistant DEC VT Function key keymap, but you can
rest assure that if you power on a wyse 50/60/120/150/55/30 and press
F1, your gonna get ESC-@-CR.
So if you wanna emulate the "Most common" sequences you'd best pick the
Wyse keyboard sequences.
--
Keith Smith aka Digital Designs keith@ksmith.com
5719 Archer Rd. Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-2201 All 28K/14K Modems (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ... 14K-V.32/28K-V.34/28K-V.34
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************