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:     Wed, 24 Aug 94 20:13:07 EDT
Subject:  Linux-Development Digest #62

Linux-Development Digest #62, Volume #2          Wed, 24 Aug 94 20:13:07 EDT

Contents:
  Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload. (Bernard Steiner)
  Re: Kernels 1.1.41 to 1.1.46 break ramdisk booting. (John Rhoades)
  How fast is your nngrab under Linux? (Erik E. Rantapaa)
  Re: DOSEMU 0.53: Developers and testers needed! (jonathan allen)
  Mailing list for discussion of new Linux BBS (Matt Midboe)
  Re: Write-Through the File System Cache? (Remy CARD)
  Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload. (Holger Veit)
  PRIORITY make an undelete command (DE KERPEL SVEN)
  Re: Crashes w/ new kernels (Matthias Urlichs)
  Re: Future of Linux (vchui@dra.hmg.gb)
  Linux for DEC Alpha platform? (James H. "Skip" Smith)
  Re: Appletalk? (Bao Chau Ha)
  Re: Disassembler for Linux? (Ken Pizzini)
  Re: prob compiling 1.1.46 with gcc 4.6.0 (Geoff Rehmet)
  Re: Future of Linux (emacs? lemacs!) (Michael Will)
  Re: Linux for DEC Alpha platform? (Dominik Kubla)

----------------------------------------------------------------------------

From: bs@Germany.EU.net (Bernard Steiner)
Crossposted-To: comp.unix.bsd,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc,comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.unix.pc-clone.32bit
Subject: Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload.
Date: 24 Aug 1994 16:37:22 +0200


In article <CurvLE.9pA@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
|> In <Cur2uA.9EI@cnn.nas.nasa.gov> tweten@wilbur.nas.nasa.gov (Dave Tweten) writes:
|> 
|> >The final revelation to me was how he planned for users to boot directly
|> >off the CD, with no need for a boot floppy.  The actual scheme is:
|> 
|> >    1.  Have an Adaptec 154xy SCSI controler, for all values of x and y.
|> >    Also have a Mitsumi CD drive.
|> 
|> >    2.      Boot DOS.
|> 
|> >    3.      Mount the CD under DOS and run a "boot 386BSD" program off the CD.
|> 
|> >Not quite as mysterious and awe inspiring as the first story I heard on
|> >the net.
|> 
|> Well, well...   But we had an inspiring discussion about the possibility and
|> practicality of this "booting from CD" anyway :-)

What on earth is DOS (as mentioned in step 2.) ?
Okay, that was a bit over the top.

How do I go about "mounting" the CD under DOS whe I haven't got any software
drivers for doing just that ?

-Bernard

------------------------------

From: rhoades@cs.unc.edu (John Rhoades)
Subject: Re: Kernels 1.1.41 to 1.1.46 break ramdisk booting.
Date: 23 Aug 1994 23:11:52 -0400

In article <Cv0IBu.L0y@qus102.qld.npb.telecom.com.au>, pclink@qus102.qld.npb.telecom.com.au (Rick) writes:
> ... Kernels since 41 no longer load a
> filesystem image from a floppy disk into the ramdisk.  At the point
> ...

Here's a kludge I made to get ramdisk to work. Surely this isn't the proper
fix for the problem. Use at your won risk, but it seems to work for me.

diff -u ramdisk.c ramdisk.c.jsr
--- ramdisk.c   Wed Aug 10 12:25:58 1994
+++ ramdisk.c.jsr       Tue Aug 23 23:09:10 1994
@@ -115,6 +115,15 @@
                block = tries;
                bh = breada(ROOT_DEV,block+1,BLOCK_SIZE, 0,  PAGE_SIZE);
                if (!bh) {
+                       check_disk_change(ROOT_DEV);
+                       bh = breada(ROOT_DEV,block+1,BLOCK_SIZE, 0,  PAGE_SIZE);
+               }
+               /* a kludge to make the ramdisk work. this is certainly not
+               the proper way to fix the problem, but I'm using it until
+               someone who understands does it correctly
+               John S. Rhoades (rhoades@cs.unc.edu)
+               */
+               if (!bh) {
                        printk("RAMDISK: I/O error while looking for super block!\n");
                        return;
                }

