Subject: Linux-Development Digest #854
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, 24 Jun 94 08:13:07 EDT

Linux-Development Digest #854, Volume #1         Fri, 24 Jun 94 08:13:07 EDT

Contents:
  Re: Disk-compression for Linux (William Doyle)
  Re: Disk-compression for Linux (Mihail S. Iotov)
  Taxan mono vid. card & XFree (Jeremy Main)
  Re: [Q] What about Amanda? (Leslie Mikesell)
  Re: Where has Stephen Tweedie gone?? (Robert Sanders)
  Re: Deadlock with unix domain sockets (Brandon S. Allbery)
  computer science (Albert D. Cahalan)
  Slackware Linux - Smalltalk (tf49665@delphi.com)
  Re: Linux/XF86 bug (Jonathan Noel Tombs)
  Re: linux-1.1.20 breaks dosemu0.52 (Rob Janssen)
  Re: Disk-compression for Linux (Rob Janssen)
  Re: VideoBlaster (Rob Janssen)
  Re: Major device number clash (iCS) (Matthias Urlichs)
  Re: Context of signal handler call (Markus Daetwyler)
  Re: Porting libpthreads to Linux? (Tony Gale)
  Re: Wine-940620 (Jochen Hein)
  Re: Bbs software for linux? (Rod Troch)
  Re: question on POSIX.1 & POSIX 1003.4 (Chris Bitmead)
  Re: Major device number clash (iCS) (Frank Lofaro)
  Re: Hard disks limited to (Brandon S. Allbery)

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

From: wdoyle@hilbert.coe.northeastern.edu (William Doyle)
Subject: Re: Disk-compression for Linux
Date: 24 Jun 1994 02:16:25 GMT


It's been a few days since I last read c.o.l.d, so I don't know how
current this topic is now, but I thought I would toss in my .02 worth.

1st point:
        On my system, most of the bulky text files are already
compressed (e.g. unsused system sources on the CDROM and man pages),
so I don't know how much a compressed file system would really help
me.  I certainly wouldn't expect a 2:1 improvement.  This seems to be
a reasonable approach.

2nd point:
        Someone asked about a package that transparently opens .gz
files as if they were normal files.  The Summer '94 release of the
Yggdrasil CD-ROM supports this.  I have only recently installed it, so
I haven't had time to explore the details, but, all I have to do is to
point my LD_LIBRARY_PATH to /lib/compressed (where it picks up a
special version of libc) and poof, I get transparent decompression of
.gz files.

3rd point:
        Would it be possible to modify /bin/ld to produce a
self-uncompressing executable?  (Of course, I know it's possible --
with computers, everything is virtually possible! :-))  Perhaps
someone who is looking for a summer project my consider this.  This
could be an alternative to the reportedly unreliable gzexe approach.

        It seems to me that a combination of points 2 & 3 could be a
reasonable alternative to a compressed file system.  It is attractive
in that it takes a "policy" decision (to compress or not to compress)
out of the hands of the kernel and places it in the hands of the
user/system administrator.


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

From: iotov@cco.caltech.edu (Mihail S. Iotov)
Subject: Re: Disk-compression for Linux
Date: 22 Jun 1994 23:12:06 GMT

kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:

>phil@zeus.fasttax.com (Phil Howard) writes:

>>vinter@cs.uit.no (Brian Vinter) replies to what
>>kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:


>And, yes, you do have to weigh the costs involved.  If you can't afford
>$1/MB for the storage you need, you will have to take the risks of loss and
>be willing to put up with the lost time in un/recompressing files.  

Are you sure about the lost time ? Since compression makes less data go to
the disk it might be actually faster (especially if your CPU would have been
idle anyway.)    
You also mention that you use backups so you could restore any lost partition.
Moreover, there is lots of software that is not critical, eg. the whole system
except /etc and /usr/local. By the time it crashed, it was probably time to
upgrade to a new distribution release anyway so you might just reinstall.
Admittedly, this may cause inconvinience for the users if you run 24-hour site
with lots of usage, but for the home users it is OK.

