Slashdot Mirror

Consider what NVIDIA's binary-only driver is for: XFree86. See the XFree86 License. Note that it is not the GPL.

IHBT, IHL, HAND, but I have to rebut.

1 It will soon be illegal because of SCO Maybe, maybe not, we don't know that for sure.
2 GPL is anti-capitalist BSD/Linux is a concept where only the kernel is GPL'd. There are systems based on BSD/Linux. Plus there is the NetLSD Project.
3 Its hard to use ...its hard to use what? Oh, you mean it's hard to use. Not any harder than DOS+Windows 3.1.
4 Its unstable Oh, and Windows isn't? I've only had Linux kernel-panic once EVER, and Windows 98SE crashes daily.
5 The software sucks Opinion, not fact.
6 The UI is inconsistent So is Windows'.
7 You have to tipe commands (type) Oh? You haven't run X Window haven't you?
8 It doesn't run Windows programs Oh? (sp?)
9 You cannot buy a computer with Linux I take it you don't look at wal-mart.com.
10 Linux companies are going out of bussiness Not all of them, look at Red Hat. And SCOrdure :
11 RMS is a communist arsehole Maybe this has to do with the GNU userland, but nothing to do with Linux.
12 High total cost of ownership Compared to paying $250 per machine every couple years for a copy of LoseDoze? If you know where to get it you can get it LEGALLY for free or at least well under $100.
13 Too many distros Maybe, but the answer is to stick to one.
14 Un-american Oh foo off!
15 Its not from microsoft That's a Good Thing, you know.
16 Poor security track record Compared to what? Windows gets hax0red more often than Linux. Besides, Hed Rat 8.0 comes with a firewall standard.
17 Anyone and their 14 year old brother can add (buggy) code maybe, but it won't go into the main source tree if it's buggy.
18 Even BeOS was better Opinion, not fact!
19 Eugenia doesn't like it And?
20 It SUCKS!!!!!!!!!!!!! If you had actually used Linux, you wouldn't have said that.

BTW, you want split pane, use KDE and Konqueror.

Now GoAT!

-uso.

Absolutely, but not for the purpose Microsoft intended.

In my .Xmodmap file (for XFree86 on Linux), I have the following:

keycode 64 = Alt_L
keycode 113 = Alt_R
keycode 115 = Meta_L
keycode 116 = Super_R
keycode 117 = Hyper_R

clear mod1
clear mod2
clear mod3
clear mod4
clear mod5
add mod1 = Meta_L
add mod2 = Alt_L Alt_R
add mod3 = Super_R
add mod4 = Hyper_R

With all this, the Alt keys send the left-ALT and right-ALT sequences into X (instead of Meta, which is usually the default for those keys). The left Windows key is Meta, the right Windows key is Super, and the Menu key is Hyper.

For those who don't use X11, Meta, Super and Hyper are three additional shift keys that the X11 standard specifies. A lot of software uses Meta (especially Emacs - which uses it eveywhere), but most programs do not use Super or Hyper, because most keybaords don't have those keys.

With my .Xmodmap, I get three extra shift keys that I can use when assigning keybaord shortcuts to stuff. I get Alt (which is normally not used, because the physical Alt keys are typically mapped to Meta), Super and Hyper.

I'm sure Microsoft is busy working out a way to make sure that future keyboards can't be mapped like this, but that's not my problem (yet).

The Xfree86 status page for ati shows accelerated support for the newer ati chips.

Maybe ati sent them the specs?

radeon is a XFree86 driver for ATI RADEON based video cards. It contains full support for 8, 15, 16 and 24 bit pixel depths, dual-head setup, flat panel, hardware 2D acceleration, hardware 3D acceleration (except R300 cards), hardware cursor, XV extension, Xinerama extension.

I thought that the latest XFree86 works by default for most Radeon chipsets. The fact that they're open source and not binary only was supposed to be a major plus over NVidia. Is this not the case? Lots of users on the red hat 9 list were crowing about how their Radeon 9xxx cards were doing 3d without any driver mucking.

half an hour and google

#
# 1024x768@43.5Hz, Interlaced mode (8514/A standard)
# Horizontal Sync = 35.5kHz
# Timing: H=(0.54us, 1.34us, 1.25us) V=(0.23ms, 0.23ms, 0.93ms)
#
# name clock horizontal timing vertical timing flags
"1024x768i" 44.9 1024 1048 1208 1264 768 776 784 817 Interlace

Hows tis?