------------------------------

Crossposted-To: comp.os.linux.admin,news.software.nn
From: rantapaa@s6.math.umn.edu (Erik E. Rantapaa)
Subject: How fast is your nngrab under Linux?
Date: Wed, 24 Aug 1994 15:50:12 GMT

I am using a 486/66DX2 with 16M ram as a nn database master.  The database
files are on a local drive (IDE) and the files are also exported to the
rest of the network via NFS.  Because of bugs in either nfsd or the kernel
(1.1.46), I have to limit the read size to 2048 (see the referenced
article).

I get a paltry 67 K/sec when I perform something like 'nngrab jpg'.
This is both when performing the nngrab on the linux box and across
the network.  Is this what I should expect from my set up?

Followups have been set to to comp.os.linux.development.

--
Erik E. Rantapaa  --  rantapaa@math.umn.edu  --  <put something here>

------------------------------

From: jonathan@mirror.demon.co.uk (jonathan allen)
Subject: Re: DOSEMU 0.53: Developers and testers needed!
Reply-To: jonathan@mirror.demon.co.uk
Date: Wed, 24 Aug 1994 11:14:53 +0000


I wanted to have a try at DOSEMU0.53, and saw a post that it was at
tsx11-mit.edu:/pub/Linux/ALPHA/private/devel but the 'private' directory
is not open for me to pick it up.  How/where _can_ I find it ?

Jonathan
===============================================================================
Jonathan Allen             | jonathan@miror.demon.co.uk   | Voice: 0271-79023
Barum Computer Consultants | jeremiah@cix.compulink.co.uk | Fax:   0271-24183
===============================================================================

------------------------------

From: matt@vespucci.iquest.com (Matt Midboe)
Subject: Mailing list for discussion of new Linux BBS
Date: 22 Aug 1994 01:54:28 -0500

I've seen a lot of posts about people who are curious about running a
BBS on linux. The BBS software available does indeed have some nice
features, but the authors knew what they were looking for and did an
excellent job putting them together. What I would like to see happen
with this mailing list is a discussion amongst linuxers (or anyone for
that matter) of what a good Linux BBS should do. Then we can put all
these ideas into some sort of executable program. If you are
interested in subscribing then send mail to:

        majordomo@magellan.iquest.com

with the words:

        subscribe linux-bbs

in the body of the message. The subject doesn't matter at all. 

------------------------------

From: card@masi.ibp.fr (Remy CARD)
Subject: Re: Write-Through the File System Cache?
Date: 24 Aug 1994 15:39:24 GMT

In article <DHOLLAND.94Aug22112723@scws3.harvard.edu>,
David Holland <dholland@scws3.harvard.edu> wrote:
] 
]  >    Thanks :-)  BTW, the ext2fs synchronous writes do not concern the
]  > files data but the metadata (bitmaps, directory entries, inodes, indirect
]  > blocks).  Even with the synchronous attribute set on a file, data is still
]  > written to the buffer cache and written back to the disk when update runs.
] 
] Writing metadata and not file data synchronously is DANGEROUS. Are you
] sure this was a good idea? 

        I know that.  Actually, my goal when implementing synchronous updates
on metadata was only to emulate the BSD behavior to be able to tell the BSD
folks `Synchronous updates?  Yes, we have them too, but we don't use them' :-)

        Maybe, I should rename the mount option from `sync' to