I would appreciate a compressed file system.

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

From: jjm2068@u.cc.utah.edu (Jeremy Main)
Subject: Taxan mono vid. card & XFree
Date: 23 Jun 1994 08:35:01 -0600

I have a Taxan 1901 Crystal View 19" Monochrome monitor and card
manufactured by Taxan, Has anyone had any luck getting this type of
configuration to work with XFree? I have linked in the Bdm2 drivers in
(after alot of time/confusion) and I was wondering if anyone has figured out
if this monitor and card are compatable with any of the current Bdm2 drivers.
I have tried all four of them, and none seem to work, I was hoping the Hgc1280
driver would be compatable, but it does not seem to work. I don't know the
specs for the vid. card and I can't afford to call Japan to ask. If
someone has some Technical information about this unit, please pass it on to
me.

        Jeremy
        jeremy.main@m.cc.utah.edu


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

From: les@MCS.COM (Leslie Mikesell)
Crossposted-To: comp.os.linux.admin
Subject: Re: [Q] What about Amanda?
Date: 22 Jun 1994 22:49:35 -0500

In article <2u85p0$tsl@serra.unipi.it>,
Gioacchino La_vecchia <gio@cli.di.unipi.it> wrote:
>Anybody working with amanda on linux systems?
>
>(amanda is the popular multi-backup client/server program)

I'd expect the Ohio State perl script system to work out of the
box, although it requires a common NFS-mounted directory for
all machines involved and probably isn't quite as fast as amanda.

Les Mikesell
  les@mcs.com

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

From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: Where has Stephen Tweedie gone??
Date: 23 Jun 1994 04:02:57 GMT

In article <2u97d8$7si@pianosa.to.sem.it> paolo@to.sem.it (Paolo Zeppegno) writes:

   While I have nothing to say about the reasons why he doesn't seem to be
   with us anymore (maybe a marriage???) there is one thing he promised to
   work on that I really would like to see, that is support for a compressed
   filesystem. (I know about DOUBLE).

I think his job's gotten extremely busy; at least that's the rumor.
Also, Stephen spent a lot of time chasing and fixing a couple of
long-lived subtle bugs in all the Linux filesystems, and that's
exactly the sort of unrewarding work that will put someone off
volunteer work for a while.

Stephen's a great guy, but he's not the only one of us who's capable
of writing a compressed filesystem.  If you really want to see, and
you're a competene programmer, here's your chance to learn a lot about
kernel internals.

   (One other project I would like to know more about is the porting of
   the Sprite/BSD4.4 log structured filesys "lfs"). Now that 4.4bsd is
   available, is anybody working on it? I'm wondering how easy would be
   to do some experience porting lfs under userfs to start playing with
   it in userland.

Well, Remy Card recently said that as soon as he could get the code
for anon. ftp, he'd work at porting it.  I think this may require some
enhancements to Linux's VFS, among other things, so it's likely to be
a big project; I'm sure Remy would appreciate some help.  As for when
4.4BSD will be available for anon. ftp, nobody seems to want to make
it available because of the guaranteed ftp storm.  FreeBSD will
probably have some of the 4.4BSD code incorporated soon (they have to
because of the USL lawsuit), but there's no telling when.  Several
months, at least.

  -- Robert

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Deadlock with unix domain sockets
Date: Thu, 23 Jun 1994 02:26:16 GMT

In article <2uadn6$m7s@zeus.fasttax.com>, phil@zeus.fasttax.com (Phil Howard) says:
+---------------
| iiitac@uk.ac.swan.pyr (Alan Cox) writes:
| >done. If that one worries you just fix linux/net/unix/sock.c to handle the
| >O_NDELAY flag properly.
| 
| Does this mean that the kernel is not organized where all I/O goes through
| a master point of some sort where things like O_NDELAY can be done in a way
+------------->8

O_NDELAY has to be done differently for different devices...

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

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

From: adc@bach.coe.neu.edu (Albert D. Cahalan)
Subject: computer science
Date: 24 Jun 1994 05:13:57 GMT

