home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8263 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  20.7 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: <1992Aug14.203842.12613@athena.mit.edu>
  6. Date: 14 Aug 92 20:38:42 GMT
  7. Sender: daemon@athena.mit.edu (Mr Background)
  8. Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  9. Organization: The Internet
  10. Lines: 605
  11.  
  12. |From Linux-Activists Fri Aug 14 15:45:12 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
  13. Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 16:30 EDT
  14. Received: by crdgw1.ge.com (5.57/GE 1.141)
  15.      id AA15983; Fri, 14 Aug 92 16:14:18 EDT
  16. Received: by bloom-picayune (5.57/25-eef)
  17.     id AA11255; Fri, 14 Aug 92 15:45:19 -0400
  18. Message-Id: <9208141945.AA11255@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 15:45:12 EDT
  23. Subject:  Linux-Activists Digest #631
  24. Content-Type: text
  25. Content-Length: 20156
  26.  
  27. Linux-Activists Digest #631, Volume #2           Fri, 14 Aug 92 15:45:12 EDT
  28.  
  29. Contents:
  30.   AMD386 and LINUX (Bill Broadley)
  31.   Re: shared libs - can everyone be happy with this? (David Engel)
  32.   Re: Troubles compiling lilo v3 (Charles H. Barry)
  33.   PTYP/TTYP programming..  (Anthony Rumble)
  34.   Small system compile woes (John B.  Jr. Rogerson)
  35.   Re: SLS: Free Linux Distribution. (Hannes Faestermann)
  36.   Need Help: TeX (Jing Huang)
  37.   0.97 WORKS with SCSI ! [attn NEWBIES] (peter.j.fillingham)
  38.   Can't Compile Kernel 0.97 (Sakari Aaltonen)
  39.   Diamond Speed Star SVGA card (Matthew A. Lewis)
  40.   Re: FAQ? (Wim `Blue Baron' van Dorst)
  41.   Re: Pointers to a list of Graphics Cards for X386 (Matthew A. Lewis)
  42.   large caches ona 486 (Matthew A. Lewis)
  43.   Re: Hey!  Linux fs on DOS partition! (Werner Almesberger)
  44.   Re: large caches ona 486 (JMS)
  45.   Re: Buffer corruption problems. (Chris Newbold)
  46.   Re: Linux Logo (James P. Callison)
  47.  
  48. ----------------------------------------------------------------------------
  49.  
  50. From: broadley@neurocog.lrdc.pitt.edu (Bill Broadley)
  51. Subject: AMD386 and LINUX
  52. Date: 14 Aug 92 16:11:12 GMT
  53. Reply-To: broadley@neurocog.lrdc.pitt.edu
  54.  
  55. As far as I know there are no documented bugs in the AMD 386.
  56.  
  57. If there were you would be sure that INTEL would brag about em.
  58.  
  59. I have run all the tests mentioned and has absolutely no problem
  60. with my motherboard with AMD396-40.  
  61.  
  62. I often use my machine hard and leave it processing for more then a
  63. day.
  64.  
  65. Maybe the motherboards in question should really be 33 MHZ, and not pushed
  66. so fast, and were not designed with the AMD in mind.
  67.  
  68. I have heard that the AMD 386 is faster then an INTEL 386 at the 
  69. same clock, so maybe the motherboards are depending on the delays in the 
  70. INTEL 386 which is a pretty flakey thing to do.  Anyways I am very
  71. happy with my AMD386-40, I recently added a Cyrix 387, nothing
  72. seemed to change except floating point speed.  I.e. 1.0+ Mflops with
  73. the flops.c benchmark.
  74.  
  75. Just one more datapoint.
  76.  
  77. -- 
  78. Bill                            1st>    Broadley@neurocog.lrdc.pitt.edu
  79. Broadley@schneider3.lrdc.pitt.edu <2nd 3rd>     Broadley+@pitt.edu
  80.  
  81. ------------------------------
  82.  
  83. From: david@ods.com (David Engel)
  84. Subject: Re: shared libs - can everyone be happy with this?
  85. Date: 14 Aug 92 16:22:50 GMT
  86.  
  87. william E Davidsen (davidsen@ariel.crd.GE.COM) wrote:
  88. :   If you didn't want to use the jump tables, you don't load the module
  89. : and you get linked to the real routines directly in memory in the slib.
  90. : The advantage of this is that you get all the benefits of the current
  91. : slib implementation in terms of performance.
  92.  
  93. Actually, we've already done that in the latest test release.
  94.  
  95. David
  96. -- 
  97. David Engel                        Optical Data Systems, Inc.
  98. david@ods.com                      1101 E. Arapaho Road
  99. (214) 234-6400                     Richardson, TX  75081
  100.  
  101. ------------------------------
  102.  
  103. From: chbarry@athena.mit.edu (Charles H. Barry)
  104. Subject: Re: Troubles compiling lilo v3
  105. Date: Fri, 14 Aug 1992 17:42:16 GMT
  106.  
  107.  
  108. I've been having the same problems compiling Lilo and ps-0.97 after
  109. installinf v0.97 and v0.97pl1.  Could someone please post or email me
  110. a description of the correct usr/include structure.
  111.  
  112. I've tried linking /usr/src/linux/include/linux to /usr/include/linux,
  113. but that doesn't work.  All I get is a lot of redefinition errors
  114. because both sys/types.h and linux/types.h are being included.  I've
  115. also tried linking the sys directory in similar fashion but that
  116. doesn't help either.
  117.  
  118.  
  119. Thanks,
  120. Chad Barry
  121. chbarry@athena.mit.edu
  122.  
  123. ------------------------------
  124.  
  125. From: arumble@extro.ucc.su.OZ.AU (Anthony Rumble)
  126. Subject: PTYP/TTYP programming.. 
  127. Date: Fri, 14 Aug 1992 10:04:01 GMT
  128.  
  129. Im sure this is a common problem, but.. i have no information
  130. to help me with this..
  131.  
  132. I am writing a small client to do something, that uses PTYP/TTYP pairs..
  133.  
  134. The client opens the ttyp open("/dev/ttyp0", O_RDWR) etc etc
  135.  
  136. and then fdopen's two streams (one for input, one for output)..
  137.  
  138. well.. anything that is sent to /dev/ptyp0 for some reason
  139. ends up on the client twice!!?!?!
  140.  
  141. the client only does this as yet..
  142.  
  143. while(1)
  144.    {
  145.    ch = fgetc(datin)l
  146.    printf("%c", ch);
  147.    }
  148.  
  149. If in another VT.. I do this echo hello >/dev/ptyp0
  150.  
  151. I will get 
  152.  
  153. Hello
  154. Hello
  155.  
  156. I get it twice?!?!
  157.  
  158. Any ideas..
  159.  
  160. Thanx in advance
  161.  
  162.  
  163. -- 
  164. Anthony Rumble
  165. aka SmilieZ
  166. "Anything is possible.. If there is enuf money in it"
  167.  
  168. ------------------------------
  169.  
  170. From: jbrogers@phoenix.Princeton.EDU (John B.  Jr. Rogerson)
  171. Subject: Small system compile woes
  172. Date: Fri, 14 Aug 1992 13:05:20 GMT
  173.  
  174. I would appreciate any help on the following two problems.
  175.  
  176. 1)   For the virtual terminals, the linefeed appears to be interpreted
  177.      as only a linefeed, not a carriage return/linefeed pair.  That is, the
  178.      cursor moves to the next line down but stays at the same column
  179.      position.
  180.  
  181. 2)   Defining the root device in /usr/src/linux/Makefile seems not to be
  182.      effective.  That is, build always creates a kernel that looks for
  183.      the root directory on a floppy.  Make prints out the build command
  184.      and the last argument is my root device (/dev/hda3), but build
  185.      seems to ignore it.
  186.  
  187. Thanks for any help.   
  188. Jack Rogerson    jbr@astro.princeton.edu
  189.  
  190. ------------------------------
  191.  
  192. From: hfaester@Physik.TU-Muenchen.DE (Hannes Faestermann)
  193. Subject: Re: SLS: Free Linux Distribution.
  194. Date: Fri, 14 Aug 1992 16:47:15 GMT
  195.  
  196. glover@dvinci.USask.Ca (Ken Glover) writes:
  197.  
  198. |erc@unislc.uucp (Ed Carp) writes:
  199. |: Peter MacDonald (pmacdona@sanjuan) wrote:
  200. |: 
  201. ...complaints about biz posting deleted...
  202.  
  203. |Read the original post again, it is available by anon ftp if you have access.
  204. |There is nothing wrong with distributing it by disk.  If you don't like it,
  205. |compete with it.
  206.  
  207. Hmm, am I blind or what ? I can't find an address for ftp in the posting.
  208. Or was this meant only for a few special people until a ftp server is
  209. found ?
  210.  
  211. Still interested in SLS
  212.  
  213.         Hannes
  214.  
  215. --
  216. Hannes Faestermann           |  Internet: 
  217. Physik-Department E17        |   Hannes.Faestermann@Physik.TU-Muenchen.DE
  218. TU Muenchen,                 |  
  219. 8046 Garching, West Germany  |
  220.  
  221. ------------------------------
  222.  
  223. From: jhuang@Chaos.mcs.kent.edu (Jing Huang)
  224. Subject: Need Help: TeX
  225. Date: Fri, 14 Aug 1992 17:12:31 GMT
  226.  
  227.         Hello everyone.
  228.  
  229.         I recently downloaded the TeX stuff from 129.78.66.1 (the Australia
  230. site) and followed the instructions in the README.222 file, and got it
  231. installed.
  232.  
  233.         I thought that I was about to fly. But when I ran "latex foo" or
  234. "tex foo", I got the following greetings:
  235.  
  236. ================================================
  237. This is TeX, C Version 3.141
  238. I can't find the default format file!
  239. ================================================
  240.  
  241. The first line is fine, but the second line ruined my whole day.
  242.  
  243.         I looked around the directories and found that all the format files
  244. "xxx.fmt" were there under the "/usr/local/lib/tex/formats" directory.
  245.  
  246.         So, what did I do wrong? How come TeX didn't like me. :-(
  247.  
  248.         Could someone please help me out here?
  249.  
  250. --
  251. Jing Huang  |  jhuang@Chaos.mcs.kent.edu
  252. Department of Physics
  253. Kent State University
  254. Kent, OH 44242
  255.  
  256.  
  257. ------------------------------
  258.  
  259. From: pete@cbnewsl.cb.att.com (peter.j.fillingham)
  260. Subject: 0.97 WORKS with SCSI ! [attn NEWBIES]
  261. Date: Fri, 14 Aug 1992 16:42:55 GMT
  262.  
  263.  
  264. Hooray ! Despite the many postings re glitches, features, bugs, etc.,
  265. both 0.97 boot-image and root-image work;
  266. In addition to boot screen announcements of hd0 etc etc the following
  267. graced my screen 
  268.         sd0 @ scsi0 ID0 lun0
  269.         sd1 @ scsi0 ID4 lun0
  270.         sd0 p.1 start    32 size 51168 end 51199
  271.             p.2 start 51200 size 40960 end 92159
  272.         sd1 p.1 start    32 size 20448 end 20479
  273.             p.2 start 20480 size 20480 end 4085?
  274. and so with fear and trembling i interpreted sd1 p.1 as sdb1 & used
  275. mkfs -c /dev/sdb1 10000
  276. when asked for /usr in the [excellent] install script.
  277. SO, the guts went on hda1 and the /usr stuff on /dev/sdb1 [AKA /usr].
  278. While this may be OBVIOUS to the cognescenti, perhaps my experience
  279. will be helpful to the less fortunate...
  280. BTW, i KNEW that my first SCSi drive was employed elsewhere as
  281. was the second half of sd1;  apparently the size reported is in
  282. blocks of 512 bytes, wheres linux uses 1024 byte/block...
  283. KUDOS to the SCSI freaks at woz etc.
  284. ...and KEEP THE ASPIDISTRA FLYING
  285.  
  286. Peter Fillingham [keeper of the DDEBs]      <<fillingham@att.com>>
  287.  
  288. ------------------------------
  289.  
  290. From: sakaria@vipunen.hut.fi (Sakari Aaltonen)
  291. Subject: Can't Compile Kernel 0.97
  292. Date: 14 Aug 1992 16:12:57 GMT
  293. Reply-To: sakaria@vipunen.hut.fi (Sakari Aaltonen)
  294.  
  295.  
  296. My attempt to build kernel 0.97 with gcc2.2.2 fails (at tools/build) because
  297. the following files are missing::
  298.      sys/types.h
  299.      fcntl.h
  300.      unistd.h
  301.  
  302. Specifically, they are not in /usr/include, that is, the directory that, as
  303. far as I understand, should be used for tools/build. 
  304.  
  305. I have files with these names among the kernel files. I tried copying them
  306. into /usr/include, which makes the make succeed. However, build then fails
  307. with the message
  308.   Can't stat root device
  309. Indeed, it seems that stat() ALWAYS returns -1...?? 
  310.  
  311.  
  312. Does anyone know where I might obtain the missing files? 
  313.  
  314. Out of curiosity: does anyone have an idea WHY the files are missing?
  315. Or why stat() should return -1, no matter what the path,
  316. "/usr/include", say?
  317.  
  318.  
  319. -- 
  320. =============================================================================
  321. Sakari Aaltonen                             Helsinki University of Technology
  322. Email: sakaria@vipunen.hut.fi
  323. ---  You can't keep a Finn down without him getting all red in the face  ----
  324.  
  325. ------------------------------
  326.  
  327. From: mal11@po.CWRU.Edu (Matthew A. Lewis)
  328. Subject: Diamond Speed Star SVGA card
  329. Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis)
  330. Date: Fri, 14 Aug 92 17:18:32 GMT
  331.  
  332.  
  333.  
  334.  
  335.  
  336. anyone got this to work with X under Linux????
  337.  
  338. And also, is it true that the Diamond Stealth card won't work 'cuz
  339. it has that new S3 chip???
  340.  
  341.  
  342.  
  343. Thanx in advance.
  344.  
  345. -- 
  346. MaThiEu a. LeWis   
  347. Thieves Like Us   
  348. mal11@po.cwru.edu   
  349.  
  350. ------------------------------
  351.  
  352. From: baron@clifton.hobby.nl (Wim `Blue Baron' van Dorst)
  353. Subject: Re: FAQ?
  354. Date: 14 Aug 92 02:04:38 GMT
  355.  
  356. wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
  357. | >I have waded through xxx million posts, and no FAQ!
  358. |> Did you see my meta-faq? It has a subject line
  359. |   Subject: README: Where to find information about Linux (25 July 1992)
  360.  
  361. Just a suggestion: How about giving the meta-faq a subject including the
  362. literal text `faq'? Then it would show up when searching all Subject
  363. lines for that very text.
  364.  
  365. Don't get me wrong: The faq and the meta-faq in itself are quite good 
  366. things. The complete faq could do with a little updating. I'm trying to get 
  367. Linux together here, and it doesn't answer all my obvious questions anymore.
  368.  
  369. Met vriendelijke groeten, Wim `Blue Baron' van Dorst
  370. =====================================================================
  371. Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
  372. (-:       baron@clifton.hobby.nl          tgcpwd@urc.tue.nl       :-)
  373. =====================================================================
  374.  
  375. ------------------------------
  376.  
  377. From: mal11@po.CWRU.Edu (Matthew A. Lewis)
  378. Subject: Re: Pointers to a list of Graphics Cards for X386
  379. Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis)
  380. Date: Fri, 14 Aug 92 17:21:07 GMT
  381.  
  382.  
  383. In a previous article, hasty@netcom.com (Amancio Hasty Jr) says:
  384.  
  385. |Currently, I am using a Diamond SpeedStar with 1MB (et4000 based).
  386. |X386 1.2E 1.0.[12] and the stock X386 server has been able to
  387. |work with my  card. I am writing a driver for the Diamond Stealth
  388. |
  389.  
  390.  
  391.  
  392. I opened a Speed Star and I couldn't find the ET4000 chip.
  393. Do all of them have it?
  394.  
  395. Thanx
  396.  
  397.  
  398. -- 
  399. MaThiEu a. LeWis   
  400. Thieves Like Us   
  401. mal11@po.cwru.edu   
  402.  
  403. ------------------------------
  404.  
  405. From: mal11@po.CWRU.Edu (Matthew A. Lewis)
  406. Subject: large caches ona 486
  407. Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis)
  408. Date: Fri, 14 Aug 92 17:24:21 GMT
  409.  
  410.  
  411.  
  412.  
  413. I was considering get a 256k cache for my i486-33 and I was wondering
  414. if anyone has had any problems with caches on these faster machine.
  415. I can't understand why there would be a hardware probelm depeendant
  416. upon software. The only problem I've ever had with a machine being TOO
  417. fast is playing video games :)
  418.  
  419. Later
  420.  
  421. -- 
  422. MaThiEu a. LeWis   
  423. Thieves Like Us   
  424. mal11@po.cwru.edu   
  425.  
  426. ------------------------------
  427.  
  428. From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
  429. Subject: Re: Hey!  Linux fs on DOS partition!
  430. Date: Fri, 14 Aug 1992 17:40:26 GMT
  431.  
  432. In article <713720748snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
  433. | Hey, here's a cool idea I had yesterday: Make a Linux filesystem
  434. | driver that puts its filesystem in a file on an MS-LOSS partition.
  435.  
  436. Sorry to disappoint you, but there are several people, who already
  437. had this idea. No shiny new patents .. ;-)
  438.  
  439. Seriously: half of it is already there. The other half will be missing
  440. until the variable block size code is completed. The first half is the
  441. loop devices patch, that makes it possible to mount regular files on
  442. file systems that support bmap as file systems.
  443.  
  444. Unfortunately, MS-DOS arranges its clusters in such an odd way, that
  445. bmap can't be used on hard disks and on some floppies. But it works
  446. with the old 360k (and I think also 1.2MB) format. If you have the
  447. loop devices patch installed, you can try something like this:
  448.  
  449. # mount -t msdos /dev/fd0 /fd   # there's a 360kB floppy in /dev/fd0
  450. # dd if=/dev/zero of=/fd/file bs=1k count=350
  451. # mkfs /fd/file 350
  452. # mount /fd/file /mnt
  453.  
  454. - Werner
  455. -- 
  456.    _________________________________________________________________________
  457.   / Werner Almesberger, ETH Zuerich, CH      almesber@nessie.cs.id.ethz.ch /
  458.  / IFW A44  Tel. +41 1 254 7213                 almesberger@rzvax.ethz.ch /
  459. /_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
  460.  
  461. ------------------------------
  462.  
  463. From: jmsimon@acsu.buffalo.edu (JMS)
  464. Subject: Re: large caches ona 486
  465. Date: 14 Aug 92 18:11:59 GMT
  466.  
  467. mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
  468. |
  469. |I was considering get a 256k cache for my i486-33 and I was wondering
  470. |if anyone has had any problems with caches on these faster machine.
  471. |I can't understand why there would be a hardware probelm depeendant
  472. |upon software. The only problem I've ever had with a machine being TOO
  473. |fast is playing video games :)
  474.  
  475. No problems here. Of course, I can't attest to any spped increase/decrease
  476. with Linux, as I haven't bothered disabling the cache. For MS-DOG it is
  477. definitely a help, tho.
  478.  
  479. It might not even be doing anything with Linux - would someone with more
  480. info like to shed some light on this? Does the cache make enough of a 
  481. difference to be worth having? I *can* compile the kernel in about 2-3mins,
  482. but that may just speak for the 486-33 and quick (relatively) IDE drives.
  483.  
  484. As an side, though, I have an opportunity to trade some hardware that I
  485. have (a 20mb hardcard, SVGA card and 12-1mbx9 SIMMS) for 4-4mb SIMMS. What
  486. kind of a difference will I notice going from 8mb to 16mb (4 of the 1x9's
  487. that I have are in a box because I only have 8 memory slots - woops!)?
  488.  
  489. |MaThiEu a. LeWis   
  490. |Thieves Like Us   
  491. |mal11@po.cwru.edu   
  492.  
  493. JMS
  494.  
  495. -- 
  496. *******************************************************************************
  497.  Jeffrey M. Simon              .o   o.       Computer Science / Business Mgmt.
  498.  jmsimon@acsu.buffalo.edu       ~~v~~        State University of NY at Buffalo
  499. ***** "Perspiration = ( Genius - 1% Inspiration ) / .99" -Ein*kinda*stein *****
  500.  
  501. ------------------------------
  502.  
  503. From: newbie@dylan.camb.inmet.com (Chris Newbold)
  504. Subject: Re: Buffer corruption problems.
  505. Date: 14 Aug 92 14:17:46 GMT
  506.  
  507. In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  508. |In article <1992Aug13.163854.21617@midway.uchicago.edu> ace3@quads.uchicago.edu (Tony 'LLama' Acero) writes:
  509. |
  510. |   I have no idea what's going on and would appreciate any input! :-)
  511. |   (The smiley is to indicate I'm not complaining and half-expecting
  512. |   that I've done something bone-headed)
  513. |
  514. |I'm not sure about your problem or the person's to whose post you followed up,
  515. |but...
  516. |
  517. |...I believe there is a bug in Linux that has the following behavior:
  518. |
  519. |-  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  520. |   so that what your app ends up with is some _other_ 1024KB chunk
  521. |   (apparently from the same file)
  522. |
  523. |-  occurs only during very heavy disk access, such as megabytes accessed
  524. |   continually
  525. |
  526. |-  is intermittent, but happens enough to reproduce fairly easily
  527. |
  528. |-  might be SCSI-related (I have a SCSI system) but, based on responses I've
  529. |   gotten from others saying they've seen the same behavior, probably isn't
  530. |
  531. |-  is still in 0.97 and perhaps happens somewhat more often there (though of
  532. |   course it's hard to measure this)
  533.  
  534. Yep. I've seen this too. My system is running off SCSI disks. I'd agree
  535. with everthing listed above and add:
  536.  
  537.         - It can happen on WRITES as well.
  538.  
  539. Occasionally when I'm rebuilding the kernel, make will die with some
  540. horrid error like it can no longer find the makefile it was working from.
  541. Shorty thereafter, anything which accesses the disk seg. faults and dies.
  542.  
  543. When I bring the system back up, the filesystem is hosed. Usually the
  544. superblock is scrambled so fsck just refuses to look at the drive.
  545.  
  546. Not good.
  547.  
  548. -Chris
  549.  
  550. -- 
  551. ---- Chris Newbold ---- > "If you fool around with a thing for very long you <
  552.    Intermetrics, Inc.   >                 will screw it up."                 <
  553.   Opinions and statements expressed are MINE and do NOT represent my employer
  554.                         newbie@inmet.camb.inmet.com
  555.  
  556. ------------------------------
  557.  
  558. From: callison@uokmax.ecn.uoknor.edu (James P. Callison)
  559. Subject: Re: Linux Logo
  560. Date: 14 Aug 92 18:11:15 GMT
  561.  
  562. In article <1992Aug14.002854.20701@constellation.ecn.uoknor.edu> callison@uokmax.ecn.uoknor.edu (James P. Callison) writes:
  563. |BTW-that thar logo jain't under the GNU Copyleft. I hold a copyright
  564. |on it. That means that you can copy it, use it on your distribution
  565. |of Linux, change it, do whatever you like, but you CANNOT sell the
  566. |LOGO for ANY price. I would like to get some credit, though. :-)
  567. |(And I mean it--don't sell the LOGO. Use it as you will. Put it
  568. |on Linux distributions you're selling for $6,000,000 apiece.
  569. |Change the release number. Change the colors. Change the font.
  570. |But absolutely DON'T sell the logo at ANY price.)
  571. |
  572. |Thanks.
  573.  
  574. Arrogant bastard, ain't I? :-)
  575. Hmm...this doesn't seem to have come out right (sorry, I was fighting
  576. a whineybaby file server--why can't it just suck it up and ignore those
  577. memory errors like a _real_ 486? :-)
  578. I just want to make sure that everybody knows that this thing is 
  579. _freely_ distributable (as in _NO_ cost), and freely editable (come on,
  580. the thing was a first draft! :-)
  581.  
  582.                                 James
  583.  
  584. James P. Callison       Microcomputer Coordinator        OU Law Library 
  585. Callison@aardvark.ucs.uoknor.edu   /\        Callison@uokmax.ecn.uoknor
  586.         constellation!biglaw!callison@mailhost.ecn.uoknor.edu
  587. DISCLAIMER: I'm not an engineer, but I play one at work...
  588.         Here's to all the soldiers who have ever died in vain,
  589.         The insane locked up in themselves, the homeless down on Main
  590.         To those who stand on empty shores, and spit against the wind
  591.         And those who wait forever for ships that don't come in
  592.                 --Joe Diffee, "Ships That Don't Come In"
  593.  
  594. ------------------------------
  595.  
  596.  
  597. ** FOR YOUR REFERENCE **
  598.  
  599. The service address, to which questions about the list itself and requests
  600. to be added to or deleted from it should be directed, is:
  601.  
  602.     Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
  603.  
  604. You can send mail to the entire list (and comp.os.linux) via:
  605.  
  606.     Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
  607.  
  608. Linux may be obtained via one of these FTP sites:
  609.     nic.funet.fi                pub/OS/Linux
  610.     tsx-11.mit.edu                pub/linux
  611.     tupac-amaru.informatik.rwth-aachen.de    pub/msdos/replace
  612.  
  613. The current version of Linux is 0.97 released on August 1, 1992
  614.  
  615. End of Linux-Activists Digest
  616. ******************************
  617.