From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 12 Nov 93 18:13:36 EST Subject: Linux-Development Digest #221 Linux-Development Digest #221, Volume #1 Fri, 12 Nov 93 18:13:36 EST Contents: Re: STRLEN() == 3 ??!?? (Kai Petzke) Re: STRLEN() == 3 ??!?? (Joost Helberg) Re: [Q] Big modem installation for Linux? (Herb Peyerl) Re: Berkeley Fast Filesystem (Herb Peyerl) Re: new Berkeley DB - anyone? (Jon Brawn) Re: [Q] Big modem installation for Linux? (Jon Brawn) Re: 16550A handling in serial.c (Grant Edwards) Kernel Compiling (Debi Reid) Re: Berkeley Fast Filesystem (Wayne Schlitt) Re: [Q] Big modem install (Ron Arts) Re: Kernel Compiling (Joseph W. Vigneau) Re: Why does abort() trash my stack frame (Kevin Brown) Re: Berkeley Fast Filesystem (CHoPP Computer Corp.) Re: STRLEN() == 3 ??!?? (Frank Lofaro) Re: Berkeley Fast Filesystem (Nate Williams) Re: Berkeley Fast Filesystem (Nate Williams) Motif - Pay? BAH! (peter j dohm) Re: Motif - Pay? BAH! (peter j dohm) ---------------------------------------------------------------------------- From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: STRLEN() == 3 ??!?? Date: 11 Nov 1993 17:43:24 GMT In pasko@ibm8.scri.fsu.edu (Joe Pasko) writes: >Under linux, I took the strlen of a null pointer and was returned 3. >Any clue as to why this is happening ?? Maybe, this is a question, which should be posted to comp.os.linux.help. strlen(NULL) is illegal syntax, because NULL is not a pointer to a string. Rather, it points to the beginning of the text segment. At this address is typically a long call instruction to the routine, which loads the shared libraries. A long call implies a one byte operand code and 4 byte address. Unless the destination of the call exceeds 64 k, the two higher bytes of the address are zero. Thus, there are typically three non-zero bytes at address zero. -- Kai wpp@marie.physik.tu-berlin.de Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, than make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: jhelberg@nlsun8.oracle.nl (Joost Helberg) Subject: Re: STRLEN() == 3 ??!?? Date: Thu, 11 Nov 1993 17:12:18 GMT In article pasko@ibm8.scri.fsu.edu (Joe Pasko) writes: Under linux, I took the strlen of a null pointer and was returned 3. Any clue as to why this is happening ?? Yes, A pointer with the value 0 points to nothing usefull, this doesn't mean you can't use this unusefull stuff, you just shouldn't. Some architecture put a 0 on location 0, some give a SEGMENTATION VIOLATION, others just don't do special things and give you the data that is availeble on 0. Nothing strange about it. -- Joost Helberg Rijnzathe 6 jhelberg@oracle.nl NL-3454 PV De Meern jhelberg@nl.oracle.com The Netherlands Oracle Europe BV Product Line Development Phone: +31 3406 94211 Fax: +31 3406 65609 ------------------------------ From: hpeyerl@novatel.ca (Herb Peyerl) Subject: Re: [Q] Big modem installation for Linux? Date: 11 Nov 1993 18:19:29 GMT Wayne Flagg (wflagg@cabernet.tymnet.com) wrote: : Carl Boernecke (carlb@hardy.u.washington.edu) wrote: : : byron@cc.gatech.edu (Byron A Jeff) writes: : : >In article <2bo97j$lvs@belfort.daimi.aau.dk>, : : >Jesper Bach Larsen wrote: [Lots of people suggesting the use of terminal servers] A Terminal server would be the correct approach in a situation like that (provided you specified that they were 8-bit clean. Nothing worse than trying to do a zmodem file transfer through a non-clean telnet session.) However; wouldn't the pre-requisite in the use of a Terminal server be "stable networking"??? -- hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | ------------------------------ From: hpeyerl@novatel.ca (Herb Peyerl) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 11 Nov 1993 18:21:44 GMT Joachim Hoenig (hoenig@immd3.informatik.uni-erlangen.de) wrote: : imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: : With some reverse engineering the NetBSD file system utilities like : tunefs, newfs and fsck compile nicely on linux, though. Why would you have to reverse engineer anything from NetBSD. The source is free you know... -- hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | ------------------------------ From: jonb@specialix.com (Jon Brawn) Subject: Re: new Berkeley DB - anyone? Date: Thu, 11 Nov 1993 17:13:33 GMT quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes: > >Please do not post source to non-source newsgroups. This newsgroup is >intended to be used for discussion of the development of the Linux OS, >not anything else. Which does prompt the question - where *should* little snippets of source be posted? >-- >Daniel Quinlan ------------------------------ From: jonb@specialix.com (Jon Brawn) Subject: Re: [Q] Big modem installation for Linux? Date: Thu, 11 Nov 1993 17:21:43 GMT carlb@hardy.u.washington.edu (Carl Boernecke) writes: >byron@cc.gatech.edu (Byron A Jeff) writes: >>In article <2bo97j$lvs@belfort.daimi.aau.dk>, >>Jesper Bach Larsen wrote: >>> >>>As headline says, I wan't to run a Unix installation, preferable Linux, as it >>>is free, with multiple modem lines. By multiple I mean in the amount of >>>30-50 modems. I suppose I will have to purchase somekind of hardware support >>>for this project. My question is: what would be the most effective (measured >>>in system-resources) installation? What kind of system-resource is required >>>for this (particular RAM recomendations, special I/O interfaces etc.) >>I'm presuming that you want to attach that many modems to 1 machine. For >>multiple machines you can possibly use 4-6 networked machines with STB >>4Ports such that each machine has 8 modems attached. >Here's an idea... how about getting a terminal server (an easy 12-14 >hpone lines there), and an ethernet card for the Linux box, and going >from there? Sounds liek it work, though terminal servers (liek the >Xytel) costs some $$$'s, but it woudl probably be less expensive and >easier to maintain than a bunch of different boxes answering 8 lines >each. >I can see it now... '/dev/ttyzz'! Ack! :) Specialix market a terminal server with the following LIST prices (US $) 8 ports $1695 16 ports Add $650 24 ports Add Another $650 32 ports Add Another $650 The MTS is easily upgrable to 32 ports by attaching 8 port modules. The modules are available as DCE, DTE, or RJ45 RS232 units, or as 7 RS232 + one parallel. Specialix can be contacted on 1-408-378-7919 >-- Carl Boernecke (carlb@u.washington.edu or carlb@inex.com) ------------------------------ From: grante@hydro.rosemount.com (Grant Edwards) Subject: Re: 16550A handling in serial.c Date: Thu, 11 Nov 1993 16:39:33 GMT Harald Koenig (koenig@nova.tat.physik.uni-tuebingen.de) wrote: : Another UART question (I have 4 16550As): : : the normal UARTS do probing for the start bit synchronously with : 16 times the baud rate (for 50 baud this is 800 Hz or 1.25ms). : : Are any (pin compatible?) UARTs known which have a better : time resolution on start bit detection? : : if not pin and plug compatible, are there any pc cards with such uarts? Not try to be a smart-ass (for once), but why do you care whether the UART samples as 16X or 32X or 64X or whatever. I can't think of _any_ benifit of sampling at higher than 16X. -- Grant Edwards |Yow! FEELINGS are cascading Rosemount Inc. |over me!!! | grante@rosemount.com | ------------------------------ From: dreid@mailer.cc.fsu.edu (Debi Reid) Subject: Kernel Compiling Date: Thu, 11 Nov 1993 18:08:14 GMT Hello, I am having serious trouble re-compiling the kernel. I have the latest SLS with 0.99p12 kernel, and am quite aware that the source include with this will not compile. However, I downloaded 99p13 with patch, and installed it, along with snd-driv-2.0 from sunsite, and I still have serious problems compiling (loop.c , actually blk.h, gives me "unknown block device"). Is there (actually I have heard of) FAQ for kernel compiling,, but can't seem to locate them. Could someone either give me some pointer or point me to a FAQ. Thank! ------------------------------ Crossposted-To: comp.os.linux.admin From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Berkeley Fast Filesystem Date: Thu, 11 Nov 1993 20:42:59 GMT In article <2bt54jE3er@uni-erlangen.de> hoenig@immd3.informatik.uni-erlangen.de (Joachim Hoenig) writes: > imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: > >> Reading O'Reilly's "Essential System Administration" (Nutshell serie), > >>on page 250 of my edition it talks about the BSD Fast filesystem. Compared > >>to the "Traditional System V filesystem", it sounds quite impressive. I > >>was wondering where ext2fs stands in comparison to these two? > > ext2fs does not yet support fragments (at least as far as I know). Fragments are not necessarily a good idea. There are two independent values here: 1) How big should the block size be when allocating space for a file? On average, you will waste about half of the last block allocated, unless you make the block size _way_ too big and most files fit in less than one block, in which case you will waste more than half. On a typical Unix system, approx 40% of the files will be 1k or less, and 90% of the files will be 4k or less. If you make the block size too small, then too much space will be wasted keeping track of the blocks. So, the allocation unit should probably be somewhere around 1k, maybe as small as 256, maybe as large as 4k. 2) How much data should you read off the disk at one time? If you read too little data, then you are going to spend a lot of time dealing with the overhead of reading blocks. You also won't be able to read consecutive tracks, causing rotational delays to be added in. If you read too much data, then you may well be wasting space on I/O buffers that could better be used for programs or data. Typically, 8k-128k should be read at one time, if you detect that the file is being read sequentially. If it is being read randomly, then read the smallest amount possible. The old Version 7 file system used 512 byte blocks, which is great for an allocation size, but horrible for a disk access size. The Berkeley Fast Filesystem changed things to use a 8k block size, which is better for a disk access size, but horrible for an allocation size. In order to "fix" the problem with the allocation size, they created fragments, which are 1k. Unfortunately, you can only use a fragment if the entire file fits in the fragment, so the FFS wastes, on average 4k any time the file is over 1k in size. Fragments add additional code and complications when something needs to be moved too or from a fragment. The 8k block size also isn't large enough to get really good throughput from the disk when reading sequentially, and it is too large when reading randomly. So, what is the solution? Well, allocate things using a 512-2k blocksize, and read/write _many_ blocks at one time. This is known as clustering. It works better than the FFS and the code is simpler to boot. The Berkeley FFS also suffers from several other problems on modern disk drives. In particular, they made the assumptions that the users knew how many heads, tracks and cylinders the disk had, and the the number of tracks per sector stayed constant across the disk. With SCSI drives, you don't know this information and the tracks per sector isn't constant. IDE drives usually lie about the number of heads and cylinders in order to work under DOS. While the Berkeley FFS was much better than the Version 7 file system, it is far from being an ideal filesystem. -wayne ------------------------------ From: raarts@hacktic.nl (Ron Arts) Subject: Re: [Q] Big modem install Date: 11 Nov 1993 20:51:32 +0100 Newsgroups: comp.os.linux.development Subject: Re: [Q] Big modem install w> How about a linux box with n serial ports and ethernet, no console, w> no anything but act as a terminal server. I remember working with w> Bridge terminal servers that were just dedicated unix boxes. They w> booted off a floppy as I remember. We used 'em to avoid trying to w> put >256 ports on a VME box - which was about as attractive as 30-50 w> serial ports on a linux box. Probably cheaper than buying a terminal w> server - anyone know what they cost these days? Cheapest I could find was 4600 Dutch Guilders (about $2500) w> What would a floppy w> only, ethernet, and no console linux box cost? Yeah, that could be a nice solution. But don't forget you need serial ports.. Can you run Linux from a floppy disk only (and get the rest from the lan)? Ron Arts Ster-BBS: +31-188040035(raarts) Internet: raarts@hacktic.nl CompuServe: 72163,463 --- þ KWQ/2 1.2b NR þ ------------------------------ From: joev@bigwpi.WPI.EDU (Joseph W. Vigneau) Subject: Re: Kernel Compiling Date: 11 Nov 1993 22:48:05 GMT [problems compiling 0.99pl13 (missing blk.h etc. deleted.] I had the exact same problem. Here's how I fixed it: 1) keep your linux pl13 tar file in a safe place on your directory tree. 1 1/2) rename zImage to zImage.99.12 (safety reasons) 2)cd /usr/src/linux 3) rm -r -f * 4) tar xvf 5) Follow the readme, make config, make dep, and finally make zBoot (or zImage, I forgot. Ony one is available, anyway). 6) Sit back and watch some tv for a while.. It took 20 minutes on my 486DX33 to compile and build... 6 1/2) You may have to move the new zImage to the root dir... 7) Rerun /etc/lilo/install -v -v -v again (if you use lilo). 8) Enjoy. The problem was that you didn't clean out the directory tree first..I had the same problem... -- joev@wpi.edu -- Joseph W. Vigneau Worcester Polytechnic Institute -- Computer Science Runnung Linux 0.99pl13: The fast *free* 32-bit OS for i386 and i486. ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Why does abort() trash my stack frame Date: Thu, 11 Nov 1993 19:10:01 GMT In article <1993Nov5.120106.5155@monu6.cc.monash.edu.au> parry@yoyo.cc.monash.edu.au (Tom J Parry) writes: >Calling the abort function inevitably leaves a stack frame which >gdb can't decipher. Does anybody know about this behaviour ? - or better >still have a fix for it. It's very annoying, as a program gets to an >assertion which is supposed to stop everything so you can do a post >mortem, but instead you get a useless stack frame. Yup. I've noticed this same problem as well. I don't know what the root cause of it is, but I have a workaround. Here's the source to an abort() that will cause the stack frame to be generated (preserved?) properly. It won't work when you're out of processes, but it'll work in all other cases: void abort() { int ppid; ppid = getpid(); signal ( SIGABRT, SIG_DFL ); if ( ! fork() ) { kill ( ppid, SIGABRT ); exit ( 0 ); } while ( 1 ) pause(); } >sigh, Indeed. >Tom J Parry. >Your reality is a figment of my imagination. Except in this case. :-) -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ Crossposted-To: comp.os.linux.admin From: chopp@netcom.com (CHoPP Computer Corp.) Subject: Re: Berkeley Fast Filesystem Reply-To: andras@cyber.net Date: Fri, 12 Nov 1993 01:53:14 GMT In article wayne@backbone.uucp (Wayne Schlitt) writes: >Fragments are not necessarily a good idea. There are two independent >values here: > > 1) How big should the block size be when allocating space for a > file? > ... > 2) How much data should you read off the disk at one time? > ... > >The Berkeley Fast Filesystem changed things to use a 8k block size, >which is better for a disk access size, but horrible for an allocation >size. In order to "fix" the problem with the allocation size, they >created fragments, which are 1k. Unfortunately, you can only use a >fragment if the entire file fits in the fragment, so the FFS wastes, >on average 4k any time the file is over 1k in size. Fragments add >additional code and complications when something needs to be moved too >or from a fragment. The 8k block size also isn't large enough to get >really good throughput from the disk when reading sequentially, and it >is too large when reading randomly. I thought any file could use fragments at the very end of the file. That is, the cluster size (transfer size) was 4k (8k on Sun), but the allocation size was effectively 1k. Files were laid out in contiguous multiples of 4k, with the last few k scattered around in fragments. If the file grew, the fragments were collected and copied into a new block. Other neat features of the BSD FFS were elevator head scheduling, contiguous space allocation, and an attempt at reasonable free space management -- directories and files created where there is room to grow (to still provide contiguous allocation even in an in-use file system, avoiding disk fragmentation). Some of the journaling filesystems may achieve as good or better performance, though, using a completely different approach. > ... >SCSI drives, you don't know this information and the tracks per sector >isn't constant. IDE drives usually lie about the number of heads and >cylinders in order to work under DOS. Newer IDE drives, like SCSI drives, all seem to have "zones" with different number of sectors per track in each zone -- so they have to lie. Andras andras@cyber.net ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: STRLEN() == 3 ??!?? Date: Fri, 12 Nov 93 05:04:26 GMT In article jhelberg@nlsun8.oracle.nl (Joost Helberg) writes: >In article pasko@ibm8.scri.fsu.edu (Joe Pasko) writes: > > Under linux, I took the strlen of a null pointer and was returned 3. > > > Any clue as to why this is happening ?? > >Yes, > >A pointer with the value 0 points to nothing usefull, this doesn't mean >you can't use this unusefull stuff, you just shouldn't. > >Some architecture put a 0 on location 0, some give a SEGMENTATION >VIOLATION, others just don't do special things and give you the >data that is availeble on 0. > >Nothing strange about it. >-- It should segfault. That would make trapping NULL pointers easier. It already works for the kernel itself... ------------------------------ From: nate@bsd.coe.montana.edu (Nate Williams) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 1993 05:49:26 GMT In article , Wayne Schlitt wrote: >Fragments are not necessarily a good idea. There are two independent >values here: > 1) How big should the block size be when allocating space for a > file? > > On average, you will waste about half of the last block > allocated, unless you make the block size _way_ too big and most > files fit in less than one block, in which case you will waste > more than half. > > On a typical Unix system, approx 40% of the files will be 1k or > less, and 90% of the files will be 4k or less. I think this has changed, but I have no numbers to back it up. > If you make the block size too small, then too much space will > be wasted keeping track of the blocks. In a non-fragmented FS, too much space will be wasted when it your program does not fit into a complete block. Keeping track of the block is pretty much the same cost no matter how big the file is since the inode is of fixed length. > So, the allocation unit should probably be somewhere around 1k, > maybe as small as 256, maybe as large as 4k. > > > 2) How much data should you read off the disk at one time? > > If you read too little data, then you are going to spend a lot > of time dealing with the overhead of reading blocks. Right. When you read in block-at-a-time mode, you can only read the blocksize value at a time. The larger the blocksize, the more data you read at one time. > You also > won't be able to read consecutive tracks, causing rotational > delays to be added in. Huh? I think the end result is that if you read one block at a time, you read one block at a time. This has very little bearing on disk tracks. > If you read too much data, then you may well be wasting space on > I/O buffers that could better be used for programs or data. ??? This is irrelavant to the file-system, and is a problem with your buffer code being overly agressive. >The Berkeley Fast Filesystem changed things to use a 8k block size, >which is better for a disk access size, but horrible for an allocation >size. In order to "fix" the problem with the allocation size, they >created fragments, which are 1k. >Unfortunately, you can only use a >fragment if the entire file fits in the fragment, so the FFS wastes, >on average 4k any time the file is over 1k in size. What *ARE* you talking about? The fragments are used for the tail ends of the files. Say you have a 40.1K file, with an 8K/1K filesystem. With a non-fragmented file-system, you would use up 6*8K=48K of your file system space, because the first 40K of the file fills up 5 8K blocks, but you MUST use an entire block in order to store the final data. So, out of a 40.1 K file we have 7.9K of wasted space. However, with the Berkeley FFS (and other similar FS), we use the same original 5 8K blocks as well, but because we have 1K fragments, we break up the blocks into 8-1K chunks. The final .1K of the file fits into the 1K chunk. This is only wasting 0.9 K of space, instead of the 7.9K. A fragmented file-system will almost invariably use less space than a non-fragmented file-system. However, as you eluded to above, the tradeoff is speed. >Fragments add >additional code and complications when something needs to be moved too >or from a fragment. The 8k block size also isn't large enough to get >really good throughput from the disk when reading sequentially, and it >is too large when reading randomly. ??? 8K isn't large enough to get really good throughput. Let's see some numbers to back that up. I get VERY good performance using an 8K/2K BSD-FFS with the 486/33. (1.5MB/sec reading and 1MB/sec writing w/out any hardware cache on a 486/33 ISA box. On EISA boxes I've seen numbers in the upper 2's and 3's) >The Berkeley FFS also suffers from several other problems on modern >disk drives. In particular, they made the assumptions that the users >knew how many heads, tracks and cylinders the disk had, and the the >number of tracks per sector stayed constant across the disk. With >SCSI drives, you don't know this information and the tracks per sector >isn't constant. IDE drives usually lie about the number of heads and >cylinders in order to work under DOS. Hmm, I know how many heads, tracks, cylinders and such on my drive. And, the filesystem knows how to optomize for this. If you don't know this information, it can't optomize for it but the BSD-FFS doesn't REQUIRE this information for it to work effeciently. (And it was pointed out in a followup article that most newer drives use zones. I've heard that the BSD 4.4 SCSI drivers take this information into account so that the FS can use them.) >While the Berkeley FFS was much better than the Version 7 file system, >it is far from being an ideal filesystem. Nobody is claiming it's the ideal filesystem, but it sure beats alot of existing filesystems that are currently out there. The BSD-FFS with the recent 4.4 additions to it is still one of the fastest filesystems around. (Now if we could pry those changes out of the author, but he has been too busy with real work to get them to us. :-) Let's all hope that the USL-BSDI suit ends soon. Nate -- nate@bsd.coe.montana.edu | Freely available *nix clones benefit everyone, nate@cs.montana.edu | so let's not compete with each other, let's work #: (406) 994-4836 | compete with folks who try to tie us down to home #: (406) 586-0579 | proprietary O.S.'s (Microsloth) - Me ------------------------------ From: nate@bsd.coe.montana.edu (Nate Williams) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 1993 05:50:47 GMT In article , CHoPP Computer Corp. wrote: >>SCSI drives, you don't know this information and the tracks per sector >>isn't constant. IDE drives usually lie about the number of heads and >>cylinders in order to work under DOS. > >Newer IDE drives, like SCSI drives, all seem to have "zones" with >different number of sectors per track in each zone -- so they have to lie. Most of the 'lying' is required because of MS-DOS's 1024 cylinder limit. Nate -- nate@bsd.coe.montana.edu | Freely available *nix clones benefit everyone, nate@cs.montana.edu | so let's not compete with each other, let's work #: (406) 994-4836 | compete with folks who try to tie us down to home #: (406) 586-0579 | proprietary O.S.'s (Microsloth) - Me ------------------------------ From: dohm@cis.ohio-state.edu (peter j dohm) Subject: Motif - Pay? BAH! Date: 12 Nov 1993 00:50:48 -0500 Hi all... Well, today I wanted to get Mosaic-2.0 and compile it on my machine... I can't. I don't have Motif. I refuse to purchase a binary-only distribution, and a source distribution is too pricey. Therefore, I'd like to throw out a project idea if the legalities allow for such... I'd like to begin programming a Motif clone that we can pass around under GPL to whomever would like it, assuming that we can legally get around the naming conventions, etc. (by this I mean, can we call the cloned functions the same names as the Motif ones, etc... ?) Ideally it would be a drop-in replacement for Motif, allowing the end user to simply create a soft-link to the "clone" library with a name libXm.a and they would (in a nutshell) have a transparent replacement. (you should have a grasp of the idea by now ;) I've begun this discussion in comp.os.linux.development simply because it's a good place to start. I know there are sufficiently many lovers of "free" software herein, and maybe a few have enough time to devote... If we (as a general community) feel it to be a good idea, then I shall enlist help from without. This seems to be one of the last pieces of software that aren't available for "free" that the masses use on a daily basis (for X in a unix environment, anyway :). This seems like a TREMENDOUS task to undertake, but heck, writing linux was a tremendous task in itself... Nothing is impossible, and I need some focus to my energies anyway ;) I'd like to be the organizer / chief coder so as to make this my resume-topper :) I've got time to devote to this task, and I feel it would be a very well received piece of software (once again, assuming legalities are surmountable). I've received so many benefits from "free" software, now I'd like to make my contribution... interested? respond to me at: dohm@cis.ohio-state.edu Pete --- +---------------------------------------------------------------------------+ | Peter J. Dohm - Comp. Science Major | The Ohio State University | | ** dohm@magnus.acs.ohio-state.edu ** | ak541@cleveland.freenet.edu | | dohm.1@osu.edu, dohm@cis.ohio-state.edu | dohm@cis.ohio-state.edu | +---------------------------------------------------------------------------+ ------------------------------ From: dohm@cis.ohio-state.edu (peter j dohm) Subject: Re: Motif - Pay? BAH! Date: 12 Nov 1993 09:32:33 -0500 >OSF has given resp. will give (I'm not quite sure) the Motif *specification* to >X/OPEN. That means, Motif will be an open standard. Everybody who wants can get >the specification and implement his own Motif. 'nuff said... I shall be looking into the formal specifications in the near future, and with all the responses I've already gotten (via email), I'm tentatively planning the design stages to begin in the next week to two weeks... Everyone who's mailed me will go into a pseudo mailing list... Keep messages coming... Pete --- +---------------------------------------------------------------------------+ | Peter J. Dohm - Comp. Science Major | The Ohio State University | | ** dohm@magnus.acs.ohio-state.edu ** | ak541@cleveland.freenet.edu | | dohm.1@osu.edu, dohm@cis.ohio-state.edu | dohm@cis.ohio-state.edu | +---------------------------------------------------------------------------+ ------------------------------ ** 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 ******************************