Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
X need not die

By enterfornone in Technology
Tue Jan 09, 2001 at 09:48:51 AM EST
Tags: Software (all tags)
Software

Havoc Pennington, Gnome hacker and author of GTK+/Gnome Application Development, posted the following comment to a recent article on Gnotices regarding a Linux frame buffer port of the GTK+ toolkit. I thought it was deserving of a wider audience.

The whole "X is slow/bloated, it could be done faster/smaller" meme that seems to be going around has no basis in reality. People look at the X server in top and notice it uses lots of memory; they don't realize that its mem usage includes an mmap() or even more than one of the video RAM, and a bunch of pixmaps and windows that should be attributed to applications, not the window system.


X runs on the iPAQ in less than a couple megs. It was designed ages ago for sub-Pentium-equivalent machines. It is simply not the bottleneck or the main resource user on your GNOME/KDE desktop.

Issues with X, such as lame fonts, lack of antialiasing, lack of direct rendering to RAM, etc. are all being addressed quite satisfactorily with X extensions. X was designed to be extensible in this way.

So moving all apps to a new window system on UNIX is a silly idea that would get you nowhere.

Hopefully this train of thought will conclusively die one of these days.

There have been a number of discussions about replacing X with something else, and there are a number of projects such as Berlin which are working on doing this.

Despite what people think of X it is an incredible piece of software and a great success. X allows you to run GUI applications on a powerful server while having it display on a cheap terminal, a feature companies like Citrix sell to Windows users for thousands of dollars. There is a version of X available for almost every modern operating system. Regardless of what RMS thinks, the X licence has allowed proprietary system developers to port X to their operating system without having to give away the resulting source (most X replacements such as Berlin are under the more restrictive GPL or LGPL). This has allowed X to be supported by companies who are reluctant to move to an Open Source model.

X does have its drawbacks. Two of the most common complaints are poor handling of fonts and an inability for applcations to directly access video hardware. Both of these problems are very near solved. A new rendering extension was recently added to X which among other things allows anti-aliased and True Type fonts. As soon as applcations add support for this extension this complaint will be no more. The two most common free software GUI toolkits, QT and GTK+, already support this in development versions.

Dependant on driver support, the Direct Rendering Infrastructure solves the problem of allowing applications direct access to video hardware.

No doubt there are still more complaints with X, but with X being free software these can easily be solved without having to start from scratch. There is no reason to reinvent the wheel when you can just improve the wheel you already have.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
X needs to be
o killed 20%
o fixed 58%
o left alone 20%

Votes: 144
Results | Other Polls

Related Links
o Havoc Pennington
o GTK+/Gnome Application Development
o recent article on Gnotices
o GTK+
o discussion s
o Berlin
o Citrix
o RMS
o the X licence
o GPL
o LGPL
o rendering extension
o QT
o Direct Rendering Infrastructure
o Also by enterfornone


Display: Sort:
X need not die | 108 comments (108 topical, editorial, 0 hidden)
Mostly correct, I'm sure. (3.80 / 5) (#1)
by pb on Tue Jan 09, 2001 at 09:21:41 AM EST

A good test for this would be to take a cross-platform application that stresses the use of video, and compare speeds on different display outputs or operating systems. (X and something else, that is)

This article should show that there doesn't have to be a huge difference in the speed of X on Linux given a set of optimized video drivers versus the speed of the native drivers from the manufacturer running on Windows.

However, things might be a bit different on the bleeding edge, and no one said that it would be easy to set up in the first place...

All this having been said, I'm sure there's bloat in X, but there's also a lot of functionality. I want to have my fast local display and my networking transparency. Now I don't care if people try to work on other alternatives and compatibility with X, and better driver support, but if they've got some better ideas, I'd like to hear them.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall

