From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 19 Oct 93 16:13:34 EDT Subject: Linux-Development Digest #174 Linux-Development Digest #174, Volume #1 Tue, 19 Oct 93 16:13:34 EDT Contents: Re: /dev not needed? (Bill Heiser) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (CSHAULIS@DELPHI.COM) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (CSHAULIS@DELPHI.COM) Re: Linux System Administration Tools (David Taylor) Linux driver for GS4500 class handscanners. (Rick) Re: Use 'jargon' reader for FAQ (Brian McCauley) Re: /dev not needed? (Matthew Dillon) Re: The %&#$@ speaks again -or- An apology (Russell Schulz) Re: /dev not needed? (Dominik Kubla) Fonts for virtual consoles (Harald T. Alvestrand) SysV IPC system-wide limits? (Adrian Wallaschek) UNIX trademark now X/Open (H. Peter Anvin N9ITP) Re: Fonts for virtual consoles (Andrew KUCHLING) Re: Use 'jargon' reader for FAQ (Ed H. Chi) Libc 4.4.4 and new sig 11's (not ram chips) (Byron Thomas Faber) Re: UNIX trademark now X/Open (Thomas Koenig) Re: /dev not needed? (Brandon S. Allbery) ---------------------------------------------------------------------------- From: bill@bhhome.ci.net (Bill Heiser) Subject: Re: /dev not needed? Date: Tue, 19 Oct 1993 00:45:55 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >original contents of /devices is retained. ("boot -r" also takes care of >maintaining the links from /dev to /devices, and of creating pseudo-device >nodes such as ptys. The latter would be unnecessary with a proc-based >mechanism; Solaris 2's /devices is solely based on the result of a hardware >probe.) I doubt a "hardware probe" is going to work very well on [an ISA based] PC :-) -- Bill Heiser bill@bhhome.ci.net heiser@world.std.com ------------------------------ From: cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 18 Oct 1993 23:02:56 -0400 tzs@stein3.u.washington.edu (Tim Smith) writes: >A Wizard of Earth C wrote: >>Note that you will either have to extend the VNOPS tabe or forget about >>resource forks. >How about making each Mac file appear to be three unix files? Mac file >"foo" would appear under unix as "foo" (the data fork), "foo:r" (the >resource fork), and "foo:i" (the Finder information). >--Tim Smith I agree with Tim's idea. I've heard talk before about doing all sorts of crazy stuff to the Linux kernel to manage Mac resources and treat files like macs do, and so forth. I find the idea very distasteful. I'd vote for the file.r, file.d, file.i design -- that should be sufficient for grabbing fonts, text, and so forth. If ya need to pick apart the resource fork then someone could write a resource decompiler like the windows folks use, just don't stick it in the file system code. My two cents, Christopher cshaulis@Delphi.com ------------------------------ From: cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 18 Oct 1993 23:13:28 -0400 ftlofaro@unlv.edu (Frank Lofaro) writes: :Ah, the Mac disk thread again! ;) If the speed changing disks for theMac800K :format use speed <= normal speed of a PC drive, you could just turn on and :off the floppy drive motor by toggling the control bit really fast. Higher :duty cycle (% on), higher speed. It would be a trouble to calibrate, might :act different on different drives (different speed vs duty cycle curve, :might not work well, could possibly hose the drive (?), etc). I caught that idea in the last thread. If memory serves, someone was telling stories about how they toasted three drives with the above method. Christopher cshaulis@Delphi.com ------------------------------ From: ddt@daisy.cc.utexas.edu (David Taylor) Subject: Re: Linux System Administration Tools Date: 18 Oct 1993 23:28:35 -0500 Frank Lofaro wrote: >Ugh, [SMIT is] that monstrosity from AIX. I've heard it is a real pain, and >always in the way. > >Maybe the menu package that SLS co-opted for itself, maybe that could be >set-up for system administration. Much better idea. SMIT is very nice for the mundane sysadmin work such as manipulating users, a lot of NFS work, most filesystem stuff, etc. However, I think the reason it is perceived as a monstrosity is that even though it is a very happy mask over the operating system administration, AIX administration used to be a fairly hideous beast to begin with (still is, sorta). Couldn't mask the entire ugliness. :) I wouldn't follow the SMIT UI to the letter, however. It's basically just a simple hierarchical menu system which turns leaf nodes into short scripts. Unfortunately, you can tell that the tty version was written by guys used to working on IBM mainframes. Has that gruesome screen-oriented feel to it. Uses F-keys, too, which I've always distrusted as part of a tty interface for some reason (some kind of brain damage?). =-ddt-> ------------------------------ From: pclink@qus102.qld.tne.oz.au (Rick) Subject: Linux driver for GS4500 class handscanners. Date: Tue, 19 Oct 1993 05:57:25 GMT If you've mailed me recently asking for a copy of the driver for a GS4500 and haven't heard from me, please post me another note. Our mail service has been royally screwed up, and it's possible that outbound mail was not correctly delivered. You can reach me at pclink@qld.npb.telecom.com.au. Alternatively, if somebody would like to send me instructions on how to put the driver on tsx or sunsite without using FTP, I would like to hear from you. I'm at the far end of a dialup link, so interactive FTP is a no-go. Thanks, Rick. ------------------------------ From: bam@wcl-l.bham.ac.uk (Brian McCauley) Subject: Re: Use 'jargon' reader for FAQ Date: 19 Oct 1993 09:11:41 GMT Reply-To: B.A.McCauley@bham.ac.uk In article tim@lorien.demon.co.uk (Tim Towers) writes: I have been following the thread about reading the FAQs before posting. I have done so, and keep an (out of date) copy nearby. However, as was pointed out by someone on the net, Linux is a moving target so there is a definite lag between a problem being fixed and appearing in a FAQ. I have a possibility which may help people to search the FAQs easier (500k chews up anyones time) and thus may cut down the 200+ linux postings I read each day. If any of you have read the GNU jargon file, you know its HUGE :-) you may also have come across the jargon file viewer also available from GNU (vh-1.5.tar.gz - compiles with the -traditional flag) which treats the jargon file as a hypertext document, allowing you to follow a thread of information. I would like to see this method used for linux documentation too. eric@tantalus.nrl.navy.mil (Eric Youngdale) is working on a texinfo verion of some of HOWTO/FAQ stuff. This is probably a more appropriate hypertext system. But a hypertext version is unlikely to cut down lazy posts. With the exisiting FAQ one can often guess a few keywords from the lazy ********s Subject: lines and find the answer in the FAQ in <30s using the emacs incremental search. I doubt any hypertext system could reduce this time. -- \\ ( ) No Bullshit! | Email: B.A.McCauley@bham.ac.uk . _\\__[oo from | Phones: +44 21 471 3789 (home) .__/ \\ /\@ /~) /~[ /\/[ | +44 21 627 2171 (voice) 2175 (fax) . l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37 # ll l\\ ~~~~ ~ ~ ~ ~ | A1 93 FE EA BE E3 2A 91 ###LL LL\\ (Brian McCauley) | More: finger bam@wcl-rs.bham.ac.uk ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: /dev not needed? Date: 18 Oct 1993 23:24:50 -0700 In article <1993Oct19.004449.629@bhhome.ci.net> bill@bhhome.ci.net (Bill Heiser) writes: :sweh.womble@spuddy.UUCP (Stephen Harris) writes: : :>Was in the shower and had this strange idea: : :>/dev isn't really needed anymore. Most (all?) of the functionality it :>provides could be done using extensions to /proc filesystem. : : :Oh come on now! : :If LINUX starts going off on tangents like this, we might :as well forget being able to consider it a "unix" ... I, for :one, will go no further with LINUX if it strays far from :"standard unix" (I realize there are many unix variants, but :I've yet to see one that didn't use /dev :-) : :-- :Bill Heiser bill@bhhome.ci.net heiser@world.std.com I think this may be something to think about a year from now. But not now. I'd rather see Linux+networking stable first. -Matt Matthew Dillon dillon@moonshot.west.oic.com 1005 Apollo Way dillon@overload.berkeley.ca.us Incline Village, NV. 89451 ham: KC6LVW (no mail drop) USA Sandel-Avery Engineering (702)831-8000 [always include a portion of the original email in any response!] ------------------------------ From: russell@alpha3.ersys.edmonton.ab.ca (Russell Schulz) Crossposted-To: news.groups,comp.os.linux.misc Subject: Re: The %&#$@ speaks again -or- An apology Date: Mon, 18 Oct 1993 22:30:26 MDT Reply-To: russell@alpha3.ersys.edmonton.ab.ca (Russell Schulz) uh, posting all this to c.o.l.d helps no one. ccn@underg.ucf.org (Chris Nystrom) writes: >> The morons who post things like "My smail doesn't work. > This is getting to be too much. I can see it now. A small huddled group > of refugees in Siberia. Banished to the coldest wastelands of Siberia yes, this _is_ getting to be too much. -- Russell Schulz russell@alpha3.ersys.edmonton.ab.ca ersys!rschulz Shad 86c ------------------------------ From: kubla@mogli.zdv.Uni-Mainz.DE (Dominik Kubla) Subject: Re: /dev not needed? Date: 19 Oct 1993 10:52:36 GMT Bill Heiser (bill@bhhome.ci.net) wrote: : sweh.womble@spuddy.UUCP (Stephen Harris) writes: : >Was in the shower and had this strange idea: : >/dev isn't really needed anymore. Most (all?) of the functionality it : >provides could be done using extensions to /proc filesystem. : Oh come on now! : If LINUX starts going off on tangents like this, we might : as well forget being able to consider it a "unix" ... I, for : one, will go no further with LINUX if it strays far from : "standard unix" (I realize there are many unix variants, but : I've yet to see one that didn't use /dev :-) : -- : Bill Heiser bill@bhhome.ci.net heiser@world.std.com Not quite! I am told that the bsd folks are/have been considering some sort of dynamic /dev. This is basically the same idea but they thougth one step further: Make the kernel configure itself! This way only the needed drivers are included and the drivers take care of generating the /dev entries. I though about it too. My idea was: - Introduce a boot-FS like SVR4 et al. - Do not generate a monolitic kernel. Instead build binary modules which can be dynamically linked with the core system. This way hardware vendors can contribute binary only versions of their drivers. ( I don't like this, but it would definetly help Linux: See the Diamond story ...) Technically a boot procedure would look like this: bootloader Linux core Call driver 'abc' Check if hardware present Yes -> Initialize driver and create /dev entries No -> Cleanup and exit. Call driver 'def' ... Mount root-FS Mount proc-FS (no need for a fstab entry!) Mount dev-FS (see above) Switch to user-mode and execute /sbin/init. This can be done in a transparent way so that applications still see a Unix- like system. Nice idea, but don't ask me to implement it: I definitely don't have the necessary skills :( Dominik +---------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.Uni-Mainz.DE | | sMail: Dominik Kubla, Steinsberg 34, 56355 Nast"atten, F. R. Germany | +---------------------------------------------------------------------------+ | | | "Linux: The choice of a GNU generation" --S. Frampton | | | +---------------------------------------------------------------------------+ DISCLAIMER: Everything written above are the expressed thoughts of the author and in no way connected to 'Johannes Gutenberg Universit"at', Mainz (Germany). This way, they do not have to care about what I say ... ------------------------------ From: hta@uninett.no (Harald T. Alvestrand) Subject: Fonts for virtual consoles Date: 19 Oct 1993 12:28:37 GMT WARNING: QUESTION AHEAD........ I have made an utility that converts an X font into the font format used by "fntpak01" by Jerry Kaidor , written in PERL. (Before you bother sending me mail about it: ftp://aun.uninett.no/pub/misc/bdf2fontpak) Now, questions two: 1) Will the console patch that allows font loading enter the "standards track" of Linux any time soon? 2) If not, is anyone working on an alternative mechanism? For the reason for my interest, see my .sig. The ø shows up as a square box on unmodified Linux, because IBM forgot about Norway and Dennmark when designing the original PC. -- Harald Tveit Alvestrand Harald.T.Alvestrand@uninett.no G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no +47 7 59 70 94 My son's name is Torbjørn. The letter between "j" and "r" is o with a slash. ------------------------------ Crossposted-To: comp.unix.internals,comp.unix.programmer,comp.unix.wizards From: Adrian.Wallaschek@arbi.informatik.uni-oldenburg.de (Adrian Wallaschek) Subject: SysV IPC system-wide limits? Date: Tue, 19 Oct 1993 12:08:40 GMT Hi everybody! I'm developing a dbm which should be able to do some fast IPC. No I arrived at the problem the SysV IPC has some arbitrary systemwide limits like the max number of message, etc. The problem is to find a way for the client not to overload the message-system, keeping the server some space to answer pending request and not to deadlock! The way I actually use is to idle loop around a msgctl IPC_STAT which is definitely not acceptable. Has anybody any idea how to unlimit the IPC this way? Btw. what kinds of limits apply to the ipc. I found msg/system! Are the limits like msg/user or msg/client, too ? Is there any documentation about SysV-IPC apart from the manpages? Please send any answer by E-Mail because I don't read all the groups I crossposted to regularly! Email: Adrian.Wallaschek@Informatik.Uni-Oldenburg.DE Thanks in advance prefect ------------------------------ From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) Subject: UNIX trademark now X/Open Reply-To: hpa@nwu.edu (H. Peter Anvin) Date: Tue, 19 Oct 1993 13:55:41 GMT In case you don't read comp.unix.misc, Novell has transferred the trademark UNIX to X/Open, who allows its use for any OS that follows the X/Open spec 1170. Spec 1170 is FTPable from "uiunix.ui.org" as "/pub/osapi/osapi.tar.Z". I thought the Linux kernel developers could have some use of this document. Please note that it is 500+ pages of PostScript. /hpa -- INTERNET: hpa@nwu.edu FINGER/TALK: hpa@ahab.eecs.nwu.edu IBM MAIL: I036073 at IBMMAIL NeXTMAIL: hpa@speedy.acns.nwu.edu ANMÄRKNING: Heja Sverige friskt humör! EG väntar utanför! rm -rf /msdos /windows /win-nt ------------------------------ From: fnord@cs.mcgill.ca (Andrew KUCHLING) Subject: Re: Fonts for virtual consoles Date: Tue, 19 Oct 1993 14:59:02 GMT In article <2a0mhm$gih@trane.uninett.no> hta@uninett.no (Harald T. Alvestrand) writes: >1) Will the console patch that allows font loading enter the "standards > track" of Linux any time soon? >2) If not, is anyone working on an alternative mechanism? I also would like to raise the same point. The fontpak patches to console.c could easily be made part of the standard kernel without adding too much to the kernel's size; they're not that big. Having fonts as part of the standard kernel would be a very good thing, since programs could just assume the capability was there; if the kernel didn't contain the font code, it could just gracefully ignore the 8192 bytes of font data sent to it. This would mean that TTY games could use their own custom font (ah...reminds me of my Commodore days...), and applications could also look a _lot_ more interesting. I would love to have a sysadmin script system that looked as professional as the Norton Utilities do. So, I agree that VC fonts should become part of the standard Linux kernel. Andrew Kuchling fnord@binkley.cs.mcgill.ca ------------------------------ From: ehhchi@maroon.tc.umn.edu (Ed H. Chi) Subject: Re: Use 'jargon' reader for FAQ Date: Tue, 19 Oct 1993 15:07:29 GMT To: B.A.McCauley@bham.ac.uk Subject: Re: Use 'jargon' reader for FAQ Newsgroups: comp.os.linux.development In-Reply-To: References: Organization: University of Minnesota Cc: Bcc: In article you write: >But a hypertext version is unlikely to cut down lazy posts. With the >exisiting FAQ one can often guess a few keywords from the lazy ********s >Subject: lines and find the answer in the FAQ in <30s using the emacs >incremental search. I doubt any hypertext system could reduce this time. For any of this reader stuff to work, it would have to be as easy as posting to the net. It's as simple as that. If it takes them 3 min to type in an article, then the system needs to be easy enough for them to get an answer in 3 min. And the answer needs to be hand-delievered to their doorstep. -- o/ \ / \ / / \o email: ehhchi@epx.cis.umn.edu /# ##o # o## #\ chi@mermaid.micro.umn.edu / \ / \ /o\ / |\ / \ Dumping messy-dos, running Linux! ------------------------------ From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) Subject: Libc 4.4.4 and new sig 11's (not ram chips) Date: 19 Oct 1993 16:27:45 GMT Ok.. here's the situation: Sunday night (the day the new c libraries were sent out), I installed ld.so.3 and libc 4.4.4. This should include the new include files, the extra-xxxx and the image-4.4.4. I did this after I installed ld.so.3 and then installed the new g++ stuff. Basically I installed anything that looked like part of the upgrades announced in comp.os.linux.announce. Everything works fine except for seyon: Upon loading seyon everything pops up fine, but upon klicking on any button in the control box I get a sig11 error from seyon. Now I KNOW signal 11 is supposed to be a memory error. But before installing libc4.4.4 I had no such error EVER with seyon. It is no an error that will happen every time seyon is loaded. The only system changes were the installation of libc, lib.so.3, and recompiling linux 0.99.pl13 with the new libraries. Has anybody else had this problem? Just thought I'd bring it up. Byron Faber: Linux system: MCC Interim release with kernel pl10+. Since upgraded to pl13. 386/40 AMD bios 8 meg ram. 8 meg swap partition 4 meg swap file. 170 Meg drive.. WD8003E ethernet board and net-2 (standard setup I guess..) ------------------------------ From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig) Subject: Re: UNIX trademark now X/Open Date: 19 Oct 1993 16:37:56 GMT hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) writes: >In case you don't read comp.unix.misc, Novell has transferred the >trademark UNIX to X/Open, who allows its use for any OS that follows >the X/Open spec 1170. Spec 1170 is FTPable from "uiunix.ui.org" as >"/pub/osapi/osapi.tar.Z". I thought the Linux kernel developers could >have some use of this document. Please note that it is 500+ pages of >PostScript. Thanks for the info; I've had a quick look - see and found that it specifies extensions to XPG/4. Soo... where do I get the XPG/4 specs? Does anybody have any information on where it might be ordered? -- Thomas König, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet The joy of engineering is to find a straight line on a double logarithmic diagram. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: /dev not needed? Date: Tue, 19 Oct 1993 16:12:35 GMT In article <1993Oct19.004555.820@bhhome.ci.net> bill@bhhome.ci.net (Bill Heiser) writes: >>mechanism; Solaris 2's /devices is solely based on the result of a hardware >>probe.) > >I doubt a "hardware probe" is going to work very well on >[an ISA based] PC :-) ...what do you think the Linux kernel does now? Of course, all the probe routines are part of the installed drivers, and they have to be very carefully written or they can crash the system (SLS 1.03 AdLib driver, anyone?). ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ ** 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 ******************************