I would like to know what some of the Linux developers think of their
jobs.  I am considering switching my major from electrical engineering
to computer science.  What would be important to learn?  What might I
end up doing?
--

Albert Cahalan
adc@meceng.coe.neu.edu

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

From: tf49665@delphi.com
Subject: Slackware Linux - Smalltalk
Date: Fri, 24 Jun 94 02:47:42 -0500

 
   Where are the FTP sites for documentations for smalltalk under Linux?
Please email response.

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

From: jon@obelix.cica.es (Jonathan Noel Tombs)
Subject: Re: Linux/XF86 bug
Date: 22 Jun 1994 10:36:21 +0200

In article <mceder.771793614@find2.denet.dk>,
Michael Cederberg <mceder@find2.denet.dk> wrote:
>Hi there!
>
>I have discovered something that looks like at bug in Linux or XFree86:
>Try typing "kill -9 -1" in an xterm (you don't have to be root). On my
>machine the system locks up.

sounds exactly what I would expect. If you kill the Xserver with a SIGKILL
all unicies forbit the program trapping the code and so the server dies 
with your card in graphics mode, and the VT in raw/graphics mode. 

Whats the bug, linux is still runing if you had a dumb terminal or a network
you could still use the machine, just some idiot has left a dead Xserver
on the console to stop you loging in. AIX/Auxwindows does this all the time
and you don't need to kill the server with a SIGKILL on aix, xpilot is
enought....


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Reply-To: pe1chl@rabo.nl
Date: Wed, 22 Jun 1994 06:49:51 GMT

In <2u706h$pab@newshost.lanl.gov> tjc@beta.lanl.gov (Timothy J. Corcoran) writes:

>In article <81264.73.772178337@novell1.rz.fht-mannheim.de> 81264@novell1.rz.fht-mannheim.de (RAINER SCHIELE INFORMATIK) writes:
>>Hello
>>
>>Yesterday i compiled dossemu0.52. When i start it, i can not enter more then
>>one keystroke. My display locks then up. Using rawkey off, give me the 
>>chance to switch to another vt and kill the process. The Problem is mentioned
>>in the HOWTO(keybint on), but this must be another mistake. When using 
>>linux-1.1.19 dosemu0.52 runs.
>>
>>Rainer

>I also am seeing a strange 'feature' in dosemu0.52, though it is under 1.1.19.
>After a clean compile, I try to run in a vt.  It goes as far as saying that no
>errors were detected parsing the config file and then just hangs.  Is this 
>possibly due to rawkey on?

There are known problems in this area.  You need to give more info.
Try to experiment with your "video" statement in the config file.

>The funny thing is when I am in X, I can run it in
>a window with the vga font from xdos and it works!  The only bad thing is that
>I lose my mouse from then on until I kill the windows manager.  Any suggestions?

Don't try to use the mouse in dosemu (either by enabling it from the config
file or loading a mouse driver).
People are working on this, and sometimes I could get the mouse operating
OK in dosemu, but the problem of sharing it between dosemu and X has not
been solved, I think.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Disk-compression for Linux
Reply-To: pe1chl@rabo.nl
Date: Wed, 22 Jun 1994 06:56:22 GMT

In <Crr53u.AoJ@sci.kun.nl> pieterh@sci.kun.nl (Peter Herweijer) writes:

>iiitac@uk.ac.swan.pyr (Alan Cox) writes:

> >This is partly true. However the bits of information lost per bit error for
> >a compressed file is much higher than for an uncompressed one.

>Who cares?  In both cases you'll have to dig up your backups.

On a compressed system it is more likely that your last backup is the
only point to which you can recover (i.e. ALL changes after that are
lost) than with an uncompressed system.  Certainly when directory and
allocation information is compressed as well.

>Anyway, modern drives do a good job at error recovery.

In what way did error recover change in modern drives?

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: VideoBlaster
Reply-To: pe1chl@rabo.nl
Date: Wed, 22 Jun 1994 06:59:48 GMT

