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

640 lines
25 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: Fri, 9 Sep 94 13:13:09 EDT
Subject: Linux-Development Digest #144
Linux-Development Digest #144, Volume #2 Fri, 9 Sep 94 13:13:09 EDT
Contents:
Which ??? (Peter Himschoot)
Don't use Linux?! (Michael Schumacher)
Re: Why I cannot mount a PhotoCD on Mitsumi ? (Erik Mouw)
how to catch FPU-errors ? (*Student)
Re: Developing Distributed Filesystems for Linux? ("Derrick J. Brashear")
Re: Survey: who wants f77,cc,c++,hpf for linux? (Ray Hann)
X11, S3 and ti3020 RAMDAC (Eric RAVE)
Re: Homemade Terminal Server cheap (Liam Greenwood)
Re: [STATUS] Linus Floppy Driver Development (Nick Holloway)
Re: Wheres blkdev.h?? (compiling 1.1.49) (Dougal Campbell)
Re: News Spool File System - new filesystem type?? (Michael Dillon)
Re: News Spool File System - new filesystem type?? (Michael Dillon)
Re: Anyone working on ISDN card drivers ?? (Matthew S. Crocker)
----------------------------------------------------------------------------
From: phimsch@vnet3.vub.ac.be (Peter Himschoot)
Subject: Which ???
Date: 9 Sep 1994 12:46:15 GMT
Sorry if this is the wrong news-group, but I have to know :
which linux (and X-windows) CD-ROM would you advise to me :
- I want to have some kind of Motif-like X-windows, and
- I'd use it primarily for C++ development
Also include the address where I can order it !
Thanx !
Peter
+-----------------------------------------------------------------------+
| Peter Himschoot E-mail phimsch@vnet3.vub.ac.be |
| Programming Technology Lab Phone (+32) 2-6413491 |
| Computer Science Department Fax (+32) 2-6413495 |
| Vrije Universiteit Brussel Pleinlaan 2 |
| B-1050 Brussels Belgium |
+-----------------------------------------------------------------------+
------------------------------
From: hightec@sbusol.rz.uni-sb.de (Michael Schumacher)
Subject: Don't use Linux?!
Date: 9 Sep 1994 14:05:57 GMT
Hello Linuxers!
Okay. Before you start sending me endless flames, I want to make sure
that you know that I *love* Linux. It's probably the best PC Un*x you
can find between here and the sun. Linux has some nice features, e.g.
the /proc filesystem, it is fast, it supports lots of hardware, it
follows the POSIX standard (which makes porting of existing software
much easier), plus: it's free. Nobody knows the exact number of Linux
installations, but it's likely to be in the 100000's. One could think
that companies are willing to consider Linux a reasonable and serious
platform, and that they would port and offer their products to the
Linux community. However, they are far away from doing so, actually.
Here's why:
1. Commercial software products are typically binary-only (i.e., no
source code is available). No matter what language you use for
compilation, you will finally need libc, which happens to be FSF's
libc on Linux. From the GLPL you learn that you are not allowed
to make statically linked, binary-only releases of your software.
You may, however, distribute a dynamically linked version of your
product, since then only the startup code (crt0) is needed, which
is explicitly excluded from the GLPL. This is perfectly okay for
other commercial OSs, but:
2. Linux's libc tends to change its version number almost every week
(sometimes even more often). Even though changes of the minor
version number should not affect previous applications, they will
sometimes break them. This means for a company that they have to
debug the library in order to find a work-around (see 3.).
3. The kernel versions change faster than the speed of light. If you
ask for a "stable" version, you'll be teached that there are two
versions: 1.0 (production) and 1.1 (hacker's paradise). Wanna have a
stable one? Get 1.0! Okay, but if I want to offer a commercial
product, it doesn't matter what kernel version *I* am using, but
what version is used by my potential *customers*! There's a reason
for 1.1: it is a bit faster, it supports more hardware, it provides
more features. As a result, most Linuxers traditionally pick up the
the newest kernel releases all the time - and usually end up in this
newsgroup, saying "this is broken", "that doesn't work anymore",
"can't compile", etc. (if you don't believe me, just exit this thread
for a moment and take a look at the other subjects). Besides other
disadvantages, this will definitely not convince companies of the
stability and usefulness of Linux!
4. The spirit of free software is all around. Free in both meanings:
free availability of the sources, and free of charge. Which does
not go together with commercial interests very well. Just to give
you an example of what I'm talking about: I'm the author of tgdb,
a graphical user interface for gdb. I like the idea of free software,
and so I asked my employer for permission to make it GPL'd freeware.
Guess what, he said "No way!". So I ripped off my bones and used all
of my talents to persuade him to make it a shareware product instead
of a true commercial package. Well, now that tgdb is available for
a couple of weeks, I'm quite sure there are 100's or even more people
who use it for their daily debug sessions. Fine. But the bloody truth
is that not even a *single* person has paid the nominal shareware
fee of US$30!
5. On the other hand, I can tell you how to make lots of money with Linux:
simply download the archives of tsx-11, sunsite, nic.funet.fi,
prep.ai.mit.edu and ftp.x.org, put them on a CDROM, call it "Dream Linux"
or similar, and sell if for US$35 per copy. It's that easy. Let's say,
an average user is looking for "the better OS" and wants to try out
Linux. He buys a "Dream Linux" CD - and is lost. Nothing works "out of
the box", no reasonable documentation is available, nor hotline support.
What will happen? I'm quite sure that most of these desperated people
will close the Linux chapter - forever.
There are a lot more things which speak against Linux as a platform for
commercial products. If an operating system is successful or not depends
on the availability of qualified (commercial) software for end-users. I
would like to see companies porting their WYSIWIG word processors, graphic
tools, spreadsheets, compilers, backup software, and whatever to Linux.
Linux is great, but at present mostly for developers and freaks - *not* for
average users who need a reliable platform for doing their jobs. Whoever
asks for a good word processor for Linux, hears something like "word
processing is out - try TeX", or "you can run xyz under DOSEMU" or "try SCO
versions of xyz; just recompile the kernel with SYSV support and get the
iBSC2 package from foo.bar". This can be - at most - a temporary work-around.
Users don't want to know how to roll a new kernel, they don't want to ftp
packages, unpack, configure, compile, debug and install them. That's why
they are willing to spend some bucks in commercial software, and that's why
Macs and Windoze are so successful. And that's why Linux is not.
Quo vadis, Linux? Do we continue to like Linux "as is", or should we
change something in order to encourage companies to develop commercial, but
sophisticated end-user software for this beautiful OS? Do we continue to
keep Linux a powerful tool for wizards only, or do we want to see Linux
being used in offices and other commercial environments? If we *really*
want Linux to succeed, we *need* the companies and their commercial products!
Thanks,
mike
PS: See 4. ;-)
--
In Linux we trust.
------------------------------
From: jakmouw@et.tudelft.nl (Erik Mouw)
Crossposted-To: comp.os.linux.help
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 9 Sep 94 16:36:00 +0200
In article <34l4gr$ahv@rutcor.rutgers.edu>, badics@rutcor.rutgers.edu (Tamas Badics) writes:
> Hi Again,
>
> I asked the above question once, but had no positive answer.
> The problem is the following:
>
> I'd like to mount a PhotoCD using Linux 1.0.9 and a Mitsumi doublespeed
> CD drive. I guess the "mount -t iso9660 /dev/mcd /cdrom" command should
> do it, but it doesnt. It gives the usual
> "mount: wrong fs type, /dev/mcd already mounted, /cdrom busy, or other error"
> error message.
>
> Is the PhotoCD compatibility missing from the mcd.c driver?
>
> I CAN mount regular data CD-s on the same drive with the same command.
> Also, the same drive CAN read PhotoCD-s under MS-DOS, so it is not a hardware
> problem.
>
> Anoybody knows the solution to this?
>
> Thanks,
> Tamas
>
I think the errormessage says enough: photo CD's don't have a
ISO 9660 filesystem on it, otherwise Linux should have mounted it.
ISO 9660 filesystems is only for CD-ROM, another CD substandard.
I don't know how to read from a photo CD under Linux, under MS-DOG with
Windows you van use Corel Draw!...
Erik
==================================================
Erik Mouw, Department of Electrical Engineering,
Delft University of Technology, The Netherlands
email : JAKMouw@ET.TUDelft.NL
D O N ' T P A N I C !
==================================================
The minimal C program:
main() { }
------------------------------
From: natst3@nat2.uia.ac.be (*Student)
Subject: how to catch FPU-errors ?
Date: Fri, 9 Sep 1994 14:04:55 GMT
Hello, world.
I'm designing a program in C to aid me with creating reports for the
experiments I have to do at univ. I've allready written a simpler version
under DOS, and now I want it to be even bigger and better ( I hate the
number 64 K ;-) !
However , I've run into a problem : matherr doesn't work, I gather this is
a choice of the creators. Ok , but what do I have to use now ? If it is
in a FAQ then please tell me witch.
I hope this isn't a too stupid question, thanks in advance.
Peter Van Eynde
natst3@nats.uia.ac.be
#include <disclamer.h>
------------------------------
From: "Derrick J. Brashear" <db74+@andrew.cmu.edu>
Crossposted-To: alt.filesystems.afs
Subject: Re: Developing Distributed Filesystems for Linux?
Date: Fri, 9 Sep 1994 10:30:25 -0400
Excerpts from netnews.alt.filesystems.afs: 9-Sep-94 Developing
Distributed File.. by Lincoln Myers@soda.CSUA.
> If not, would it be possible to make a freely available implementation of
> AFS or DFS for Linux, without infringing on their current owner's
> (Transarc's) rights? Is there enough information out there?
>
> I would be willing to help develop something like this if there is any
> demand.
I suppose one could do it, but I wouldn't want to. Some docs are
available by ftp from grand.central.org, I think.
-D
------------------------------
From: mshann@hyperthink.lerc.nasa.gov (Ray Hann)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 9 Sep 1994 15:20:14 GMT
In article <1229@snll-arpagw.ca.sandia.gov> hwstock@snll-arpagw.ca.sandia.gov (stockman harlan w) writes:
>
>In my experience, the executables produced by f2c + C compilers can be 3
>times slower than executables produced by a good FORTRAN compiler. You
>won't see this big a difference with a 486, where the average floating
>point instruction takes about 14 clock ticks, but it will show up on a
>Pentium or RISC chip. The problem has to do with the way f2c translates
>FORTRAN multi-dimensional arrays into 1-D arrays with lots of integer
>multiplications. Most C compilers end up assuming you must really want
>all those integer multiplications for some reason.
The performance with f2c + gcc seems to vary wildly from one application
to the next. A good F77 compiler will beat f2c+gcc on the whetstone
benchmarks by 3 fold. But then again I have found on some of my own
scientific codes that f2c+gcc produces code that actually executes faster
than that of the Sun F77 compiler. The only tweeking that was needed
was to set -DREGISTER as an option on the gcc compile. Consistancy is
the problem along with the lack of a free F77 debugger.
When does gf77 come out of alpha testing?
Ray
--
=============================================================================
Ray Hann |
NASA Lewis Research Center |
Cleveland, Ohio 44135 | email: mshann@hyperthink.lerc.nasa.gov
=============================================================================
Deep Magic in Scheme
==>(set! x (eval '(define (set! a b) (sows_ear->silk_purse C++-program))))
=============================================================================
------------------------------
From: eric@crih.fdn.org (Eric RAVE)
Subject: X11, S3 and ti3020 RAMDAC
Reply-To: eric@crih.fdn.org
Date: Fri, 9 Sep 1994 08:01:03 GMT
Hye,
I possess S3 928 card with a ti3020 RAMDAC, PCI Bus, Pentium 60 Mhz.
X11 (XF86_S3 2.1.1) works correctly (1024x768) but with a little problem.
A small band (about 20 pixels) is not printed left but right. So there
is a gap between mouse cusor and real pointed position.
When i specify no_ramdac in Xconfig, these problems don't appear (but
a small one line shift is present in middle of screen) and screen is not
so clean than with ti3020.
I'd like to know :
- if bugs are known !
- if the band can be suppress (by example with an option in Xconfig) or
- if cursor is able to be manage not by S3_card but by soft (in order to
suppress gap).
- HP Vectra XP 60 owners's experiences with X11............
I join X info and Xconfig.
*---------------- START XCONFIG ----------------------------------*
...........
ACCEL
Virtual 1024 768
Viewport 0 0
Modes "1024x768"
option "dac_8_bit"
Clocks "icd2061a"
ModeDB
# name clock horizontal timing vertical timing flags
"1024x768" 75 1024 1096 1256 1336 768 774 791 801
............
*------------- END OF XCONFIG ---- BEGIN OF STARTX -------------*
XFree86 Version 2.1 / X Window System
(protocol Version 11, revision 0, vendor release 5000)
Operating System: Linux
Configured drivers:
S3: accelerated server for S3 graphics adaptors (Patchlevel 0)
mmio_928, s3_generic
(using VT number 7)
Xconfig: /usr/X386/lib/X11/Xconfig
(**) stands for supplied, (--) stands for probed/default values
(**) Mouse: type: PS/2, device: /dev/mouse
(**) FontPath set to ........
(**) S3: Option "dac_8_bit"
(--) S3: card type: EISA
(--) S3: chipset: 928, rev D or below
(--) S3: chipset driver: mmio_928
(--) S3: videoram: 4096k
(--) S3: Detected a TI ViewPoint 3020 RAMDAC
(--) S3: Using hardware cursor from Ti3020 RAMDAC
(**) S3: Using ICD2061A programmable clock
(--) S3: Maximum allowed dot-clock: 135MHz
(**) S3: Mode "1024x768": mode clock = 75.000
(--) S3: Operating RAMDAC in pixel multiplex mode
(**) S3: Virtual resolution set to 1024x768
(--) S3: Local bus LAW31-26 is 0
(--) S3: Using a banksize of 4096k, line width of 1024
(--) S3: Pixmap cache:
(--) S3: Using 2 256-pixel 6 128-pixel 8 64-pixel and 8 32-pixel slots
(--) S3: Using 8 pages of 768x3327 for font caching
*-------------------------------------------------------------------------*
THANKS FOR YOUR REPLY AND FOR TIME YOU'LL EVENTUALLY SPEND FOR ME.
________________________________________________
Eric RAVE
Centre Regional d'Informatique Hospitaliere
CHU de Tours, France
eric@crih.fdn.org - eole@crih.fdn.org
------------------------------
Crossposted-To: comp.dcom.servers
From: liam@durie.wanganui.gen.nz (Liam Greenwood)
Subject: Re: Homemade Terminal Server cheap
Date: Fri, 9 Sep 1994 10:34:28 GMT
William (billw@glare.cisco.com) wrote:
> 1) MSRP for the 16 port card is over $700 apiece - I don't know where
> the original poster got $400 for 16 ports. (MSRP of 8 port cards
> was over $400.) Cyclade also sells a full "terminal server", 16 ports
Cyclades ad in Linux Journal #5 page 6 says;
"Order Now Just $99.- 8 ports $399.- 16 ports"
Cheers, Liam
------------------------------
From: Nick.Holloway@alfie.demon.co.uk (Nick Holloway)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: Fri, 9 Sep 1994 06:59:28 +0000
On my TODO list for MAKEDEV is trying to decide what devices should be
made for the new floppy driver. David's message makes it clear that there
are more problems in just adding extra names for the new sizes/densities
(which had been my original plan).
Thus, I suspect that some decision will have to be made on the naming
of floppy devices, and I don't feel qualified to do this. I'm quite
happy to add to MAKEDEV whatever is felt to be best.
My only comment is that fd0H2880 was based on something, but I know not
what, and was a name chosen quickly to support the 2.88 Mb support.
In <34gk8k$2nj@clarknet.clark.net> niemidc@clark.net (David C. Niemi) writes:
> 5) Minor device naming problems (density letter)
>
> The minor device naming conventions are currently inconsistent
> between the new MAKEFLOPPIES script (which bases the density
> letter on the drive type) and MAKEDEV (which bases the density
> letter on the media format). For example, a 1.44MB disk in an
> ED drive would be called /dev/fd0E1440 by MAKEFLOPPIES, and
> /dev/fd0H1440 by MAKEDEV.
>
> This problem is especially sticky with 5.25" 360 KB disks, where
> there are three very different drive types to consider (40-track
> 300rpm "PC"; 80-track 300rpm "Quad Density"; and 80- track 360-
> rpm "AT". These point toward using the drive type in determin-
> ing the density letter (d, q, and h respectively). Thus fd0d360,
> fd0q360, and fd0h360 would all refer to the same media format in
> different drive types. There is no BIOS code for the "Quad
> Density" drives, so simply relying on the BIOS code for the
> drive when creating the devices is not sufficient in all cases.
>
> OTOH, ED 3.5" drives support all 4 different densities, and many
> scripts assume that fd0H1440 is the name for a 1.44MB 3.5" disk.
> Having to know whether you have a HD or ED disk drive is
> confusing to both users and scripts which want to access a known
> media format. The problem is even worse with DD disks if the
> density letter is based on the drive type. For example, the
> same 720KB diskette would have to be referred to as /dev/fd0D720,
> /dev/fd0H720, or /dev/fd0E720 depending on the drive type.
>
> Just to add to the confusion, the current MAKEDEV also makes
> device fd0H2880, which makes no sense in either scheme.
--
Nick Holloway | `O O' | Home: Nick.Holloway@alfie.demon.co.uk
[aka `Alfie'] | // ^ \\ | Work: nickh@parallax.co.uk
------------------------------
From: dougal@vespucci.iquest.com (Dougal Campbell)
Crossposted-To: comp.os.linux.help
Subject: Re: Wheres blkdev.h?? (compiling 1.1.49)
Date: 8 Sep 1994 17:10:59 -0500
In article <CvL0JI.G2F@dorsai.org>, Carlos Dominguez said something like:
> I'm trying to compile the latest/greatest kernel in order to
> get support for my 1mb/sec QIC80/floppy controller.
> I got the 1.1.45 kernel, applied all the patches sequentially from
> 46 to 49 to my 45 source tree, and whenever I do a make dep I always
> get this.
> ksyms.c:13: linux/blkdev.h: No such file or directory
> make[1] *** [dep] Error 1
> I did a diff between a ksyms.c and a ksyms.c.orig and the diffs were
> that statement and a "BLOCK DEVICE" section towards the end.
> Can/Should I compile even with this dependency error?
I ran across the same thing when I compiled the 1.1.49 kernel. The
patches seem to not place some of the files correctly. If you look in
directory you applied the patches from (probably /usr/src or
/usr/src/linux) I'd bet that you'll see some stray .h and .c files.
Look at what source files the make fails on, look at the paths, and move
the stray files to their proper directories.
--
Dougal Campbell | Check out the interQuest home page:
System Administrator | http://www.iquest.com/
dougal@iquest.com | interQuest: "We can hook you up!"
------------------------------
From: mpdillon@halcyon.com (Michael Dillon)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: Thu, 08 Sep 1994 23:59:09 +0100
> I think the modern news systems could avoid most of the the defects in
> the notes and WinNet approach. (just a small matter of programing) :-)
>
> But, I really like being able to do "brute force" emergency admin of my
> spool dir using OS cmds and other tools. (find, reap, even rm -rf soc/* on
> a bad day)
That's why it should be implemented as a file system. All the normal OS
tools would continue to work, but under the hood it would be optimised
to not waste disk blocks and to not even need a fixed size inode table.
> The convenience of the current approach make it worth enduring the performance
> and space hits. A new design would have to be faster, compress 2-3X, and
> totally compatible with INN to get my interest.
If it was a file system, it would be totally compatible with all
existing news software, although you might want to keep certain
things out of /usr/news/spool. Of course, modifications could be
made to INN to take advantage of new features like the integrated
history and NOV.
cruisin' down the information highway, lookin' for a blast
breakin' all the speed limits as I come zoomin' past!
--
Michael Dillon Internet: mpdillon@halcyon.halcyon.com
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
------------------------------
From: mpdillon@halcyon.com (Michael Dillon)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: Fri, 09 Sep 1994 00:04:25 +0100
> > 1. This is a compressed file system using LZ technology
> > 2. Since LZ compression replaces repeated strings with a dictionary
> > reference and since news postings tend to have a lot of the
> > same words over and over, the NSFS uses a two part dictionary.
> > The first part of the dictionary is applied to all files in the
> > NSFS and contains words that are likely to occur in many news postings.
> > This includes headers
>
> >and common English words and phrases. The
>
> NON. Tout compris? (Translation: NEIN. Alles klar?).
> See what I mean?
In the original suggestion I mentioned that the list of common strings
used would be configurable and that there should be a tool that
would analyse existing news spools to come up with a suggested
list for your unique site. If nothing else, the headers
(i.e. References: or Newsgroups:) and the newsgroup names of the
most common newsgroups would end up in that dictionary. As you will
note, those strings occur in every (many) article(s) but LZ
compression on a single article will not be able to compress them.
> > second part is a file specific dictionary as is normally found in
> > LZ compression systems.
>
> >I don't think this would work, as so many words in usenet postings are
> >misspelled that looking them up in a dictionary, probably won't buy
> >you anything, cuz they won't be found!
> > ^
> > c whut i meen?
LZ dictionaries aren't used to look up words, they are used to look
up repeated strings so in your example strings like " thi" and "ing"
would end up in the dictionary for that one posting. I'm not sure that
there is much payback on LZ compression of short articles, but longer
ones should work well.
cruisin' down the information highway, lookin' for a blast
breakin' all the speed limits as I come zoomin' past!
--
Michael Dillon Internet: mpdillon@halcyon.halcyon.com
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
------------------------------
From: matthew@rmc1.com (Matthew S. Crocker)
Subject: Re: Anyone working on ISDN card drivers ??
Date: 9 Sep 1994 14:51:16 GMT
nhead@esoc.bitnet wrote:
: Thanks - I'll follow this up ... using a cheap card doesn't sound like too
: much of a problem to me :-)
: This has been the only answer so far. I can't really believe that all you
: IP service providers out there aren't using Linux machines !!!!
: Nigel.
Actually, we are :)
Only we are using a CISCO 2501 router to handle our IP feed (T1).
Putting 64-128k through the ISA bus would be murder on interrupts
(even for the P5-90 we have here...)
BTW, don't bother with the header of this post, I still haven't fixed
the news server so it put the right info up there...
-Matt
--
-Matthew S Crocker "The mask, given time, comes
mcrocker@crocker.com to be the face itself." -anonymous
*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*OS/2*
*linux*linux*linux*linux*linux*linux*linux*linux*linux*linux*linux*linux*
------------------------------
** 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
******************************