X apps (3.50 / 2) (#50)
by Delirium on Tue Jan 09, 2001 at 05:37:52 PM EST

The problem in doing this is that X is so horrendously slow that graphics-intensive apps avoid it like the plague, so it's hard to find one to test. The first example that comes to mind is Quake 3 Arena. For Windows it's written as a full Win32 program. For Linux it is most certainly not written as an X program.

[ Parent ]
Yes it is (4.00 / 2) (#57)
by goonie on Tue Jan 09, 2001 at 07:07:12 PM EST

Linux quake runs just fine under X. It runs unplayably slow unless you use hardware acceleration, but with the DRI and a Matrox G400 it runs as smooth as silk.

[ Parent ]
Um... (3.00 / 2) (#63)
by pb on Wed Jan 10, 2001 at 12:08:48 AM EST

First, did you read my links at all? They explicitly test Q3A, for one, and performance isn't as bad as you'd think, especially in the first article.

Second, it most definitely is an X app. What else would you call it when you can run it in a window on X? It can run fullscreen, too, generally with an X extension, which is also X. (and a good feature of X, too, I might add, as is hardware acceleration...)

For Windows, I'm sure it's using native hardware accelerated APIs that allow it to grab the console and whatnot, just as it does in X; no difference there.

Or am I missing something?
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

games (5.00 / 1) (#82)
by Delirium on Wed Jan 10, 2001 at 01:39:43 PM EST

Hmm, I was not aware that it was actually an X app, I stand corrected.

Things seem to be making progress on the Linux front with some video cards, though I noticed that none of the tests were actually faster under Linux than under Windows, even with Quake3, one of the few games which has been explicitly written for Linux (as opposed to being ported as an afterthought six months later). Even with Windows98 being a horribly inefficient piece of crap, it still somehow doesn't do as badly as X. =P

Of course in my particular situation those benchmarks give me a good reason not to switch, since I have a p2 266 with an 8mb voodoo2 that runs Quake tolerably well (30-40 fps or so), and judging by the voodoo3 results, I could expect more like 20-30 fps under Linux+X, which is significantly less playable.

I suppose if you have a top-of-the-line system whether you're running at 90 fps or 80 fps makes little difference, but not all of us have gigahertz p3's with a geforce2. =)

And while I assume their benchmarks are fairly unbiased, I can't help but thinking that trusting benchmarks showing Linux's performance while running games from a site named "linuxgames.com" is a bit like trusting stability information from a site called "microsoft.com" - likely things will be tailored so the tests are run under absolutely best-case scenarios with expertly-tuned Linux setups.

[ Parent ]

Analyzing the results... (5.00 / 1) (#91)
by pb on Thu Jan 11, 2001 at 09:06:12 AM EST

You're right, there is a performance hit, but here's the difference. I've got an 800Mhz Athlon with a Matrox G400 MAX in it, and I was using Utah-GLX and XFree86 3.3.6 on it. Utah-GLX is not related to Matrox; it's a project that works on producing accelerated drivers, but it isn't official.

Microsoft gets the latest drivers from the manufacturer, before the card is shipped, optimized as much as possible because faster drivers make for better reviews and better sales. Linux relies on volunteers to reverse-engineer it (or use whatever tech docs they can) to build a driver after the card is shipped; when the manufacturer releases binary-only drivers, I'd only use them if there is no other alternative. And now that XFree86 4.0 is out, it needs its own acceleration (new driver model), so the results for that are worse at the moment...

You can consider linuxgames to be an upper bound given the test systems, or you can test it yourself; I'm sure there'd be a bit of a fuss if none of their readers could reproduce their results. But basically, that's the review that made me get my G400 MAX, and I'm pretty happy with it. :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Do I misunderstand the problem? (4.46 / 15) (#2)
by Anonymous 242 on Tue Jan 09, 2001 at 09:28:43 AM EST

I noticed that the majority of votes in the poll are for "X must be fixed." Personally, I didn't realize that X was broken. I've been under the impression that it is not X that is broken, but rather the current XFree86 implementation is what is broken. Historically, the freely available X servers have been somewhat lacking. The same is especially true of current font servers. While this is beginning to change, XFree86 still has a long way to go.

My view is that as more and more end user productivity applications are delivered for the low or now cost Unices and Unix-like operating systems, the companies producing this software will have an incentive to invest in improving the weak areas in X implementations. Face it, when the typical Linux/*BSD user was creating document in vi/emacs/joe in Docbook or Latex and sending the output to postscript files, there wasn't a whole lot of need for the bells and whistles in an implementation of X that the modern Linux/*BSD end user raised on WordPerfect and Microsoft Office expect.

An example is the complaint I've heard most often from newbie users of Netscape on Linux. "Those buttons are ugly." (For the typical computer user, an asthetically pleasing program is far more important than stability.) This is not a problem with X, this is a problem with the toolkit chosen by Netscape (Motif). The second most common complaint I hear is "those fonts are ugly." This also is not a problem with X, but with the current implementation of X.

Virtually all of the programming I do is server side work for Solaris, so I'll readily admit that X may be broken for programmers in ways unknown to me. That said, I've very seldomly heard complaints about X itself. Most of the complaints I've heard are about this toolkit or that toolkit or this implementation or that implementation.

Well... (4.25 / 12) (#3)
by 11223 on Tue Jan 09, 2001 at 09:38:19 AM EST

XFree86 is actually (IMHO) the best X implementation out there, at least in version 4.0. The problem with X is two-fold: it wasn't designed for a "real" graphical environment, and it was designed to be exclusively network transparent. If you've ever programmed raw Xlib, you know what I mean: color management is a mess, pixmap management is a kludge, etc., etc. Have you ever seen rio, the Plan 9 windowing system (no longer eight-and-a-half)? That's what X was originally designed to be - an overgrown console and clock.

MIT-SHM is also a mess. It's hard to use, and it was added as an afterthought. Imagine that - using the fastest System V form of IPC was an afterthought!! Supporting local users well an afterthought!

--
The dead hand of Asimov's mass psychology wins every time.
[ Parent ]

no it isn't (4.00 / 2) (#38)
by joto on Tue Jan 09, 2001 at 03:14:03 PM EST

XFree86 is actually (IMHO) the best X implementation out there, at least in version 4.0

XFree86 still doesn't support multiple color depths simultaneously. Multi-head support is not there (or if it is, it is very new and untested). GLX is not very stable, and easily crashes the server. And so on... Clearly there are other X-servers that are better in more than one area.

But, with all the resent changes in 4.0, the situation is getting better. Give them a few more years to stabilize and I might agree with you.

[ Parent ]

The font problem. (4.27 / 11) (#4)
by i on Tue Jan 09, 2001 at 09:39:16 AM EST

It lies with X itself. X is not designed to handle anti-aliased fonts, and many fonts (especially TT) look ugly on low-res devices unless anti-aliased. This must be fixed.

Also, IMHO X needs standard audio extension ASAP. When I run Netscape across the network and it starts playing stupid background music on a wrong computer... well, I hate it.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]

The font problem? (3.88 / 9) (#6)
by YellowBook on Tue Jan 09, 2001 at 10:19:52 AM EST

X is not designed to handle anti-aliased fonts, and many fonts (especially TT) look ugly on low-res devices unless anti-aliased.

I'm not sure that that's not a piece of folklore on the order of "X is (bloated|slow|in need of being replaced)". The thing about font anti-aliasing is that it is often alleged to increase readability. It doesn't. What it does is make fonts look more like their "ideal" shape (what they would look like on a higher resolution device like a printer), at a cost in readability. Anti-aliased text is harder to read, especially for large bodies of text.

What we really need are better fonts: fonts that have shapes designed for reading on-screen, and which are well-hinted for low-resolution devices. We also need font servers with as good hinting support as we can get: hinting in FreeType is good, but has room for improvement (though freetype2 may have already take care of this, I don't know). Even with a good font server, bad fonts with no hinting are not going to look good on screen. You can kluge them into looking better with antialiasing, but that's really only a solution for decorative fonts.

Also, IMHO X needs standard audio extension ASAP.

I agree with you in spirit, but I don't think this is an X problem. There are at least two major solutions already, netaudio and ESD. One of them needs to become standard and be cleaned up if necessary. SSH then needs to start automatically tunnelling that client-server audio as it does for X. There's no need to put audio support in X itself.

[ Parent ]

Yes, the font problem. (3.75 / 8) (#11)
by i on Tue Jan 09, 2001 at 10:59:24 AM EST

The problem is, no one is going to produce well-hinted fonts any time soon. We have to live with those that we have right now, and many of them are absolutely, utterly unreadable unless anti-aliased. For those fonts which are well-hinted, anti-aliasing may or may not produce more readable output. It depends largely on personal preferences.

As for audio, I still want the stuff to be a part of X, because it will simplify application programming. It need not be anything more than a bridge between X and whatever sound server it can detect.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]

Audio in X? (5.00 / 2) (#75)
by maxz on Wed Jan 10, 2001 at 05:51:02 AM EST

As for audio, I still want the stuff to be a part of X, because it will simplify application programming. It need not be anything more than a bridge between X and whatever sound server it can detect.

Then it should not be a part of X but rather the toolkit/API riding on top of X (and the sound server). Someone pointed out that abstraction is the way to go; the user shouldn't know that there in fact are two servers running, he only sees one API. But the way to handle abstraction is to divide up the programs and libraries into distinct modules each handling it's task in the best way. That way you can easily replace one module when someone invents a new better renderer/mixer/etc without replacing the whole lot.

The keywords here should be better integration between the existing things and not replacing them with a monolithic giant one-program-handles-everyting.

[ Parent ]

omigod, klugey! (3.22 / 9) (#13)
by G Neric on Tue Jan 09, 2001 at 11:05:44 AM EST

The thing about font anti-aliasing is that it is often alleged to increase readability. It doesn't.

It doesn't matter if it does or not. Font anti-aliasing is a well-accepted thing that people want to do with fonts. The cabability should be built into the way fonts are handled for the users who want those semantics. Anti-alias is a property, a checkbox a flag. It should not require a programmer to use a different API.

SSH then needs to start automatically tunnelling that client-server audio as it does for X. There's no need to put audio support in X itself.

huh? a combined audio and video feed from one app to be displayed/played on some UI server's desktop ought to be encapsulated within one protocol at some layer, not cobbled together from different ones.

[ Parent ]

Why? (4.20 / 5) (#32)
by YellowBook on Tue Jan 09, 2001 at 01:13:37 PM EST

It doesn't matter if it does or not. Font anti-aliasing is a well-accepted thing that people want to do with fonts.

I don't want to give the impression that I think font anti-aliasing is something that should never be done. If people want less readable text, then that's fine with me. And it does have some uses, such as in print previews (and PDF/DVI/GS viewers), which I think should be anti-aliased, so that the font shapes more closely resemble their printed forms. I'm just trying to correct a common misconception. I also think that more people think they want font anti-aliasing than would really want it if they knew the real benefits and costs.

The API issue you raise is a red herring, I think. In actual use, anti-aliasing or not will be handled at the toolkit level, and will use whatever anti-aliasing functionality the underlying toolkit provides. Application programmers will use only one API (per toolkit ^_-)

a combined audio and video feed from one app to be displayed/played on some UI server's desktop ought to be encapsulated within one protocol at some layer

Maybe, but I can think of a few reasons why it shouldn't be.

  • Sound has never been X's job before -- why should it start being X's job now?
  • There are existing solutions for this problem, notably ESD.
  • Multiple programs working together is the Unix Way.

IMHO, the right way to add client-server audio is to go with the existing solutions, but make it more transparent to the user (who will never see that audio is being handled by another server). Making ESD forwarding in ssh as implicit as X forwarding is one way of working toward this; no doubt there are others.



[ Parent ]
polymorphism (4.25 / 4) (#36)
by G Neric on Tue Jan 09, 2001 at 02:30:14 PM EST

and will use whatever anti-aliasing functionality the underlying toolkit provides. Application programmers will use only one API

...and if that one API handles aliasing or anti-aliasing the same way, that choice can percolate all the up to give the user a choice at runtime. Or, any code thus written can easily be repurposed in another app with a different context that might call for a different aliasing decision. The same code could display on a portable phone LCD, a desktop displaying text, a desktop displaying print preview (to use your good example), or on a Jumbotron.

Anti-aliased or not, fonts are polymorphic. Anti-aliased fonts have more information in them and are not theoretically less readable. Perhaps a future implementation will be more to your liking, or a future display technology will produce something you you find more pleasing anti-aliased. An application programmer should be able to write code today that benfits from future improvements.

but make it more transparent to the user (who will never see that audio is being handled by another server)

The programmer is also a user, as is the sysadmin in charge of the network. It should be transparent to all of them when they are not actually dealing with the differences. Pausing the stream should pause both audio and video so they don't need to be resynched. A programmer is going to have to accomplish this task at some point. When that happens, it should be inside of a shared API call so everybody does not have to reinvent the wheel.

That's not to say that your other points are not important, they are, and your suggestions should be observed. But there are more needs to be served than just the ones you are suggesting which should be observed as well.

Some of this may be terminology. When force-feedback, smellovision, and other VR technologies become mainstream, they need to be integrated into the client-server-display-stream API as well. You might say, "that's not Xwindows" and maybe it isn't. But then we should not run Xwindows, we should run Xsensurround and maybe it's implemented in terms of lowlevel protocols nobody ever heard of called Xwindows and ESD. In this paragraph I'm making the point that it doesn't matter what you call the abstraction, it is still useful for that which the user thinks of as one abstaction to be observed as one abstraction by the programmers, systems, networks, etc. In some sense, turning down the volume should turn down the smell too, and the relationship between the two (linear? log?) might be dependent on the user, or the species or who knows, but once solved it should not be the concern of the everybody else who encounters the abstracted stream.

[ Parent ]

fonts designed for reading on-screen (4.20 / 5) (#18)
by nickwkg on Tue Jan 09, 2001 at 11:49:23 AM EST

Despite being made by Microsoft, the Verdana and Georgia fonts that come with most versions of Windows are excellent for reading on-screen (they were specially designed specifically for this purpose).

It's nice to know they make some stuff that's worthwhile.

[ Parent ]
Fonts designed for on-screen reading are OK. (3.60 / 5) (#24)
by i on Tue Jan 09, 2001 at 12:12:09 PM EST

But they don't help me at all when I have a choice between PDF, PostScript and DVI renderings of the same document. If you replace native doc fonts with on-screen fonts, you screw up formatting (different font metrics). If you don't antialias, you pretty much have to magnify enormously. Otherwise the stuff is not readable at all.

DVI and PDF viewers that I use do their own antialiasing. PostScript viewer doesn't, and I wish it did.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]

Postscript viewer (4.00 / 3) (#30)
by YellowBook on Tue Jan 09, 2001 at 12:52:01 PM EST

DVI and PDF viewers that I use do their own antialiasing. PostScript viewer doesn't, and I wish it did.

What PostScript viewer are you using that doesn't use antialiasing? GV and ggv certainly do (both use GhostScript as their backend).



[ Parent ]
Thanks I'll try it. (3.00 / 3) (#67)
by i on Wed Jan 10, 2001 at 03:19:40 AM EST

I've got a new machine (Sun) and didn't have time to install everything I might need yet...

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Yes, that's so... (4.33 / 3) (#29)
by YellowBook on Tue Jan 09, 2001 at 12:49:59 PM EST

Anyone using X with a Truetype font server (such as the freetype-based font server in XFree86) should run out and get the full set of Microsoft web fonts: Verdana, Georgia, Trebuchet MS, Andale Mono, TTF versions of the standard PS fonts, and a few other junk fonts. Especially for web browsing, your font experience will be immensely improved. This set of fonts is possibly the only truly great thing MS has ever produced.



[ Parent ]
AA fonts _are_ better (3.66 / 3) (#68)
by Joeri Sebrechts on Wed Jan 10, 2001 at 03:58:14 AM EST

The thing about font anti-aliasing is that it is often alleged to increase readability. It doesn't. What it does is make fonts look more like their "ideal" shape (what they would look like on a higher resolution device like a printer), at a cost in readability.

I used to think this too, and then I saw the anti-aliased fonts on BeOS. Despite being a lot smaller than the non-AA equivalents in other OS's (small because I made them so, not because they are) they are a lot more readable. Just reading a text in BeOS will immediately point out that AA does make text more readable, no matter what the theory behind it says.
Maybe our brain has trouble dealing with sharp edges and can deal with soft edges better, hence be better at decyphering AA text. Or maybe because we train our reading on books we get used to the way fonts look in books, and since AA fonts resemble those better, they're more readable. I don't know why it is, but they definitely ARE more readable.

[ Parent ]

Anti-aliasing increases readability (3.00 / 3) (#74)
by maxz on Wed Jan 10, 2001 at 05:42:22 AM EST

What it does is make fonts look more like their "ideal" shape (what they would look like on a higher resolution device like a printer), at a cost in readability. Anti-aliased text is harder to read, especially for large bodies of text.

This is not true. Anti-aliasing enhances the shape of the glyphs on low resolution devices and thus makes it easier for the reader to recognize the shape (in other words increasing readability). This is especially true for very small point size fonts on ordinary screens. On large point size fonts and high resolution devices antialiasing doesn't matter much, exept for decreased speed and increased memory consumption.

But as someone pointed out, well hinted fonts is also very important, and that is harder to get. Few really good font designers GPL their work.

What you could do is to enable anti-aliasing only for small font sizes where it does the most good. A good renderer would probably be able to determine itself when this is needed.

[ Parent ]

Does anti-aliasing increase readability? (5.00 / 2) (#77)
by YellowBook on Wed Jan 10, 2001 at 11:43:26 AM EST

Anti-aliasing enhances the shape of the glyphs on low resolution devices and thus makes it easier for the reader to recognize the shape (in other words increasing readability).

I think we may be talking past each other. When I talk about readability, I'm talking about things that prevent eyestrain and increase comfort when reading long passages of text. I haven't seen any evidence that says antialiasing does this, and I've seen some evidence that it makes the situation worse, especially at normal font sizes.

Do you have any concrete evidence that shows that anti-aliasing does increase readability? This isn't a debate tactic or a jab -- I'd really like to know. Anti-aliasing looks cool, and I'd like to think it's actually helpful, but the balance of what I've read suggests that it's not.



[ Parent ]
Does anti-aliasing increase readability? (5.00 / 2) (#89)
by maxz on Thu Jan 11, 2001 at 06:16:38 AM EST

I think we may be talking past each other. When I talk about readability, I'm talking about things that prevent eyestrain and increase comfort when reading long passages of text. I haven't seen any evidence that says antialiasing does this, and I've seen some evidence that it makes the situation worse, especially at normal font sizes.

Sorry, now I see your point. Of course bad anti-aliasing just tends to "blur" text and that, of course, can cause eyestrain.

Do you have any concrete evidence that shows that anti-aliasing does increase readability? This isn't a debate tactic or a jab -- I'd really like to know. Anti-aliasing looks cool, and I'd like to think it's actually helpful, but the balance of what I've read suggests that it's not.

Well, not much other than what I learned way back when studying typography :-) I have not found any notes in my old books, but the ones I have pretty much predates widespread use of computer graphics.

If you look on the net you will se as many people telling you to use anti-aliasing as people telling you not to. The people that think anti-aliasing is bad generally say that it blurs text, expecially at smaller point sizes, this is true to some extent. But on the other hand, try rendering a font so that the individual glyphs are 6-8 pixels high on a screen. You then see that many glyphs are almost indistinguishable from each other and you cannot read the words just based on how the overall "word-picture" (since you have a hard time to recoginice the individual glyphs) but instead have read the word based upon the context. This is what I meant with decreased readability. With anti-aliasing (or gray-scaling as Bitstream calls it) the outline might be blurred but on the other hand the human brain is very good at regognizing shapes and the anti-aliased glyph looks more like the shape we are used to see than the non-antialiased one.

In an graphics textbook I once read they had a heavily distorted photo of Abraham Lincoln. It consisted of a matrix of maybe 10x10 cells each filled with grayscales. The picture was clearly recognizable as Abraham, but if the same thing had been done with just black and white cells based upon some treshold (a decision the font renderer does today) I seriously doubt that anyone would have been able to guess what the picture showed. Unfortunately I have not found the picture online, but I anyone know what picture I am speaking about and finds it, please post an URL.

I have tried to recreate the effect on an old ascii-art that I had lying around. This is not really the same thing as the ascii-art uses characters that not only affect the "gray-scale" in the character-cell but also the over-all shape. But it shows for example that some details in a glyph that might be too small to render in small point sizes disappear and thus makes it harder to see. Compare an O to a Q, not much differs and if the smal diagonal slab were to disappear due to bad rendering, this would decrease readability. Anti-aliasing can counter this effect somewhat.

I hope that I was clear about what I meant with improving readability. I believe that anti-aliasing should be optional and configurable depending upon the application and circumstances.

[ Parent ]

sound support (4.00 / 1) (#96)
by kubalaa on Thu Jan 11, 2001 at 07:21:08 PM EST

There's no need to put audio support in X itself.

Why not? From a network user standpoint, you have input devices to send information to your computer and output devices to return information. Right now the main inputs we have are mouse and keyboard, and the main outputs video and sound. X supports mouse, keyboard, and video; why not sound? You're thinking like a programmer; X is a GUI, so what's sound got to do with it? A user needn't make such distinctions; sound can, and should be, an integral dimension of an application, and if X is for running applications over a network, then it should be providing transparency for all possible inputs and outputs of applications.

Anyways, if you really believed that interactions should be compartmentalized then you'd agree that we should have a different application handling every aspect of the interaction (a sound server, a display server, a mouse server, a keyboard server, a microphone server, etc.). What a headache when all you want to do is run the damn application over the network.

[ Parent ]

Why has it taken so long to add AA fonts to X? (3.00 / 6) (#20)
by cr0sh on Tue Jan 09, 2001 at 12:02:39 PM EST

I don't know anything about coding for X (ie, I haven't looked at the source code for it), but I can't understand why it has taken so long for developers to add AA support. Why hasn't a patch (or something) been made that simple "diffused" the pixels around the letters as they were drawn. An intelligent algorithm could do this with little to no overdraw, and not much calculation to determine the proper diffusing colors for the AA filling (I am thinking a sort of state machine that looks for things like currentX, currentY, then next step is at currentX+1, currentY+1, so calculate and fill currentX+1, currentY and currentX, currentY+1 with the AA color). Why hasn't this been implemented?

I know it is a kludge, but such a patch should be simple, and would make the rendering look a lot better (it would need to know when it was only doing text - so as not to AA everything, which would massively slow things down). I just wonder if anyone could shed light on why something like this wasn't done several years ago (or even why it wasn't done on X originally - AA text has been known for a long while)?

[ Parent ]

Two things. (4.60 / 5) (#26)
by i on Tue Jan 09, 2001 at 12:24:30 PM EST

First, X didn't have any vector-type (e.g. TrueType or Type1) fonts initially, only simple bitmapped fonts. Bitmapped AA fonts require N times more memory (where N is your device's colour depth), and memory wasn't cheap those days.

Second, things rapidly become very ugly when you think about cheap colormapped devices (as opposed to TrueColor).

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]

I can agree to this... (4.00 / 1) (#83)
by cr0sh on Wed Jan 10, 2001 at 03:14:30 PM EST

In general, at the start of X - but truecolor support has been cheap since 1993 or so. Maybe it was a priority thing, though - that and maybe because you don't really start to notice the need for AA support until you get into higher resolutions, scaling the fonts up (thereby making BM fonts blocky, and in need of AA)...

[ Parent ]
Antialiasing is here. :-) (4.66 / 3) (#42)
by simmons75 on Tue Jan 09, 2001 at 04:01:41 PM EST

Take a look at this screenshot. You may recognize the text. :-) No, that's not edited in any way. (NOTE: Wait for the image to completely load; I saved it as a progressive JPEG.) Open it up in your favorie image editor and zoom in.

That's KDE2.0 under XFree 4.0.2. If I understand correctly, that's not a KDE-exclusive feature; rather, it uses the new XRender extension. Before long, you'll see GNOME and just about anything else that people want to have antialiased fonts using XRender. And apparently that's just the start; soon, there'll be fun things like alpha channel support.

As to why it took so long, I don't know, because I'm not much of a coder either. I'd guess that, as some people have told me, it just wasn't a priority to anyone until now.
poot!
So there.

[ Parent ]

Must not have... (3.00 / 1) (#84)
by cr0sh on Wed Jan 10, 2001 at 03:17:24 PM EST

I realize that X now has the support (as of the 4.0 line), but I just wondered why it took so long. It not being a priority seems to be the case...

[ Parent ]
A word of advice (5.00 / 1) (#85)
by der on Wed Jan 10, 2001 at 04:24:44 PM EST

When making screenshots to show off things like AA text, save it as a .png, it's really hard to tell anti-aliasing from jpeg compression artifacts. And contrary to seemingly popular belief, .pngs of this type/size can get quite small (the gimp compresses pngs quite well, and pngcrush does even better). Of course it all depends on the image.

[ Parent ]
Waiting for good Type 1 rendering (5.00 / 1) (#88)
by cwong on Wed Jan 10, 2001 at 07:29:12 PM EST

Thanks to Freetype, we have good TrueType font rendering on X. With good screen-optimized TT fonts like Microsoft's, fonts look good even when not anti-aliased. What bothers me is that we still do not have decent rendering of Type 1 fonts. XFree86 4 now comes with professionally hinted Type 1 fonts (Lucidux). They look like crap. The problem is that XFree86 still lacks a good Type 1 renderer, so even good fonts are wasted on XFree86. I'm surprised that there is hardly any discussion on how this situation might be improved. This situation is quite separate from anti-aliasing, since AA is not to everyone's taste.

[ Parent ]
There aren't any X Hackers for a *Reason* (3.50 / 16) (#5)
by lucas on Tue Jan 09, 2001 at 10:06:58 AM EST

>X does have its drawbacks. Two of the most common complaints are poor
>handling of fonts and an inability for applcations to directly access video >hardware.

...and use of a plethora of window managers, no common GUI elements, archaic configuration files (figuring out my monitor's frequencies "lest I destroy the monitor" is not exactly modern)... inability to directly access video hardware is only a piece in the puzzle. Handling of fonts is hysterical, at best.

there are still apps included that should have been ditched a long time ago; should I dub it the "install sprawl"? why are ancient apps like "xbiff" still being included in distros?

X would be fine if it were small and fairly minimal. People could move around its limitations and work ... but it is code upon code upon year after year.

hackers? (3.20 / 5) (#8)
by mikpos on Tue Jan 09, 2001 at 10:37:28 AM EST

The term "X hackers" to me would indicate people working on X applications. "The use of a plethora of window managers, no common GUI elements, archaic configuration files" would be a problem to end-users, not developers.

[ Parent ]
None of this is a fundamental problem... (4.50 / 8) (#16)
by pak21 on Tue Jan 09, 2001 at 11:41:04 AM EST

use of a plethora of window managers, no common GUI elements, archaic configuration files (figuring out my monitor's frequencies "lest I destroy the monitor" is not exactly modern)

Which of those are actually a problem with X? Multiple window managers: no. Just because people choose to use different things, doesn't mean the underlying protocols are broken. GUI: ditto. Configuration files: no. The files themselves aren't broken - what might be is the routines to configure them, which don't recognise enough monitors.

These may be things which need tweaking in X, but that's not a reason to throw out the baby with the bathwater (which is what the article's actually about).

Two points about xbiff: 1) <fx: looks in bottom-right hand corner of his desktop. Sees xbiff> 2) At least on this Solaris box, it's only 20Kb. Maybe you think that's 20Kb too much, but I guess there's much bigger amounts of bloat on your box.



[ Parent ]
Thank you (4.33 / 3) (#47)
by fluffy grue on Tue Jan 09, 2001 at 05:13:43 PM EST

pwm is a perfect example of why I love the X protocol the way it is, without any sort of policy specified. Even with all the various GUI hacks available for MacOS and Windows, I seriously doubt there'd be any clean, consistently-working way for something like pwm to happen on either of those platforms, whereas under X, pwm is simple, elegant, and applications work just fine with it (they don't even need to know what window manager they're using, except in the case of WM-specific hints).

I'm glad that toolkits are getting standardized, and that things such as GTK are sitting nicely on top of the existing X configuration stuff (from what I understand, GTK somehow uses X resources to publish theming/configuration stuff, rather than relying on the .gtkrc on the host system) so that it still fits the network-transparency model - i.e. in theory, remotely running a Gnome app and displaying it on my machine should have it display with my local .gtkrc. It's too bad that there's a few bad apples out there ruining the consistency model that's built up now (why do we need skinned apps like XMMS and Mozilla? why not just skin everything in the nice, consistent manner that modern toolkits prescribe? and why was it so hard to find a simple, non-gradient-and-logo-and-eyecandy-laden XMMS skin?) but otherwise, X's policy-free nature has led to a de-facto policy standard being accepted which retains the user's freedom to configure things in the way they see fit.

It's nice how I can use an experimental interface like pwm (or even its sister project ion, if I had the patience to configure it) which is signifigantly different from more 'standard' WMs without my choice having any impact on anyone else, and likewise, how other peoples' choices of running fvwm or twm or wmaker or afterstep or whatever doesn't impact me in the slightest.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

There is a plain XMMS skin (5.00 / 1) (#76)
by pwhysall on Wed Jan 10, 2001 at 07:55:55 AM EST

GTK+ Skin
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]
I know (5.00 / 1) (#100)
by fluffy grue on Fri Jan 12, 2001 at 12:03:38 PM EST

That's the one I've been using. It's the ONLY one I've found which isn't gaudy! (Note that I said, 'Why was it so hard to find', not 'I couldn't find'. Subtle difference.)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Sucks, doesn't it? (3.00 / 1) (#108)
by pwhysall on Sun Jan 14, 2001 at 04:34:26 PM EST

A visit to $THING.themes.org generally results in a total taste and usability implosion, right there in your web browser.

I can't understand this passion for skinning things - I use the Helix-Sweetpill themes for Sawfish, and the Notif theme for GTK. No fuss, no mess, no waxy buildup.
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]

Themed Apps (3.00 / 1) (#97)
by treke on Fri Jan 12, 2001 at 06:29:07 AM EST

I disagree with you slightly on the topic of per applicationt theming. In almost every case I'd agree that per application themes are a bad idea, but I think XMMS is one of the cases where it isnt. It could be done properly using straight qt/motif/gtk because of the number of controls to be organized in one place. By writing their own gui for the main window they can efficiently use up space. Since the widgets are being generated anew there is no reason not to give the option for theming. Now on something like Mozilla it's just plain a bad idea because it doesnt provide anything extra to the user.

[ Parent ]
Sure about that? (4.00 / 1) (#101)
by fluffy grue on Fri Jan 12, 2001 at 12:08:12 PM EST

I don't see a single widget on XMMS which couldn't have been done as a standard GTK widget, and thus get all of the GTK theming. Also, XMMS themes don't allow you to rearrange the buttons or anything, you're just basically putting bitmaps on top of an interface which only cares about the mouse's position when you push down the button.

The only 'new' widget is the oscilloscope/spectrum analyser, and that can just be a canvas with its own separate configuration. I suppose a case could be made for the windowshade view, which is really the only justification for having it a shaped window, and even then it still could have been done using just GTK widgets.

Also, what gain does the user get from an XMMS skin? Since when was it a bad thing to have a boring but usable interface? The only theme I've ever found to be at all usable and easy on the eyes was - get this - the GTK theme, which goes and emulates an unthemed GTK widgetset as an XMMS skin. Whee. And, of course, it doesn't respond to my gtkrc...
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

I am sure (2.00 / 1) (#102)
by treke on Fri Jan 12, 2001 at 03:18:17 PM EST

The interface could be done as gtk in theory... but then it would take up a great deal more space. Keeping it nice and compact like it is a good thing. I can leave it on screen and use it. There's nothing wrong with the boring but useable interface, but what makes the themes xmms interface unusable? The buttons are always in the same place, they just look different.

That's not to mention that xmms was meant to be a copy of winamp, so themes came along for the ride.

[ Parent ]

Huh? (3.00 / 1) (#103)
by fluffy grue on Fri Jan 12, 2001 at 06:30:45 PM EST

Why would it take any more space? It's not like GTK doesn't let you specify how much packing space to put around widgets.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Oh (5.00 / 1) (#104)
by fluffy grue on Fri Jan 12, 2001 at 06:31:48 PM EST

And themes make it 'unusable' in that you can't really tell where the buttons end and the 'skin' begins. And a lot of them are just plain FUGLY, and are annoying and distracting. I want to HEAR the music, not stare at the fucking player all day long!
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

The configuration file (4.00 / 4) (#23)
by deaddrunk on Tue Jan 09, 2001 at 12:11:04 PM EST

That might have been true 2 years ago, but X has an excellent GUI config tool, so the days of hand-hacking are pretty much gone (unless you want to). The current distro I'm using (Mandrake 7.2) automatically configured everything correctly when I installed it, so no aggro there either. As for monitor config, all the info is in the Windows driver (a complex text file :) ), so you can crib it from there.

[ Parent ]
You forgot color correction. (2.00 / 2) (#37)
by bored on Tue Jan 09, 2001 at 02:37:33 PM EST

X doesn't support any method of guaranteed color correction either.

[ Parent ]
Sure? (4.50 / 2) (#46)
by fluffy grue on Tue Jan 09, 2001 at 05:03:40 PM EST

I seem to recall that the X11 protocol has had support for color correction for as long as it's had color (R4 IIRC). I know that color correction stuff was gone into in great depth in the "color" section of some book I got many years ago on X11R4/R5 programming; it's just that most servers don't implement the color correction stuff, and applications usually don't use the color correcting calls and instead opt for directly grabbing videocard-level colors. I'm pretty sure that XFree 4 at least supports the independent gamma curve adjustments available on most modern graphics cards, in any case, which is the same hardware-level way that it's done in Windows and MacOS.

Of course, changing that stuff is a pain. xvidtune really needs to start supporting more stuff than just modeline management, especially since it's been deprecated thanks to finally having Vesa DDC support. (Look ma, no modelines!)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

xcmsdb(1) (4.50 / 2) (#64)
by jwb on Wed Jan 10, 2001 at 12:42:48 AM EST

X has color correction. Check the chapter 1 manual page for xcmsdb:

xcmsdb - Device Color Characterization utility for X Color Management System

In case you didn't know, you can also correct for your monitor's gamma, either in aggregate or for each color gun independently. Use the xgamma program.

X really is all that and a side of fried alligator tails. It has 3d accel, the most advanced font rendering system in the computer world (freetype), and color correction. What else were you hoping for?

[ Parent ]
XFree86 4.x supports DDC (4.66 / 3) (#41)
by hannibal on Tue Jan 09, 2001 at 03:50:02 PM EST

figuring out my monitor's frequencies "lest I destroy the monitor" is not exactly modern

As of 4.x, XFree86 supports detecting your monitor's capabilities through VESA DDC (monitors that have this capability are known in the Windows world as Plug-and-Play monitors). Simply add 'ddc' to the 'Load' subection of your XF86Config. Of course, you will need a newer monitor to support this (every monitor >= 15" ought to support DDC)

Reference: http://www.xfree86.org/4.0.2/RELNOTES4.html#18

[ Parent ]

RMS quote (uhh) (2.28 / 14) (#7)
by mikpos on Tue Jan 09, 2001 at 10:31:51 AM EST

Regardless of what RMS thinks, the X licence has allowed proprietary system developers to port X to their operating system without having to give away the resulting source

Either you haven't read the link you linked to, you screwed up and mis-linked, or (most likely), you have horrendously bad writing skills. The sentence above seems to suggest that RMS thinks the X licence wouldn't allow proprietary system developers to port X to their operating system without having to give away the resulting source. RMS has never said, at least not in anything I've read by him (if you have evidence on the contrary, maybe you'd like to link to that instead of to his critique on how the X licence lead to problems in the past). Or, here's a novel idea: say what you mean?

simple (3.50 / 4) (#35)
by Anne Marie Fornone on Tue Jan 09, 2001 at 02:20:46 PM EST

RMS thinks the X licence allowing proprietary versions is a disadvantage. I think it's been shown to be an advantage.

--
Erotic is when you use a feather. Kinky is when you use the whole chicken.
[ Parent ]

X is client-server (4.18 / 11) (#9)
by G Neric on Tue Jan 09, 2001 at 10:48:01 AM EST

X is client-server, and I don't care about anything else.

Memory is cheap, and so are fast networks and fast processors.

I think its great that today a teenager can have his own linux box, and that folks at home are playing with linux. But if you haven't used X to run apps sprinkled across a whole bunch of servers, you won't appreciate what is *so* cool about it. Plus the fact that it is not embedded in the OS means you can boot your OS from a floppy and actually have a chance of fixing a broken machine.

Yep, I'd like less clunky looking controls, etc., but the fact that you actually have a choice of window managers is worth more to me. I marvel at what X does every time I use it. I have windows from three machines on my notebook desktop right now, and I haven't gotten out of bed yet!

Even Just One... (3.83 / 6) (#22)
by Matrix on Tue Jan 09, 2001 at 12:07:20 PM EST

Even the convenience of just being able to run a graphical text editor and other stuff like that on my university's CS server from my home machine is enough to impress me. Especially since most of the people I know use Windows, and have to make do with whatever works over ssh if they want to edit stuff on the server.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

1st class windows (4.00 / 5) (#33)
by G Neric on Tue Jan 09, 2001 at 01:19:12 PM EST

yeah, we like the same thing: the app running on the remote machine is still a 1st class window on your desktop.

Y'know, your Windows (and Mac) pals should be able to do the same thing unless ssh's X forwarding is blocked, they'd just need an X server running on Windows. The commercial ones are pretty expensive (I like Reflection, but eXceed is very good too. haven't used any others.), but there is a free one you can download from <a href="http://www.microimages.com/freestuff/mix/>http://www.microimages.com/freestuff/mix/. I haven't used it in a couple of years, but then it was OK, very basic but better than nothing. You really had to hack at the config to get it to run a different window manager than their built in twm :)

[ Parent ]

Couldn't live without it (5.00 / 1) (#87)
by abo on Wed Jan 10, 2001 at 07:21:13 PM EST

Yesterday i logged into a GNU/Linux workstation. I didn't manage to compile the application I needed right then, but I knew a place in AFS (a distributed filesystem) at another site where it could be found, compiled for Solaris/SPARC. I also have an account at a third site where thay have Solaris/SPARC workstations, so I logged in there, started the application out of AFS and had its window open on my local X display. Three sites used just so I could run that stupid program. Wonderful! :)

And yes, I tunneled my X connection and used proper authentication. And no, VPN is not the answer.


-- Köp BRUX!
[ Parent ]
keep X, but tolerate alternatives (3.91 / 12) (#10)
by yavor on Tue Jan 09, 2001 at 10:51:04 AM EST

We should keep X, since(as long as I know) it is the best available solution. But we should be happy, that there are alternatives. X has its good and bad sides, but it gives us a decent GUI platform. It has slowly approved through the time.

X may be good, X may be the best, but software changes fast. Will X be the best after 15 or 20 years? This is way I am especially happy to see alternatives.

For instance: there are lots of window managers and desktop environments(yes all/most of them rely on the good old X) but 90% of the people are using the top 2 - KDE and Gnome. There are 3D desktop projects for Linux. They are not stable and very usable, but maybe after some time one of them will prove superior to The Big Two(tm) and replace them. Who knows?

The technology on which is based the Linux kernel is quite old. But it rocks. And most probably it will for quite more time. But one day there there may appear a free kernel that will blast Linux, *BSD. Although I don't see myself running HURD at my server anytime soon, I am Happy that it exists.

Look at Pentium 4 - as long as I know it one of the reasons it sucks is because Intel hit the P6 barrier - the old architecture just doesn't scale well above 1GHz. So is it bad having ThunderBird or Itanium?

Is having alternative approaches bad? No because one of the magic words for free/open source software(and the software industry as a whole) is competition.

I like alternatives, I like new things and this was the reason I installed Linux for the first time. That time I didn't know much about open source software. Now I have other reasons for using it - its freeness.

For myself I will no through X away anytime soon, but I will enjoy something new if it appears to be better.

X, etc (2.50 / 12) (#12)
by trhurler on Tue Jan 09, 2001 at 11:05:38 AM EST

I personally don't want the network stuff unless and until it can be made secure. Sure, I can VPN it, but that isn't the magic bullet people make it out to be unless your security model is awfully simple. Currently, X is the only real security hole on my network. I can block it at the network, but that's not a fix so much as a bad hack. In addition, because X was developed by and for experimenters with GUIs(which is fine,) it has no standards whatsoever for any kind of presentation issues even now, when it is production software(which is not fine.) All attempts to create such standards have failed miserably, and probably will continue to fail miserably. X is nice, but it is nice in a "this is a neat toy for our laboratory!" kind of way rather than a "I'd like to deploy this across the whole planet" kind of way. It is in use because Unix vendors have no acceptable alternative - and contrary to your story, technical considerations have little to do with that fact.

Not to worry, though. The days of anyone caring about exporting X displays are rapidly coming to a close; for better or worse, every app people care about is being redone using a web front end:) After that, we'll probably see interest in window systems that don't include this "feature" and instead concentrate on being user interfaces, which is what is really needed.

--
'God dammit, your posts make me hard.' --LilDebbie

How to run X securely (4.28 / 7) (#25)
by seb on Tue Jan 09, 2001 at 12:13:58 PM EST

If you use ssh to access your host computer, why not just use its super-duper transparent magical X tunnelling feature?

$ ssh user@www.yourhost.com
user@www.yourhost.com's password:

$ netscape &
No need to feel guilty about typing things like xhost +, either.

Or is that not what you meant?

[ Parent ]
Well... (3.71 / 7) (#27)
by trhurler on Tue Jan 09, 2001 at 12:24:32 PM EST

First off, it isn't what I meant. What I mean is, X is a huge body of mostly unaudited code that listens on various ports, which means if I have an X server running, my machine is not really all that secure.

However, as for ssh, there are several problems. First off, they've found security issues with X forwarding, so in general I disable it, because when you find one problem in a given piece of software, you usually find more later. I don't want to be the guy who finds out the hard way. Secondly, this doesn't prevent people from attacking your X server, which was my point. Third, xhost+ is a horrible idea, because after you use it, you are relying solely on whatever firewall you have for security, regardless of how you tunnel your normal X traffic. The one big win ssh has in this regard is that if you use it consistently, you can use filtering to block all incoming X requests except from your own machine. That's great, if and only if the forwarding feature spends some time in the wild without anyone finding more security problems. I'm not yet convinced. VPN is currently a better solution, if you can set one up, but it has its own problems, such as the fact that any traffic gateway onto the VPN is a potential hole, so your network ends up being either insecure or else totally isolated from everyone and everything not on the VPN - the old firewall problem in a different form.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
X and Security (5.00 / 4) (#60)
by chewie on Tue Jan 09, 2001 at 08:22:16 PM EST

Your security concerns are well noted. Because X is a client-server model, it is succeptible to the risks associated with that design model. Remember, X can operate with or without TCP/IP. If you don't want to have the risk the network brings, turn it off.

startx -- -nolisten tcp
X's security advisories are found here
http://www.xfree86.org/security
Second 10.2 of the X-Window-HOWTO
http://www.linux.com/howto/XWindow-User-HOWTO-10.html#ss10.2
Securing X Windows
http://wwwinfo.cern.ch/umtf/working-groups/X11/security/ciac2316.txt
See also man pages for
xauth(1)

assert(expired(knowledge)); /* core dump */
[ Parent ]
Network X is GRRRRREAT (4.00 / 1) (#92)
by johnnyb61820 on Thu Jan 11, 2001 at 01:10:13 PM EST

Running X over a network is great for systems manageability. Take, for example, diskless workstations. You can have each user have a diskless workstation that just runs X over the network, with TREMENDOUS savings in terms of both hardware and systems management. If a user box is broken, you just THROW IT AWAY. You only have to install things in one place. Ahhh, it is a utopia.

[ Parent ]
Window Managers (3.50 / 12) (#14)
by theboz on Tue Jan 09, 2001 at 11:09:25 AM EST

I believe most of the complaints about the speed of X come from those using KDE and Enlightenment. Most of the l33t purists try to stick with the cli anyways, so they may complain about how it is slower for them to point and click than to type it in the cli. I would say, with experience of running X on many different platforms with different versions of *nix and such, that X works fine.

Basically my preferences are as follows:

Work: Solaris 8 on a Sparcstation 5 with CDE. Home: SuSE Linux (originally 6.1 but upgraded by me) on an AMD P133 with KDE or Gnome.

KDE runs slower but it has a lot more features that I like, including some resembling Micro$oft's Windows. I have just started to use Gnome with Enlightenment and think it's ok so far. No real complaints but I still kinda prefer KDE for some reason.
CDE is perfect for work. I have a few types of windows I need to open, so I simply made buttons for them (basically I use xterms, a shell script to call the java applet for AOL Instant Messenger, Netscape, and the Remedy User Tool) and away I go. Also, I prefer it over the cli alone because of the multiple desktops so I can have one for each of the systems I develop on at work. (One development, one testing, one production, and one webserver.) I also can run xsnow but that's another discussion. :o)

Anyways, X does have more features than Windows, however it is not as easy to use for a novice, and to install can be a pain. But look at it this way too: How many people install their own version of Windows? Usually when someone gets a computer 98 or ME is installed on it already so they don't even need to worry about that. I would think that if someone bought a computer with linux or such already installed they wouldn't have to worry about setting up XFree86 or anything. In fact, I think Solaris is a good example. The install was just as easy as installing Windows NT. X is good, but it can definitely be improved. We just need easier install tools for now, then improve how it works.

Stuff.

Just a note... (4.00 / 5) (#39)
by a clockwork llama on Tue Jan 09, 2001 at 03:25:00 PM EST

Gnome and Enlightenment together is slow as molasses. There is just too much duplication of features between the two. Gnome has long since abandoned Enlightenment as its default window manager, instead opting for the less glamorous but faster Sawfish. Enlightenment has moved on to providing its own "desktop environment," independent on Gnome.

[ Parent ]
bah (4.33 / 3) (#40)
by simmons75 on Tue Jan 09, 2001 at 03:43:13 PM EST

It may seem as slow as molasses to you. Enlightenment was never intended to be just a windowmanager. It was intended to be an ultra-configurable desktop management system with an emphasis on looking good. The only time period in which Enlightenment was "the windowmanager for Gnome" (GNOME has never had an official windowmanager, BTW; it's designed to be windomanager-agnostic to a degree) was while some memers of the GNOME project and Rasterman of Enlightenment fame worked for Red Hat. After Raster left Red Hat and decided to resume making E its own windowmanager/desktop system, Miguel decided to declare E as no longer being part of the GNOME project.

If running GNOME and E together seems slow, it's probably because you're running both a memory-intensive desktop environment and a memory-intensive windowmanager.
poot!
So there.

[ Parent ]
Memory reporting (3.75 / 12) (#15)
by mcelrath on Tue Jan 09, 2001 at 11:19:32 AM EST

I think this perception that X is bloated is a symptom of the fact that memory reporting under linux just plain sucks. Consider:
  1. mmap()'ed memory is added to the application's SIZE
  2. shared libraries are added to the application's SIZE, and there's no straight forward way to determine if more than one application is using a given shared library (via top/ps, though you could 'lsof | grep')
  3. If an application forks, both the parent and child report the same SIZE initially, despite the fact that linux uses copy-on-write, and most of that memory is shared between them.
  4. threaded applications receive one PID per thread, and each PID reports the same SIZE, even though all PID's are sharing that memory.

Taken together, these things tend to lead to very skewed perceptions of the amount of memory an application is using. Everyone go run 'top' and type f within it. Notice the number of memory related fields you can turn on. (%MEM, TSIZE, DSIZE, SIZE, TRS, SWAP, SHARE, RSS, LIB -- there are probably others). But even none of these will tell you how much memory is mmap()'ed. 'top' and 'ps' both report the amount of address space in use, not the amount of memory being used. The latter number is somewhat hard to come by. I, personally, would like to see this shortcoming addressed. There should be some memory field via top/ps that when you take all the processes and add this field up, you get thea amount of used memory. (Mem used + Swap used at the top of 'top') One of my machines amusingly reports that X is using 302MB, on a 256MB machine, with no swap used!

--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 2=0; 1=0.

That's down to how UNIX memory is allocated (4.00 / 5) (#17)
by PhadeRunner on Tue Jan 09, 2001 at 11:45:42 AM EST

The reason the actual used memory in the system is hard to find is because it is all being used all of the time, UNIX (incl. Linux) use an always full memory model such that all physical memory (RAM) is always full of something. Well, full isn't strictly correct I should really say allocated. UNIX splits its memory into 3 types:
  1. Kernel memory which (surprise surprise) holds the kernel
  2. User memory which holds daemons and user space applications (like X)
  3. Buffer memory which is up to the limit of physical memory and holds file buffers, caches, socket buffers, shared memory, you name it, its there.
When an application requests a slice of memory the kernel will make a decision on what to swap out to VM (based around its VM algorithms) either applications or buffers or a combination of both and will then swap it out to VM (i.e. swap space on disk) and allocate the requested memory. Since it must allocate in a contigious chunk it must defrag the current RAM contents as part of this operation. This, incidentally, is why some X programs appear to take a little longer to start initially than their Win 32 or Mac OS ports.

Rant about memory usage over...

You are right though, Linux memory reporting does suck, especially threads... moan moan...

[ Parent ]

not system memory (3.80 / 5) (#19)
by mikpos on Tue Jan 09, 2001 at 11:55:04 AM EST

Finding the amount system memory used/free is trivial (on Linux anyway): use the program free (who knows why top and ps don't display this information for you).

The poster was talking about process memory used, though. Right now, Linux reports the size of a process's address space, but not how much memory it uses. Calculating that is a real pain.

And I was under the impression that Win2k, Mac OS X, and Linux all used basically the same memory allocation technique (though of course they would use different code, so the heuristics might be different).

Finally, I somewhat like the way Linux deals with threads. Spawning a thread is, more or less, just an old-school vfork() (not to be confused with modern vfork() implementations; it's actually __clone() under Linux), so I don't see any need to confuse and ugly things just so your ps output is a bit prettier.

[ Parent ]

RSS+SWAP-(SHARE+LIB) ? (4.40 / 5) (#21)
by molo on Tue Jan 09, 2001 at 12:04:38 PM EST

You make some good points. However, if you add RSS (resident set size) and SWAP, then subtract LIB amd SHARE, you should get the amout of unique memory a task is taking up.

From the top man page:

SWAP Size of the swapped out part of the task.

LIB Size of use library pages. This does not work for ELF
processes.

RSS The total amount of physical memory used by the task,
in kilobytes, is shown here. For ELF processes used
library pages are counted here, for a.out processes
not.

SHARE
The amount of shared memory used by the task is shown
in this column.
I have the following numbers for X (4.0.1, 1600x1200x16, nv module):

SIZE: 83372
RSS: 23M
SWAP: 9.9M
SHARE: 2304
LIB: 0

(23 * 1024) + (9.9 * 1024) - 2304 = 31385

This yields a much more reasonable 30.6M rather than the 81.4M given by the SIZE field. Perhaps we should call this the 'real' size and add it to top?

This doesn't help us with the thread issue though. As long as threads are treated as processes (due the the functioning of clone() ) I don't know if there will be a simple solution.

--
Whenever you walk by a computer and see someone using pico, be kind. Pause for a second and remind yourself that: "There, but for the grace of God, go I." -- Harley Hahn
[ Parent ]

But what about video memory? (4.25 / 4) (#28)
by fluffy grue on Tue Jan 09, 2001 at 12:49:33 PM EST

That figure still probably includes memory-mapped but non-system-memory things like the AGP window, which depends on how large it's set in your BIOS (likely anywhere from 32M to 128M), and the framebuffer, which is (IIRC) done by effectively mmap()ing the PCI device. I know that when i start up an OpenGL application, the SIZE of my X server grows from 56M to 192M (128M AGP window), but neither SWAP, SHARE nor LIB grow at all.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

What about RSS? (3.50 / 4) (#31)
by molo on Tue Jan 09, 2001 at 01:02:02 PM EST

RSS is supposed to be the "physical memory used." Does this include mmap()'ed blocks? I'm really not sure. As for SIZE growing by 100+M, does RSS do so as well? That'd be more interesting to me.

Just so I'm sure you and I are on the same page here, note that SIZE is not in my little equation at all.

--
Whenever you walk by a computer and see someone using pico, be kind. Pause for a second and remind yourself that: "There, but for the grace of God, go I." -- Harley Hahn
[ Parent ]

They both grow (3.66 / 3) (#44)
by fluffy grue on Tue Jan 09, 2001 at 04:31:33 PM EST

Both RSS and SIZE grow. Interestingly enough, this time when I ran a GL program to test this, neither of them grew by 128M (only 10M this time)... weird.

Oh, wait, it was xlock which was getting the 160M+ size stats, not X. That's right, it's the DRI's libGL which locks AGP now, not the X server... must have overlooked that when I was testing last time. The X server still has to lock more video memory for the framebuffer and Zbuffer, though, which would explain that increase in size. X is growing about 10M for both SIZE and RSS.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Ah! (3.50 / 2) (#51)
by molo on Tue Jan 09, 2001 at 05:51:33 PM EST

Interesting. In this case, it makes sense for both SIZE and RSS to increase by the allocated memory amount, as that memory is local to the application and not on the video hardware.

However the question remains: Did xlock's SIZE or RSS increase by 128M (due to the mmap() )?

P.S.: Don't mean to be a pain in the butt. I'm really curious now.

--
Whenever you walk by a computer and see someone using pico, be kind. Pause for a second and remind yourself that: "There, but for the grace of God, go I." -- Harley Hahn
[ Parent ]

As I said before... (3.50 / 2) (#55)
by fluffy grue on Tue Jan 09, 2001 at 06:55:27 PM EST

xlock's SIZE is 162M, and its RSS is 2928. Its SHARE is 2244. Its SWAP is 0. It's at this size whether it's doing any mode, not just a GL-using one, ostensibly because it's always loading libGL.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

X' problems stem from more than memory usage (3.00 / 6) (#34)
by gblues on Tue Jan 09, 2001 at 02:05:24 PM EST

One of the other comments used the term 'install sprawl' and I think this is a fairly accurate way to describe X' failings.

The problem with X isn't so much because X itself is bloated, but because there are virtually no standard libraries from X installation to X installation. How many times have you downloaded some X program only to find it depended on a bunch of libraries you didn't have installed? Or had to upgrade a library, only to discover that the new version of the library breaks several other applications?

As X applications are added to the system, the install "spreads" as more and more shared libraries are installed. Both KDE and GNOME give developers a (more or less) standard API to program with, but you still have fragmentation between the two.

Nathan

... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
Confused (2.75 / 4) (#43)
by gengis on Tue Jan 09, 2001 at 04:14:21 PM EST

I read through your comments twice, but I honestly can't figure out what you're talking about.

At first I thought you meant that every distribution had different...perhaps versions...of X...And that caused problems.

Then I thought you were speaking about library prefixes and whatnot.

But in the end, I am simply confused. I have never expereienced the 'install sprawl' you're referring to. I can't remember a program being dependant upon an X library that I didn't already have.



[ Parent ]
I assumed (4.00 / 3) (#45)
by enterfornone on Tue Jan 09, 2001 at 04:43:28 PM EST

They were talking about all the different toolkits etc that are available for X (gtk, qt, Motif etc). This isn't really a disadvantage of X, since X was only ever designed to handle the really low level stuff and the rest was to be left up to the toolkits. But it is a disadvantage that there isn't a single consistant way of programming applications that run on X. Still freedom of choice is a good thing too.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]
we had it (4.00 / 1) (#71)
by Joeri Sebrechts on Wed Jan 10, 2001 at 04:53:14 AM EST

We once had a universal toolkit, and it was called motif. It'll all pan out eventually. Although I have to admit that I think the whole idea of being toolkit agnostic was pulling it by the hairs a bit. It has it's uses, but in today's world I'd very much like KDE and GNOME to standardize on the same toolkit, since they have 100% duplication of functionality there. One can always dream, I guess ...

[ Parent ]
not quite universal (5.00 / 1) (#99)
by mihalis on Fri Jan 12, 2001 at 08:53:59 AM EST

We once had a universal toolkit, and it was called motif.

I don't agree, although a lot of people do.

Back in the days when it was at its _most_ popular, Motif was always expensive which acted as a high barrier to entry. It was also quite unstable for a long time, not to mention resource hungry.

On my first linux box which obviously had X and Xt there was no Motif, apart from whatever code was statically linked into Netscape.

I was earning a living programming Motif for Solaris apps in those days, and so I thought that Motif would obviously "catch on" for linux, so I spent my $200 on Metro-Link Motif, however I never used it, not even once (oh yes, I installed it, even build the XRT widget demos, but that was it). Even then there were existing alternatives to Motif, which must have been developed on commercial unix - early evidence of Motif's downfall.

Even on good old Solaris, Motif didn't totally dominate. I tried compiling Emacs for Motif but it was crap, basically, so I reverted to using Athena widgets.
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

X is slow and bloated (2.33 / 6) (#48)
by Delirium on Tue Jan 09, 2001 at 05:29:01 PM EST

I don't know about you, but I do not claim "X is slow/bloated" on the basis of the numbers reported by top. I claim it is slow/bloated because when I use it it is slow and unresponsive.

I have a Pentium 120 MHz with 64 MB RAM. It ran win98 very well, and responsiveness is excellent. Then I reformatted and installed Linux, so it now runs X+GNOME (you need either GNOME or KDE to even approach a modern desktop in which things like interprogram drag-and-drop have a chance of working). X+GNOME, on the exact same hardware, is infinitely less responsive than win98. While win98 responded instantly to a mouse-click, in X there is a noticeable lag in response, sometimes up to a full second. This is compounded by the fact that this computer is mainly a web-browsing machine, and none of the graphical Linux web browsers can match IE's responsiveness - Mozilla and Netscape 6 are painfully slow, while Netscape 4 crashes a LOT while still being pretty slow. But this is a secondary fact to the primary fact that X sucks.

It's also a bitch to configure, and you have to exit and restart X to get any changes to things like color depth, vidmode, etc. to take effect (and people make fun of Windows for the frequent restarts, yet I can do this in Windows on the fly).

For a more complete documentation of the massive extent of X's sucking, please read The X Windows Disaster, my favorite chapter from the (in)famous Unix Hater's Handbook.

Not X (4.00 / 2) (#53)
by enterfornone on Tue Jan 09, 2001 at 06:17:11 PM EST

I would say that the problem there is that KDE and Gnome are bloated, not X.

The X Windows Disaster is incredibly outdated. It was written when there were two programs written for X and Unix didn't support shared libraries. It is no longer even slightly relevant.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]
X (2.50 / 2) (#58)
by Delirium on Tue Jan 09, 2001 at 07:40:53 PM EST

I would say that the problem there is that KDE and Gnome are bloated, not X.

Well, they are certainly the worst part of the bloat, but X itself is not slim either. I've tried using X+WindowMaker on the same hardware, and while it was better, it was still not as responsive as Windows98 is. Plus, without KDE and GNOME, X is really not a usable modern desktop. The fact that KDE and GNOME's bloatedness is required to get a good modern desktop is a shortcoming in X itself.

[ Parent ]

ah (4.50 / 2) (#70)
by Joeri Sebrechts on Wed Jan 10, 2001 at 04:48:59 AM EST

Plus, without KDE and GNOME, X is really not a usable modern desktop. The fact that KDE and GNOME's bloatedness is required to get a good modern desktop is a shortcoming in X itself.

But is it really X's fault then? You're mostly complaining about GNOME and KDE adding too much excess baggage to X. Isn't it then more reasonable to say that it's GNOME's and KDE's fault that your PC runs slow?
Currently GNOME and KDE are in a feature sprint, and you only get bloat by adding features. Once they reach a saturation point they'll look at size again, and trim down their environments to a reasonable point. Besides, nobody forces you to use the entire environment. You can pick and choose (although I admit it's difficult).
A good example to look at is Mozilla. First they wrote the thing, then they made it stable, and now they're making it lean (and making a good job of it). Well, as lean as a cross-platform unified internet development and application environment can become ofcourse. :-)

[ Parent ]

x features (3.00 / 1) (#79)
by Delirium on Wed Jan 10, 2001 at 01:09:08 PM EST

Well, it's not so much that GNOME and KDE are adding "excess baggage" to X, but that they are adding needed features to X, and in the process adding a lot of bloat and slowing things down as well. Sure, X runs faster without them, but you can't really call something a "modern desktop" unless simple things like cut and paste and drag-and-drop between apps always work.

[ Parent ]
Shortcomings of X? (5.00 / 1) (#72)
by maxz on Wed Jan 10, 2001 at 05:14:29 AM EST

Well, they are certainly the worst part of the bloat, but X itself is not slim either. I've tried using X+WindowMaker on the same hardware, and while it was better, it was still not as responsive as Windows98 is.

Try some window managers that don't claim to do everything. Personally I think that WindowMaker is barely sightly less bloated than GNOME or KDE. What is wrong with fvwm2 for example? It is not the least sluggish on my P133 and on my 486/33 X is not to blame for the lack of speed. Just adding features to a windowmanager doesn't make it great or easy to use. These features could just as well be implemented as stand alone programs and let the windowmanager do what it does best, manage windows. I have had no trouble getting any of the window managers I have run to start whatever programs I wanted in the way I wanted it.

The fact that KDE and GNOME's bloatedness is required to get a good modern desktop is a shortcoming in X itself.

I don't think you know what X really is. When I started at my school about one third of the computers were in fact dumb X-terminals and X was designed to be able to run transparently on machines like these.

Today we have multiple architectures all around campus (Intel/Linux, Digital Alpha/DUX, Sparc/Solaris) and X allows me to access these machines by running it over encrypted tunnels since it was designed that way. Of course X has its drawbacks; it is horrible to program (have you tried to hack X directly without a toolkit?) and it has a lot of overhead, but claiming that you have to "bloat" software to get it usable (as in "modern desktop") is a lie. There are a few projects to come up with a better X, but none of them are about low-level fiddling with framebuffers or like.

The architecture of X does not prevent you from running other programs on top of it (like GNOME or KDE), in fact you are assumed to do so. So are the features from GNOME/KDE, missing in X, really shortcomings of X or deliberate design choices? Think again.

[ Parent ]

x (3.00 / 1) (#80)
by Delirium on Wed Jan 10, 2001 at 01:13:51 PM EST

While I agree that some of what I see as the shortcomings of X are in fact deliberate design choices, it seems many are not. XFree86 has done a lot of work over the past few years in trying to hack in features of a modern desktop to X, and much of the work is just that - ugly hacks. Through its design, X makes it very difficult to get simple things like anti-aliased fonts working, and things like GNOME and KDE are absolutely necessary if you want such features of a modern desktop as cut-and-paste and drag-and-drop between apps to work (and I'm being pretty generous with my definition of "modern" here; the Mac OS and Windows have had these features for a decade).

Sure, network transparency is nice, but for a single-computer desktop user it's not worth it if it comes with lots of trade-offs. However, I don't think it's impossible to have a windowing system which is good for a single-computer desktop and still has a high level of network transparency. The main problem with X is that it's a 20-year-old design upon which many things which were never originally planned for have been piled on, and it's starting to show the strain as more and more ugly hacks get thrown in.

[ Parent ]

X (3.00 / 1) (#90)
by maxz on Thu Jan 11, 2001 at 06:32:05 AM EST

Through its design, X makes it very difficult to get simple things like anti-aliased fonts working, and things like GNOME and KDE are absolutely necessary if you want such features of a modern desktop as cut-and-paste and drag-and-drop between apps to work.

I agree that X is old and many things are hard to accomplish using it. When it comes to drag-and-drop I have seen several solutions, but in the true spirit of free software everyone thought their solution was the best and refused to agree upon one. The only looser in this war is the end user. When it comes to cut-and-paste I see no problems with text, but if you want metadata, like fonts and colors, yes. Cutting and pasting graphics is nothing else than screen captures, something that X has several utilities for, including my favorite xwd :-)

Sure, network transparency is nice, but for a single-computer desktop user it's not worth it if it comes with lots of trade-offs. However, I don't think it's impossible to have a windowing system which is good for a single-computer desktop and still has a high level of network transparency. The main problem with X is that it's a 20-year-old design upon which many things which were never originally planned for have been piled on, and it's starting to show the strain as more and more ugly hacks get thrown in.

Network transparency is becoming increasingly more important as more and more people are getting fast connections at home. A few years ago not anyone would dare to run a X session over the modem connections to my school. Today with cable-modems many of my friend do their work from their home boxes.

But I agree that there should be no problem with having both network tranparency and "modern" features. But X doesn't disallow this, in fact I would say that what we need is perhaps another layer on top of X that applications can use, a standardized layer that is more than new look on widgets.

There are several projects that intend to replace X (for example WHY) and I welcome them, but I have yet to see one that gets somewhere beyond an idea. Also, since X does a lot of things correctly, why not extend it in a controlled, reasonable way, instead of throwing out everything and starting from scratch.

[ Parent ]

I have trouble believing this (2.50 / 2) (#78)
by Anonymous 242 on Wed Jan 10, 2001 at 12:03:41 PM EST

I've tried using X+WindowMaker on the same hardware, and while it was better, it was still not as responsive as Windows98 is.

I regularly use WindowMaker on a 486DX2-50 with 20 MB of Ram. It is much snappier and more responsive than Windows 95 on the same hardware. I've no direct experience with Windows 98, but all of my friends who "upgraded" their 486 class machines to Windows 98 from Windows 95 have all complained about a hit in speed.

I'll concede that anecdotes are just that, anecdotes. It could very well be that your experience differs from mine. I also don't know the differences between the box I'm running WindowMaker on the box that you've run it on. But my experience tells me that if X + WindowMaker is slower on your box than Windows, something is wrong.

Most of your other points, I agree with in the context that Windows suits your needs better than X. Do be careful, however, when extrapolating your needs to everybody's needs.

regards,

-l

[ Parent ]

X (5.00 / 1) (#81)
by Delirium on Wed Jan 10, 2001 at 01:22:48 PM EST

Well, perhaps X was not slower per se (with Windowmaker; it certainly was slower with GNOME), but it was less responsive. It's somewhat like comparing Mozilla on win32 to programs using the native win32 API: Mozilla is not particularly bad, but there is a noticeable difference between the responsiveness of its custom-programmed UI and the responsiveness of the UI of native win32 apps. X+Windowmaker felt like Mozilla in that regard: somehow the responsiveness was not quite as good as what I'm used to; UI events (highlighting, dragging, etc.) did not quite feel like they happened instantly.

But despite being a bit annoying, this I could get used to, if it weren't for the lack of a lot of features. I'm used to being able to drag-and-drop between apps, have cut-and-paste (whether within and app or between apps) always work, be able to read stuff with anti-aliased fonts, and enjoy a variety of other features that modern desktops generally support. Without installing KDE or GNOME, it does not appear that I can get these features in X.

So basically my complaint with X is not so much that it is useless (it is certainly the best solution for many people, especially those to whom network transparency is important), but that it is not a good replacement for Windows. My argument is directed against the type of people who claim that you can take your parent's Win98 box, set up an equivalent Linux+X box, and end up with a setup that is just as functional but crashes less. Obviously I disagree with that claim; I don't feel X, as currently available, is up to being the modern desktop for the masses.

[ Parent ]

try 'renice -20' (5.00 / 1) (#93)
by johnnyb61820 on Thu Jan 11, 2001 at 01:13:56 PM EST

If you run X and windowmanager/panel with a renice value of -20, you'll get a great performance improvement.

[ Parent ]
re: X is slow and bloated (4.50 / 2) (#54)
by mihalis on Tue Jan 09, 2001 at 06:25:10 PM EST

Briefly some points :

Gnome or KDE may well be a little slow on your machine, but if it takes a second to respond to a mouse click, something is very wrong with your system.

I agree about web browsers, except I don't have much problems with Netscape 4.71 crashing. I can't really comment on "the primary fact that X sucks" except to say that I disagree and to ask "compared to which other open source, cross-platform, network transparent, policy free window mechanism"?

Video mode can be switched on the fly with Ctrl-Alt-+ etc (I think that's right, I'm on my Sun right now). You're right about color depth though, but it still doesn't mean a reboot.

The X Windows Disaster is old and dated and no longer accurate. It's still a hell of a lot of fun though!

By the way, from what you say, why not go back to Windows?

Cheers,

Chris
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

x and win98 (2.50 / 2) (#59)
by Delirium on Tue Jan 09, 2001 at 07:49:15 PM EST

I can't really comment on "the primary fact that X sucks" except to say that I disagree and to ask "compared to which other open source, cross-platform, network transparent, policy free window mechanism"?

Well, that's the point - I need a single-computer local GUI. Network transparency, open sourceness, etc., is really not a concern of mine. If it were, I could always use one of the many 3rd-party utilities that let you remotely control a win2k desktop.

The X Windows Disaster is old and dated and no longer accurate. It's still a hell of a lot of fun though!

I find a lot of it somewhat relevant. I read it shortly after my first (brief) experience with X, and many of the things it bitches about seem all too familiar. The client/server thing too. =P

By the way, from what you say, why not go back to Windows?

Well, I don't really need that computer at the moment for any real work. On my primary computer (a p2 266 Mhz) I do run win98 exclusively, I just play around with Linux on the old computer. If I ever do need the computer though, i'll probably reformat it and stick win98 on it just so I can use AIM and IE (I don't like the Linux webbrowsers or gaim).

[ Parent ]

Well that explains it! (3.33 / 3) (#62)
by mihalis on Tue Jan 09, 2001 at 10:51:51 PM EST

It seems to me you know what you like, and it is Windows, so you run it on a decent computer and it works for you. That's great, more power to you, but it doesn't really seem like you've given linux let alone X a chance here, and you certainly don't need it, so your comments on this thread are from a way different point of view than the target audience.

If I can ressurect a tired analogy, it's like you're posting to rec.auto.weReallyReallyLove4WD.advocacy and saying "I find those big knobbly tires bad for handling, I don't like that big thirsty V8 and what's with the big brutish styling, eh!". And then after some more discusion it turns out that all you personally need or want is a hot little sport runabout to get to the running track with your Nikes, and to get to the beach at weekends -huh?!?

[I obviously made that all up, I hope it conveys my POV though!).

Cheers,

Chris Morgan
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

X is the least of your problems (4.33 / 3) (#61)
by SEAL on Tue Jan 09, 2001 at 10:47:09 PM EST

I rated this a 3 because it is the typical complaint about X, when in fact the responsiveness has little to do with X itself.

I used to run X + fvwm on a P-100, 32MB, Matrox Mill 2. I also even tried it on a 486/50 with 16 megs and an old Diamond 2MB card. It was acceptable on the former; a bit slow on startup (lots of swap), but usable on the latter.

The fact that you are using GNOME is a major hit to your performance from the start. Mozilla is still beta, which means it isn't optimized. Netscape 4 is statically linked to Motif, which adds another big library into the mix. Don't treat all these piggish layers as a problem with X.

Just a side note - I've found Netscape 4.08 more stable than 4.5+, and it has less of the annoying features.

- SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]
netscape 4.08 (3.50 / 2) (#69)
by Joeri Sebrechts on Wed Jan 10, 2001 at 04:39:47 AM EST

Just a side note - I've found Netscape 4.08 more stable than 4.5+, and it has less of the annoying features.

But it also has a number of, later fixed, security bugs. Just though you ought to know what you're running.

[ Parent ]

actually... (4.66 / 3) (#73)
by SEAL on Wed Jan 10, 2001 at 05:24:53 AM EST

But it also has a number of, later fixed, security bugs. Just though you ought to know what you're running.

You should read them first - most are trivial or avoidable. Netscape has a page with known vulnerabilities.

The brown orifice exploit is really more of an issue with the Java implementation, and is easy to avoid, assuming you even use Java in your webbrowser.

The SSL thing has a workaround. The frame spoofing vulnerability is easy to avoid. The rest don't affect version 4.08. Of course, there could be unpublished exploits, but that is also true for current versions.

But I agree: anyone who uses 4.08 should first read through the exploits and be aware of them. That's why I responded to your post :)

- SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]

X is not your problem but blackbox is your answer (4.00 / 1) (#94)
by noumena9 on Thu Jan 11, 2001 at 01:48:26 PM EST

listen: I use a P133 laptop w/ 40MB of RAM as my main machine. There are some things that you need to look after to make sure that your system is running up to snuff.

Firstly, when your machine slows down like that you ought to check top and make sure that you dont have some runaway processes. Certain netscape versions leave ldlinux.so's around that will suck every cycle they can out of your machine. If this is happening to you, upgrade your netscape to the newest 4.x version -- and I would recommend //navigator// not communicator for your RAM foorprint. And you (and I) do not have the machine to run mozilla properly. That app needs >64MB of RAM and some more processor, imho. It is slow on my machine too. Netscape navigator is very quick, though, much quicker than IE in 98 on my machine.

Secondly, get the blackbox windowmanager. If you are using Gnome, KDE or especially englightenment you are not doing yourself a favor. These environments are very intensive cpu and RAM wise. The blackbox windowmanager is the fastest, more rewarding app that I've worked with in UNIX. Download it, make your own theme and thank me later.

Finally I take issue with the notion that GNOME and KDE are worthwhile because they provide a "desktop environment." What the hell is that? I run with netscape, rxvt, vi maybe nedit and mutt and do tons and tons of varied work. You are not going to need the rest of that stuff! I have found that more a person learns about unix the more the command line becomes a place where more complicated work can be done much faster and more efficiently than all those widgity-GUI tools.



[ Parent ]
DRI on platforms other than X86 Linux (4.50 / 2) (#49)
by pope nihil on Tue Jan 09, 2001 at 05:30:46 PM EST

What about DRI on platform other than Linux on Intel? From what I can tell, there is a major lack of support for 3d on other processors and even on other x86 unices (like *BSD).

I'm not sure if the problem is a licensing issue or simply a lack of time to do the work. It could be a licensing issue if the kernel modules required to do DRI are under the GPL. I know that all the newer Linux kernels come with DRI modules as a standard part of the kernel, so I assume that they are under the GPL. This would present a problem for the BSDs.


I voted.

DRI (3.50 / 2) (#52)
by enterfornone on Tue Jan 09, 2001 at 06:12:39 PM EST

I haven't had much experience with it, but the DRI project page on Sourceforge suggests that DRI is under the same licence as X (which is compatible with both the GPL and BSD licences as well as allowing proprietary ports) and that it runs under BSD. Given that it is being developed by VA I would expect it to be more advanced under Linux.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]
DRI runs on Alpha and PPC (4.00 / 2) (#66)
by jwb on Wed Jan 10, 2001 at 01:05:43 AM EST

The DRI runs on x86, Alpha, and PPC. I think this probably hits 99% of the people who would want the DRI and benefit from it. People using HPPA, Sparc, and Mips can probably turn to their platform vendor for a good GL implementation to run their solid modelling programs or whatever on.

You can read all about these things on the DRI development mailing list.

[ Parent ]
the frame buffer is still unstable. (4.00 / 2) (#56)
by camadas on Tue Jan 09, 2001 at 07:02:58 PM EST

If they port the whole Gnome stuff to frame buffer, maybe that way it gets fixed. For those who haven't tried it, using the the accelerated matrox module (because 60 hz is not an option) still gives you corrupted display (large interlaced characters) if you run X too (with DRI) or simply stops giving output after some time (whithout X, only one console open). The vesa module works fine though, but the fixed modes are a nuisance, mostly because of vertical refresh rates too low, only usable for the graphical boot.

incredible design (3.00 / 2) (#65)
by mx on Wed Jan 10, 2001 at 12:55:02 AM EST

i would have to say that x-windows is one of the most incredible designs i've seen to date as it provides flexibility, networkable user interaction, user choice of window management, etc. performance problems are mostly a function of video support and feature-rich window managers (the smaller window managers are much faster). the MS Windows shell is fast as it is optimised for a single featureless case (and video driver support is very good), but it has resulted in a marginal gui (imho) ... x allows for a much better experience for those of us who want it. i do hope they improve x, but i'd hate to see it become more like the limited MS gui.
- mx
The *GUI* is bloated and slow (4.33 / 3) (#86)
by cwong on Wed Jan 10, 2001 at 07:14:53 PM EST

The trouble with defending X alone is that you really cannot do much with it. Almost any graphical environment will be dramatically smaller if you strip out its widget/toolkit library, its printing subsystem, its sound subsystem and desktop environment. Most people, however, would prefer to use all of the above. The problem with X, then is not just what it has, but also what it does not have. If your graphical environment does not have the stuff you need for a productive desktop environment, you will have to add them. Sometimes, they are added haphazardly. That adds bloat.

I can forsee the retort that this is a feature, that X gives us the freedom to choose the toolkit etc that we want. But the result is a lot of bloat and redundancy. Because X lacks a single decent widget set, a desktop might load libXaw, libXaw3d, libqt, libgtk, Lesstif, libforms, libtk plus stuff statically linked to the app. Had X included a good widget library, this redundancy would be eliminated, and any missing features can be added by extending the existing library.

The end result is that an X desktop environment comparable to Windows 95 (when that actually happens) will likely consist of many redundant pieces that do not integrate well and have a larger footprint than its non-X competition.

If only X had a single widgetset (4.00 / 1) (#98)
by Dion on Fri Jan 12, 2001 at 07:40:05 AM EST

You complain that X does not dictate a widgetset, well, just think about it for a second.
if X had forced people to use a single toolkit then X would have died years ago because it would have been stuck with the horrible look n feel of the pre-motif(yurgh) days.
The result would be one of two evils:
  • X would have died, tons of apps would have been rewritten
  • People would ignore the ugly toolkit and use only the pixel primitives as they do today, but X would be bloated with rarely used code


In stead we have the basic functionality that we need and very little dead wood hanging around, granted, people still only use the pixel primitives, but implementing better primitives is something that can be worked on.
I'm quite happy not being locked into an antient toolkit.

[ Parent ]
Nope (5.00 / 2) (#106)
by Simon Kinahan on Sat Jan 13, 2001 at 12:57:15 PM EST

If X had a single widget set the same thing would have happened as happened for the Mac and Windows. The look and feel would have been revised and made configurable while the API remained consistent to keep the software working.

As things are everyone who looks at X has the first reflex: "that looks awful" and writes yet another widget set.

Simon

If you disagree, post, don't moderate
[ Parent ]
X need die (3.00 / 1) (#95)
by 0tim0 on Thu Jan 11, 2001 at 04:12:23 PM EST

Personally, I think X was a great thing for its time, but its time has passed. Modern guis have improved quite a bit over X.

Here's where I think X falls short:

  • The API -- it's too big and complicated
  • Window manager -- hey, give me a pluggable look and feel, and an integrated Window Manager
  • Lack of a real standard gui framework and one that looks nice
  • Configurability -- need I say more
  • Modern Gui stuff -- antialiasing lines, fonts, etc.
  • Shared memory pixamps

I know the last two are solved by extensions, but extensions are a pain in the a$$ to write for.

The real problem is that it was originally written long ago before all this modern technology was common. We need a replacement long the sames lines as X but with this modern stuff designed in.

My choice will be OS X. Great modern gui, with an X server that runs along side teh apple gui. Now we're talk'n!

Just my $0.02. --tim

rebuttal :) (4.00 / 1) (#105)
by matman on Fri Jan 12, 2001 at 09:56:56 PM EST

- The API -- it's too big and complicated

(I cant really comment on this)

- Window manager -- hey, give me a pluggable look and feel, and an integrated Window Manager

If you dont want choice, stick with the wm included by default in your distribution, or let someone else make the decision for you.

- Lack of a real standard gui framework and one that looks nice

Choose either gnome or kde and stick with the choice. Limiting yourself to one means you limit your choice of applications. If you all of a sudden introduce a new 'standard' to compete with KDE and gnome, there'll be three (primarily anyway, I recall cde, etc) options to choose from, and the newest addition will support almost no applications. This 'non standard' gui framework isnt going to solve its self overnight, live with it.

- Configurability -- need I say more

How can you have more configurability than available source code? Most window managers are highly configurable through graphical means, or through simple config files.

- Modern Gui stuff -- antialiasing lines, fonts, etc.
- Shared memory pixamps

Like you said, mostly solved.


[ Parent ]
Re: X Needs To Die (4.00 / 1) (#107)
by Girf on Sun Jan 14, 2001 at 12:21:20 PM EST

> The API -- it's too big and complicated
At least it is all documented.. (in comparsion to Windows)

The other few points:
X is not the GUI; think of it this way: Calling X the GUI is like calling the console the CLI..

Now stop being a mass produced monkey who is trying to justify using Windows on the 'fact' that everything else is inferior..

[ Parent ]

X need not die | 108 comments (108 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!