From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 26 Nov 93 01:13:10 EST Subject: Linux-Development Digest #262 Linux-Development Digest #262, Volume #1 Fri, 26 Nov 93 01:13:10 EST Contents: Re: Comments from the "TAMU Crap" author (Rob Janssen) Re: console.c questions (Rob Janssen) Re: Linux/68k Version 0.06 released (Hamish Macdonald) Re: How many BogoMips on a Pentium? (Dan Hildebrand) Re: BusLogic SCSI under Linux...compatible with AHA 1740 or not? (Kobayashi Masaoki) Re: Comments from the "TAMU Crap" author (John E. Krokes) Re: Creeping featuritis (post --rant --flame) (Richard Brooksby) Re: Creeping featuritis (post --rant --flame) (Richard Brooksby) Re: Some ideas and reasons for a more modular kernel. (Richard Brooksby) Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? (Jan Newmarch) Re: [Q] .13s and AT1500 Ethernet cards (Donald J. Becker) Re: console.c questions ("John E. Davis") Porting UN*X apps to Linux (Jerry Ablan) ---------------------------------------------------------------------------- From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Comments from the "TAMU Crap" author Date: Thu, 25 Nov 1993 22:00:28 GMT In <2d07ah$aqs@TAMUTS.TAMU.EDU> drs0587@net.tamu.edu (Dave Safford) writes: >OK, for all the reasonable linux developers/users out there, >how about some constructive ideas on how to improve X configuration? I think any possible damage to monitor will not be caused by inappropriate selection of the dotclock itself, but by the combination of the dotclock and the horizontal and vertical division ratios. It would be a big help when the server (or some auxilliary utility) would display the resulting horizontal and vertical frequencies for each mode, so they could be verified against the monitor specs. My monitor has a small LCD display which can display the H and V frequencies, and it automatically switches off and displays "Out of Range" when they are inappropriate. But not all monitors have such a feature, and manual verification of the setup would be eased by display of the frequencies by a program. An automatic configuration program should be able to display the resulting frequencies, and possibly the user should be asked to keyin limits on H and V frequencies acceptable for his monitor. (in text mode, of course :-) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | | e-mail: pe1chl@rabo.nl | Tel. BBS: +31-30715610 (23:00-07:30 LT) | ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: console.c questions Date: Thu, 25 Nov 1993 22:04:31 GMT In davis@pacific.mps.ohio-state.edu ("John E. Davis") writes: >Hi, > I just discovered from going through the console driver code kernel >sources that ^[[0m resets the terminal colors. Is this a good idea? Whenever >I login in to a remote system and an ESC [ m is received, the colors go back >to black and white. That's what it is supposed to do on an ANSI terminal... If you don't like it, write to ANSI (or DEC who seems to have originally designed this style of escape sequences) > I would prefer it it ESC [ m just turns off highlighting/bold/underlining >and leaves the colors alone. There are a lot of things that would be more convenient about attribute control in ANSI terminals, but alaa, it is a bit late to change them :-) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | | e-mail: pe1chl@rabo.nl | Tel. BBS: +31-30715610 (23:00-07:30 LT) | ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Crossposted-To: comp.unix.amiga Subject: Re: Linux/68k Version 0.06 released Date: 25 Nov 1993 22:45:48 GMT >>>>> On 25 Nov 1993 16:57:24 EST, >>>>> In message <2d39o4$fgb@aludra.usc.edu>, >>>>> parkinso@aludra.usc.edu (Steve Parkinson) wrote: Steve> I changed the byte at offset 0x0d72 from 67 to 60 (this changes Steve> a BEQ to a BRA, skipping the code you highlighted) Take note, folks. Steve> OK... so the boot progresses, and then the screen clears, Steve> probably as expected, but then NOTHING happens. Actually, nothing happening is somewhat expected, too. Remember that the 68040 part of the kernel has not been tested at all (because I can't test it). There are probably all sorts of bugs lurking in there Steve> I'm running bootstrap like this: Steve> bootstrap -r filesys This is correct. Steve> [...] but I would have expected more than this on the linux Steve> screen? Sure, if we had any expectation that the 68040 code is working correcly the first time. I didn't have any such expectation. For us to get this working, someone with a 68040 has to take the bull by the horns and *DEBUG* the kernel. I can't do it. I can *help* with advice, but I can't debug it. This requires that they be able to recompile the kernel, with all the kernel development environment installation that this implies. As a start, a terminal attached (through a null-modem) to the serial port will get information indicating how far the kernel initialization got before some error occurred. Hamish. ------------------------------ From: danh@quantum.qnx.com (Dan Hildebrand) Subject: Re: How many BogoMips on a Pentium? Date: Thu, 25 Nov 93 19:28:07 GMT In article , Robert Stockmann wrote: >But of course no shame to linus, because at the moment there's even >no commercial OS on the market that boost's the power of the pentium. >So we just have to wait for the 100 MHz version to get 51.5 or something >like that reported as the new record. Not quite, QNX 4.2 has been shipping for a couple months now. It ships with the Watcom v9.5 Pentium optimizing compiler, and is itself, compiled from top to bottom with that compiler. :-) To Linus's credit, he needs a GCC that does Pentium optimization. Hopefully one will happen soon. -- Dan Hildebrand email: danh@qnx.com QNX Software Systems, Ltd. QUICS: danh (613) 591-0934 (data) (613) 591-0931 x204 (voice) mail: 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 ------------------------------ From: masaoki@akebono.tky.hp.com (Kobayashi Masaoki) Date: Thu, 25 Nov 1993 08:20:23 GMT Subject: Re: BusLogic SCSI under Linux...compatible with AHA 1740 or not? Try to look for ALPHA/scsi directory at tsx-11 or its mirror. Masaoki masaoki@tky.hp.com ------------------------------ From: bbfaus@wam.umd.edu (John E. Krokes) Subject: Re: Comments from the "TAMU Crap" author Date: 26 Nov 1993 04:20:14 GMT In article , Michaela Merz wrote: > >I think, we should stop blaming each other. We all have to thank the >Xfree developers for this very good package. BUT: Like most of all >freeware, it sometimes seems to be made for freaks and gurus, not >for Mr. Normaluser. > Agreed on both points. >If we want Linux to become an alternative operating system even for >non gurus, we have to find a simple and bulletproof way to get graphics >working. Remember, the usual user doesn't have netaccess and just wants >to plug and play. The usual user is not interested in the details of his >graphics board or display. Agreed on this also. > >I'm a system- and networkprogrammer. I'm not to deep in graphics - so my >question would be: Where is the problem to start X and use cursor up >or cursor down until there is a usable picture? > >Like tuning in a tv channel ... ? > The problem is that cycling through various video modes looking for one that works makes it VERY easy to put you into a video mode that your monitor can't handle, thus possibly damaging it. It can probably be shown statistically that this method is no more dangerous than calculating usable values. (lies, damn lies, and statistics) However, I would be cautious about recommending this method to other users, after all, if someone blows up their monitor (exaggeration) because of something that I recommend, well, whose fault is it? Even with a loud disclaimer, if I distribute this method as a safe and easy alternative to doing the numbers by hand, well, the waters are a little murky if it doesn't work. I apologize if the above paragraph doesn't make as much sense as I intended it to. The bottom line is this: if improper Xconfig values damage a monitor, there are only so many people you can blame: 1. The XFree86 team. This is unlikely. These people are wonderful programmers and I have yet to see any claim against them substantiated. 2. The manufacturer. Providing incorrect information is certainly possible but is probably not very common and most likely due to typographical error. 3. The user. Provided that the "officially" recommended methods of finding Xconfig values is used, (and done correctly) there should never be any damage caused by the user. If there is, perhaps you can place blame on the XFree86 team, but it's unlikely that a bug causing just YOUR monitor to fry would go unnoticed long enough for it to happen. If you go cycling through video modes willy-nilly, the possibility of damage becomes significantly greater, and the blame can be placed on whoever came up with the video modes. (because none of the video modes except VESA standards can be "guaranteed" safe.) I personally wouldn't want to be responsible for the latter, but I don't personally care how you get your Xconfig numbers. But, if you're not using the XFree86 recommended method, don't try to blame them unless you can prove conclusively that there's a bug in the code. _____________________________________________________________________________ ( John E. Krokes -- "Mag" -- First Accolade to The One True Dave ) ) bbfaus@wam.umd.edu Most useful UNIX command: sleep 240 & ( (_____________________________________________________________________________) ------------------------------ Crossposted-To: gnu.misc.discuss From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Creeping featuritis (post --rant --flame) Date: Thu, 25 Nov 1993 11:43:55 GMT haley@scws6.harvard.edu (Elizabeth Haley) wrote: > Also, I question that it is just aesthetics. I'm sure most of us have > seen programs that were once simple and efficient, that later became > complex behemoths, possesing perhaps much power, but being quite slow > about the functions they originally performed... Hear hear! My complaint is that the GNU project is _accelerating_ this process by producing old tools with many, many, new `enhancements'. Stop it! I find multi-volume IO very useful, for example. But don't add it to tar, dd, cpio, etc. Think first, and make a new tool for the purpose, and keep it simple. I also think there's a problem here in understanding the difference between a professional opinion and a personal preference. Too many people seem to love software that is neat and clever without considering the wider implications. There are basic software principles which are being ignored: simplicity and elegance are not just a matter of aesthetics, they are a matter of efficiency. Efficiency is a matter of economics! Imagine if each individual component of your system required a tenth of the memory and ran twice as fast. Imagine if you were using really simple and solid tools whose documentation took you only minutes to absorb. I'm getting responses along the lines of `why not write it yourself?' I dream about it. However, I'm paid to put my skills to use for the direct benefit of my employers. Again, here I have a professional opinion and a personal one. I make decisions, the consequences of which I won't enjoy, but which I know will benefit my employers. --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ Crossposted-To: gnu.misc.discuss From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Creeping featuritis (post --rant --flame) Date: Thu, 25 Nov 1993 11:53:16 GMT mib@geech.gnu.ai.mit.edu (Michael I Bushnell) wrote: > Anyway, GNU cat, when given no options (other than -u, --version, and. > --help) uses read and write with the optimal block size (as reported > by stat). I'm sorry I ever mentioned cat. cat -n is the classic example of a feature which unnecessarily complicates a tool. My postings are not a critique of cat. _Obviously_, GNU aims to be compatible with BSD and POSIX, and so it must have cat -n as well as lots of other lunacy. However, GNU is compounding the problem by adding lots of _new_ features as well. --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Some ideas and reasons for a more modular kernel. Date: Thu, 25 Nov 1993 11:59:43 GMT I'm sorry I haven't had time to participate in the discussion that has resulted from my posting about device drivers as user processes (and various consequential kernel interface stuff). I'm glad to see that there is some intelligent discussion going on as a result, though. If anyone would be kind enough to summarize it and mail it to me I would be grateful. Only if you're feeling kind-hearted though. Thanks. --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.motif From: jan@pandonia.canberra.edu.au (Jan Newmarch) Subject: Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? Date: 26 Nov 93 03:51:12 GMT In hasty@netcom.com (Amancio Hasty Jr) writes: >On the topic of an object paradigm for tcl/tk: >This is from a thread in comp.windows.interviews. >Please ignore the stuff about tk vs. interviews and read what >Mr Linton has done with tcl. I am including the full message >to avoid mis-interpretation on my part. X11R6 is going to fun :) > .... >You are not making a relevant comparison. The fast turnaround and >interpretation of scripts comes from Tcl, not Tk. Several people I get the same experience for the binding of tcl to Motif that I did: the short code, the quick development cycle, etc, come from using tcl, not from Tk. I have dropped a 7000 line C/Motif program down to 700 lines of tclMotif. Not a bad saving! [tclMotif is on ftp.x.org under /contrib/tclMotif*.Z] Jan -- Jan Newmarch, Information Science and Engineering, University of Canberra, PO Box 1, Belconnen, Act 2616 Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041 AARNet: jan@ise.canberra.edu.au ------------------------------ Crossposted-To: comp.os.linux.help From: becker@super.org (Donald J. Becker) Subject: Re: [Q] .13s and AT1500 Ethernet cards Date: Thu, 25 Nov 1993 15:49:47 GMT In article <2cune3$dqf@louie.udel.edu>, Jason Cash wrote: > Has anyone gotten patch level 13s to work with the AT1500 (lance)? In the >boot up sequence the machine locks up at this point: > >eth0: LANCE at 0x300, 00 00 f4 b0 b6 2e ... > The driver code for the lance appears to have undergone some revision. Is >there something new that has to done? Yes, this is a bug I introduced in pl13s. It should affect only the new ">16M" LANCE driver -- the other drivers are started after time_init() in main.c as they used to be. The autoIRQ code assumes that "jiffies" are ticking, and goes into an infinite loop when they are not. A work-around is to explicitly specify the LANCE IRQ so that the autoIRQ code isn't run. You can do that with a boot time parameter -- see the ethernet HowTo for details. A source code fix is to use my new autoIRQ code on ftp.super.org:/pub/linux/pl14/auto_irq.c which changes a '>=' to a '>' so that zero timeouts don't depend on jiffies. (This change in my private version is why I didn't notice the problem.) The right fix is for me to actually write my planned autoIRQ code, which reads the 8259 IRR and timer directly instead of installing interrupt handlers and spinning on 'jiffies'. -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: davis@pacific.mps.ohio-state.edu ("John E. Davis") Subject: Re: console.c questions Reply-To: davis@pacific.mps.ohio-state.edu (John E. Davis) Date: Fri, 26 Nov 1993 05:31:09 GMT In article <1993Nov25.220431.2350@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes: >In davis@pacific.mps.ohio-state.edu ("John E. Davis") writes: >> I just discovered from going through the console driver code kernel >>sources that ^[[0m resets the terminal colors. Is this a good idea? Whenever >>I login in to a remote system and an ESC [ m is received, the colors go back >>to black and white. > >That's what it is supposed to do on an ANSI terminal... >If you don't like it, write to ANSI (or DEC who seems to have originally >designed this style of escape sequences) I have DEC's Terminals and Printers handbook from 1987 in front of me. According to it, CSI Ps ; ... Ps m is `select graphic rendition' (SGR). For `0' as a parameter, it simply says ``All attributes off''. I can see that foreground/background color can be considered an attribute; however, were colors considered when the standard was introduced? > >> I would prefer it it ESC [ m just turns off highlighting/bold/underlining >>and leaves the colors alone. > >There are a lot of things that would be more convenient about attribute >control in ANSI terminals, but alaa, it is a bit late to change them :-) Perhaps, but I wonder how many problems one would encounter if the interpretation of just this particular escape sequence were changed. The reason I am wondering about this issue is because I the next version (0.94-3) of my JED editor will support colors on Linux (default being white on blue). I would like to restore the forground/background colors when the editor is exited or suspended. I found an ESC sequence that does not touch the colors but the termcap entry for console is not consistent with this escape sequence. This is the root of `less' messing up the color of the display when viewing man pages. -- _____________ #___/John E. Davis\_________________________________________________________ # # internet: davis@amy.tch.harvard.edu # bitnet: davis@ohstpy # office: 617-735-6746 # ------------------------------ From: munster@genesis.Mcs.Com (Jerry Ablan) Subject: Porting UN*X apps to Linux Date: 25 Nov 1993 23:32:51 -0600 Is there some sort of porting guide available for help porting apps for like Suns or other machines to Linux? Thanks, Jerry ------------------------------ ** 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 ******************************