#
# 1024x768@43.5Hz, Interlaced mode (8514/A standard)
# Horizontal Sync = 35.5kHz
# Timing: H=(0.54us, 1.34us, 1.25us) V=(0.23ms, 0.23ms, 0.93ms)
#
# name clock horizontal timing vertical timing flags
"1024x768i" 44.9 1024 1048 1208 1264 768 776 784 817 Interlace

Forget features. I'm stuck with the vid cards that work under XFree86, in non-framebuffer mode. I still remember the day I tried to install Linux on a machine with an ATI Rage 128 card, only to have it say: sorry, driver not written yet.

Except for the ``public domain'' part, I believe that is roughly what the BSD license calls for. It's this ``you can do whatever you want with it'' stuff that the BSD people always brag about.

Exactly what the modified BSD license calls for (copied from here):

2.2. Berkeley-based copyrights:

2.2.1. General

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.

If some Linux kernel coder DID improperly redistribute BSD without the attribution, that's naughty and needs to be fixed, but SCO has no standing in the matter, which is the only thing that matters for present purposes.

• They wanted to optimize for the only the operations they use. Their renderer performs no lighting calculations, for instance.
• They can optimize for a specific operating system and processor. They use MMX instructions, for instance.

I think I do and I still don't like it.

> My favorite complaint is that it's bloated
> or eats too much memory. It's bogus -- X uses
> relatively little memory itself, but pixmaps are
> stored in X instead of in apps. So Linux GUI apps
> tend to use less memory than they would with a
> Windows-like environment, but X's memory usage go up.

Heh, that might be true when you're using a simple windowing toolkit such as Xlib but what happens when you start using GTK or KDE? Things get a LOT more complicated.

If you really want to understand why some of us dislike X11, take a look here: X-Windows Disaster.

Also, one of the people who has been vocal in X11 criticism is no one else than David Wexelblat.

There's a castlerock driver in xfree 86. Now. Finally.

We're talking five days ago, mind. So don't feel so bad :)

Two things of interest:
1, The driver is a result of via and Alan Cox working together.
2, Alan has been using an epia as his main box, and I quote:
"I have two boxes with the relevant hardware. One of them is my desktop box and I've been running the driver as my main desktop for a couple of weeks now."

Seal of approval, if ever I saw one.

Dave

Some reasons why X is not a good idea in this case:

