LWN.net Logo

The Evolution of Linux (TechRepublic)

Over at TechRepublic, Jack Wallen laments the loss of Linux configuration files. He went to edit his xorg.conf file on Fedora 10, finding, to his dismay, that there wasn't one. "Don’t get me wrong, I understand the 'why'. For large-scale adoption Linux needs to be as simple to use as the competition. One way to make this so is to take the guess work out of setting up such things as video. And I think it’s safe to say we all know that configuring video has, in the past, been a nightmare on certain chipsets. And to that end I can fully understand why the developers would want to go this route. And if they can create a fool-proof system that will be able to successfully configure X Windows with zero user intervention, more power to them. But I think this is a sign of things to come, and that sign looks like a Merge with Linux and Windows."
(Log in to post comments)

The Evolution of Linux (TechRepublic)

Posted Jan 19, 2009 21:25 UTC (Mon) by loki (guest, #53020) [Link]

That's a non-issue imho! The new X server doesn't need to have a xorg.conf file because it tries to autodetect devices, but if you put one into /etc/X11/, it will use it. So we have the best of two worlds acctually.

Yes, but...

Posted Jan 19, 2009 22:28 UTC (Mon) by pr1268 (subscriber, #24648) [Link]

Yes, but speaking for myself (and probably Mr. Wallen), it's a lot easier to modify an existing config file rather than create a new one in that you don't have to memorize its syntax and all the config option names and range of proper values.

Also, I would likely go into a mild panic if I went to edit xorg.conf and discovered that it didn't even exist. Config files may be passé but they're also a welcome reminder of how easy and convenient it is to customize Linux.

Yes, but...

Posted Jan 19, 2009 22:34 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Then run one of the many tools that probe your system and create xorg.conf.

Yes, but...

Posted Jan 19, 2009 22:41 UTC (Mon) by srwalter (guest, #54187) [Link]

So... you want text-based manual configuration files, but you want them to be easy? That position seems a bit schizophrenic to me.

Besides, even without using the legacy config file, X has not lost configurability or flexibility, it has just become more dynamic, instead of static. The "xrandr" command give you the ability to change anything you would want in the server, at least as far as outputs and modes go.

Yes, but...

Posted Jan 19, 2009 23:19 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

For anyone who wants to edit their system-wide xorg configuration, the best starting place would be running the command Xorg -configure which will generate an initial xorg.conf file that can be edited.

man Xorg for details

-jef

Yes, but...

Posted Jan 19, 2009 23:38 UTC (Mon) by drag (subscriber, #31333) [Link]

> So... you want text-based manual configuration files, but you want them to be easy? That position seems a bit schizophrenic to me.

It's not.

A configuration file with the proper treatment, as a user interface, is quite easy to use. Relative to the problem, of course. Most configuration files are trying to address complex things and it's going to require knowledge and effort on the part of the end user irregardless in how it's presented. Two examples of things I like are going to be:

OpenSSH's /etc/ssh/sshd_config (and related files) as well as OpenBox's $HOME/.config/openbox/rc.xml

OpenSSH because it takes something that is crazy-security conscious and complex and turns it into something that is easy to wrap your head around.

And OpenBox, even though its a XML file, because it takes something that is hideously complex as a highly configurable WM and boils it into something that is actually readable by humans. Other WM try to go about the problem by attempting a sort of combination proprietary (as in specific to the application) scripting/configuration language that is just nuts.

Besides just the formatting they also have GOOD DOCUMENTATION. SSH's keywords are useful and easy to look up and the man files are informative. OpenBox's configuration file is fully documented with examples and everything.

Without the documentation both of those would be much much less usable.

-----------------------------

"Aha!", you may say, "This requires documentation and thus is not easy to use! It requires reading skills and patience!"

Well true.. but having a GUI is no substitution for good documentation. A GUI without good documentation is just as much as a pile of shit as a text configuration file without good documentation.

-------------------------------

A few examples of things I consider shitty text files would be:

* Sendmail (absolute shit)
* Apache (not so bad if it's split up and has lots of nice, but not excessive comments)
* Samba (it's just difficult to get working and the debugging isn't very useful to end users)

--------------------------------

The thing with X.org is that it's configuration needs to be _dynamic_. It also needs to be specific to one user or another.

So, like Linux hardware configuration in general, it needs to be done on the fly and thus a static configuration file is not very useful, except for situations were your still trying to work around buggy (!@#$%) X Windows drivers by trying different options and such.

Otherwise it's not really that useful. Most things that people dealt with on older X windows stuff was all stuff that could be dynamically configured anyways. There was no need for most options because the hardware provided all the information necessary from the get-go. It's just that X sucked so that it couldn't use any information that the hardware itself was providing.

-----------------------

And just a FYI for anybody who cares.. if you look in your /var/log/Xorg.0.log file you'll see that X will print out it's initial default configuration file. Usually something like 30 lines of xorg.conf. You can just copy-n-paste that into a xorg.conf file as the basis of your configuration file. You'd have to do this if those X-sucks times pop up and your forced to use a driver option or enter a modeline or something.

Yes, but...

Posted Jan 20, 2009 1:07 UTC (Tue) by jreiser (subscriber, #11027) [Link]

if you look in your /var/log/Xorg.0.log file you'll see that X will print out it's initial default configuration file xorg-x11-server-Xorg-1.5.2-3.fc9.i386 does not do that on my up-to-date Fedora 9. Which version are you running?

Yes, but...

Posted Jan 20, 2009 1:30 UTC (Tue) by drag (subscriber, #31333) [Link]

Fedora 10. :)

But it only does it if your not using any config at all. And I am thinking of my intel box. If your running proprietary Nvidia then all bets are off.

Yes, but...

Posted Jan 22, 2009 18:42 UTC (Thu) by jschrod (subscriber, #1646) [Link]

I beg to differ.

Last week at a customer, someone with a Ubuntu workstation asked me how he can get rid of those d*mned dead keys on his German keyboard. The display configuration had no respective option that he found and well, I didn't find it either in my first 2 min search. So I just edited his xorg.conf and turned on the nodeadkeys option. Voila, immediate success.

If I had to first extract some xorg.conf default from Xorg.0.log, it would had needed much longer. And sax2 with its ability to simply select nodead keys is even better...

Yes, but...

Posted Jan 20, 2009 2:01 UTC (Tue) by stumbles (guest, #8796) [Link]

With the newer versions of the NVIDIA driver, just run as root; nvidia-xconfig Ta..... da.

Uh? X configuration is easy??

Posted Jan 21, 2009 11:30 UTC (Wed) by renox (subscriber, #23785) [Link]

I wouldn't call X configuration easy!

I remember a time where I had to compute the horizontal and vertical frequency which was interesting as if you get it wrong you could fry your monitor(!), thanks to auto-detection this is no more the case, but there are still issue with the weird keyboard configuration:
this week upgrading from RHEL3 to RHEL5, my left windows key doesn't work anymore as a modifier in KDE and I have absolutely no clue why.

Debugging those keyboard issue with X is a real pain.

Yes, but...

Posted Jan 22, 2009 8:56 UTC (Thu) by ceplm (guest, #41334) [Link]

You get the basic one (which is actually used) in /var/log/Xorg.0.log

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 9:15 UTC (Tue) by russell (subscriber, #10458) [Link]

and when the autodetect failed as was his case...

Clueless or clueful

Posted Jan 21, 2009 1:06 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Having a non-working xorg.conf is not much help either, unless you are an X guru. A clueless guy like me will probably look at /var/log/Xorg.0.log, find a lot of weird errors and then google them (along with the monitor model or something). But this process is a PITA with a console browser, so he'll probably need another computer. If our anti-hero can do this process then he can lookup a few xrandr commands to fix the mess instead, or download a working xorg.conf from someone else. Or even find out how to generate a default xorg.conf and then fix it, although in my limited experience this last option is the hardest.

A clueful X guru, on the other hand, will know his modelines by heart. So he will probably just know how to generate the default xorg.conf, and then tweak it at will. So what's the problem?

Clueless or clueful

Posted Jan 22, 2009 18:46 UTC (Thu) by jschrod (subscriber, #1646) [Link]

But xrandr just changes the screen part of X.

What if the problems are with the Synaptics touchpad, e.g., gesture support, the keyboard configuration (e.g., Meta vs. Alt), or the mouse configuration? Many of them are easier done in xorg.conf than in many X configuration programs that I have seen. (Actually, sax2 does it nicely; but that's SUSE only.)

Clueless or clueful

Posted Jan 22, 2009 21:20 UTC (Thu) by man_ls (subscriber, #15091) [Link]

I am rather at the clueless end of the spectrum so I cannot tell. But for dual monitor setup xrandr was far easier than editing xorg.conf.

For other things I have used just a couple of X configuration tools (Mandrake's and Debian's), and they didn't work very well in the basic tasks; let alone advanced configuration. But now thanks to the nice folks at xorg I don't have to know much to have a working system. Wow, it is easy. Now, I can have milk everyday!

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 18:06 UTC (Tue) by jwb (guest, #15467) [Link]

This isn't even true. You can put as much crap in xorg.conf as you want, regarding your mouse, and the latest xorg will just freely ignore it. People believe in the magic of evdev but those people probably also believe in unicorns and whatnot.

The Evolution of Linux (TechRepublic)

Posted Jan 19, 2009 23:59 UTC (Mon) by magnus (subscriber, #34778) [Link]

I think one of the reasons that things like X configuration have been painful historically is that it mixes hardware description and software configuration into one big file.

I have this vision of a central hardware description file where you can hint the OS on which peripherals are present on your system. You can specify as much as you want and the system will then try to autodetect/guess the left-out bits, but the description file always takes precedence. This file should be standardized and software/system independent.

Software configs for X and other applications could then be synthesized from this description with possibility for overriding options etc by the user, but the hardware description should never need to be hacked to suit the software, except for adding more information.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 8:40 UTC (Tue) by asamardzic (guest, #27161) [Link]

I have this vision of a central hardware description file where you can hint the OS on which peripherals are present on your system.
As a side note: this is pretty much how an *BSD kernel build config file looks like. For this reason, I always liked editing these much more than going through "make menuconfig" on Linux side...

Welcome to 2004?

Posted Jan 20, 2009 0:27 UTC (Tue) by iabervon (subscriber, #722) [Link]

No released server since X.org took the project over from XFree86 has needed an xorg.conf. I discovered this when I switched from XFree86 to Xorg and didn't create a new config file initially. I ended up needing to create a config file, but only because I had a very nice 19" Trinitron which was capable of something like 4096x3072, and Xorg defaulted to the highest possible resolution; while it was nice to have that much screen real estate, my mouse cursor was too small to see, and I didn't have 300 dpi fonts to produce visible text.

What's actually killed the use of config files for a lot of stuff is hotplug hardware. If I plug a monitor into my laptop, I'd like to use the monitor's natural resolution, but I don't know in advance what that will be. The most critical case is now when you've just plugged somebody else's projector into your laptop and you have no information about the new hardware, you're already running your X server with your presentation loaded in an application, and there's a ton of people watching. You need to not have configured the server in any way that would exclude having the projector work the way you're going to want.

Relying on hotplugging considered harmful

Posted Jan 23, 2009 18:36 UTC (Fri) by anton (guest, #25547) [Link]

Actually the projector thing is one area where the automagic of recent X servers has gotten in my way; in my experience recognition of projectors through DCC/EDID does not work in all cases (too long cables), so I want a fixed 1024x768 clone mode output to the external monitor. I could set up Xorg 7.1.1 (coming with Debian Etch) for that, but the X server 1.4.2 (Debian Lenny) only outputs to devices that it sees (no way to fix this with xrandr or xorg.conf). I eventually "down"graded the X server from Lenny to Etch in order to get the behaviour I need.

Relying on hotplugging considered harmful

Posted Feb 12, 2009 11:51 UTC (Thu) by daenzer (✭ supporter ✭, #7050) [Link]

It's still possible to override autodetection with RandR 1.2, both in xorg.conf or at runtime. It sounds like you may have just hit a bug somewhere.

Welcome to 2004?

Posted Jan 29, 2009 17:49 UTC (Thu) by Xanadu (guest, #1215) [Link]

Funny you say that, I did exactly that a couple days ago.

I plugged a company projector into my laptop. With the the nvidia-settings, I was able to hot set it up (meaning I didn't have to restart X or anything like that). Just plugged it in, told the nVidia control panel to "detect" and then hit apply. That's it.

The resolution it gave me by default wasn't the greatest, so I played with that, but... M.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 0:45 UTC (Tue) by jd (guest, #26381) [Link]

The lack of an xorg.conf file isn't too tragic, for "normal" hardware. It can be a problem for hardware that's not "standard", as it may give faulty information, which can be hard to manually correct if you have nothing to edit.

Back in the days when I used Viglen computers, I suffered from non-standard hardware problems all the time. Well, suffered is probably not the right word, as I ended up with some amazingly useful screen resolutions. 730x395. (It -is- useful if you're supposed to be getting 640x480 but need the width more than the height.)

Modern autodetect systems rely on (a) such bugs not happening, and (b) all modes being standard. The first will never happen, bugs are a part of life. The latter should never happen, as needs are far more important a determinant as to what you should use than whether Microsoft added the resolution to their "official" list that everyone and their kid brother now uses as Absolute Gospel.

Personally, I'm far more narked by X still not supporting split resolutions (something you could do on the BBC Micro in 1985 and even on the Commodore PET in 1978), where you have different windows at different screen resolutions. This is 30 year old technology, guys! C'mon!

Split resolution

Posted Jan 20, 2009 1:16 UTC (Tue) by dfsmith (guest, #20302) [Link]

The compositing X servers support different window resolutions.

And the Beeb only split the screen because of memory limitations (with the colo(u)r limitations being a consequence of that). Video memory is much too cheap to be able to afford complex multi-pixel-rate engineering effort these days.

30 years

Posted Jan 20, 2009 2:29 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

It surely is 30 year old technology.

Specifically in a BBC Micro you're spitting out analogue video, and so you can change your mind about the horizontal resolution on a line-by-line basis without screwing anything up. You can't do this at all in digital video, since you have to declare up front how many pixels are going to be in the line (to be honest in Beeb-era analogue video you could really only do it because the resolution was pitiful, much less than TVs could display)

So, assuming that someone had hardware which could do this (most VGA-compatible chipsets aren't designed with such nastiness in mind, and so probably can't or would be unreliable) it would only work for the minority using an analogue display in 2009.

Oh, and the reason it was so easy in these ancient computers is that they were doing all the work by hand. Every so-and-so many microseconds, tie a line high, move a byte, write the new luminance value to a register, etc. Well, I hope you're not nostalgic for that - drawing the screen was wasting most of the power of your expensive 8-bit computer. The Amiga (a slightly later machine which still did it) had a custom chip for such hacks, and it still couldn't manage good old 640x480 in full colour.

30 years (and the BBC Micro)

Posted Jan 21, 2009 11:09 UTC (Wed) by pboddie (subscriber, #50784) [Link]

Oh, and the reason it was so easy in these ancient computers is that they were doing all the work by hand. Every so-and-so many microseconds, tie a line high, move a byte, write the new luminance value to a register, etc.

Well, the video hardware was "doing all the work by hand", if it even makes sense to put it in such terms. Certainly, the CPU in the BBC Micro wasn't writing intensively to video registers in order to produce a video signal. Various early Sinclair microcomputers had a reputation for doing video with the CPU, however.

Well, I hope you're not nostalgic for that - drawing the screen was wasting most of the power of your expensive 8-bit computer.

On the BBC Micro very little "power" (or, more appropriately, bandwidth) was lost, since the RAM was clocked faster than the CPU, eliminating contention between the CPU and video hardware. On the Acorn Electron, bandwidth was more of a problem.

30 years (and the BBC Micro)

Posted Jan 21, 2009 20:10 UTC (Wed) by nix (subscriber, #2304) [Link]

The CPU may not have been doing all the work by hand, but the CPU was
still impacted by the video signal generation due to the lack of anything
like VRAM. I remember on the C64 the CPU would pretty much stall for
approx 1/10th of the time (once per character cell for a complete screen
width minus overscan) while the VIC monopolized the bus pulling the
character bitmap, colour and screen data from RAM. That's not ignorable by
any means.

30 years (and the BBC Micro)

Posted Jan 22, 2009 12:39 UTC (Thu) by pboddie (subscriber, #50784) [Link]

The CPU may not have been doing all the work by hand, but the CPU was still impacted by the video signal generation due to the lack of anything like VRAM.

Yes, but as I noted, the BBC Micro architecture effectively achieved the equivalent of "dual-ported" VRAM by providing enough memory access bandwidth. On other microcomputers, as I noted, such bandwidth was more of an issue (with larger screen modes requiring more bandwidth and effectively making interrupt servicing somewhat unreliable in certain cases), but apart from a few microcomputers it wasn't an issue of the CPU being tied up doing video signal generation, which is what the "by hand" reference suggests.

That's not ignorable by any means.

True, but it's quite a different assertion to that of computers "doing all the work by hand". Obviously, there are components doing the work that needs to be done, but there are many situations on such computers other than that of displaying a screen image where the CPU is more actively tied up doing other things, notably situations involving input/output from/to storage devices - the "by hand" reference would be much more appropriate in describing those cases.

30 years (and the BBC Micro)

Posted Jan 23, 2009 0:36 UTC (Fri) by nix (subscriber, #2304) [Link]

True. The last microcomputers that I can think of that really *did* do all
the work by hand were the Electron and the ZX81. (I think the Spectrum had
a video chip of sorts, but I'm not sure. Certainly the BBC and the
Commodore line did: the Commodore people were so proud of it that they
named one of their machines after the chip...)

30 years (and the BBC Micro)

Posted Jan 23, 2009 12:06 UTC (Fri) by pboddie (subscriber, #50784) [Link]

The last microcomputers that I can think of that really *did* do all the work by hand were the Electron and the ZX81.

Nope: the Electron had the ULA to do the heavy lifting, but as I wrote, the memory bandwidth wasn't as generous as on the BBC Micro. So, when the ULA had to access more memory, it stole more bandwidth from the CPU. There were various enhancements to the Electron (such as the Turbo Board) which gave exclusive access to the CPU for non-screen memory, thus reducing contention and improving performance.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 16:46 UTC (Tue) by iabervon (subscriber, #722) [Link]

With LCDs, you really want to use the monitor's natural resolution, and you can get that from the monitor (at least, as long as you don't have a lame KVM), and the timings don't matter at all as long as they're something reasonable. Between these factors, it should be possible for the software to find out from the hardware what it should do, and skip any guessing or user configuration. Actually, aside from some historical problems with drivers not knowing how to configure video cards with resolutions that aren't in the BIOS, it seems fine; my laptop correctly autodetects the screen resolution and uses it, despite the BIOS not listing it and it not being a standard size. (And before it was able to autodetect the correct resolution, it was also unable to set that resolution when it was specified by hand; in fact, it was pretty much unable to set a user-specified mode from the config file.)

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 19:23 UTC (Tue) by drag (subscriber, #31333) [Link]

Ya.. It's much better to use the 'natural' resolution for LCD displays and then scale the GUI elements to whatever size you want, rather then trying to use the resolution change the size of the GUI elements.

The Evolution of Linux (TechRepublic)

Posted Jan 21, 2009 1:15 UTC (Wed) by man_ls (subscriber, #15091) [Link]

... except when your puny computer doesn't support that native resolution.

I used to think non-native resolutions looked horrible, and always corrected the resolution on my work machines (and even on my colleagues's, some of which reverted it horrified by the small type). But now my first-gen Asus Eee cannot be overclocked and thus cannot drive my 1680x1050 monitor, so I'm stuck with a ridiculous 1600x1000 and hardware scaling. And guess what, it is not so bad. A punishment for my hubris, maybe.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 0:46 UTC (Tue) by maney (subscriber, #12630) [Link]

There's this song lyric from my youth that's looping in my head because Jack seems to need its advice - Life is change / That's how [it] differs from the rocks

This molehill is, frankly, FUD, and nothing but:

if this new setup is heralding a new era of Linux then I worry that, when something goes wrong, the only way to solve a problem will be the old fashion Microsoft way of re-installing. That just will not do.

Right - if it changes so as not to need the dumb, redundant, config file that's little changed since now ancient versions of X, it's a sign of the end times, of the Microsoftization of Linux. Isn't that obvious?

Well, no, Jack, it ain't. As has been pointed out, not least by yourself, this shocking new arrangement just means that X can work without a painfully hand-tweaked config file, not that it can't be given one in those special cases that guidance is needed. X is a living system, so sometimes it changes; since it's open source, any changes that are really boneheaded will be fixed, in extremis by a fork. As the history of X already bears witness...

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 9:36 UTC (Tue) by russell (subscriber, #10458) [Link]

You need to get yourself some real world experience. You obviously only use computers to do tasks that every man and his dog are doing. Flexibility is the strength that linux (currently) has that allows it to be used where windows can not.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 12:05 UTC (Tue) by jayavarman (subscriber, #19600) [Link]

The flexibility you talk about comes from the fact the it's free software, not from having every knob under the sun exposed in a configuration file and failing to run without it.

The Evolution of Linux (TechRepublic)

Posted Jan 23, 2009 9:46 UTC (Fri) by russell (subscriber, #10458) [Link]

That is far from true.

If I can lookup some documentation on knobs and flex the system into something I need, the cost will be a fraction of the cost involved in changing code.

* It takes a lot longer to change code.
* It takes more experienced people to change code.
* There is often less documentation on the code than there is on knobs.
* Changing the code makes the license tracking more complicated. Our lawyers have forbidden it.

So yes, with free software, you have to option to change the code, but it's often not cost effective or time effective. flexibility comes from the unix way of doing things. That is what we a losing.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 17:42 UTC (Tue) by finsko (subscriber, #10117) [Link]

> There's this song lyric from my youth that's looping in my head because Jack seems to need its advice - Life is change / That's how [it] differs from the rocks

I have to chip in with an OT elaboration here: the song is Jefferson Airplane/Paul Kantner's "Crown of Creation", but the lyrics of the song are taken/adapted (often verbatim) from John Wyndham's SF novel "Rebirth" (where this line refers to the conservative genetic purists who cannot adapt to the new telepathic "mutants").

Sorry, no JA/Linux connection, but I do remember Phil Lesh of the Grateful Dead wearing a UNIX shirt at a concert in the 80's. And Roger McGuinn of the Byrds used to be a regular attendee at (old) SCO Forum.

Grateful Dead, etc. (off-topic)

Posted Jan 20, 2009 19:26 UTC (Tue) by pr1268 (subscriber, #24648) [Link]

Sorry, no JA/Linux connection, but I do remember Phil Lesh of the Grateful Dead wearing a UNIX shirt at a concert in the 80's.

Adding to this, one of the Grateful Dead's longtime lyricists was John Barlow, now working for the EFF. For some reason I can envision GD band members (and Deadheads) being fans of Linux and FLOSS...

The Evolution of Linux (TechRepublic)

Posted Feb 26, 2009 7:42 UTC (Thu) by finsko (subscriber, #10117) [Link]

Even though this is a dead OT thread, I've found my copy of John Wyndhams's "Rebirth" (aka "The Chrysalids"), and I'd like to provide the actual text as what is (IMHO) an example of something (a mashup?) which is both a blatant ripoff of copyrighted material and a brilliant creative work (the Jefferson Airplane song "Crown of Creation", from the 1968 album of the same name). This probably won't make any sense unless you know the song. Note the reference to the text that started this thread.

Material (c) 1955, John Wyndham, 1978 Ballantine Printing (paperback).

p 168:
"Let him be...Your work is to survive. Neither his kind, nor his kind of thinking, will survive long. They are the crown of creation, they are ambition fulfilled, they have nowhere else to go. But life is change, that is how it differs from the rocks, change is its very nature.
...
Soon they will attain the stability they strive for, in the only form it is granted - a place among the fossils".

p 181:
"In loyalty to their kind they cannot tolerate our rise; in loyalty to our kind, we cannot tolerate their obstruction".

According to Wikipedia (http://en.wikipedia.org/wiki/Crown_of_Creation#cite_ref-0), this was done "with permission".

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 4:54 UTC (Tue) by dkite (guest, #4577) [Link]

Right now, configuration file or not, if it doesn't work without an
xorg.conf, it probably won't work with one. It seems that X is in such flux
at the moment.

There is a certain tragedy in having spent hours figuring out the finer
points of an xorg.conf and having all that hard learned knowledge thrown
away.

Personally I consider the tragedy having been forced to learn these finer
points.

Derek

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 7:42 UTC (Tue) by voluspa (guest, #49821) [Link]

In the interest of ah... 'normal users' ubuntu 9.04 kills Ctrl-Alt-Backspace making this xorg.conf tweak necessary for therestofus:

Section "ServerFlags"
Option "DontZap" "no"
EndSection

As for the use of X configurations, I've always found Wacom tablets in need of explicit setups.

/Mats J.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 7:57 UTC (Tue) by Los__D (guest, #15263) [Link]

The rest of us? I haven't used ctrl-alt-backspace more than 5 times in 5 years or so...

The pain of having to go to the console and killing X is much less than the pain of hitting ctrl-alt-backspace by accident.

- Not possible by accident you say? It is with programs using ctrl-alt-page down. (or any Ctrl-Alt combination, page down is just right next to backspace on my laptop)

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 8:48 UTC (Tue) by job (guest, #670) [Link]

It's useful on desktop machines when the video mode is corrupt (which often makes text mode useless as well), finding another computer just to remote login and kill X is a little unnecessary.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 8:56 UTC (Tue) by Los__D (guest, #15263) [Link]

If that is a problem on your computer, you can enable it.

(Or type user[enter], pass[enter], killall X[enter] in the blind, it's not exactly hard)

Enabled-by-default is worse than disabled-by-default, IMHO.

The Evolution of Linux (TechRepublic)

Posted Jan 21, 2009 6:30 UTC (Wed) by lacostej (guest, #2760) [Link]

you're missing sudo or su -c

:)

The Evolution of Linux (TechRepublic)

Posted Jan 21, 2009 8:20 UTC (Wed) by Los__D (guest, #15263) [Link]

dammit! :)

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 8:57 UTC (Tue) by lkundrak (subscriber, #43452) [Link]

In fact, I used to disable it since I keep hitting it accidentaly.

The Evolution of Linux (TechRepublic)

Posted Jan 22, 2009 1:32 UTC (Thu) by Richard_J_Neill (subscriber, #23093) [Link]

I filed a bug on this ages ago. The thing is, if you press and hold Ctrl for 8 seconds (eg while selecting multiple objects), both KDE and Gnome will automatically ("helpfully") turn on slow-keys and sticky keys.

Now, consider, if you pressed Ctrl, then released it (without having done anything; perhaps you changed your mind), then later press Alt-Backspace (to delete a whole word), then it's bye-bye X.

That's a really bad thing to be able to do by accident!

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 14:36 UTC (Tue) by wingo (guest, #26929) [Link]

Funny, I just hit this one a couple of days ago. Does no X developer use emacs, I wonder?

</hyperbole>

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 17:45 UTC (Tue) by cortana (subscriber, #24596) [Link]

About time someone set DontZap in the default X configuration. I was forever hitting it by accident on my laptop (where the ctrl and alt keys are right next to each other, and are narrower than on a full size keyboard). It is just too similar to the Ctrl+Backspace combinations used to delete to the last whitespace in text input widgets.

If it is to be enabled by default then it really needs to use a key combination that is harder to hit by accident. Left Ctrl + Right Alt + Shift + delete, for instance.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 17:46 UTC (Tue) by cortana (subscriber, #24596) [Link]

Or better, that uselesss "Sys Rq" key that is carefully captioned on every PC keyboard I've ever used, despite not actually doing anything. :)

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 19:16 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

You mean: "not actually doing anything except when you need to reboot a hung system".

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 20:54 UTC (Tue) by Kit (guest, #55925) [Link]

Actually, it's already used for that ;)

(assuming it's enabled in your kernel, in OpenSUSE there's a config option somewhere to enable it... one of the key combo kills all programs on the active VT)

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 13:31 UTC (Tue) by dps (subscriber, #5725) [Link]

My (CRT) display is 1680x1216 due to a custom mode in my Xorg.conf file. If I relied on automatic configuration I would be limited to 1600x1200. Linux
should *not* re-invent the windows registry and plug'n'pray.

If you actually try installing windows you will discover it is hard work and the automatic discovery, to the minimal extent it exists, just makes it harder. Fortunately for M$ most people get it pre-installed and never aware of the difficulty of the process.

The Evolution of Linux (TechRepublic)

Posted Jan 20, 2009 22:43 UTC (Tue) by oak (subscriber, #2786) [Link]

Btw. Why X cannot detect the best AGP mode? There's pretty large
performance difference between the default x1 mode and x4 mode that I
still need to set manually in xorg.conf.

The Evolution of Linux (TechRepublic)

Posted Jan 21, 2009 0:25 UTC (Wed) by nix (subscriber, #2304) [Link]

Mainly because there are a lot of systems (including all of mine) in which
4x AGP mode not working is signified by the PCI bus locking up. Good luck
noting that failure anywhere automatically so you can try something less
extreme next time, with the bus locked up...

AGP blacklist

Posted Jan 21, 2009 17:23 UTC (Wed) by cesarb (subscriber, #6266) [Link]

The radeon driver seems to have a blacklist to work around that problem, see radeon_agpmode_quirk at http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tr...

The Evolution of Linux (TechRepublic)

Posted Jan 22, 2009 22:28 UTC (Thu) by spitzak (guest, #4593) [Link]

There should be an xorg.conf file. It should clearly state with comments exactly the sorts of things you want to put in, but do nothing. In addition you should be able to put a single item in (such as some fix for a mouse) without breaking any of the other automatic items.

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds