From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 29 Nov 93 00:13:10 EST Subject: Linux-Development Digest #267 Linux-Development Digest #267, Volume #1 Mon, 29 Nov 93 00:13:10 EST Contents: Found slow socket bug :) (Lawrence Foard) Linux/68k Version 0.06 Patchlevel 1 released (Hamish Macdonald) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Piercarlo Grandi) Re: /dev/audio in Sound 2.0 (Gustaf Neumann) Re: Found slow socket bug :) (Kai Petzke) Re: Don't use Motif for free sw: it now requires runtime royalties! (Chad Phillip Brown) Minor Problem In .13t (Jerry Shekhel) Re: PCI support, automatic config, Plug-n-Play (T. David) Voicemail/Answering Machine program?? (ha) Re: PCI support (Dave Cole) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) ---------------------------------------------------------------------------- From: entropy@world.std.com (Lawrence Foard) Subject: Found slow socket bug :) Date: Sun, 28 Nov 1993 19:49:44 GMT I've always been wondering why drawing large areas on X windows with XPutImage was very very slow. I finally found the answer and its a bit icky: Every read and write call calls verify_area, which in turn checks every page in the area by calling do_wp_page. Lets say you want to write 1M through a pipe, each write will write at most 4K of your buffer (likewise for read). This results in calling do_wp_page atleast ((1M/4K)^2)/2=62500, in reality it is probably much higher since 4K is not generally written at once. I put in a check which only calls verify area when the object in question is not a socket, I then fixed some verify areas already in the socket code to return an error in the event of bad memory. I got a significant speed up (factor of 2 or 3) of drawing big pixel images as a result. I'm going to send the patchs to Linus but it got me thinking about verify area. And I have a few questions: Is verify area used to prevent paging inside of the calls (something which would fail for very large writes or reads), or only for checking the area? If so would it be possible to make a version of memcpy_tofs/memcpy_fromfs which would set a flag telling the memory managment code to cause it to return an error code in the event it accesses bad memory? I think this might have a big effect on the amount of overhead in the kernel. How do you run the kernel profiler? -- ====== Legalize: >==--< | have given us jacks. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Crossposted-To: comp.unix.amiga Subject: Linux/68k Version 0.06 Patchlevel 1 released Date: 28 Nov 1993 21:12:58 GMT This message announces the availability of version 0.06pl1 of Linux/68k. It can be ftped from directory /pub/linux/680x0 at tsx-11.mit.edu. A precompiled kernel executable and the Amiga "bootstrap" program can be found in kern-0.06pl1.tar.gz in the "kernel" subdirectory. *) This version includes a device driver for the GVP Series II SCSI controller. *) The "bootstrap" program has a couple of bug fixes related to 68040 support, as well as some code added to avoid "AGA" incompatibilities in the A4000. *) The kernel has a bug fixed which prevents it from running in machines whose FAST RAM is located in the ZorroII autoconfig space (200000-A00000). Source patches against linux-0.06 are available in the "src" subdirectory of the "680x0" directory in the file linux-0.06pl1.diffs.gz. ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Sun, 28 Nov 1993 21:35:55 GMT >>> On 25 Nov 1993 16:55:04 GMT, john@hopf.math.nwu.edu (John Franks) said: John> In article hops@x.co.uk (Mike John> Hopkirk) writes: Mike> Darrel Crow OSF/Motif Technology manager just posted a human Mike> readable clarification I think "human readable clarification" is a bit optimistic, but... Mike> of the Motif 2.0 licensing to the motif-talk mailing list (If it Mike> doesn't get out to the newsgroup I'll see if its ok to repost it) Mike> [ ... ] Following is (I hope) a precis of the main points of his Mike> posting vis a vis PD/Freely distributed (binary) software Mike> (emphasises and errors omissions are mine). John> ... Precis omitted ... John> If this account is accurate it is very disturbing. It is very disturbing for one major reason: the conditions for Motif licensing require a lawyer or an expert system to figure. They gist of them though is that they are designed to make it very hard/impossible to legitimately distribute sw containing any bit of OSF Motif code without somebody paying the OSF a runtime library fee. There are zillions of special cases; I also understand that if one cares and has money the OSF might sell them a license with ad-hoc conditions. All in all, as of Motif 1.2.x, it is a fair statement that the runtime library attracts a royalty, in most cases, or all cases save for internal use at an academic institution. Summing up, life's too short to bother using OSF Motif for free sw. And if I were a commercial developer I'd be way of doing OSF Motif for any platform that does not come with a bundled runtime license. John> It says that NCSA is not complying with their license when they John> distribute Xmosaic statically linked binaries without a notice John> that users are required to have a Motif license. Contributory infringement, perhaps -- but I cannot imagine the OSF being so dumb as actually going after UIUC for this. Their lawyers probably should spend their days imagining way to simplify their license instead; or goin back to the 1.1.x terms (statically linked libraries should _never_ attract any sort of royalty fees, which is the industry practice). John> In particular, academic and commercial institutions who are very John> careful about subjecting themselves to liability will be unwilling John> to use Xmosaic on any CPU without a Motif license. This must John> include nearly all Suns in existence today. And all machines that run or will run any sort of free OS. ------------------------------ From: neumann@watson.ibm.com (Gustaf Neumann) Subject: Re: /dev/audio in Sound 2.0 Date: Sun, 28 Nov 1993 21:50:00 GMT In article <2dac0s$dgr@lll-winken.llnl.gov> from [28 Nov 1993 14:19:08 GMT] you wrote: |> I have a PA *STUDIO* (A superset of the Spectrum, I believe). i've a very similar configuration: PA STUDIO, 486DX2@66, Lx0.99p13r, Linux Sound Driver 2.1 (from the 13r source) i see similar symptoms when i cat to /dev/audio: the end of the .au file sounds truncated or garbled, similar symptoms with xboing1.8a. however the "play" command of lsox works much better (best with .WAV files). in my current configuration rsynth-0.9 makes only noises when used on /dev/audio (is it supposed to work better?) when used on /dev/dsp* nothing is heard at all. /dev/mixer works, fm (using sndkit/fm/fmtest) not (i had fmtest working in a configuration, where i could not access my floppy disk; see below). |> Sound Driver:2.0 (Fri Nov 26 01:17:35 GMT 1993 root@darkstar.frop.org) |> Config options: 0x00000c43 |> |> Major number: 14 |> HW config: |> Type 3: ProAudioSpectrum at 0x388 irq 5 drq 1 |> Type 2: SoundBlaster at 0x220 irq 5 drq 1 |> Type 1: AdLib at 0x388 irq 0 drq 0 when i tried irq5 for the PAS (the recommended value from the manual), my floppy drive stopped to work, so i switched to irq10 (snddriv's default). i noticed, that you used irq5 for PAS and the SB emulation. Is this supposed to work? here is my current config. i've build a couple of kernels (20?) with different irq/drq settings and options, htis is one of the better ones. Sound Driver:2.0 (Sat Nov 20 16:36:36 GMT 1993 root@mohegan.) Config options: 0xffffffef Major number: 14 HW config: Type 4: Gravis Ultrasound at 0x230 irq 15 drq 6 Type 3: ProAudioSpectrum at 0x388 irq 10 drq 3 Type 2: SoundBlaster at 0x220 irq 7 drq 1 Type 1: AdLib at 0x388 irq 0 drq 0 PCM devices: 00: Pro Audio Spectrum 01: SoundBlaster 2.0 Synth devices: 00: Yamaha OPL-3 Midi devices: 00: Pro Audio Spectrum Mixer(s) installed greetings, -gustaf PS: the PA STUDIO 16 manual is not very good. i found a couple of obviously wrong addresses in the io map, when i tried to check whether some io addresses have been changed to fix the mentioned floppy problem. -- Gustaf Neumann neumann@watson.ibm.com Postdoctoral/Visiting Scientist Tel: (914) 784 7086 IBM T.J.Watson Research Center, P.O.Box 704 Yorktown Heights, New York 10598 ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: Found slow socket bug :) Date: 28 Nov 1993 22:59:15 GMT In entropy@world.std.com (Lawrence Foard) writes: >Is verify area used to prevent paging inside of the calls (something >which would fail for very large writes or reads), or only for checking >the area? I'm not 100% certain, about what is going on, but some facts: The kernel should avoid to produce page faults while in kernel mode. Just think, you were in a routine, all interrupts disabled, and produce a page fault, so you need to read some sectors from swap space. What if the disk uses an interrupt to signal that the data is there? It won't get delivered, because interrupts are still off. As far, as I know, 386 chips even have problems of reporting page faults while in kernel mode at all. They don't regard the write protect bit, for example. In other words: don't produce page faults in the kernel. Therefore, verify_area() is called, before any user supplied area is accessed in the kernel. It swaps in all relevant pages. However, system calls often can't do all their work in one run. If they have to wait for something (data from hard disk, or for a pipe buffer to empty, etc.), the kernel switches to other processes. If they request memory, the kernel may have to do swapping again. Worst case is, that the area, which we just confirmed to be present with verify_area() is swapped out. In other words: repeat verify_area() after any sleep (whether caused by sleep_on(), get_inode(), etc., etc.) Kai -- 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: yandros@mit.edu (Chad Phillip Brown) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 28 Nov 1993 22:59:56 GMT From: Anthony A. Datri (aad@dvorak.amd.com): : >I would guess none whatsoever. Mosaic *is* a Motif interface to libwww. If : >you want to have another interface then you would throw out virtually all of : >Mosaic. : Huh? How can Mosaic's functionality *possibly* depend on pseudo-3D art-deco : borders around everything? Lots of Mosaic's `functionality' is heavily based on the HTML widget, written in Motif, and the gui code, also written in motif. The networking code and WWW support is seperate, and pretty much directly stealable (the www code is most likely taken directly from CERN, with perhaps some bugfixes here and there). Looking at the code, it seems easily modular enough to do a port to another widget set, given that you're willing to rewrite the widget and gui code. Good luck; I'd be glad to see someone do it. Seriously, though, I think that the choice to use Motif was a reasonable one, given the conditions. Remeber that when the choice was made different licensing restrictions were in place. As for the other choices, I don't believe XView is better, based on personal preference (I strongly dislike many elements of the Open Look interface) and what I hear from a friend who's trying to get it to build on some non-sun platforms recently (but I don't find it hard to imagine similar things about Motif). The Athena widgets are not and were never intended to be a `real' widget set - it was created as an example set, and used for some of the `basic' clients. It was always their intent that other `real' widget setws be developed. (at least, that's what they say about it now. :-) Tk may someday be ready, but `someday' certainly isn't today - the last release (3.6) came out less than three weeks after the previous one (3.4 - if there was a 3.5 in between that I missed that only makes things worse) and is changing rapidly - for example, 3.4 had a bug that caused it to try to parse the comments in it's resource files. :-) Don't get me wrong - I think tcl and Tk were really neat toys a while ago and are fast becoming really neat tools (things like the tk toolkit effort will certainly help this), and I use them myself, but they aren't yet ready for the kind of things Eric and Marc are doing with Mosaic (maybe in tk4.0, sez the author of tkWWW). As for the Athena widgets, I imagine someone could come up with something that does most of what Mosaic does, and it would probably be faster, too, or at least use less memory), but I'm dubious as too how successfull it would be, given that Mosaic is so much more popular than things like Midas, Viola, tkWWW, and all the others... What really *needs* to happen (and will, eventually, sinc eI'll do it myself if nothing else (and it'll be slow and poor and silly and look like it was written by someone who doesn't know how to write toolkits, 'cause I don't :-)) is a free Motif clone. There is a person on one of the linux lists talking about organizing just such a thing, and he is reportedly getting a strong response, so there's hope for a better first cut still. :-) If you're interested in this and you can't find the address in the linux groups/list (c.o.l.developement, I believe), then drop me a message and I'll try to find the address and send it back to you. In the meantime, I hope people can stop flaming about what toolkit NCSA choose to use for the work they give out for free and concentrate either on making better products, either out of Mosaic or tkWWW or whatever, and if you think that means porting WinMosaic to SmallTalk and using STDWIN as the GUI, then go for it, and if you think that means working on a free Motif clone, then definately go for it. :-) -- chad ------------------------------ From: jerry@msi.com (Jerry Shekhel) Subject: Minor Problem In .13t Date: 28 Nov 1993 23:22:28 GMT Hello, I just got .13t, and I'd like to report a minor problem. The older ALPHA kernels, during bootup, used to say something about my CPU (a 486DX) honoring the WP bit in kernel mode. The new .13t kernel does not. I have verified that the "wp_works_ok" flag is *not* being set on my 486DX. -- +-------------------+----------------------------+---------------------------+ | JERRY J. SHEKHEL | Molecular Simulations Inc. | Funny how everything | | Drummers do it... | Burlington, MA USA | was Roses while we | | ... In rhythm! | jerry@msi.com | held on to the Guns... | +-------------------+----------------------------+---------------------------+ ------------------------------ Crossposted-To: comp.sys.intel From: lfern@netcom.com (T. David) Subject: Re: PCI support, automatic config, Plug-n-Play Date: Sun, 28 Nov 1993 23:21:07 GMT In article richk@netcom6.netcom.com (Richard Krehbiel) writes: >Which makes me wonder: is the ISA Plug-n-Play spec publicly available? >How hard would it be to support? Is PCI automatic config anything >like it? Intel runs a Plug-n-Play forum on Compu$erve... I'm not sure what they have out there. From what I've heard, Intel has done the Plug-n-Play ISA spec and is supposedly working on the PCI one for Microsoft to include in their next OS. For the Chicago betas out now, you have to use Intel's software to pre-configure it. The industry papers seem to indicate that the official released of Chicago will have everything all builtin. So... as long as the windows software is aware that you want to run your old Procomm version then it would not do anything non-compatible with the IRQs and addresses. I have a feeling that they don't have this big scoreboard and AI to figure out how you would want to configure your SW, so fully expect to have to manually tell the configuration software to stick with AT compatibility as much as possible to be able to use your non-plugplay aware software. At least with the newer programs, you should be able to do weird stuff like put COM ports all over the place and even share IRQs on EISA boards (to some extent). I also heard that VESA is coming out with a way for new monitors to actually talk to the PlugnPlay software so that the monitor and video board can work out the best setting for you... I can hear the software now... "Dave, I'm afraid that I can't allow you to do that. You would prefer the 1024x768 resolution with 68Hz refresh. It is for your own good." -- T. David ------------------------------ From: aehall@netcom.com (ha) Subject: Voicemail/Answering Machine program?? Date: Mon, 29 Nov 1993 01:38:31 GMT I don't know a whole lot about modem/phone-line communications, so no flames please... Would it be possible to write an answering program that uses just a standard modem or would special hardware be required?? If a standard modem could be used, could this program be essentially a combination of kermit (to receive the RING and pick up) and the soundcard "record" and "play" programs (to record the message) that uses /dev/ttySx instead of /dev/audio. (Yes, simplistic I know.) Just wondering... Thanks, A ------------------------------ From: dave@auspost.com.au (Dave Cole) Subject: Re: PCI support Date: Mon, 29 Nov 1993 03:35:13 GMT Here is the semi-standard response I give to people who ask me about the PCI machine I am typing this on. The motherboard is a noname Taiwanese brand. It has the Intel Saturn 82420 PCI chip set. The onboard SCSI controller is the NCR 53C810 PCI-SCSI I/O processor. The BIOS is by Phoenix. It had some problems with CMOS updating, and sometimes confuses drives A and B. The new version of the BIOS seems to fix this. Linux does not recognise the SCSI chip so I put in a Future Domain TMC-1680SVP ISA SCSI-2 controller. I have 16Meg RAM. The processor is a 486DX2-66. The VGA card is a noname Taiwanese board. It is a 2Meg S3 86c805 32bit PCI card. It supports 1280x1024x256. I have a NEC 5FG monitor, but still run in 1024x768 because I can not get a mode that looks good at 1280x1024. XF86_S3 supports the card well (I used to run XS3-0.4.4), and seems to recognise the 2Meg of RAM. Sometime soon someone who hacks SCSI drivers will get one of these SCSI chips and the onboard one will work. As far as performance goes - the machine goes like sh*t off a shovel. - Dave PS. The best way to get a good machine without going bankrupt in Australia is to go for a Taiwanese clone. This machine cost ~ $8,500 here (including 500Meg 9.5m/s SCSI-2 drive, NEC 5FG monitor). ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 04:04:35 GMT In article misch@eurom.fsag.rhein-main.de (Michaela Merz) writes: > >On Thu, 25 Nov 1993 15:19:19 GMT, dwex@aib.com (David E. Wexelblat) wrote: > >> [I'm about to leave town for the weekend, so I won't be able to follow >> up anything until Monday.] >> >> In article <2d07ah$aqs@TAMUTS.TAMU.EDU> drs0587@net.tamu.edu writes: >> > >> >Dirk Hohndel has recently posted several attacks on the >> >use of my TAMU Xconfig.1M configuration file. I believe quite >> >strongly that his arguments are flawed, and a disservice >> >to the linux community. The fact that he voiced them with >> >inflammatory terms such "Crap", and "stupid" is inappropriate >> >for serious newsgroups such as comp.os.linux.announce. Let's >> >leave such behavior to the alt newsgroups please. (All my >> >such usage is valid quoting of his initial post :-) >> > >> >> It's pretty amusing to see him do what he tells me I shouldn't do (:->) >> Unfortunately for you, he's right. > >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. We get hundreds of calls for help every month. >I would say about 60 % DO have trouble configuring X-Windows. > >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. > Guess what? It's a HARD problem. If there were a simple answer, don't you think we would have released it a year and a half ago when we started this? IF we picked a specific set of supported boards and supported monitors, then we could do things trivially by table look up. But you folks want us to support everything known to mankind. The generic problem is hard, perhaps impossible, to solve. Don't ever think there is any correlation between a BIOS or a Windows driver and what we have to do for XFree86. The folks who write the BIOS or write the Window driver: a) Only have to worry about one board. b) Know EVERYTHING there is to know about that one board. >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? > Because it can damage or destroy your hardware. Since you don't know this stuff, accept the answer from those who have been immersed in it for almost two years now. It is relatively rare. But it DOES happen. >Like tuning in a tv channel ... ? > You're trying to equate a receiver with a generator. Or are you referring to the fact that X and TV both make video images? There is only ONE set of video parameters in a TV, 100% independent of channel. >MM. > > >---- >FREE SOFTWARE ASSOCIATION irc: misch @ #fsag >OF GERMANY gopher: eurom.fsag.rhein-main.de >Voice: ++49-69-6312083 www: http://callisto.fsag.rhein-main.de -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 04:09:24 GMT In article <1993Nov25.220028.2203@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes: >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. Jeez, DO IT BY HAND! Hsync == Dot-clock/Horizontal-Total Vrefresh == Hsync/Vertical-Total Yeah, I guess we could make the server print that out. Probably should. But this is 3rd grade math here. > >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. Manual verification should be done MANUALLY, BEFORE starting the server. >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 :-) We've experimented with this idea. The problem is that users won't put in the right information, and then they'll think they're fine, but things will die. For example, this TAMU Xconfig.1M. It has clocks of 1 2 3 4 5 6 7... How on earth can the server verify based of something like that? This, specifically, is why I think Xconfig.1M is garbage and hand calculation isn't, given that both can lead to damage. > >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) | -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 04:15:57 GMT In article <2d5cdn$8ll@renux.frmug.fr.net> rene@renux.frmug.fr.net (Rene COUGNENC) writes: >Ce brave Michaela Merz ecrit: > > >> On Thu, 25 Nov 1993 15:19:19 GMT, dwex@aib.com (David E. Wexelblat) wrote: Watch your attributions! I didn't write this. > >> 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 ... ? > >This is the good point of view. > >If an electronic set (Monitor, Video generator, washing-machine 10 BogoMips), >made to be used by any end-user, can be destroyed just because you turned >the wrong switch, then it is ill-designed. Right. So blame your hardware vendors. Don't blame us when we do everything in our power (which isn't much) to prevent this happening. > >If, for example, the components of an oscillator may burn over some frequency, >then first this oscillator should not be adjustable to it, and even if it >is, some protection must stop the power before any problem occur. > >That is just how, more than 20 years ago, I have been teached electronics >engineering... Things have changed now... Good things: We have fantastic >integrated circuits. Bad things: There are more and more Mac Donald's >"restaurants" here France :-)) > >Imagine your TV-set destroyed just because you tried to display >an NTSC video tape on a PAL monitor: This is what happens^H^H^H^H^H may >happen whith XFree86, and the PC-Compatible hardware. Well, the monitors are evolving. Most, if not all, current monitors simply shut down the display if it gets too far out of spec. So it's being dealt with. THe problem is the bazillions of older technology monitors out there. > >Translate this to a software point of view: Imagine a function to get >characters from the keyboard in your program, allowing to enter some values >which makes your program hang... Gee, I've NEVER seen software that does something like that... :-> > > XFree86 is a really great software. Thank you. > The Tamu Xconfig file is an intelligent approach for helping people > to get XFree working. No, it's not. It is not at all intelligent. It is horrifically stupid to, knowing that it is possible to overdrive the monitor, to allow the user to send RANDOM timing values to their monitors. > > In my opinion, neither the people from the XFree86 team, neither the > people from the Tamu config are responsible for destroying any > hardware. However, in a court of law, the XFree86 way is far more likely to survive a lawsuit than the TAMU way. Science is ALWAYS better than randomness when physical damage is possible. > >Ok, I know that the kind of software programming done whith the video cards >in XFree is like adjusting whith a screwdriver or a soldering iron, on the >other hand. Don't start a big thread and don't flame me by mail, It costs >me a lot of money... > >I just wanted to say that most of us accept 'hardware bugs' which are >never discussed, in the equipment we all PAY, and at the opposite we blame >the FREE software authors as soon as we don't like something in their work... > >BTW, this thread should be moved in a more appropriate newsgroup I think now... >-- > linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ ** 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 ******************************