`stupid_bsd_sync'? :-)

] --
]    - David A. Holland          | -- "Do you have a moment?"   -- "Yes.
]      dholland@husc.harvard.edu | Unfortunately, it's a moment of inertia."

                Remy

------------------------------

From: veit@borneo.gmd.de (Holger Veit)
Crossposted-To: comp.unix.bsd,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc,comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.unix.pc-clone.32bit
Subject: Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload.
Date: 24 Aug 1994 18:10:30 GMT

Bernard Steiner (bs@Germany.EU.net) wrote:
: 
[...]
: What on earth is DOS (as mentioned in step 2.) ?
: Okay, that was a bit over the top.
: 
: How do I go about "mounting" the CD under DOS whe I haven't got any software
: drivers for doing just that ?
: 
Well, all the drivers you need for that are provided on the CD :-)

--
         Dr. Holger Veit                   | INTERNET: Holger.Veit@gmd.de
|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...

------------------------------

From: we34329@vub.ac.be (DE KERPEL SVEN)
Subject: PRIORITY make an undelete command
Date: 24 Aug 1994 18:02:04 GMT

Somebody should REALY make ASAP an undelete function for Linux.
An rm is dangerous as hell. 

I just typed rm * .bak in stead off rm *.bak

Greetings,

Sven De Kerpel

------------------------------

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Crashes w/ new kernels
Date: 24 Aug 1994 18:39:05 +0200

In comp.os.linux.development, article <MIKE.94Aug24112613@moocow.math.nat.tu-bs.de>,
  on.dowling@zib-berlin.de writes:
> 
>  - in debugging dumps like the above, it helps enormously if you can
>    look up what the EIP value means.  The hex value as such doesn't help

The simplest way to do this is the following:
- Add "-g" to the CFLAGS line in linux/Makefile.
- make clean ; make
- Check if the old and the new kernels differ;
  if so, install the new kernel, reboot, reproduce the error.
- gdb tools/zSystem /proc/kcore
- l *0Xxxxxxx <- the xxxes are the EIP value

gdb should now show you the line where the error is.

Building the kernel with debugging information does slow down the kernel
make and takes some MB disk space, but it helps a lot when you try to
figure out what went wrong.

-- 
I don't know if we're having an argument; but if we are, I'm right!
-- 
Matthias Urlichs        \ XLink-POP Nrnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstrae 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nrnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
          PGP: 1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE 
      Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

------------------------------

From: vchui@dra.hmg.gb
Subject: Re: Future of Linux
Date: 24 Aug 1994 16:41:44 GMT
Reply-To: vchui@dra.hmg.gb

Hi,

After reading many postings concerning the "Future of Linux" and other topics
related to the design of user interface,  I have some opinions and suggestions.

As an user of unix/linux, I have found the concepts such as devices as files
and pipe are very useful.  Together with a set of filters and shell commands
based on a command line interface, I think unix/linux offers a consistent user
interface and it brings the power of a dump character based terminal/keyboard
to its full.  For information are bit sequences, whereas computers are machines
to transform bit sequences from one form to another according to a supplied
sequence of instructions which is also a bit sequence.  Characters or ascii
characters are simple elements for encoding bit seqences.  I believe that an
unix/linux dump terminal/keyboard interface offers a good environment for users
to do bit sequence transformation.

Nowadays in the age of graphics terminals and mice, it would be nice if a
consistent graphical analogy of the character based interface can be found.
Would it require a new graphical encoding system from bottom up instead of
ascii in the operating system design?

I think the graphical user interface (GUI) and command line interface (CLI) 
designs have different merits.  CLI offers flexibility and consistence, but it
can be psychologically threatening to new users.  Since a new user can only see
a prompt on the command line and if the commands have strange names such as
cat, ls, awk, etc., or strange sequences such as control-x, escape-x, etc.,
it could be a daunting start.  Just remember the first instance when we were
introduced to computers, most of us did not even know that you have to hit the
return key to execute the commands typed on the command line.  GUI offers a
slightly different enviroment.  All basic commands are shown on the screen as
buttons.  Whereas button pushing is well-known to anyone who has experience
with radio and tv sets, so learning is minimal.  Fundamentally, however, both
GUI and CLI require button pushing actions as means to execute commands.  So,
their difference is that a GUI shows the commands while a CLI does not.  A GUI
presents the users a picture whereas a CLI presents a prompt!  Most GUIs can
only allow commands to be executed one at a time.  Whereas a CLI may, as in
unix/linux, allows commands to form combinations and outputs of commands are
piped.

It would be really nice if a GUI can incorporate the concepts of pipe.  For
a CLI, it would be nicer if more information could be displayed.  For example,
a line which scrolls text horizontally can be used to display the commands in
$path, or to show the action of command selection by the shell, or to show the
command history, or contents of a directory.  If these text displayed, or even
any strings on the screen, can be grabed and brought on to the command line
using a combination emacs's incremental search and hypertext action, it may
be a way to implement the paradigm of point and shoot in a CLI environment.

  Victor

\quote

"... A totally spiritual machine.  If you write with goose quill you scratch
the sweaty pages and keep stopping to dip for ink.  Your thoughts go too fast
for your aching wrist.  If you type, the letters cluster together, and again
you must go at the poky pace of the mechanism, not the speed of your synapse.
But with the computer your fingers dream, your mind brushes the keyboard, you
are borne on golden pinions, at last you confront the light of critical
reason with the happiness of a first encounter. ..."

                     Umberto Eco, in "Faucalt's Pendulum"

\unquote

------------------------------

From: jh_smith@ping.com (James H. "Skip" Smith)
Subject: Linux for DEC Alpha platform?
Date: Wed, 24 Aug 1994 00:17:25


Does a version of Linux exist for the new DEC Alpha workstations?  A 
co-worker mentioned to me that he thought a version of Linux for the Alpha 
was available, or at least "in the works". 

I currently have an AXP 150 at the office (running OpenVMS) and I would love 
to load Linux on it.

Any info will be greatly appreciated!

James H. Smith
jh_smith@ping.com
 ______________________________________________ 
| ----->     James H. "Skip" Smith      <----- |
|               Systems Analyst                |
| jsmith@skipsys.ping.com  2605 Sequoia Drive  |
| (314) 922- 2307          St. Peters, MO 63376| |______________________________________________|


------------------------------

From: habaoch@eng.auburn.edu (Bao Chau Ha)
Subject: Re: Appletalk?
Date: Wed, 24 Aug 1994 18:36:54 GMT

In article <rob.324.001F3BE0@eats.com> rob@eats.com (Rob Newberry) writes:
>
>CAP 6.0 pl 192 will work on Linux provided you apply the patch on sunsite.  
>However, this version will not support EtherTalk.
>
>We are currently adding support for EtherTalk, and are pretty close.  However, 
>this support is for Phase 1 only -- we hope to add Phase 2, but according to 
>Alan Cox, it may be quite difficult until the kernel actually supports 
>multicast directly.
>
Please forgive my ignorance.  But why do we need the kernel to actually
support multicast directly for EtherTalk Phase 2 support?  I thought
EtherTalk Phase 2 can ride on the same 802.3 packet that Linux is
already supporting.

Bao

------------------------------

From: ken@coho.halcyon.com (Ken Pizzini)
Subject: Re: Disassembler for Linux?
Date: 24 Aug 1994 07:09:22 GMT

In article <32jbmi$77t@nic.umass.edu>,
ADAM P JENKINS <apj@twain.ucs.umass.edu> wrote:
>  Hi, does anyone know of a disassembler for Linux?  I just want
>something like 'dis' on unix, that will read an object file and give
>me the assembler code.  Thank you.

Try "objdump -d".  If your distribution doesn't come with objdump,
the source can be found in the GNU "binutils" package.

                --Ken Pizzini

------------------------------

From: csgr@cs.ru.ac.za (Geoff Rehmet)
Subject: Re: prob compiling 1.1.46 with gcc 4.6.0
Date: 24 Aug 1994 19:24:43 GMT
Reply-To: csgr@cs.ru.ac.za

In <33c65g$n66@senator-bedfellow.MIT.EDU> andy@eng.kvaerner.no (Andrew Walker) writes:

>WARNING: some people have had bad experiences compiling the
>kernel with 2.6.0 - it is rumoured to screw some of the inline
>assembler code in certain drivers. Works for me!

There does appear to be a problem with 2.6.0 -- we are experiencing
some problems with gcc 2.6.0 on FreeBSD 2.0.0.  There is work underway
on submitting a bug report.  (I expect that Linux might get bitten in
similar ways.)

Geoff.
--
 Geoff Rehmet, Computer Science Department,   | ____   _ o         /\
  Rhodes University,  South Africa            |___  _-\_<,        / /\/\
 FreeBSD core team                            |    (*)/'(*)    /\/ /  \ \
     csgr@cs.ru.ac.za, csgr@freefall.cdrom.com, geoff@neptune.ru.ac.za

------------------------------

From: michaelw@desaster.student.uni-tuebingen.de (Michael Will)
Subject: Re: Future of Linux (emacs? lemacs!)
Date: Tue, 23 Aug 1994 19:27:07 GMT

faustus@zilker.net (Bret Patterson) writes:

>Riku Saikkonen (riku.saikkonen@compart.fi) wrote:
>to do the desired functions. With emacs you have to spend hours and
>hours learning how to use it.
Yes, emacs takes some time to learn. 

But I suggest taking a look at lucid-emacs 19.10.

If you are new to it, you will be able to use most of it with the mouse.
The menues are nice.

>If you already know lisp then sure you
>can pick it up real fast, but most users don't know lisp.
You don't need lisp to use emacs. But you need to learn a lot about
it's philosophy - why which keybindings are emacs-standard and get
used to them. This certainly takes time. With lemacs you can just begin
with the menu.

But this does not make a wordprocessor, because it is just plain ascii-
text. So you would have to say: edit \LaTeX-source, and that is where
the learning-curve is getting very steep again. 

I remember there was some interviews-doc application which did wysiwyg
and saves kind of tex-source. prints postscript. This is more like what
you need. And andrews multimedia-system is supposed to have a wysiwyg-editor
too.

>: With even limited commercialism, there is the large problem of greed...
>: 'Hey, I wrote this for 6 months, shouldn't I charge at least $200?!'
If you find someone who pays that? :-) noone prevents you from trying to be
greedy, but the break-even-point might be at a different price and people
will buy elsewhere.

>: >   1- Companies selling Linux CDs and support. They should be asked to
>: >      donate a part of their income back into Linux development.

>: Which company would do such a thing? I.e. what is their gain? Linux is
>: free (and I sincerely hope that it will remain that way)...
XFree86 get's supported by quite some companies as far as I have heard, 
and if it where not the case, we would not have XFree86 as it is now. 
Their gain is being able to use XFree86(tm) in a high-quality state. 

>: >(2) A powerful word processing with GUI interface for Linux. These two

>: Many would argue that the TeX/emacs combination is better than a GUI
>: word processor. It's just that the MS-Windows people are too used to
>: GUIs...

>No emacs takes too much time to learn for your average user. 
And TeX takes even more. I prefer it because of it's high-quality output,
but I am a used to complicated systems.

Concerning quality of output: when I have to look at some 
WordForWindows-output people produce I get real sick... 
it is easy to procude good stuff with these easy-to-use-toys, but it is quite 
as easy to produce complete junk.

Cheers, Michael Will
-- 
  . .       Michael Will <michaelw@desaster.student.uni-tuebingen.de> 
   .   cs-student in Tuebingen, Germany, Europe, Earth, Solar-System, [...]
 <HR><A HREF="http://wsiserv.informatik.uni-tuebingen.de/~will">Click here</A>

------------------------------

From: kubla@goofy.zdv.Uni-Mainz.DE (Dominik Kubla)
Subject: Re: Linux for DEC Alpha platform?
Date: 24 Aug 1994 07:36:41 GMT


Rumour has it that DEC offerd an Alpha PC to Linus in order to port Linux to
AXP. Also there is no Linux/AXP at the moment, it might eventually show up
in the (hopefully near) future. Stay tuned ...

Dominik
--
===========================================================================
eMail: Dominik.Kubla@Uni-Mainz.DE    sMail: Dominik Kubla, Lannerstrasse 53
                                            55270 Ober-Olm, F.R. of Germany
>>> Save the environment NOW! <<<           ******  European  Union  ******

------------------------------


** 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
******************************