In <MJO.94Jun21130003@piglet.ra.phy.cam.ac.uk> mjo@mrao.cam.ac.uk (Martin Oldfield) writes:

>Has anyone started work on a device driver for Creative Lab's
>VideoBlaster ?

Earlier posts on this topic indicate that the place to start work is
"getting the hardware specs" on this board...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Major device number clash (iCS)
Date: 24 Jun 1994 10:53:45 +0200

In comp.os.linux.development, article <1994Jun23.165244.21889@dcs.warwick.ac.uk>,
  Nick.Holloway@dcs.warwick.ac.uk (Nick Holloway) writes:
> 
> BTW:  The latest MAKEDEV will be released mid July, after I have moved
> to a new job, and settled the business of net-connectivity.  It will
> allow the parsing of /proc/devices to determine the major device number.
> 
Two points..:
- Ask Linus to PLEASE split /proc/devices into separate files for character
  and block devices.
- Change register_*device to auto-allocate the first (or perhaps better,
  last) free major device if it is passed major number zero.
  I really dislike allocating fixed numbers for drivers that don't need them.

... and a feature request:
- Let MAKEDEV have a flag which remembers the old settings (maybe copy
  /proc/devices to /dev/DEVICES) and silently quit if nothing has changed.
  That way MAKEDEV can be used safely when booting.

  In fact, MAKEDEV should probably default to only create "new" and
  "changed" devices and leave the rest alone.

Opinions?

-- 
Yow!  And then we could sit on the hoods of cars at stop lights!
                -- Zippy the Pinhead
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: mdaetwyl@iiic.ethz.ch (Markus Daetwyler)
Subject: Re: Context of signal handler call
Date: 24 Jun 1994 07:28:23 GMT

In article <1994Jun23.131320.6295@imec.be>,
Steven Buytaert <buytaert@imec.be> wrote:
>  You should check out the signal.h file in the linux/include/linux
>  directory. You'll see there that the definition of a signalhandler
>  is as you describe, a function taken a signal as a parameter.
>
>  You'll see also that there is another definition 'ifdef' ed out,
>  that takes a sigcontext_struct as second parameter. The 
>  sigcontext_struct however is described later in the include file.
>

Thank you for your help: it seems I should update my Kernel sources
more often. I only had kernel 1.0.8, and in its signal.h there's
no sigcontext_struct. I've got now the new sources and just discovered
the sigcontext_struct. Well, that should take me a step further.

Markus Daetwyler
mdaetwyl@iiic.ethz.ch


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

From: gale@minotaur.dra.hmg.gb (Tony Gale)
Crossposted-To: comp.os.linux.kernel
Subject: Re: Porting libpthreads to Linux?
Date: 24 Jun 1994 09:14:25 GMT

Yves Arrouye (arrouye@petole.imag.fr) wrote:
: Hello,

: I would like to port Mueller et al.'s libpthreads (ftp.cs.fsu.edu:/pub/PART/)
: to Linux, but I am having a lot of problems because I really do not know where
: to find the information I need.
:       Did someone do the port? If so, where can I find it? If not, does
: someone volonteer to help me? The informations I need are relative to the

There is a different implementaion of pthreads that should compile
out of the box on Linux at:

rtfm.mit.edu /pub/pthreads
   
 _____________________________________________________________________________
|        Tony Gale           |         Stop whinging and start Wine'ing       |
|                            | http://daedalus.dra.hmg.gb/gale/wine/wine.html |
|  gale@minotaur.dra.hmg.gb  |                                                |
 -----------------|  This ^ stands for Great Britain  |-----------------------
                  | All opinions expressed are my own |
                  -------------------------------------

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

From: Hein@Student.TU-Clausthal.de (Jochen Hein)
Subject: Re: Wine-940620
Date: Fri, 24 Jun 1994 07:40:37 GMT

In article <CruL87.FAy@info.bris.ac.uk> ccnjb@sun.cse.bris.ac.uk (NJ. Bruton) writes:

> I've just built wine940620 but nothing now works (including sol.exe)
> Have I made a mistake or has this release broken something ?

