home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8293 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  37.0 KB

  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
  2. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  3. Newsgroups: comp.os.linux
  4. Subject: (none)
  5. Message-ID: <1992Aug15.024246.23279@athena.mit.edu>
  6. Date: 15 Aug 92 02:42:46 GMT
  7. Sender: daemon@athena.mit.edu (Mr Background)
  8. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  9. Organization: The Internet
  10. Lines: 983
  11.  
  12. |From Linux-Activists Fri Aug 14 22:15:13 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  13. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 22:34 EDT
  14. Received: by crdgw1.ge.com (5.57/GE 1.141)
  15.      id AA01537; Fri, 14 Aug 92 22:27:29 EDT
  16. Received: by bloom-picayune (5.57/25-eef)
  17.     id AA22473; Fri, 14 Aug 92 22:15:20 -0400
  18. Message-Id: <9208150215.AA22473@bloom-picayune>
  19. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  20. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  21. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  22. Date:     Fri, 14 Aug 92 22:15:13 EDT
  23. Subject:  Linux-Activists Digest #647
  24. Content-Type: text
  25. Content-Length: 36814
  26.  
  27. Linux-Activists Digest #647, Volume #2           Fri, 14 Aug 92 22:15:13 EDT
  28.  
  29. Contents:
  30.   (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)
  31.  
  32. ----------------------------------------------------------------------------
  33.  
  34. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  35. Subject: (none)
  36. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  37. Date: Sat, 15 Aug 1992 02:03:30 GMT
  38.  
  39. |From Linux-Activists Fri Aug 14 21:30:14 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  40. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 21:55 EDT
  41. Received: by crdgw1.ge.com (5.57/GE 1.141)
  42.          id AA29603; Fri, 14 Aug 92 21:43:58 EDT
  43. Received: by bloom-picayune (5.57/25-eef)
  44.         id AA21176; Fri, 14 Aug 92 21:30:31 -0400
  45. Message-Id: <9208150130.AA21176@bloom-picayune>
  46. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  47. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  48. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  49. Date:     Fri, 14 Aug 92 21:30:14 EDT
  50. Subject:  Linux-Activists Digest #643
  51. Content-Type: text
  52. Content-Length: 35036
  53.  
  54. Linux-Activists Digest #643, Volume #2           Fri, 14 Aug 92 21:30:14 EDT
  55.  
  56. Contents:
  57.   (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)
  58.  
  59. ============================================================================
  60.  
  61. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  62. Subject: (none)
  63. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  64. Date: Sat, 15 Aug 1992 01:26:54 GMT
  65.  
  66. |From Linux-Activists Fri Aug 14 21:00:17 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  67. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 21:18 EDT
  68. Received: by crdgw1.ge.com (5.57/GE 1.141)
  69.          id AA28466; Fri, 14 Aug 92 21:14:04 EDT
  70. Received: by bloom-picayune (5.57/25-eef)
  71.         id AA20204; Fri, 14 Aug 92 21:00:30 -0400
  72. Message-Id: <9208150100.AA20204@bloom-picayune>
  73. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  74. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  75. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  76. Date:     Fri, 14 Aug 92 21:00:17 EDT
  77. Subject:  Linux-Activists Digest #640
  78. Content-Type: text
  79. Content-Length: 33258
  80.  
  81. Linux-Activists Digest #640, Volume #2           Fri, 14 Aug 92 21:00:17 EDT
  82.  
  83. Contents:
  84.   (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)
  85.  
  86. ============================================================================
  87.  
  88. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  89. Subject: (none)
  90. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  91. Date: Sat, 15 Aug 1992 00:56:56 GMT
  92.  
  93. |From Linux-Activists Fri Aug 14 20:15:20 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  94. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 20:48 EDT
  95. Received: by crdgw1.ge.com (5.57/GE 1.141)
  96.          id AA27064; Fri, 14 Aug 92 20:37:53 EDT
  97. Received: by bloom-picayune (5.57/25-eef)
  98.         id AA18981; Fri, 14 Aug 92 20:15:36 -0400
  99. Message-Id: <9208150015.AA18981@bloom-picayune>
  100. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  101. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  102. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  103. Date:     Fri, 14 Aug 92 20:15:20 EDT
  104. Subject:  Linux-Activists Digest #637
  105. Content-Type: text
  106. Content-Length: 31480
  107.  
  108. Linux-Activists Digest #637, Volume #2           Fri, 14 Aug 92 20:15:20 EDT
  109.  
  110. Contents:
  111.   (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)
  112.  
  113. ============================================================================
  114.  
  115. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  116. Subject: (none)
  117. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  118. Date: Sat, 15 Aug 1992 00:06:22 GMT
  119.  
  120. |From Linux-Activists Fri Aug 14 19:00:10 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  121. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 19:58 EDT
  122. Received: by crdgw1.ge.com (5.57/GE 1.141)
  123.          id AA23792; Fri, 14 Aug 92 19:13:30 EDT
  124. Received: by bloom-picayune (5.57/25-eef)
  125.         id AA16951; Fri, 14 Aug 92 19:00:18 -0400
  126. Message-Id: <9208142300.AA16951@bloom-picayune>
  127. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  128. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  129. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  130. Date:     Fri, 14 Aug 92 19:00:10 EDT
  131. Subject:  Linux-Activists Digest #633
  132. Content-Type: text
  133. Content-Length: 29702
  134.  
  135. Linux-Activists Digest #633, Volume #2           Fri, 14 Aug 92 19:00:10 EDT
  136.  
  137. Contents:
  138.   Re: The Third Degree (Kevin Cummings)
  139.   64Mb on HD limit? (Christopher Aaron Ekberg)
  140.   Re: Installing Linux w/o destroying existing partitions (Steve Sheldon)
  141.   Re: Modem dial-in procedures needed (Steve M. Robbins)
  142.   (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)
  143.  
  144. ============================================================================
  145.  
  146. From: cummings@hammer.Prime.COM (Kevin Cummings)
  147. Subject: Re: The Third Degree
  148. Date: Fri, 14 Aug 1992 21:13:54 GMT
  149.  
  150. In article <pz91Ht-g*8@atlantis.psu.edu>, bairstow@copland.psu.edu (Steven Bairstow) writes:
  151. | My Linux partition just bit the dust, so I'm going to ask for some 
  152. | information before I re-partititon it. (I want usr and swap partitions 
  153. | instead of one big one this time.) Anyway I want responses from anybody 
  154. | who knows about any of this, even if it's just a "yep." Without further 
  155. | ado here are the questions....
  156. |       - Has anyone noticed free inodes being left around? I think 
  157. |         halt/shutdown is doing it. (This is what I was trying to figure 
  158. |         out when it crashed.)
  159. |       - What is the current status of long filenames? Is it a patch?
  160. |         How reliable is it?
  161. |       - Do any of the current disk sets handle SCSI disks well? How about 
  162. |         the partitioning programs?
  163. |       - How big are the X11 binaries plus whatever special stuff is needed 
  164. |         to write X-programs? 
  165. |       - Has anyone ever considered an X driver for plain VGA? Why or why 
  166. |         not make one?
  167. |       - Is anyone interested in a patch that would add a timeout default 
  168. |         to the "Press <RETURN> to see SVGA modes or any other key to 
  169. |         continue." message?
  170.  
  171. YES INDEED.  I haven't had the time to work on this stuff lately, but a timeout
  172. would definately be useful.  (Especially one with a configurable default, but then
  173. again I haven't looked at 0.97 or 0.97pl1, shame on me).
  174.  
  175. =================================================================
  176. Kevin J. Cummings                       PrimeService
  177. 20 Briarwood Road                       A Computervision Company
  178. Framingham, Mass.                       500 Old Connecticut Path
  179.                                         Framingham, Mass.
  180. Work:  cummings@primerd.Prime.COM
  181. Home:  cummings@kjc386.framingham.ma.us
  182.  
  183. Std. Disclaimer: "Mr. McKittrick, after careful consideration,
  184.                   I've come to the conclusion that your new
  185.                   defense system SUCKS..."   --  War Games
  186. =================================================================
  187.  
  188. ==============================
  189.  
  190. From: ce12+@andrew.cmu.edu (Christopher Aaron Ekberg)
  191. Subject: 64Mb on HD limit?
  192. Date: 14 Aug 92 13:15:42 GMT
  193.  
  194. Hello,
  195.  
  196. I read someplace that there is (was?) a limit of 64Mb hard disk space
  197. for Linux.  If I didn't just dream that, is that still true for 0.97?  
  198.  
  199. Thanks,
  200. -Chris
  201.  
  202. ==============================
  203.  
  204. From: sheldon@iastate.edu (Steve Sheldon)
  205. Subject: Re: Installing Linux w/o destroying existing partitions
  206. Date: Fri, 14 Aug 1992 21:14:39 GMT
  207.  
  208. In <1992Aug14.193838.16110@nas.nasa.gov> chiu@wk211.nas.nasa.gov (Ing-Tsau Chiu) writes:
  209.  
  210. |Wonder if there's any way to install Linux w/o destroying existing
  211. |partitions.  (Sorry if this is an faq.)
  212. |--
  213. |--
  214. |Ing-Tsau Chiu                       chiu@nas.nasa.gov
  215.  
  216.  Sure on floppy disks, silly! :-)
  217.  
  218.  There is some explanation of this in 'install.notes' written by
  219. I Reid.  Actually it's an appendix towards the end written by
  220. Drew Eckhardt.
  221.  
  222.  I personally wouldn't recommend it, even though I think I understand
  223. what he's doing.
  224.  
  225.  Basically it seems to me that it's much more work than it is worth.
  226. I did a complete backup of my harddisk of about 60 Megs of data to
  227. floppy disks(720K no less! as I have hundreds of these), using
  228. CP Backup 6.0.  It takes about 1/2 hour to backup, another 1/2 to
  229. reinstall.
  230.  If you've got more than 100 Megs, definately buy a cheap tape
  231. backup for around $200.
  232.  
  233.  Basically, it just doesn't seem worth the possible frustration, and
  234. you're going to have to backup the partition anyway.
  235.  
  236.  Any comments?
  237.  
  238. -- 
  239. Steve Sheldon         sheldon@iastate.edu
  240. Iowa Cooperative Soil Survey Resource Unit
  241. 2142 Agronomy, Iowa State University  (515) 294-5429
  242.  
  243.  
  244. ==============================
  245.  
  246. From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
  247. Subject: Re: Modem dial-in procedures needed
  248. Date: 13 Aug 92 22:16:48 GMT
  249.  
  250. In article <1992Aug13.052324.8490@athena.mit.edu> chchen@stat.fsu.edu writes:
  251. |I've seen several discussions about modem dial-in for Linux system. I
  252. |got two unsolved questions here:
  253.  
  254. |1. Is it necessary to get getty_ps program to allow modem dial-in?
  255.  
  256. No.  Not if you just want to dial in.  Getty_ps is required if you want to also
  257. be able to dial out on the same line (uucp, kermit...).  To my knowledge there
  258. are no other uugetty programs that work.  [uugetty being the version of getty
  259. (included in getty_ps) that uses lockfiles to negotiate with uucp et al. for 
  260. the line]
  261.  
  262.  
  263. |2. If I just want to use the getty from MCC-INTERIM or root image (.96 or
  264. |   .97), what steps should I follow?
  265. [..]
  266. |                (2) Without changing the /etc/initab, give the command
  267. |                          echo atq1e0s0=2v1x4 >/dev/ttys1
  268. |                          (no device busy this time)
  269. |                    and then
  270. |                         getty 2400 /dev/ttys1 &
  271. |
  272. |                    This seemed to work but after my friend logout,
  273. |                    his screen went messy (he is also running Linux)
  274.  
  275. I think this is the way to do it.  But with the getty line in inittab, I
  276. don't think you need to run getty by hand.  You might have to kill off the
  277. old getty and let init restart it, though.  [since atq1 turns off the command 
  278. responses, sending v1x4 is superfluous, isn't it?]
  279.  
  280. The best way would probably be to put the initializing string (i.e. 'echo
  281. atq1.. >/dev/ttys1) into /etc/rc, so the modem will be set up before init
  282. ever tries running getty on it.
  283.  
  284. The messy screen is your friend's problem, probably to do with getting noise
  285. after disconnecting.
  286.  
  287. |                    Also, how to choose terminal type with this
  288. |                    apporach?
  289.  
  290. The terminal type will be set by init to whatever is on the inittab line.  If
  291. you need to change it after logging in, just do TERM=whatever from BASH's
  292. command line, or login script.
  293.  
  294. -- 
  295. Steve Robbins  --  steve@nyongwa.cam.org
  296. I asked Hank Williams "how lonely does it get?"
  297. Hank Williams hasn't answered yet.
  298.  
  299. ==============================
  300.  
  301. From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  302. Subject: (none)
  303. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  304. Date: Fri, 14 Aug 1992 22:54:47 GMT
  305.  
  306. |From Linux-Activists Fri Aug 14 10:00:24 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  307. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 18:46 EDT
  308. Received: by crdgw1.ge.com (5.57/GE 1.141)
  309.          id AA00964; Fri, 14 Aug 92 10:12:33 EDT
  310. Received: by bloom-picayune (5.57/25-eef)
  311.         id AA00427; Fri, 14 Aug 92 10:00:33 -0400
  312. Message-Id: <9208141400.AA00427@bloom-picayune>
  313. From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
  314. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  315. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  316. Date:     Fri, 14 Aug 92 10:00:24 EDT
  317. Subject:  Linux-Activists Digest #629
  318. Content-Type: text
  319. Content-Length: 21613
  320.  
  321. Linux-Activists Digest #629, Volume #2           Fri, 14 Aug 92 10:00:24 EDT
  322.  
  323. Contents:
  324.   Re: XView, olvwm, and OLIT (Scott Dunn)
  325.   Re: Linux logo (Joost Helberg)
  326.   Re: Troubles compiling lilo v3 (Joost Helberg)
  327.   tlA: reggae's Incoming dir must be chmod ugo+x... (Tero Laakkonen)
  328.   Re: loadable device drivers (Joost Helberg)
  329.   Dial-in and kill -HUP 1 (Ching-Hsiang Chen)
  330.   Re: Schedules (Mark Komarinski)
  331.   Where can I get linux-logo.gif or GhostScript(for Linux)? (Rick Miller)
  332.   Re: Stabilizing Linux (Juhana Kouhia)
  333.   X11 and the joys of modes (Julien Maisonneuve)
  334.   Re: Stabilizing Linux (william E Davidsen)
  335.   How safe is Mtools? (Robert W. Bingler)
  336.   Re: Buffer corruption problems. (Scott A. Taylor)
  337.   Re: Stabilizing linux (william E Davidsen)
  338.  
  339. ============================================================================
  340.  
  341. From: scottd@cs.hw.ac.uk (Scott Dunn)
  342. Subject: Re: XView, olvwm, and OLIT
  343. Date: 13 Aug 92 14:21:41 GMT
  344.  
  345. I am also looking for xview.  I do have the source and when gcc2.2.2d is
  346. released I am going to attempt to make it.  Assuming, that is, that noone
  347. has already done it.
  348.  
  349. When will gcc2.2.2d be released?
  350.  
  351. Also, gwm, where can I find it?
  352. And when I do find it, how do I compile the lisp files?  
  353. Having looked at it at uni, it seemed rather slow, but that was 
  354. probably largely down to the fact that all the lisp files were
  355. not compiled.
  356.  
  357. Scott.
  358.  
  359. ==============================
  360.  
  361. From: jhelberg@nl.oracle.com (Joost Helberg)
  362. Subject: Re: Linux logo
  363. Date: 14 Aug 92 08:59:30 GMT
  364.  
  365. X-Disclaimer: This message was written by an unauthenticated user
  366.               at Oracle Corporation.  The opinions expressed are those
  367.               of the user and not necessarily those of Oracle.
  368.  
  369. welshm@snail.rtp.dg.com (Matt Welsh) writes:
  370. : I got the newest version (EPS) of the linux logo direct from
  371. : the artist, and my previewers (Ghostview and GS) both barf on
  372. : it, with the errors:
  373. : Error: /undefined in !
  374. Right, I notified James.
  375.  
  376. 10 minutes of hacking however solves your problem too!
  377.  
  378. --
  379.    Joost Helberg                                Rijnzathe 6
  380.    jhelberg@oracle.nl                           NL-3454 PV De Meern
  381.    jhelberg@nl.oracle.com                       The Netherlands
  382.  
  383.    Oracle Europe BV                             Product Line Development        
  384.    Phone: +31 3406 94211                        Fax:   +31 3406 65609
  385.  
  386. ==============================
  387.  
  388. From: jhelberg@nl.oracle.com (Joost Helberg)
  389. Subject: Re: Troubles compiling lilo v3
  390. Date: 14 Aug 92 09:05:35 GMT
  391.  
  392. X-Disclaimer: This message was written by an unauthenticated user
  393.               at Oracle Corporation.  The opinions expressed are those
  394.               of the user and not necessarily those of Oracle.
  395.  
  396. newbie@dylan.camb.inmet.com (Chris Newbold) writes:
  397. : The problems: Both /usr/src/linux/include/linux/types.h and /usr/include/sys
  398. : /types.h get included. I tried to fix this by linking /usr/include/sys
  399. : to /usr/src/linux/include/linux. This seems like a hack, but I don't really
  400. : know. Didn't reall help.
  401. Added #define _LINUX_TYPES_H to /usr/include/sys/types.h
  402. and   #define _SYS_TYPES_H   to /usr/include/linux/types.h
  403.  
  404. That makes them mutualy exclusive.
  405.  
  406.  
  407.  
  408. --
  409.    Joost Helberg                                Rijnzathe 6
  410.    jhelberg@oracle.nl                           NL-3454 PV De Meern
  411.    jhelberg@nl.oracle.com                       The Netherlands
  412.  
  413.    Oracle Europe BV                             Product Line Development        
  414.    Phone: +31 3406 94211                        Fax:   +31 3406 65609
  415.  
  416. ==============================
  417.  
  418. From: laakkone@klaava.Helsinki.FI (Tero Laakkonen)
  419. Subject: tlA: reggae's Incoming dir must be chmod ugo+x...
  420. Date: 14 Aug 92 10:25:32 GMT
  421.  
  422. ... so that people can cd into it.
  423.  
  424. -tero.
  425.  
  426. ==============================
  427.  
  428. From: jhelberg@nl.oracle.com (Joost Helberg)
  429. Subject: Re: loadable device drivers
  430. Date: 14 Aug 92 10:49:47 GMT
  431.  
  432. X-Disclaimer: This message was written by an unauthenticated user
  433.               at Oracle Corporation.  The opinions expressed are those
  434.               of the user and not necessarily those of Oracle.
  435.  
  436. almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
  437. : In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:
  438.  
  439. [deleted]
  440. : > The kernel must be mapped when implementing loadable device drivers (to
  441. : > get page-faults) so the kernel doesn't need contiguous memory --> less
  442. : > problems allocating memory.
  443. : Page-faults are deadly for most parts of the kernel. Unless the interrupt
  444. : handling is changed in radical ways (see below), you don't want interrupt
  445. : handlers and code that's called by them to reside in paged memory. (Besides
  446. : the obvious case of device drivers that may be possibly invoked when
  447. : handling a page fault.)
  448. : Using the paging hardware to map kernel pages is a good idea, though.
  449. : > - The kernel will never use more core than necessary. Only text/data really
  450. : >  used will be in core (that is using LRU algorithms). 
  451. : Yes, but you need interrupt queues and an interrupt scheduler to be able
  452. : to accept interrupts from devices that can send more than one interrupt
  453. : per interaction (i.e. SIOs) even if you have to fault in the driver first.
  454. : Might be hairy to implement, although it looks like a very elegant
  455. : solution for most interrupt problems.
  456. : You also need a way to lock certain kernel areas in physical memory.
  457. : (MM, at least one FS, scheduler, hd driver, some other kernel data
  458. : structures, drivers for devices that expect a low interrupt latency, etc.)
  459. :  
  460.  
  461. You're right about all this; my idea came from the time I developed
  462. streams drivers and streams drivers only. These can very easy be made
  463. pageable in the sense that streams-modules/drivers get scheduled by the
  464. scheduler as if they are user-processes. You can swap them if you want!
  465.  
  466. [deleted]
  467.  
  468. I think it is not a good idea to implement any driver as a loadable driver,
  469. but with a new driver-interface (like STREAMS is) it is easy to implement,
  470. without too much problems.
  471.  
  472. One could even implement a seperate driver-space (analog to user-space, with
  473. its own mmu-tables) for each streams-driver instance, bus-errors etc. result
  474. in core dumps in stead of terminal-dumbs!
  475.  
  476. I think (before STREAMS are implemented) that we should invest in defining
  477. a configurable driver-interface for Linux, discussion in mailing-list 
  478. 'configuration' at niksula.hut.fi or on the news.
  479.  
  480. Any comment?
  481.  
  482. --
  483.    Joost Helberg                                Rijnzathe 6
  484.    jhelberg@oracle.nl                           NL-3454 PV De Meern
  485.    jhelberg@nl.oracle.com                       The Netherlands
  486.  
  487.    Oracle Europe BV                             Product Line Development        
  488.    Phone: +31 3406 94211                        Fax:   +31 3406 65609
  489.  
  490. ==============================
  491.  
  492. From: Ching-Hsiang Chen <chchen@stat.fsu.edu>
  493. Subject: Dial-in and kill -HUP 1
  494. Reply-To: chchen@stat.fsu.edu
  495. Date: Fri, 14 Aug 1992 11:46:59 GMT
  496.  
  497.  
  498.  Thanks to those who were so kind to help me in modem dial-in
  499. problem. Since the getty_ps program needs M4 to compile the
  500. manual pages and I am so lazy, I adopt the original getty
  501. approach. I created the following 4 files to make things easy.
  502. To allow remote dial-in, I just give the command 'dialin' and
  503. to restore the modem and/or to allow dial-out, I use 'dialout'.
  504. One small problem is that the 'init' and 'kill' from MCC-INTERIM
  505. 0.96 root disk can not work together to allow 'kill -HUP 1'
  506. to kill the spawned getty. I need to retype 'kill -HUP 1'
  507. several times or to kill the process by its job ID in order
  508. to make it disapper under 'ps gu'. Any idea?
  509.  
  510. Steve Chen              chchen@stat.fsu.edu
  511.  
  512.    file name 'dialin' (put in /root/bin )
  513. =========================== cut here =================
  514. #! /bin/sh
  515. cp /etc/inittab1 /etc/inittab
  516. echo ate0s0=2 >> /dev/ttys1
  517. kill -HUP 1
  518. =========================== cut here =================
  519.  
  520.    file name 'dialout' (put in /root/bin )
  521.  
  522. =========================== cut here =================
  523. #! /bin/sh
  524. cp /etc/inittab0 /etc/inittab
  525. echo ate1s0=0 >> /dev/ttys1
  526. kill -HUP 1
  527. =========================== cut here =================
  528.  
  529.     file name 'inittab0'  (put in /etc)
  530.  
  531. =========================== cut here =================
  532. tty1:console:/bin/getty 9600 tty1
  533. tty2:console:/bin/getty 9600 tty2
  534. tty3:console:/bin/getty 9600 tty3
  535. tty4:console:/bin/getty 9600 tty4
  536. =========================== cut here =================
  537.  
  538.     file name 'inittab1'  (put in /etc)
  539.  
  540. =========================== cut here =================
  541. tty1:console:/bin/getty 9600 tty1
  542. tty2:console:/bin/getty 9600 tty2
  543. tty3:console:/bin/getty 9600 tty3
  544. tty4:console:/bin/getty 9600 tty4
  545. ttys1:vt100:/bin/getty 2400 ttys1
  546.  
  547. ==============================
  548.  
  549. From: Mark Komarinski <komarimf@craft.camp.clarkson.edu>
  550. Subject: Re: Schedules
  551. Reply-To: komarimf@craft.camp.clarkson.edu
  552. Date: Fri, 14 Aug 1992 12:30:19 GMT
  553.  
  554. On Aug 13,  2:35am, Rick Sladkey wrote:
  555. | A rule that I picked up from somewhere is quite useful in such situations.
  556. |         "Bump up to the next unit of measurement and muliply by two."
  557. | So when you hear a schedule like:               Expect:
  558. |         1 hour                                  2 days
  559. |         2 days                                  4 weeks
  560. |         1 month                                 2 years
  561. | Sad, but often true.
  562.  
  563. So how long is Real Soon Now? :) (That is about when SLIP will come to 
  564. Clarkson...grr..)
  565.  
  566. -Mark
  567.  
  568. -- 
  569. - Mark Komarinski - komarimf@craft.camp.clarkson.edu
  570. [MIME mail welcome]
  571. The only candidate worth voting for is Bill the Cat.  He might not
  572. do good, but that's never been a requirement.
  573.  
  574. ==============================
  575.  
  576. From: rick@ee.ee.uwm.edu (Rick Miller)
  577. Subject: Where can I get linux-logo.gif or GhostScript(for Linux)?
  578. Date: Fri, 14 Aug 1992 12:22:26 GMT
  579.  
  580. I'd love to see the Linux Logo... but I get "Permission Denied"
  581. when I try to "get linux-logo.gif" from tsx-11:/incoming.
  582.  
  583. Where and how can I get this file???
  584.  
  585. I don't have a PostScript printer, so GhostScript will probably come
  586. in handy in the future as well... where can I get it for Linux (or DOS)?
  587.  
  588. Rick Miller   <rick@ee.uwm.edu> | <rick@discus.mil.wi.us>
  589.  
  590. ==============================
  591.  
  592. From: jk87377@cc.tut.fi (Juhana Kouhia)
  593. Subject: Re: Stabilizing Linux
  594. Date: 14 Aug 92 12:21:04 GMT
  595.  
  596.  
  597.  
  598. Well, I have no much experiences in software system engineering and I
  599. don't know about the heart of Linux, but I suggest:
  600.  
  601. 1. All common sources for the various different Linuxes are checked
  602. to a master version.
  603.  
  604. 2. Those features which are in one Linux only is directly copied to
  605. master version; if this is not possible to do directly, people
  606. rewrite them.
  607.  
  608. 3. Those features which overlaps in Linuxes is added to master version
  609. either by switches or choosing best one or writing a compromise.
  610.  
  611.  
  612. About 1: I don't know what different program parts (modules)
  613. there are and how they communicates together.
  614. It could help to organize if those parts (or program modules) are
  615. listen down -- at least if I have to organize Linux again, I would
  616. like to write a list (or program tree) about what is there.
  617. Then it could be easier to check where programs overlaps
  618. and helps to design more modular system.
  619.  
  620.  
  621. By these differences I don't mean different versions of GNU emacs or
  622. zoo or such  :-)
  623.  
  624.  
  625. Actually, does somebody know what features are different in the
  626. different Linux releases (MCC, etc.)?
  627. We could list only those in the first place.
  628.  
  629.  
  630. As I said I'm not experienced software developer, so no flames,
  631. instead an educating critisms, which I have allready read from this
  632. group, are welcome.
  633.  
  634.  
  635. Juhana Kouhia
  636.  
  637. ==============================
  638.  
  639. From: julien@incal.inria.fr (Julien Maisonneuve)
  640. Subject: X11 and the joys of modes
  641. Date: 14 Aug 92 12:01:24 GMT
  642.  
  643. OK, I grabbed X11 a bit late, but I just received a new video board (pvga based)
  644. to replace my trident.
  645.  
  646. My problem is that I can't get my monitor to sync properly using the modes I
  647. found in Xconfig and vga.dbase. Horizontally, things look right, but vertically,
  648. I get flying superimposed pictures (Color is OK though :-). I can see xclock
  649. jumping a bit (two superimposed pictures) but can't do any better.
  650. The (numerous) changes I could make in the mode settings didn't do much, and the
  651. mode I made using the video.tutorial doesn't seem to handle things better than
  652. the others (not much worse either). Despite the tutorial, I figured out what the
  653. mode values meant, but I can't find the proper values.
  654.  
  655. The clocks.exe reports only four clocks for my vga (something like 25 29 65 36)
  656. and X11 does NOT find the same at all when I leave the clocks line out (reports 8
  657. lower values, max is at 40). I try to use 65 (large values intuitively suggest
  658. better resolution...).
  659.  
  660. My SVGA board & monitor can do a neat 1024x768x256 non interlaced picture under
  661. DOS. Isn't it possible to write a DOS program that reads the vga registers in a
  662. given mode (this very one) and tell the appropriate video timings ? That would
  663. help a great deal the poor X11 installers with uncommon hardware.
  664.  
  665. That kind of help message seems to have disappeared from c.o.l, so most people
  666. have likely solved the problem: I couldn't, someone please HELP !!!
  667.  
  668. Usual praises & kudos about Linux and X11...
  669. -- 
  670.   _________                    Julien.Maisonneuve@inria.fr  julien@sor.inria.fr
  671.       /                 _ _ _                     ...!uunet!inria!corto!julien
  672.      /     /)          ' ) ) )                    INRIA :  33 (1) 39 63 52 08
  673.   __/_    // o _  __    / / / _   o _   _   __   __   _      _     _
  674.  / / (_(_(/_(_(<_/) )  / ' (_(_(_(_/_)_(_)_/) )_/) )_(<_(_(_( \_)-(<_
  675. (_/
  676.  
  677. ==============================
  678.  
  679. From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  680. Subject: Re: Stabilizing Linux
  681. Date: 14 Aug 92 13:22:32 GMT
  682. Reply-To: davidsen@crd.ge.com (bill davidsen)
  683.  
  684. In article <1992Aug13.195406.23296@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  685. | In article <1992Aug13.133313.15221@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
  686. | >In article <1992Aug12.173012.17552@colorado.edu>, drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
  687. | >
  688. | >And the person trying to install on a new machine can't rebuild the
  689. | >kernel, so s/he needs another working system to get going. Bleh.
  690. | >Relocation at load time might take 1-2 sec of cpu. Big deal. Without
  691. | >loadable device drivers you must have a working system to generate a new
  692. | >kernel.
  693. | Most Unices distribute the distribution kernel as a generic kernel,
  694. | ie one with support for all device drivers compiled in.  It gets a little
  695. | bloated, but if you can boot it, you can run anything.
  696.  
  697.   Sounds to me like you think the Linux kernel as distributed contains
  698. all the devices anyone would ever want to use, so there's no need for
  699. being able to support new devices.
  700.  
  701.   It also sounds like you're trying to say that you think it's too
  702. hard, and you personally don't need it, so you want to convince
  703. everyone it's a bad idea.
  704.  
  705. -- 
  706. bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  707.     I admit that when I was in school I wrote COBOL. But I didn't compile.
  708.  
  709. ==============================
  710.  
  711. From: rwb@Turing.ORG (Robert W. Bingler)
  712. Subject: How safe is Mtools?
  713. Date: Fri, 14 Aug 1992 12:50:03 GMT
  714.  
  715. Hey,
  716.         Can anyone tell me just how safe it is to use mtools on my 130 meg
  717. dos partition?  I don't want to have to go the expensense of messing it
  718. up.  I have been hesitant in the past, so I just use a floppy.  It would
  719. make things much easier if there is no real chance of damage being done.
  720.  
  721. Thanks,
  722. Rob
  723.  
  724. +--------------------------+----------------------+--------------------------+
  725. |   o    \ /  <o>    o     |  Robert Bingler      |  .sig Virus Disenfector  |
  726. | _/|-'   |    |   _/|-'   |->rwb@turing.org      |                          |
  727. |  / \,  /o\  / \   / \,   |  dwb4h@virginia.edu  |  To envoke type:         |
  728. | `                `       |                      |  rm .sig                 |
  729. +--------------------------+----------------------+--------------------------+
  730.  
  731. ==============================
  732.  
  733. From: scott@natinst.com (Scott A. Taylor)
  734. Subject: Re: Buffer corruption problems.
  735. Date: Fri, 14 Aug 1992 13:31:32 GMT
  736.  
  737. In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
  738. |In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
  739. |burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  740. |
  741. |>  ...I believe there is a bug in Linux that has the following behavior:
  742. |>
  743. |>  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  744. |>     so that what your app ends up with is some _other_ 1024KB chunk
  745. |>     (apparently from the same file)
  746. |>
  747. |>  -  occurs only during very heavy disk access, such as megabytes accessed
  748. |>     continually
  749. |>
  750. |>  -  is intermittent, but happens enough to reproduce fairly easily
  751. |[Etc...]
  752. |
  753. |       I have noticed some abnormalities, but I have been writing them
  754. |off to a disk block in the process of going bad.  Here's what I have
  755. |noticed:
  756. |
  757. |       - Under heavy and prolonged disk I/O (in this example, while compiling
  758. |gdb from scratch) there seem to be problems with the buffer cache.  After 
  759. |compiling for a while, gcc will choke with a TON of strange errors and die.
  760. |However, if I just restart make, the compiler will continue successfully
  761. |with the file that it had just died on, but it will die a little later 
  762. |down the line (after some more intensive I/O) under the same circumstances.
  763. |After a couple of tries, I can usually get through the entire make.
  764. |
  765. |       - I am running on MFM drives on a 486-33 with 4 Megs RAM (gcc 2.2.2d and
  766. |gcc 2.2.2 and Linux 0.97 PL1), so while compiling large things, my disks never 
  767. |stop to breath, especially if I am trying to do something else while the compile 
  768. |is running.
  769. |
  770. |       - The errors always include the same file (which is why I thought
  771. |perhaps that that particular file was living on a disk block that was going
  772. |belly up.  I plan to rename that file to .deadblock and putting a new copy
  773. |of the file in the directory to test this theory).  I am also going to run some
  774. |more large compiles to see if I can reproduce this error elsewhere in the 
  775. |system.
  776. |
  777. |       I don't know what it is yet, and I'm not sure if it's anything, but
  778. |I'll see what I can reproduce and hopefully we can determine if this is an
  779. |OS bug or a hardware bug and whether or not it has anything to do at all with
  780. |the above problem.
  781. |
  782. |       Anyone else out there having problems?
  783. |
  784. |
  785. |
  786. |                                       Cory West
  787. |                                       corywest@rice.edu
  788.  
  789. I am running 0.96c pl2 with the latest SCSI drivers from woz.headrest.colorado.
  790. edu, and I have not had any problems like this, even under heavy load (i.e.
  791. building a new kernel in one VC while compiling groff, GNU file utils, text
  792. utils, etc. in another).  I have 8 megs of RAM and an UltraStor 14F w/ 213 MB 
  793. Maxtor disk in a 386-25 with no cache. I do not have swapping enabled.  Maybe 
  794. this problem is paging- or cache-related?
  795.  
  796. I have used (and abused ;-) ) linux pretty heavily in the past, and it has
  797. been solid as a rock (Thanks Linus and everyone else involved!).
  798. -- 
  799. Scott Taylor            |
  800. (512) 795-6837          | "Well, I wanted to work with gymnasts." -David Byrne
  801. scott@natinst.com       |
  802. ** NI pays me to write their code, not their opinions, and that's what I do **
  803.  
  804. ==============================
  805.  
  806. From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  807. Subject: Re: Stabilizing linux
  808. Date: 14 Aug 92 13:32:17 GMT
  809. Reply-To: davidsen@crd.ge.com (bill davidsen)
  810.  
  811. In article <1992Aug13.200750.1247@athena.mit.edu>, komarimf@craft.camp.clarkson.edu (Mark Komarinski) writes:
  812.  
  813. | Why not have both?  Whipping up some on-line manuals that can be printed
  814. | or viewed should not be that much trouble, and everyone will benefit in the
  815. | end.
  816.  
  817.   I think you should be the one to do it, then. I've written 40-50 page
  818. user manuals, and many programs of that size, and I can tell you that a
  819. quality manual takes about 2x longer, per page, than code. That insuring
  820. that the notation is consistent end to end, the style is uniform (chatty
  821. or dry, but consistent), that every fact is correct, exceptions are
  822. noted (this works with 0.96a and 0.96b, but not later versions), and
  823. that there are clear examples for all sections which a user could
  824. possibly misunderstand.
  825.  
  826.   My recent experience with asking for the location of docs rather than
  827. useful hints was revealing; on two questions I got a total of 31 answers
  828. (Linux people are the nicest on the net!), but I got 30 "I don't have
  829. docs, but this worked for me," and one "thaere's a doc on tsx... but
  830. it's not very clear, this is what I think it means." So I now have a few
  831. more lines of notes in my KWS notes file, but no new docs.
  832.  
  833.   This could really be a huge job, you've been warned.
  834. -- 
  835. bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  836.     I admit that when I was in school I wrote COBOL. But I didn't compile.
  837.  
  838. ==============================
  839.  
  840.  
  841. ** FOR YOUR REFERENCE **
  842.  
  843. The service address, to which questions about the list itself and requests
  844. to be added to or deleted from it should be directed, is:
  845.  
  846.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  847.  
  848. You can send mail to the entire list (and comp.os.linux) via:
  849.  
  850.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  851.  
  852. Linux may be obtained via one of these FTP sites:
  853.     nic.funet.fi                                pub/OS/Linux
  854.     tsx-11.mit.edu                              pub/linux
  855.     tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace
  856.  
  857. The current version of Linux is 0.97 released on August 1, 1992
  858.  
  859. End of Linux-Activists Digest
  860. ******************************
  861.  
  862. ==============================
  863.  
  864.  
  865. ** FOR YOUR REFERENCE **
  866.  
  867. The service address, to which questions about the list itself and requests
  868. to be added to or deleted from it should be directed, is:
  869.  
  870.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  871.  
  872. You can send mail to the entire list (and comp.os.linux) via:
  873.  
  874.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  875.  
  876. Linux may be obtained via one of these FTP sites:
  877.     nic.funet.fi                                pub/OS/Linux
  878.     tsx-11.mit.edu                              pub/linux
  879.     tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace
  880.  
  881. The current version of Linux is 0.97 released on August 1, 1992
  882.  
  883. End of Linux-Activists Digest
  884. ******************************
  885.  
  886. ==============================
  887.  
  888.  
  889. ** FOR YOUR REFERENCE **
  890.  
  891. The service address, to which questions about the list itself and requests
  892. to be added to or deleted from it should be directed, is:
  893.  
  894.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  895.  
  896. You can send mail to the entire list (and comp.os.linux) via:
  897.  
  898.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  899.  
  900. Linux may be obtained via one of these FTP sites:
  901.     nic.funet.fi                                pub/OS/Linux
  902.     tsx-11.mit.edu                              pub/linux
  903.     tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace
  904.  
  905. The current version of Linux is 0.97 released on August 1, 1992
  906.  
  907. End of Linux-Activists Digest
  908. ******************************
  909.  
  910. ==============================
  911.  
  912.  
  913. ** FOR YOUR REFERENCE **
  914.  
  915. The service address, to which questions about the list itself and requests
  916. to be added to or deleted from it should be directed, is:
  917.  
  918.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  919.  
  920. You can send mail to the entire list (and comp.os.linux) via:
  921.  
  922.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  923.  
  924. Linux may be obtained via one of these FTP sites:
  925.     nic.funet.fi                                pub/OS/Linux
  926.     tsx-11.mit.edu                              pub/linux
  927.     tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace
  928.  
  929. The current version of Linux is 0.97 released on August 1, 1992
  930.  
  931. End of Linux-Activists Digest
  932. ******************************
  933.  
  934. ==============================
  935.  
  936.  
  937. ** FOR YOUR REFERENCE **
  938.  
  939. The service address, to which questions about the list itself and requests
  940. to be added to or deleted from it should be directed, is:
  941.  
  942.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  943.  
  944. You can send mail to the entire list (and comp.os.linux) via:
  945.  
  946.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  947.  
  948. Linux may be obtained via one of these FTP sites:
  949.     nic.funet.fi                                pub/OS/Linux
  950.     tsx-11.mit.edu                              pub/linux
  951.     tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace
  952.  
  953. The current version of Linux is 0.97 released on August 1, 1992
  954.  
  955. End of Linux-Activists Digest
  956. ******************************
  957.  
  958. ------------------------------
  959.  
  960.  
  961. ** FOR YOUR REFERENCE **
  962.  
  963. The service address, to which questions about the list itself and requests
  964. to be added to or deleted from it should be directed, is:
  965.  
  966.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  967.  
  968. You can send mail to the entire list (and comp.os.linux) via:
  969.  
  970.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  971.  
  972. Linux may be obtained via one of these FTP sites:
  973.     nic.funet.fi                pub/OS/Linux
  974.     tsx-11.mit.edu                pub/linux
  975.     tupac-amaru.informatik.rwth-aachen.de    pub/msdos/replace
  976.  
  977. The current version of Linux is 0.97 released on August 1, 1992
  978.  
  979. End of Linux-Activists Digest
  980. ******************************
  981.