1. Plain X protocol doesn't work well with high-latency connections (like a 56k dialup connection): it's the best thing since sliced bread in a LAN, it employs several tecniques to save bandwidth, but unfortunately apps have to continuosly talk with the X server and latencies play a big role. IMHO this is expecially true with modern (read: relatively young) toolkits like Qt or GTK+, which probably could do better at keeping the number of requests to the X server to a minimum (note: the number, not the size). Of course, there is the Low Bandwidth extension to X (LBX, to be used via lbxproxy, and the Differential X Protocol Compressor dxpc which, aside from compression, employs some caching to avoid contacting the X server on the other side when it is not absolutely necessary (thus making latency less of a problem).
2. The X session is fragile: dialup connections tend to go down unexpectedly, and in such cases your X session is abruptly closed. For each connected client (application on the application server), the X server keeps a lot of state which isn't saved. If the link goes down, you can't reconnect later and find your session again (or, for the same reason, transparently move an app from one X server to another - even if there are some tricks about the subject)

For these two reasons, VNC seems to be a better idea in this case.

Not to be nit-picky.. but it's "X Window" not "X Windows". Linkage here and here.

From the man himself ...

other desktops have functioning fast local desktops

Everytime I hear someone say "X really needs to die", they blame the wire protocol. Well, the first step in optimization is to prove that the optimization you plan to do is actually necessary.

I have seen a large number of projects where "blind optimization" involves reworking large chunks of code only to find out that they haven't really solved the real problem.

As one doctor put it to us a few months ago: "If you think your baby is colicky, she isn't."

Unfortunately we don't, and probably never will, know the exact circumstances behind this split in developer ranks. It mirrors Matt Dillon's recent dismissal from the FreeBSD project.

As not enough that GNOME shit made it's way into Xfree86, now the minions of GNOME want to fork Xfree86 and make it become some more dependant to GNOME. Specially this mail is quite annoying. Xfree86 should not include the application breaking specs from FreeDesktop.org. An fork of Xfree86 is interesting and of course good for the future but not if it's made by the GNOME people who are only interested to push their own visions into their own fork of Xfree86.

Please think about this. Specially FreeDesktop.org caused no good. Try doing a fullscreen with Phoenix on GNOME 2.x with MetaCity. The specs break nearly every 2nd application.

Finally KeithP put out his response .

I saw this link on OSNews and thought it should be reposted here. This is a member of the XFree BOD giving more information on why Keith was expelled and a discussion of how X is governed (i.e. the distinction between BOD and Core). He also argues for LSB taking a much larger role with respect to X (I can't help but think that BSD, Solaris, etc.. would object to that).

OTOH YMMV as far as this attack since there is no discussion of what specifically are the issues leading to the fork and rather vague comments about "corporate interests".

XFree86 seems very poorly managed, especially compaired to somthing like KDE.
The whole project seems to take a black box approach, or at least that's my view from XFree86.org

If I take a look at what's in the next release I get Release Plans
"XFree86 4.x
Our current release is the 4.3.0 release, which was released on 27 February 2003.

A current snapshot of the 4.x code can be checked out of our public CVS repository."

And what's in 4.x? looks like nobody knows.

Unless, of course, your display manager isn't retarded and actually knows that the real world looks at things in inches or centimeters, not pixels, and adjusts font sizes (which are generally based on points, 1pt is 1/72") accordingly. Your display doesn't do that? Well, perhaps you should make the switch.

From XFree86 4.3.0 release notes:

2.1. Video Driver Enhancements

* ATI Radeon 9x00 2D support added, and 3D support added for the Radeon 8500, 9000, 9100, and M9. The 3D support for the Radeon now includes hardware TCL.

Looks like pretty good support to me... I really prefer that to a binary-only driver such as NVidia's.

It looks as though both of you are right:

DPS portion of XFree86-4.3.x manual

DPS is indeed part of XFree-4.3. But as you point out, the main sourceforge DPS site has announced that it is obsolete due to the X Render extension. This is a real shame as DPS does stuff far more elegantly than X Render and is of extreme importance to the GNUStep project. *sigh* --M

• ATI Radeon 9x00 2D support added, and 3D support added for the Radeon 8500, 9000, 9100, and M9. The 3D support for the Radeon now includes hardware TCL.
• Support added to the i810 driver for Intel 845G, 852GM, 855GM and 865G integrated graphics chipsets, including 2D, 3D (DRI) and XVideo. Support for the 830M has been improved, and XVideo support added.
• National Semiconductor SC1x00, GX1, and GX2 chipset support added with the "nsc" driver.
• Support added for the NVIDIA nForce2 integrated graphics, GeForce 4, and GeForce FX.
• Major SiS driver updates for some of the latest chipsets. Unfortunately the SiS 3D driver has had to be disabled because no one has yet taken up the challenge to port it to Mesa 4.x.
• The s3virge driver now has support for double scan modes on the DX (with XVideo disabled).
• Updates to the savage driver, including fixing problems with the TwisterK, and problems with incorrect memory size detection.
• 2D acceleration added for the Trident CyberBladeXP/Ai1 chipsets.
• Support for big endian architectures has been added to the C&T driver.
• Various updates and bug fixes have been made to most other drivers.

• The mouse driver now has automatic protocol detection for PS/2 mice.
• Several new input drivers have been added, including tek4957, jamstudio (js_x), fpit, palmax, and ur98 (Linux only).

• Support for the RandR extension has been partially integrated into the XFree86 server, providing support for resizing the root window at run-time.
• The Mesa version used for OpenGL 1.3 and DRI driver support has been updated to 4.0.4.
• The XFree86 server's hot keys (including those for switching modes and virtual terminals) can now be configured via XKB. Previously they were hard coded. An X server configuration option has been added to allow the VT switching hot keys to be disabled.

• An Xcursor library providing support for alpha blended (ARGB) and animated cursors. Two Xcursor themes are provided (redglass and whiteglass), as well as the default "core" theme (the traditional cursors).
• Xterm updated to patch level 173, including the following bugfixes:
  • Fix two infinite loops (special cases of mouse hilite tracking, DECUDK parsing).
  • Make repainting of the 256-color example work properly.
  • Modify parser tables to improve detection of malformed control sequences, making xterm behave more like a real DEC terminal.
  • Fix a problem with the blinking cursor which occasionally caused xterm to pause until a key was pressed.
  • Fix improper parsing of multiple items in the ttyModes resource.
  and the following improvements:
  • Modify xterm to invoke luit.
  • Add simple session management client capabilities.
  • Add a modifyCursorKeys resource to control how the shift- and similar modifiers are used to make a cursor escape sequence.
  • Check if the printerCommand resource string is empty, and use this to allow the user to disable printer function.
  • Sort the options list which is displayed in help- and syntax-messages at runtime to simplify maintenance.

• FreeType2 updated to version 2.1.1.
• The "freetype" X server font backend has undergone a partial rewrite. The new version is based on FreeType 2, and handles TrueType (including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old "type1" backend is now deprecated, and is only used for CIDFonts by default.
• A new utility called "mkfontscale", which builds fonts.scale files, has been added.
• The Xft library has undergone a major restructuring, and is now split into fontconfig (which deals with font discovery and configuration and is independent from X), and Xft itself (which uses fontconfig and deals with font rasterisation and rendering. The format of the Xft font configuration files has changed in an incompatible manner.
• Support has been added to the Xft library to do rendering with the core X11 protocol. This allows clients using this library to render to X servers that don't have support for the RENDER extension.
• There has been a significant reworking of the XKB support to allow multi-layout configurations. Multi-layout configurations provide a flexible way of supporting multiple language layouts and switching between them.

• Updates for Darwin/Mac OS X, including:
  • Indirect GLX acceleration added.
  • Smaller memory footprint and faster 2-D drawing in rootless mode.
  • Full screen mode now uses shadowfb for much faster 2-D drawing.
  • Native fonts can be used on MacOS X.
• Various Cygwin support updates, including an experimental rootless X server for Cygwin/XFree86.
• AMD x86-64 support (primarily for Linux so far) has been added.
• Support added for OpenBSD/sparc64.
• Major OS/2 support updates.
• Major SCO OpenServer updates.
• Multi-head support has been added for 460GX-based Itanium systems, and for ZX1-based Itanium2 systems.
• Experimental support for SunOS/Solaris on UltraSPARC systems.

A more complete list of changes can be found in the CHANGELOG that is part of the XFree86 source tree. It can also be viewed online at our CVSweb server.

> I don't know if the Watcom license allows relicensing as BSDL

Relicensing actually means adding restrictions. So one can take the modified BSD license and relicense it under the GNU GPL, but the same is not true for the original BSD license.

> I can't imagine how the advertising clause would prevent it.

The FSF enlightens ye!

> wasn't it removed awhile ago anyway?

Yes, but code licensed under it is still floating around.

I must be missing something fundamental to XRender. It's mostly focused on anti-aliased fonts and alpha blending both of which it will be used for by Gnome when XRender adoption becomes a bit more universal (Sun (Solaris 9) and XFree86 (version 4) are, AFAIK, the only X displays to offer this extension currently). XRender's big advantage, in fact, is that it doesn't require you to interact with X in a radically different way.

Suggesting that not using such a sparsely available and relatively new technology to do something that it's not intended for is "misprogram[ming] X" seems to be way out of line to me.

OpenGL is not the right way to go, as it's designed for an entirely different purpose.

The correct solution is to re-think the way X works (specifically with regards to XImage data, Colormaps, Fonts and drawing primatives), and design it to use modern graphics cards correctly. That's not going to happen tomorrow, but it is happening. KDE/Qt and Gnome/GTK+ will take advantage of such features at the become available.

From the makers of Things You Cant Do in Windowscomes Things You Can't Do in Linux You Can Do in Windows:

With chapters such as, Playing games without a Athlon XP 2200 emulation runner, Running a 21th century GUI!, and free time!! Thats right folks, with our guide to Things You Can't Do In Linux you can actually install programs without scheduling the time to do so! Install a new camera without restarting 6 times to find the right driver! Even use the latest video card without scrambling for seventy-two kernel patches!

All for the price of only thirty-nine ninety-five.

Xlib was made thread safe in the X11R6 release in 1994, but only if you initialize the locks it needs to do it properly via XInitThreads.

This is not some sort of mind-numbing disaster. This is just basic economic reality. When you take a valuable and limited resource (investors' money, employees' time) and produce something which the free market finds less valuable than what you started with, Adam Smith's "invisible hand" strikes. This is one of the benefits of a free market- it discourages losing enterprises and thus helps to ensure economic health. Other distros are doing just fine commercially (RedHat, SuSE, Slackware) or are nonprofit organizations (Debian). With RedHat targeting the desktop with recent releases and the releases of Lycoris, Xandros, and Lindows, Mandrake has failed to give people a compelling reason to use it.

If you want to see Linux on the desktop survive and have some cash you want to use for that purpose, don't throw it onto a sinking ship. Invest in a company which holds some promise. Or you could donate to XFree, Gnome, or KDE, all of which are nonprofits (though only Gnome is currently recognized by the IRS as a nonprofit).

That being said, it does the job of being the foundation of a basic desktop system. After installation and proper configuration (which most distros get right by now), most users won't even notice the difference. There are specialized libraries for direct rendering, and games performance is not an issue. Driver availability is OK and getting better.

The problem is that X is such a mess that the traditional open source collaboration model doesn't work too well. There are only relatively few people hacking on the project -- it doesn't even have a Bugzilla and according to Keith Packard, one of the real X gurus, doesn't want one because there aren't enough people to deal with the bug reports. Just look at their gopher-era homepage to get an impression about their professionality. Yeah, I know, HTML 2.0 should have been the end of web technology, but I am not only criticizing the looks here but also the lack of structure and meaningful information.

X would be fixable in a dedicated corporate effort (if IBM got their act together and started pushing LOTD it would not be an issue), otherwise open source will slowly evolve it into something more usable. Whether a competing GUI system will reach this state sooner remains to be seen.

The conclusion is inescapable: folks, Linux is officially gay!

Which ATI card did you have in mind? Most of the ones I've looked at are supported under Linux, and some are even more supported.

I will agree with you about the lack of necessary apps, (I like the gimp, but I don't see it anywhere near the level of Photoshop for professional work) but I think the issue of necessary drivers is mostly an issue for super-legacy devices or NDA'd device designs. The rest seem to fall into place fairly well, from what I've seen.

They don't have 3D support or dual head support for the 9700 yet, do they? The changelog only seems to mention 2D support.

Because until the late 90's desktop UNIX renaissance

The late 90's means 1997 or so. It's 2003 now, that's 6 years. And it'll surely be at least another year before RnR becomes broadly available. That's a long time. (Especially when you consider that the RnR guys only needed a few months, once they started. This suggests that writing extensions is so hard that only a select few can do it. Not encouraging)

Apple and Microsoft have both improved their GUIs enormously since 1997. X (and the other Unix graphics system, OpenGl) don't seem to have gotten much better during that time.

Since the founding of the XFree86 foundation, X has been improving at a faster rate than it has in fifteen years

XFree86 was founded in 1994. I guess I don't remember how well X worked in 1979, so I can't comment on how fast it's progressed.

This guy is clueless beyond imagination.. Anyway..

The Xfree86 stuff he is getting riled up about is probably this
While the gnome/gtk stuff is here and here
How he mixed it together is - impressive.

You're still arguing that it is X's C-S design alone that is causing the problems you're talking about. The C-S design is an easy thing to single out.. "the other window systems don't support network graphics, and they are faster, so it must be the C-S design causing the problem" is not a valid logical argument. That's not to say that it mightn't be the problem, of course, but it's not to say it is, either.

Having to do context switches between the client and the server all of the time is a real issue, certainly. It is one that can be addressed through means other than simply throwing out 20 years of software developed on Unix, though.

Keith Packard wrote a good presentation on this, Efficiently Scheduling X Clients at USENIX 2000.

Something like the improvements to the X server's internal behavior mentioned in that presentation (or in the associated paper, see Keith's Publications Page for more), in conjunction with Linux kernels more optimized for low-latency multiprocess scheduling could help the performance issues a great deal without having to junk the whole system.

You're still arguing that it is X's C-S design alone that is causing the problems you're talking about. The C-S design is an easy thing to single out.. "the other window systems don't support network graphics, and they are faster, so it must be the C-S design causing the problem" is not a valid logical argument. That's not to say that it mightn't be the problem, of course, but it's not to say it is, either.

Having to do context switches between the client and the server all of the time is a real issue, certainly. It is one that can be addressed through means other than simply throwing out 20 years of software developed on Unix, though.

Keith Packard wrote a good presentation on this, Efficiently Scheduling X Clients at USENIX 2000.

Something like the improvements to the X server's internal behavior mentioned in that presentation (or in the associated paper, see Keith's Publications Page for more), in conjunction with Linux kernels more optimized for low-latency multiprocess scheduling could help the performance issues a great deal without having to junk the whole system.

This is part of the RandR extension, wait for XFree86 4.3. This was mentioned some time ago.

Try Gentoo - it is known as well working with power on Macs.

Quake 3 !

Not an argument for unix geeks - they either don't play it or they run it on Linux :)

EXCELLENT 1392 support. Linux is still flaky at times with many devices.

If you mean 1394 (firewire) then Vist zip 250 and Sony DV are perfectly fine working firewire devices on both Linux/x86 and Linux/ppc boxes for me.

Cocoa API. This is a *REAL* serious reason

That's not a reason at all: I cannot run Cocoa applications on the other hardware platforms, most of my customers do not have Macs and I am not a marketing guy to force them to pay money to Steve Jobs. Web is the best GUI for information applications. Of course you disagree if you are a graphic designer, but we are talking about Unix geeks, remember?

First-rate font and color support.

Fonts? Colors? I don't know many of Unix geeks who cares about it. In my application I separate design and data aspects, so web designer can fix any style if dislike it.

Nice anti-aliasing isn't just eye-candy, it's great for extended-duration viewing, imho.

One more time - who cares about fonts. I can read and that's enough.

Now, let me try to convince you to install Gentoo. Right now you can enjoy clustering, advanced file systems, amazing amounts of available open source software that you can use to prototype or integrate your applications.

If it is not enough then don't worry and don't rush, wait for few more months and meanwhile read about RANDR? Read and think. And think different. Ask yourself - can Cocoa do such new stuff?

I agree with Sun: "The network is the computer". But I can add: for years in X11 the network is the computer including the display. With RANDR even more - you will be able to migrate the window of your application from display on one computer to display on ANOTHER computer without interrupting the process of execution? I guess Cocoa cannot do it and will never do it - Cocoa GUI is not network compatible at all, is it?

Pay your attention that RANDR is not new rebuild from scratch X11, it's just a small X extension. And not proprietary, by the way :)

Can Cocoa have different windows simultaniously with different resolution and color depth? If you are GUI designer that might be a nice and useful feature for you.

Finally, can Cocoa rotate the screen on the fly?

Snobs care about style of fonts. Geeks care about more amazing things.

Hey, I guess that was a good reason that RandR doesn't support bitdepth changing at all.

Don't tell anyone, but I found a list of sitez that host the XFree86 source code! Hopefully you can get it before they shut them all down! That ought to give you a head start!

• Lameness filters (It blocks a lot of legitmate posts)
  
• Unnessary posting delays. Hasnt taco learned to touch type? A lot of posts are typed in less than 20 seconds and it is a ANNOYING DELAY! 2 minute ban? Come on, so some are faster then others, big deal, some people have more to say than others
  
• Broken moderation system, The whole point is to sort the gems from the crap, yet a lot of posts designed to make a LIVELY DISCUSSION are MODERATED as flamebait! Come on, not everyone likes X, but just because some one bashes it dosent mean its Flamebait. Flame bait is more useful for DIRECT INSULTS and not legitmate discussions.
  

• Crapfloods, a meaningless flood of random letters or text, which the lameness filter does a crappy job at trying to stop, besides trolls have written tools using the opensource slashcode to generate crapfloods which bypass the filter
• Links to offensive websites, the most common one is known a http://www.goatse.cx, a awful site which shows a bleeding anus being stretched on the front page. Trolls sneak these links in by posting messages that look legitimate, but infact are sneaky redirects to the site. Common examples include rd.yahoo.com, www.linux-kernel.tk, goatsex.cjb.net, and googles "Im feeling lucky".
• Trying to break slashdot, this is actually a good thing, as it helps test slashdot for bugs. Famous examples include the goatse.cx javascript pop-up, the pagewidening post and the browser crashing post!
  

• Lameness filters (It blocks a lot of legitmate posts)
• Unnessary posting delays. Hasnt taco learned to touch type? A lot of posts are typed in less than 20 seconds and it is a ANNOYING DELAY! 2 minute ban? Come on, so some are faster then others, big deal, some people have more to say than others
• Broken moderation system, The whole point is to sort the gems from the crap, yet a lot of posts designed to make a LIVELY DISCUSSION are MODERATED as flamebait! Come on, not everyone likes X, but just because some one bashes it dosent mean its Flamebait. Flame bait is more useful for DIRECT INSULTS and not legitmate discussions.

• Crapfloods, a meaningless flood of random letters or text, which the lameness filter does a crappy job at trying to stop, besides trolls have written tools using the opensource slashcode to generate crapfloods which bypass the filter
• Links to offensive websites, the most common one is known a http://www.goatse.cx, a awful site which shows a bleeding anus being stretched on the front page. Trolls sneak these links in by posting messages that look legitimate, but infact are sneaky redirects to the site. Common examples include rd.yahoo.com, www.linux-kernel.tk, goatsex.cjb.net, and googles "Im feeling lucky".
• Trying to break slashdot, this is actually a good thing, as it helps test slashdot for bugs. Famous examples include the goatse.cx javascript pop-up, the pagewidening post and the browser crashing post!

X11 is short for X protocol, version 11. That's defined by the X consortium. What most people use is XFree86, developed by the XFree86 Project.

And by the way RMS, add in the code base of XFree86 and KDE, and you've got much, much more code already than all of the GNU stuff that gets installed in a typical distribution, even considering gcc.

The technology needed to implement Palladium is patented by Microsoft. The BSD license does not prevent the copyright holder from charging a patent license fee nor does it prevent the copyright holder from suing unlicensed implementors into oblivion.

Berkeley License

Hi werdna,

You wrote:

Reasonable people may differ with our anonymous coward about whether discounting his 1990 suggestion constitutes ignoring the entire Unix market, or whether he simply has an overblown view of the representattive constituency of his own design choices as compared to those of others.

You make a good point. My personal design choices don't represent the entire Unix market. I grant that.

Many Unix users are young, and learned with Linux or FreeBSD on IBM compatible hardware. For some of them, the IBM AT keyboard layout is OK.

Many other unix users were using Unix (or CP/M or VMS) systems long before the IBM AT, and grew accustomed to a keyboard layout having Ctrl to the left of the A key. Many of these people share my desire for a solution to the "ADB keyboard problem".

Executive Summary:

I am the anonymous coward who posted "Apple Laptop Keyboards Unsuitable for Unix Users". I am not the author of the UseNET post asking how to re-map the CapsLock key on an Apple Macintosh back in 1990. My point is that Apple's design choices back in the mid-80's are having very negative effects now. (They were having negative effects back in 1990 as well, as the UseNET post indicates.)

Additional evidence that other long-time Unix users share my need for a Ctrl key to the left of the A key is the fact that soon after IBM re-designed the keyboard layout for their IBM AT in 1984, unix man pages started to include sections on how to re-map the CapsLock key. For modern examples, see xmodmap(1), pckbd(4), wsconsctl(8), and XF86Config(5).

All Apple laptops still have ADB keyboards, and have a design flaw that prevents re-mapping the CapsLock key with software. If Apple really wants to expand into the Unix market, they should correct this problem.

Not all Unix people absolutely need a Ctrl key to the left of the A like I do, but a significant number do. Those people can't effectively use Apple laptops.

Historical Background:

Back in 1984, when the IBM AT first came out, IBM correctly recognized that the killer-app was word processing. IBM chose to have a keyboard layout that closely matched the IBM Selectric typewriter. They placed CapsLock to the left of the A key.

I think IBM's choice was a mistake. The Ctrl key was very heavily used in unix, CP/M, and even in DOS in those days. By placing the Ctrl key in an ergonomically very hard to reach place they discouraged its use. I don't think that this was the intention of the IBM people who made this decision; it was a consequence they didn't foresee. There are many other ways to achieve the functionality of CapsLock, but no other ergonomically good ways to achieve the meta- functionality of the Ctrl key. So, IBM foisted a bad keyboard layout upon us.

Apple followed IBM down the route to keyboard layout perdition, but they made the problem much worse! Apple not only copied IBM's (bad in my opinion) layout, but they also designed the ADB keyboard such that it was not possible to re-map the layout in software. You can re-map every key on every IBM compatible keyboard, and every key except CapsLock on the ADB keyboards. You ought to be able to re-map the CapsLock key as well! Preventing this was Apple's horribly bad mistake.

The original Apple ADB keyboards were not like this. They had a layout like all IBM XT keyboards, with the Ctrl key to the left of the A. The first ADB keyboards didn't even have a CapsLock key. However, when Apple added a CapsLock key, they also botched the design of the keyboard. They made the CapsLock key operate as if it was an actual hardware-locking typewriter key.

Proper Keyboard Design:

• When a key is pressed, the keyboard sends a keyPress event.
• When a key is released, the keyboard sends a keyRelease event.
• Each key is assigned a different keycode.

ADB Keyboard Mis-design:

• When the key to the left of the 'A' (CapsLock) is pressed, the ADB keyboard sends both a keyPress event and a keyRelease event.
• When the CapsLock key is then released, the ADB keyboard sends NO events.
• When the CapsLock key is next pressed, the ADB keyboard sends NO events.
• When the CapsLock key is then released, the ADB keyboard sends both a keyPress event and a keyRelease event.
• The above cycle repeats over and over.

Now, you and I may differ on the best layout. However, designing a keyboard that prevents re-mapping cannot be defended!

The Unix users who don't care about keyboard layout can use Apple's laptops as they currently exist. I know some of them.

For those Unix users (and there are many) who depend upon the Ctrl key being to the left of the A key, current Apple laptop hardware is unusable. For these folks, it doesn't matter if they are using vi or emacs; the keyboard layout must satisfy ergonomic requirements. It must be possible to re-map the CapsLock key. These users currently go elsewhere for their (laptop) computer hardware. Apple loses sales to these people.

Hi werdna,

You wrote:

Reasonable people may differ with our anonymous coward about whether discounting his 1990 suggestion constitutes ignoring the entire Unix market, or whether he simply has an overblown view of the representattive constituency of his own design choices as compared to those of others.

You make a good point. My personal design choices don't represent the entire Unix market. I grant that.

Many Unix users are young, and learned with Linux or FreeBSD on IBM compatible hardware. For some of them, the IBM AT keyboard layout is OK.

Many other unix users were using Unix (or CP/M or VMS) systems long before the IBM AT, and grew accustomed to a keyboard layout having Ctrl to the left of the A key. Many of these people share my desire for a solution to the "ADB keyboard problem".

Executive Summary:

I am the anonymous coward who posted "Apple Laptop Keyboards Unsuitable for Unix Users". I am not the author of the UseNET post asking how to re-map the CapsLock key on an Apple Macintosh back in 1990. My point is that Apple's design choices back in the mid-80's are having very negative effects now. (They were having negative effects back in 1990 as well, as the UseNET post indicates.)

Additional evidence that other long-time Unix users share my need for a Ctrl key to the left of the A key is the fact that soon after IBM re-designed the keyboard layout for their IBM AT in 1984, unix man pages started to include sections on how to re-map the CapsLock key. For modern examples, see xmodmap(1), pckbd(4), wsconsctl(8), and XF86Config(5).

All Apple laptops still have ADB keyboards, and have a design flaw that prevents re-mapping the CapsLock key with software. If Apple really wants to expand into the Unix market, they should correct this problem.

Not all Unix people absolutely need a Ctrl key to the left of the A like I do, but a significant number do. Those people can't effectively use Apple laptops.

Historical Background:

Back in 1984, when the IBM AT first came out, IBM correctly recognized that the killer-app was word processing. IBM chose to have a keyboard layout that closely matched the IBM Selectric typewriter. They placed CapsLock to the left of the A key.

I think IBM's choice was a mistake. The Ctrl key was very heavily used in unix, CP/M, and even in DOS in those days. By placing the Ctrl key in an ergonomically very hard to reach place they discouraged its use. I don't think that this was the intention of the IBM people who made this decision; it was a consequence they didn't foresee. There are many other ways to achieve the functionality of CapsLock, but no other ergonomically good ways to achieve the meta- functionality of the Ctrl key. So, IBM foisted a bad keyboard layout upon us.

Apple followed IBM down the route to keyboard layout perdition, but they made the problem much worse! Apple not only copied IBM's (bad in my opinion) layout, but they also designed the ADB keyboard such that it was not possible to re-map the layout in software. You can re-map every key on every IBM compatible keyboard, and every key except CapsLock on the ADB keyboards. You ought to be able to re-map the CapsLock key as well! Preventing this was Apple's horribly bad mistake.

The original Apple ADB keyboards were not like this. They had a layout like all IBM XT keyboards, with the Ctrl key to the left of the A. The first ADB keyboards didn't even have a CapsLock key. However, when Apple added a CapsLock key, they also botched the design of the keyboard. They made the CapsLock key operate as if it was an actual hardware-locking typewriter key.

Proper Keyboard Design:

• When a key is pressed, the keyboard sends a keyPress event.
• When a key is released, the keyboard sends a keyRelease event.
• Each key is assigned a different keycode.

ADB Keyboard Mis-design:

• When the key to the left of the 'A' (CapsLock) is pressed, the ADB keyboard sends both a keyPress event and a keyRelease event.
• When the CapsLock key is then released, the ADB keyboard sends NO events.
• When the CapsLock key is next pressed, the ADB keyboard sends NO events.
• When the CapsLock key is then released, the ADB keyboard sends both a keyPress event and a keyRelease event.
• The above cycle repeats over and over.

Now, you and I may differ on the best layout. However, designing a keyboard that prevents re-mapping cannot be defended!

The Unix users who don't care about keyboard layout can use Apple's laptops as they currently exist. I know some of them.

For those Unix users (and there are many) who depend upon the Ctrl key being to the left of the A key, current Apple laptop hardware is unusable. For these folks, it doesn't matter if they are using vi or emacs; the keyboard layout must satisfy ergonomic requirements. It must be possible to re-map the CapsLock key. These users currently go elsewhere for their (laptop) computer hardware. Apple loses sales to these people.

XFree86 does support your Radeon 7500 and 8500, anything more recent you're on your own ! ATI doesn't offer any better drivers, just "support" by the way of links (www.linux.org ... yeah riight, like that's gonna solve my problem).