- This information is not enough to help you. (Kernel/libc/XFree86-versions)
- You should probably ask in the wine-users-mailing-list
- Remember that Wine is currently only a developers ONLY release.

I guess, you run a kernel 1.1.2x, which broke the signal-handling of Wine

Jochen

--
     The problem with troubleshooting is that the trouble shoots back!

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

From: troch@gandalf.Rutgers.EDU (Rod Troch)
Subject: Re: Bbs software for linux?
Date: 21 Jun 94 17:41:00 GMT

>>>>> "Andrew" == Andrew Grillet <Andrew.Grillet@purplet.demon.co.uk> writes:
        Andrew>  -=> On 04-16-94  23:31, Shawn Rhoads posted to All <=-
 SR> I was wondering if anyone can suggest a good BBS package for Linux,
 SR> complete with source code?
        Andrew>  I want one too =                                   
        Andrew>  Preferably with good documentation.

A friend of mine is running Waffle on Linux.  Not shareware, but
worth the money.

-Rod

--
--PGP 2.3 Public Key Available (finger me or ask for it)
If you yell try : Rod Troch                  | Zeta Beta Tau
 internet       : troch@gandalf.rutgers.edu  | 
 bitnet         : troch@zodiac               | Linux Enthusiast
Rutgers University - Faculty of Arts and Sciences / History Dept.
                   - Microcomputer Analyst (Network Admin)

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

From: chrisb@cssc-syd.tansu.com.au (Chris Bitmead)
Subject: Re: question on POSIX.1 & POSIX 1003.4
Date: 23 Jun 1994 13:52:54 +1000

p2_copel@banana.uwe.ac.uk (P Copeland) writes:

>       Interprocess communication      [x] Posix.4 again threw out SysV's version
>                                           and decided to use special files???
>                                           sounds crazy to me.

It's no wonder Posix threw out the hopeless SysV Ipc. Not using file
descriptors means you can't select on an SysV ipc channel. Using special
files sounds like the way to go. It keeps the Unix paradigm of
"everything's a file". SysV Ipc is also flawed in that two processes
cannot guarantee a unique ipc key without writing the key value to a file
anyway, thus defeating the purpose of avoiding files.


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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Major device number clash (iCS)
Date: Thu, 23 Jun 94 18:46:13 GMT

In article <1994Jun23.162834.18705@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>In article <2uauvn$svq@sun.cais.com>, ericy@cais.cais.com (Eric Youngdale) says:
>+---------------
>| In article <2u6p3g$18nh@serra.unipi.it>,
>| Romano Giannetti <romano@pimac2.iet.unipi.it> wrote:
>| >Only to point out to all around here that iBCS2 and the PC sound
>| >driver (for reference: pcsndrv-0.6 ibcs-940526) use the same major
>| 
>|      It would seem that neither the iBCS2 nor the sound driver has 
>| officially reserved major number 30.  Take a look in include/linux/major.h.
>| I think that since we (iBCS2) got there first that we should get it, but 
>+------------->8
>
>Last time I checked, Linux only supported 32 major device numbers... and we're
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>about to run into the limit.  I hit this problem also, and took the same
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>solution (change iBCS) because (a) it was more convenient and (b) PCSNDRV was
>already in my kernel :-)

The change required to the kernel to increase this limit (up to a maximum 
of 255) is absolutely trivial. Just change in linux/include/linux/major.h

#define MAX_CHRDEV 32
and
#define MAX_BLKDEV 32

to the desired value and recompile.



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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Hard disks limited to
Date: Wed, 22 Jun 1994 01:52:22 GMT

In article <1.9615.2382.0N27D143@dscmail.com>, john.will@dscmail.com (John Will) says:
+---------------
| P > >There is a standard called "enhanced IDE" that should solve those
| P > >problems.
| P >Yes.  No bullshit, no physical and logical geometry hassles, just
| P >Linear Block Addressing (LBA).
| Gee, why don't we call it SCSI? :-)
+------------->8

Because it still doesn't allow simultaneous commands to multiple targets.  :-)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

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


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