Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA06647; Sat, 2 Dec 95 01:16:14 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA10484; Sat, 2 Dec 95 01:15:12 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id BAA11090 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Sat, 2 Dec 1995 01:13:57 -0500 Message-Id: <199512020613.BAA11090@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Sat, 2 Dec 95 01:13:53 EST Subject: Linux-Development-System Digest #72 Linux-Development-System Digest #72, Volume #2 Sat, 2 Dec 95 01:13:53 EST Contents: Re: 8088 port (David J. Liu) Re: why no slackware bugfixes? (Mark A. Stevens) Re: Weak Thread Support: Linux Weakness ? (Chris Adams) Re: CTRL-ALT-DEL under XFree86 (Markus Gutschke) Re: Has any one heard of VAX? (Grant Edwards) Re: kernel 1.3.45 and PPP --> not working :((( (Alex Martelli) Re: Netscape 2.0 breaks RedHat 2.0 Linux (Alex Martelli) Re: Latest Stable Kernel ??? (Andries Brouwer) Re: pipe troubles (Robert Budzynski) Error in slakware ioctl.h ???? (Neil Radisch) Re: Anyone working on a tape file system ? (Hamish Macdonald) Re: Standardized Printing for Linux (Albert Cahalan) Re: [suggestion] about pty's new major number ("Theodore Ts'o") ---------------------------------------------------------------------------- From: liudj0@minerva.cis.yale.edu (David J. Liu) Subject: Re: 8088 port Date: 1 Dec 1995 19:19:02 GMT Dan Newcombe (newcombe@aa.csc.peachnet.edu) wrote: # . . . # Because 8088's are cheaper than dirt :) There are a lot of them out there, # and they are powerful enuff to do some basic functions. Also, it's a lot # easier to put 8088's in an embedded system (ie. Linux for toasters.) A few years ago, rumor said that Microsoft was working on Windows for home electronics, like toaster and walkman. We ought to have GNU versions too. ------------------------------ From: xmas@uxa.ecn.bgu.edu (Mark A. Stevens) Subject: Re: why no slackware bugfixes? Date: 1 Dec 1995 14:39:25 -0600 In article <49ng60$i9k@smurf.noris.de>, Matthias Urlichs wrote: >In comp.os.linux.development.system, article , > jin@spdcc.com (Jerry Natowitz) writes: >> >> Unbelievable at it might seem, there was once a bug in IEFBR14 [...] Several in fact. It took several PTFs (Program Temporary Fixes) to kill that bug. The first was that it didn't zero out register 15 (the return code). >There's at least one other bug -- it's called "IEFBR14". Why didn't they >call the program NOOP or DUMMY? It didn't do a no operation. It set the return code to 0. The purpose was to allow IBM Job Control Language to set up files for later job steps. You needed a program to run and it had to return a non-zero return code to indicate successfull completion. BR 14 is the IBM Assembler mnemonic to branch to the contents of register 14, which by standard programming conventions contained the address of the calling program. The nonsensical part was the IEF, except it did indicate the program was an IBM utility. >Unix command names are stupidly cryptic too, but at least they're shorter. >;-) awk, I just rm'd protoize. Do I need it? And what about xferstats?! ;-> If you know enough about the OS, it can always be said it makes sense. -- Mark A. Stevens Phone: 708-235-2204 Systems Programmer Internet: xmas@uxa.ecn.bgu.edu Educational Computing Network BITNET: XMAS@ECNUXA.BITNET Board of Governors Universities VMSHARE: ECE/MARK ------------------------------ From: cadams@fly.HiWAAY.net (Chris Adams) Subject: Re: Weak Thread Support: Linux Weakness ? Date: 30 Nov 1995 22:25:58 -0600 =====BEGIN PGP SIGNED MESSAGE===== In article <49krmb$aa8@zippy.cais.net>, Tim Bass wrote: >William S. Gribble (grib@cs.utexas.edu) wrote: >First he decides to launch a flame.... I don't see much of a flame here. You said in your post that Linux is weak in the thread area, which it isn't, so he corrected you. If you call this a flame, you need to line your terminal with a little more asbestos. >Bill: > >I think that you're speaking from ignorance. There are at least two >: implementations of the POSIX thread API for Linux, one of which (Chris >: Provenzano's MIT PThreads) I have been using for a couple of years in >: a distributed object system for real-time vision research. What kind >: of ``multithreaded environment'' is it that Linux doesn't have? > >Then he states that Linux does not have kernel thread, which was the >basis of my original question. You conveniently deleted your original post, that said NOTHING about kernel threads. Here is YOUR post: - -- The next generation netstuff seems to be moving into the Java world. Java requires a multithreaded environment. Linux is very weak in the multithread arena. Is this an omen? Or a wake up call? Tim - -- Bill's response answers your question. Linux is NOT 'very weak in the multithread arena.' There are a couple of implimentations of threads. Yes, there are no kernel threads, but as Bill pointed out, >Bill again: > >: It would be nice if Linux had kernel threads, but on a non-SMP machine >: it just doesn't matter as far as performance. POSIX threads are what >: every other UNIX either has or is moving towards, and that's good enough >: for Java. Then you end up with: >What every happened to the days when jerks like this were not a part >of the comp.os.linux.* groups. > >Please Mr. Gribble, take your pedantic, anal attitude elsewhere, OR >just don't answer questions. If you don't have a nice answer, just >don't answer. You seem to be the jerk here. You ask a kind of vague question with false assumptions, someone tries his best to answer you, and then you flame him for trying. By the way, I don't think Java requires a multithreaded environment, since it works under Netscape 2.0b3. I don't remember (I could be wrong here, but) an a.out version of any threads package, so unless Netscape implemented their own version of threads for Linux (unlikely, since they claim not to support Linux), Java can be done without threads. Now, it might could be done more _efficiently_, but that is another story. =====BEGIN PGP SIGNATURE===== Version: 2.6.2 iQEVAwUBML6DxyJFQNhhNdm5AQHPbAf9EcR+Zy9DiemD5Zq48+qvZtGrp436kn00 QFrZdLWAQjJOvrMX2fd5BGNLcA5E9pPqDWsgNeixkj3+e8dSItQEOSS0B+Z4JFzk eMugvSTvX1di1aATzohdYMiO40AmyaYljvtBVI153X25r0gIsaD7/fwbKxy+T0kl gO/H88yvcFahh3GRvMJjYDgzfj3ODKzI8+GZMjayoI5lfDB6vmdEMS6mflQ54wVi tRE5YDGPYgy3OVzEAWTIZkTgFLBDSMyd4CMjIE5v0KXIX29YcQ0/lM1fSzmtSddK 33MikeQHxHoq8pqBe4qm2+IbgyYo/iTCZympGBxtFYIOCThAWREVpw== =XOIX =====END PGP SIGNATURE===== -- Chris Adams (cadams@HiWAAY.net) Finger for PGP public key "So, if anybody wants to have hardware sent to them: don't call me, but instead write your own unix operating system. It has worked every time for me." - Linus Torvalds, author of Linux (Unix-like) OS ------------------------------ From: gutschk@math.uni-muenster.de (Markus Gutschke) Subject: Re: CTRL-ALT-DEL under XFree86 Date: 02 Dec 1995 00:15:31 GMT In article <49k4mk$efa@news.uni-paderborn.de> aurel@uni-paderborn.de (Aurel Balmosan) writes: > I am searching for a patch that enables the CTRL-ALT-DEL boot key under > XFree86. (I think a patch in the keyboard driver that disable the > reassignment of this key combination should work) *** linux-1.3.39/drivers/char/keyboard.c.orig Sat Oct 14 09:58:47 1995 --- linux-1.3.39/drivers/char/keyboard.c Tue Oct 31 21:56:15 1995 *************** *** 15,20 **** --- 15,24 ---- * dynamic function/string keys, led setting, Sept 1994 * `Sticky' modifier keys, 951006. * + * Added support for CTRL-ALT-DEL detection and SAK handling when in + * medium raw or raw mode (June 1995) + * (Markus Gutschke, gutschk@math.uni-muenster.de) + * */ #define KEYBOARD_IRQ 1 *************** *** 501,506 **** --- 505,527 ---- } else rep = set_bit(keycode, key_down); + #if !defined(CONFIG_DONOTHANDLECTRLALTDEL) || \ + !defined(CONFIG_DONOTHANDLESAK) + if (raw_mode || kbd->kbdmode == VC_MEDIUMRAW) { + int shift_final = shift_state ^ kbd->lockstate; + ushort *key_map = key_maps[shift_final],keysym; + if (key_map != NULL && + (KTYP(keysym = key_map[keycode]) == (0xF0|KT_SHIFT) + #ifndef CONFIG_DONOTHANDLECTRLALTDEL + || keysym == (0xF000|K_BOOT) + #endif + #ifndef CONFIG_DONOTHANDLESAK + || keysym == (0xF000|K_SAK) + #endif + )) + (*key_handler[KTYP(keysym)-0xF0])(KVAL(keysym),up_flag); } + #endif + if (raw_mode) goto end_kbd_intr; *************** *** 739,745 **** static void SAK(void) { do_SAK(tty); ! #if 0 /* * Need to fix SAK handling to fix up RAW/MEDIUM_RAW and * vt_cons modes before we can enable RAW/MEDIUM_RAW SAK --- 760,766 ---- static void SAK(void) { do_SAK(tty); ! #if CONFIG_DONOTHANDLESAK /* * Need to fix SAK handling to fix up RAW/MEDIUM_RAW and * vt_cons modes before we can enable RAW/MEDIUM_RAW SAK *** linux-1.3.39/drivers/char/defkeymap.map.orig Fri Feb 24 20:38:27 1995 --- linux-1.3.39/drivers/char/defkeymap.map Tue Oct 31 21:56:15 1995 *************** *** 223,229 **** keycode 97 = Control keycode 98 = KP_Divide keycode 99 = Control_backslash ! control keycode 99 = Control_backslash alt keycode 99 = Control_backslash keycode 100 = AltGr keycode 101 = Break --- 223,229 ---- keycode 97 = Control keycode 98 = KP_Divide keycode 99 = Control_backslash ! control keycode 99 = SAK # used to be Control_backslash alt keycode 99 = Control_backslash keycode 100 = AltGr keycode 101 = Break *** linux-1.3.39/drivers/char/defkeymap.c.orig Fri Feb 24 20:38:27 1995 --- linux-1.3.39/drivers/char/defkeymap.c Tue Oct 31 21:56:15 1995 *************** *** 18,24 **** 0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301, 0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf03c, 0xf10a, 0xf10b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, ! 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603, 0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116, 0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, --- 18,24 ---- 0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301, 0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf03c, 0xf10a, 0xf10b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, ! 0xf30e, 0xf702, 0xf30d, 0xf20f, 0xf701, 0xf205, 0xf114, 0xf603, 0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116, 0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, *** linux-1.3.39/arch/i386/config.in.orig Tue Oct 31 21:57:14 1995 --- linux-1.3.39/arch/i386/config.in Tue Oct 31 21:58:45 1995 *************** *** 65,70 **** --- 65,73 ---- source fs/Config.in source drivers/char/Config.in + bool 'Supress CTRL-ALT-DEL handling when in raw-mode' CONFIG_DONOTHANDLECTRLALTDEL n + bool 'Supress SAK handling (bound to CTRL-SYSREQ)' CONFIG_DONOTHANDLESAK n + bool 'Use soft SAK' TTY_SOFT_SAK y mainmenu_option next_comment comment 'Sound' ------------------------------ From: grante@reddwarf.rosemount.com (Grant Edwards) Subject: Re: Has any one heard of VAX? Date: Tue, 28 Nov 1995 22:42:48 GMT Jordi Guillaumes i Pons (jguilla@ibm.net) wrote: : Stephen Knilans wrote: : - The CLI (DCL) lacks some features. I _really_ miss pipes and : redirections. The /OUTPUT=XXX or DEFINE/USER SYS$INPUT... thing is a : poor substitute for the real thing... And I think it _can_ be done using : mailboxes. Yes, it can. The DECShell package included a v7 Bourne shell that impelmented pipes using mailboxes. It also included a surprisingly complete set of v7 utilities including awk, sed, nroff, lex, yacc, etc. It worked, but it was slow. Creating processes (which happens a _lot_ if you are in the habit of stringing together a handful of commands to do something useful) involves a lot more overhead on VMS than on Unix. As I remember it, running a program from DCL didn't create a new process (the program ran in the same process as DCL somehow). Running a program from the Bourne shell has to create a new process. -- Grant Edwards | Microsoft isn't the | Yow! When you said ``HEAVILY Rosemount Inc. | answer. Microsoft | FORESTED'' it reminded me of | is the question, and | an overdue CLEANING BILL.. grante@rosemount.com | the answer is no. | Don't you SEE? O'Grogan | SWALLOWED a VALUABLE COIN | COLLECTION and HAD to murder | the ONLY MAN who KNEW!! ------------------------------ From: alex@cirfid.unibo.it (Alex Martelli) Subject: Re: kernel 1.3.45 and PPP --> not working :((( Date: Fri, 01 Dec 1995 23:34:04 MET Reply-To: alex@cirfid.unibo.it Pavel Korensky writes: ... >yesterday, I tried to compile kernel 1.3.45. Everything seems OK, except PPP. >I compiled kernel with SLIP and PPP support (I triple check it). >When I tried to run pppd, I got the message "PPP is not on system" or >similar. I think you just need to download and install the very latest release of pppd. Alex -- Alex Martelli, Bologna, Italia -- DISCLAIMER: these are only MY opinions...! __ Man has no Body distinct from his Soul... | William Blake \/ Energy is the only life, and is from the Body... | DID know Energy is Eternal Delight. | where it's at... ------------------------------ From: alex@cirfid.unibo.it (Alex Martelli) Subject: Re: Netscape 2.0 breaks RedHat 2.0 Linux Date: Fri, 01 Dec 1995 23:45:01 MET Reply-To: alex@cirfid.unibo.it Michael Breuer writes: ... >It would seem that netscape takes whatever memory it can get. If you >run as root, this is ALL your memory. >Solution: Don't run netscape as root. ... >> ls: can't map '/dev/zero' >> ls: can't map '/dev/zero' >> ls: can't load library 'libc.so.5' Another possible solution is either to upgrade to a very recent kernel (I think anything over 1.3.40 should work, though I only tried 1.3.45), or, if you're a 1.2.13 aficionado like me, to fix your 1.2.13 kernel source by applying this one-line patch to mm/mmap.c which Linus himself suggested...: *** mmap.c.save Tue Nov 28 23:23:03 1995 --- mmap.c Tue Nov 28 23:23:21 1995 *************** *** 199,204 **** --- 199,205 ---- if (fd >= NR_OPEN || !(file = current->files->fd[fd])) return -EBADF; } + flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); return do_mmap(file, get_fs_long(buffer), get_fs_long(buffer+1), get_fs_long(buffer+2), flags, get_fs_long(buffer+5)); } This worked for me (as did uprading to 1.3.45, but I'd rather be running a "production" kernel). Incidentally, rebuilding the kernel with this patch is of course very fast, since (assuming you've ever recompiled your kernel at all, of course!) you only need to redo the "make zImage" and it will only compile one file and relink -- no need to redo the make config/dep/clean rigmarole. Others reported success with upgrading to a recent ld.so (but I tried the very latest, ld.so.1.7.11, and it did nothing for me), or even more obscure "fixes". Alex -- Alex Martelli, Bologna, Italia -- DISCLAIMER: these are only MY opinions...! __ Man has no Body distinct from his Soul... | William Blake \/ Energy is the only life, and is from the Body... | DID know Energy is Eternal Delight. | where it's at... ------------------------------ From: aeb@cwi.nl (Andries Brouwer) Subject: Re: Latest Stable Kernel ??? Date: Fri, 1 Dec 1995 20:47:37 GMT gknitz@netcom.com (Gary K Nitzberg) writes: : I want to undate my kernel. : What is the latest stable kernel you would recommend? 1.3.45 is stable for me. YMMV ------------------------------ From: Robert Budzynski Subject: Re: pipe troubles Date: 29 Nov 1995 14:01:25 GMT I'm not sure whether I understood correctly, but some time ago I had a problem with a version of ksh for Linux that, when passing data through a pipe, seemed to write an extra block of null bytes at the beginning. I junked that shell, and have never seen any problem of this sort with bash. I think it was a known bug of that ksh. Hope this helps, rjb ------------------------------ From: Neil Radisch Subject: Error in slakware ioctl.h ???? Date: 30 Nov 1995 15:16:52 GMT I have the slakware distribution that came with Linux Unleashed. The linux/ioctl.h file defines references IOC_SHIFT. Yet IOC_SHIFT is not defined anywhere. HOWEVER, IOCSIZE_SHIFT is defined. I wonder if IOCSIZE_SHIFT is really what was meant in the reference to IOC_SHIFT (in the definition of IOCSIZE_MAX) Neil ------------------------------ Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc From: hamish@border.ocunix.on.ca (Hamish Macdonald) Subject: Re: Anyone working on a tape file system ? Date: Sat, 2 Dec 1995 02:52:06 GMT >>>>> On Wed, 22 Nov 1995 13:54:31 GMT, >>>>> In message , >>>>> Michael Ashton wrote: Michael> Diskless workstations are frequently configured to swap Michael> across NFS. What's so funny about that ? Ouch. It wasn't funny when I was exposed to it. In 1988 I used a network of diskless Sun3/50s with 4 megabytes of memory. These machines were "disked" by a single "bigger" Sun3 via NFS. At the time we were using X10, I think. Every hour, some sort of maintenance function was started on all of them at once. They'd all immediately swap over the single ethernet segment to the NFS server. Basically everybody in the lab would just watch lines on xload build and build and build. You couldn't do anything for at least 10 minutes. Eventually we persuaded the administrators to stagger the maintenance actions by a few minutes for each machine. ------------------------------ From: albert@krakatoa.ccs.neu.edu (Albert Cahalan) Subject: Re: Standardized Printing for Linux Date: 02 Dec 1995 04:42:19 GMT >>>>> "G" == Gregory H Margo writes: >>> Has anyone heard anything about stadarizing printing for linux? >>> I have heard that SCO has some kind of standarization of printing. >> Check out magicfilter: >> >> sunsite.unc.edu:/pub/Linux/system/Printing/magicfilter-1.1b.tar.gz >> >> /hpa G> Ditto this. I use magicfilter for my non-postscript HP laserjet, and G> merrily print ascii, postscript, and .dvi formats transparently. G> Completely configurable, so it's easy to support different formats or G> different rendering tools. What is needed: a printing language that takes less processing power than postscript and a set of drivers to go with magicfilter. Magicfilter would need to be in the fsstnd thing and all distributions. -- Albert Cahalan albert@ccs.neu.edu ------------------------------ From: "Theodore Ts'o" Subject: Re: [suggestion] about pty's new major number Date: 2 Dec 1995 00:17:10 -0500 Reply-To: tytso@MIT.EDU From: hanky@Henry.Dorm10.NCTU.edu.tw (Henry Shieh) Date: 9 Nov 1995 22:50:04 GMT New kernel 1.3.39 now allows more than 64 ptys since pty/tty's major numbers are moved to 2 and 3. but it meets major 4 (which is for tty0 and ttyS0) soon if we want more than 256 ptys. First of all, there's no requirement that major numbers be consecutive, so there's no reason to move the pty major numbers just because you want to add new major numbers. Secondly, the right way to get more than 256 pty's is not to add a new major number, but to finally support 32-bit device numbers. This is something that is planned, will hopefully happen in the near future. In the meantime, people who want to manually patch their kernel to have more than 256 pty's are free to do so, but I doubt Linus will accept such patches into the mainline kernel. - Ted ------------------------------ ** 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-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@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-System Digest ******************************