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

The Future Of XFree86

By damballah in Technology
Sat Mar 22, 2003 at 08:29:48 PM EST
Tags: Technology (all tags)

Recent news of the split of the XFree86 project have raised some questions about its future and validity.

According to this article, Keith Packard has been expelled from the XFree86 project for trying to create another project based on it. Some interesting questions that arise from this event are:

Will Packard go on with his plan? How successful can this forked project be? There have already been many successful forks. The many browsers based on the Mozilla rendering engine such as Phoenix and Camino can be thought as forks. XEmacs is also one of them, and in this letter (please scroll down), Richard Stallman clearly establishes that Xemacs was born "as a separate forked version" of Emacs, due to conflicting views between Stallman and Zawinski (the creator of XEmacs). The forking of Emacs to XEmacs corresponds more to the situation that Packard faces now, as his views disagree with the rest of XFree86's team.

This fork also raises the question of how relevant the X Window system really is. Do we need another implementation of this window system? Many think that it is at best outdated technology. Why not develop a single windowing system for Linux that fully takes advantage of the latest hardware? While this seems to be the best solution, one must not forget that thanks to X, one can run many window managers within a single operating system (KDE, GNOME, etc in Linux). Thus it provides many choices, not limiting the user to a single window manager.

Some people also suggest that the X Window protocol is not outdated at all, and that poor implementations (such as XFree86's) have contributed to give it a bad name. This fork might lead to a cleaner, more modern implementation of this windowing system, thus extending X's lifetime. Also, replacing X would mean sacricifing its good parts for pretty much nothing since one would have to design another abstraction layer from scratch.

Among other things, Packard complains that the XFree86 team employs an outdated development model. It is thought of as slow and unfair to driver makers. How can the XFree86 people change their development model so that it is more dynamic?

According to Packard: "XFree86 is not currently a friendly place to play." Alan Cox agrees that it's hard to join the project. David Wexelblat offers an explanation to these accusations. According to him, poor commercial support is partly to blame. In a forum about Packard's expulsion, he says that "Rather than venting forever at David Dawes and XFree86 not having a tracking system, why not just shut up and pay someone to do it?" This is a valid point, since the primary focus of the volunteers is on taking care of the code. Either they need more volunteers or some commercial company might set it up.

If it is only a matter of finding more volunteers, why is it so hard for people to get involved in XFree86 and how can that change? Wexelblat thinks that it is because of the XFree86 people's focus on meritocracy and individual contributors. Gaining a respectable status requires a lot of hard work and dedication. The nature of the XFree86 company is fairly secretive, and Wexelblat thinks it should remain that way:

- There is no reason for XFree86 BOD matters to be public. The XFree86 Project, Inc is a privately-held corporation.
- There is no reason for Core Team matters to be public. This is the leadership forum, not a public forum.
- There is no reason to change the meritocracy, other than to work on promoting sufficient people through it, of sufficient skill/quality/integrity to get the work done.

This split raises some valid concerns about the management of XFree86 and if addressed well, might reinvigorate the evolution of this project.


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


Related Links
o this article
o Mozilla
o Phoenix
o Camino
o XEmacs
o letter
o X Window
o X Window protocol
o a forum
o Also by damballah

Display: Sort:
The Future Of XFree86 | 184 comments (150 topical, 34 editorial, 0 hidden)
Forking X (2.30 / 10) (#7)
by Pac on Fri Mar 21, 2003 at 02:56:13 PM EST

Maybe we should discuss the convenience of forking the whole X mess to dev/null and develop something modern from scratch. Maybe even something where servers are servers and clients are clients.

Evolution doesn't take prisoners

Then again (4.40 / 5) (#12)
by Znork on Fri Mar 21, 2003 at 03:11:46 PM EST

Maybe we shouldn't since there is no actual problem with X.

To understand X terminology you need to understand the concept of a server. Until you understand that a server provides access to resources (in the case of X, display and input resources), and a client is something that uses those resources (to get input and display it's output) you will have trouble with that. Labelling the parts of a network capable display protocol differently would be inconsistent with accepted computer terminology.

[ Parent ]

I hope you noticed the irony (3.25 / 4) (#16)
by Pac on Fri Mar 21, 2003 at 03:26:13 PM EST

I know exactly why the components of X are called the way they are. But the average user doesn't.

And I won't discuss the statement "there is no actual problem with X" because I am really in no mood for a flamewar that is exactly where this discussion leads.

Evolution doesn't take prisoners

[ Parent ]
X (3.66 / 6) (#20)
by Znork on Fri Mar 21, 2003 at 03:59:49 PM EST

Then again, there was a time when 'the average user' couldnt tell the difference between 'computer' and 'monitor'. That is no reason to change the correct terminology. 'The average users' are not stupid. It is merely a reason to educate the users, and a reason to use terminology they understand a bit better when talking to them, and explain the concepts if you absolutely have to get into them.

If you're not in the mood for a discussion around what issues you have with X, why did you bring it up? I'm genuinely curious, because most arguments I've seen criticising X are criticising it because of lack of understanding regarding how it works. The lack of some features, which is not a problem with X, as recent implementation of several of them has shown. Or the belief that as X is a networked system, it always goes over the network, which isnt the situation in reality.

If you think there's a problem with X, what is it, and are you sure it hasnt been adressed already? It has to be a fairly serious problem to advocate throwing almost two decades of learning and development out the window and start from scratch.

[ Parent ]

You're absolutely right. (2.20 / 5) (#18)
by tkatchev on Fri Mar 21, 2003 at 03:47:01 PM EST

X was designed to suck right from the start.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Reports of X11's death greatly exaggerated (none / 0) (#129)
by phliar on Sun Mar 23, 2003 at 04:39:05 PM EST

... the convenience of forking the whole X mess to dev/null and develop something modern from scratch.
Talk is cheap. It's been my experience that everyone who talks about how X11 is crappy or slow or whatever just doesn't have the background or expertise to make that judgement. On what basis are making this statement? Are you designing a replacement? I want actual features that I use everyday, rather than your opinion of what the words server and client mean.

When you design the replacement for X11, make sure you consider network transparency (absolutely invaluable for serious work), device and OS independence (SunOS, Solaris, *BSD, Linux, Windows-NT), and protocol extensibility (font servers, SHAPE, shm, DGA, XVideo etc.).

One place to start your research might be , the window system for Plan 9.

Faster, faster, until the thrill of...
[ Parent ]

Fresco (3.80 / 5) (#8)
by lb008d on Fri Mar 21, 2003 at 02:59:41 PM EST

Maybe this will help Fresco gain some momentum.

Questions (3.00 / 1) (#43)
by llimllib on Fri Mar 21, 2003 at 07:30:02 PM EST

Can you actually do anything with fresco yet? Will all the drivers for X have to be rewritten to work with fresco? Has anyone actually tried goofing around with it?

[ Parent ]
Fresco has been dead for years (4.00 / 1) (#45)
by HidingMyName on Fri Mar 21, 2003 at 08:01:45 PM EST

I tried to learn Interviews and Fresco in the Mid 1990's and those guys were always so busy being the "next big thing" that I gave up waiting for documentation. Sure they had some toys and proof of concept stuff, but they never really bit the bullet and did the kind of stuff that is needed for wide spread acceptance. Maybe they'll do something, but TrollTech and the Gnome folks ate their breakfast as far as I can tell.

[ Parent ]
Check them out again (4.83 / 6) (#84)
by fluffy grue on Sat Mar 22, 2003 at 07:48:20 PM EST

I was absolutely certain they were dead and vaporware, but a few months ago someone told me to check out the site again, and it looks like they're actually making real progress now. Like, actual applications (including an X server). It's still very conceptual, but it's a much firmer concept than it used to be, and they're also pushing towards a semantic UI, which is something I'm a huge proponent of.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Fresco: FAQ rebuttal (5.00 / 1) (#133)
by kmself on Sun Mar 23, 2003 at 05:48:04 PM EST

I'd originally posted this elsewhere but think it's apropos here (lightly adapted).

Note that I'm not an X or graphics developer. I have watched SW development, and free software development in particular, for years. Observations are based on what I've noted of successful and unsuccessful projects over the years. From what I can see, Fresco doesn't have what it takes. Fluffy Grue could probably speak to some of the technical issues I raise.

Some point out the Fresco project as an alternative to X. Taking a look at the Fresco v. X FAQ , I'm pretty underwhelmed. Well, not completely. They do use a Wiki....

1 Consistent user interface policy

One of the problems with the X Window System's flexibility was the accumulation of several inconsistent GUI toolkits. New users are often puzzled, when they see that their Netscape window looks different than their Gimp window, which in turn looks different than the rest of their KDE desktop.

Fresco takes care of the user interface by itself without calling upon the use of GUI toolkits to render buttons, menus and scrollbars. This way, all widgets in the applications on the desktop look alike. Eventually, Fresco will support theming, which will be truly universal theming.

This is the old "interface consistency" chimera. Several problems:

  • Interface consistency comes from one source: imposing an interface on all apps, regardless. E.g.: no choice. For instances of this, see Mac OS/X and legacy MS Windows.
  • Of course, consistency means that there's no support for alternatives. Which means that you don't have support for legacy apps built to other toolkits.
  • ...unless, that is, you provide backwards compatibility. In which case you're back to square one: the interface isn't consistent, so long as legacy apps (and newly emerging toolkits) are supported.
  • Meantime, the problem with the "single approved method" solution is that opportunity for experimentation and initiative, or dare I suggest innovation, are reduced. Multiple toolkits means different methods, presentations, mechanisms, etc., can be explored. Including the whole ORB vs. API interface issue.
  • Even the platforms with "GUI consistency" (why does that phrase make me queasy?) don't. legacy MS Windows is burdened with, well, legacy MS Windows GUI toolkits. Not to mention a set of new apps which ignore the system toolkit to provide their own. In one case encountered recently, itself a clone of the system GUI...if you're running WinXP, though it looks oddly out of place on Win2K, or with "Classic" themes applied in XP. Mac's got its Aqua/Cocoa issues.

Conclusion: Fresco either can't deliver on this promise, or presents a worse situation if succeeds, failing the compatibility requirement in the process.

2 Alpha transparency

An often wanted feature of XFree86 has been support for true alpha transparency. The Free Software community has worked around this limitation in various ways from copying the background image into the X terminal to a very alpha translucent GTK+ theme. The Enlightenment window manager has been able to achieve the translucent moving of windows. But real alpha transparency has yet to be added.

Fresco has alpha transparency today. You can see this on Fresco's screenshots page.

Note that they're transparent windows, not just the background image - generally, Fresco's architecture allows for anything to be transparent, from a single widget to the entire desktop.

OK, color me stupid, but how the hell does Alpha transparency rate as the number two argument in favor of Fresco? I could give a f---. I really could.

As Fresco itself admits, there are hacks in X to support transparency. Several in development. Googling doesn't indicate whether or not this is something that can be readily supported without major architectural hacks. Still, a graphics hack of limited utility is hardly a reason to toss an entire, working, debugged, entrenched graphics subsystem.

3 Resolution Independence

Most current graphical enviroments are pretty much pixel-based. Each window is so-many pixels high by so-many pixels wide. This is why, when you up the resolution of your environment, all of your windows shrink, giving you more room. Then the user changes the size of the fonts used for text so that he or she can read everything clearly.

In contrast, Fresco uses vector-based drawing and supports arbitrary linear transformations of the desktop. This means, in part, that the desktop can be scaled to any size the user wants. This makes pixel-based units more or less meaningless. Fresco uses common sense laymen units for sizes: inches, centimeters, or millimeters. This guarentees that the size of an object on a 15 inch screen is the same as its size on paper, which is the size of an object on the big viewscreen at NASA (assuming someone ported Fresco over). Thus users would be compelled to use the highest resolution/color depth possible for the visual quality rather than for the space on their desktop or the size of the text.

Seems to me this is the sort of thing which can be handled in a desktop environment, handling the translations for the user. With reporting of properties from smart monitors, probably trivial.


One of the big problems with resolution independence in X is that nobody cares.

Couldn't 'a said it better myself.

4 Programming Language Independence

Fresco achieves programming language independence by exposing its API through CORBA. Any language that has bindings for the ORB can be used to create Fresco applications.

...meaning the ORB model has to be embedded into each programming language, as opposed the the X11 API. Yawn.

There are enough implementations of the X API that the programmer isn't restricted to any particular programming language. Or scripting tool. The work's been done. Fresco, by contrast, would require additional work to develop both the API and train developers.

5 Network Transparency

Like the X Window System, Fresco provides network transparency.

Great! We can tear out all the plumbing to have...the exact same functionality. This isn't an improvement, it's a lateral move.

The difference is that Fresco uses CORBA for network transparency while X Window System uses the X Protocol which is much lower level. So where Fresco transmits the creation request for a button and click events on that button, X transmits the look of the button each time it gets moved/redisplayed after being obscured by another window plus all events that happen inside the window the button is displayed in.

...so not only is it a lateral, it's a backwards-incompatible lateral. Unless X protocol events are also supported. In which case you might want to look over the uniform interface discussion above.

5.1 Alternative Explanation:

Like the X Window System, Fresco provides network transparency. Fresco accomplishes this by using CORBA for network communications, while the X Window System uses the X Protocol. While it has been noted that IIOP (the network protocol underlying network communications in CORBA) has more overhead than the X Protocol, Fresco still manages significant advantages.

The X Window System specifies a set of graphical operations to be provided by the server. These operations are not well suited to the modern environment of true-color displays with hardware acceleration, and most toolkits and client programs get around the limitations of X by using XSHM (X Shared Memory Extension) or similar means to perform their graphical operations local to the client or toolkit, and provide X with a bitmap to render.

Fresco improves upon this by providing a very sophisticated suite of operations on the server, all of which act on an in-server vector representation of the screen. This permits complex operations such as transparency and arbitrary transformations to be represented with single IIOP requests.

So while IIOP may have more overhead, the overlying Fresco communications will be much terser than corresponding communications under the X Protocol.

Which would be a substantial improvement...on 4mbps ethernet. GigE's got bandwidth to spare. X runs usably over 56K lines via compression and low-bandwidth proxies. For broadband (DSL and better) connections, distance is invisible for most common business needs. Issues of latency, rather than bandwidth, are more significant for most GUI response, and this can't be addressed by either bandwidth or network traffic.

Largely: network capabilities are such that this doesn't particularly matter. There are far less efficient protocols than X which run over networked connections, usably.

6 Advanced Text Features and Internationalization

Fresco has copious support of Unicode. This means that Fresco is capable of rendering all languages supported by 16-bit Unicode. In the X Window System, Unicode support is still in development with the [WWW] Pango project.

In addition, Fresco supports text operations such as kerning and ligatures that are required for non-latin-based character sets. Ligatures and kerning can also make latin-based text look better.

Improving font and characterset handling in the graphics environment would be a major plus. Unfortunately, the characterset situation is getting seriously unweildy. Original ASCII was 127 characters, extended to 256, in several incompatible encodings (thank you, BillG). With various extended byte (with various deltas on numbers of bytes) encodings, not only can't you tell what a character is without doing signifcant decoding of the bytestream itself, but the possible encodings go into the tens of thousands, if not millions. It's a mess.

And dumping this mess into the middle of the graphics subsystem is the Wrong Place To Put It.

Put characterset handling in its on separate module. Let that module talk to the graphics subsystem. We're going to trash this whole thing several times, and the less collateral damage the better.

Oh: and I'm completely ignorant on most of this, I'm parroting bits recalled from bookstore conversations with folks involved in Asian charset projects with HP, and some of Larry Wall's discussion from various Perl docs and State-of-the-Onion speeches.

7 Device Independence

Fresco's API was designed to allow you to separate presentation from content. Taskets, which still need to be defined, will leave the rendering up to the server, so that the same application can be used on a palm pilot, printed onto a printer, spoken to a blind or hands-off user or rendered in true 3D. Those with low hardware resources may choose to use the application on a text terminal. All this is blue-sky at the moment.

What Fresco does provide today is resolution independance (see above), allowing it to render the same content with good quality on a wide range of display / print devices. In comparison, try to run X [apps] with a 1200 dpi display :).

This is blue-sky today and will be blue-sky in a century. Device-independence in a GUI system isn't something that can be extended to bitmapped to full-screen text to interactive line mode to text-to-speech devices. GUI apps are fundamentally interrupt driven. Audio environments are principally batch-mode one-dimensional -- and that dimension is time.

It's possible that a single toolkit could assist in this process. It's also more likely that providing a backend-frontend design based on toolkits specifically tuned to the needs of each environment.

Another misguided aim of Fresco.

8 Threading

Responsive UI, Scalability etc.

See sections "Pervasive Multithreading" and "Multithreaded User Interface" of the [WWW] BeOS Whitepaper for a description of the advantages.

Sure. When I get a round TUIT.

9 Structured graphics

The most radical difference of Fresco to X is how the content of the display is created by the applications. It would go too far to explain it here, check out ArchitectureQuestions , especially question "What's the relationship between Fresco and TheFrescoProject? What is Fresco, anyway?" and the other documents referenced at the top of that page.

Again, it would be more compelling to describe the benefit succintly here.

10 And if that doesn't convince you...

...see http://lcamtuf.coredump.cx/evilfinder/ef.cgi?said=X+Window+System.

Sigh. Good thing programmers don't moonlight as comics...

11 Conclusion

Fresco has been in development for five years. When Berlin 0.1 was released (3 years ago), much of the code had been rewritten and the design has been completly revamped. In other words, this time it's for real . We have more in common with Fresco nowadays than with Berlin 0.1. The terminal marked the release of Berlin 0.2 and its first useful application.

So, what we've got:

  1. Four misguided, useless, or specious benefits.
  2. One lateral. Without backward compatibility.
  3. Possible internationalization benefits.
  4. Another unfulfillable, misguided benefit (device independence).
  5. Two unarticulated benefits.
  6. A bad joke.
  7. Five years' development.

Well, at the very least, I would hope that in another five years we've got a good joke.

I see few if any real concerns addressed by any of this, much complexity, and a lot of pie-in-the-sky.

Wager: Fresco's dead. $100 says it won't be signficantly used in ten years.

Is it useful? Yes. You're suprised? Well: Berlin, Fresco, and similar projects are a good way to explore various concepts and features. I expect most of these will be rolled back into X11, or an X11 replacement (I'm not saying X won't be replaced, but it's going to be a tough sell). As it stands, Fresco's an iceball in a hot low point, with commensurate chances.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Since you asked, what interests me about Fresco: (5.00 / 3) (#138)
by fluffy grue on Sun Mar 23, 2003 at 07:30:33 PM EST

I pretty much agree with you in your assesment of Fresco, except that they seem to be moving in the direction of a semantic UI (where the interface is designed semantically and can adapt to different environments more or less seamlessly). Of course, a semantic UI doesn't require a completely new windowing system, and would preferrably be done using some sort of XML-based toolkit or something.

Anyway. It would be nice if X11 had a way of encapsulating higher-level widgets, but I don't really see it as that necessary (like, X protocol for sending the low-level device-level information probably takes about the same overall bandwidth as Fresco protocol for sending the high-level widget events), and yeah, I agree with the whole look-and-feel issue (and semantic toolkits would totally solve that problem as well).

And alpha blending and anti-aliasing has already been solved, through the X Render extension, which basically takes the useful subset of OpenGL blend and AA operations and maps them to extended GC stuff in Xlib (and IIRC the extended GC still works with normal X drawables). The problem with X Render is just that it's never really gotten past the proof-of-concept stage.

Actually, I'd be interested to see an X server implemented in OpenGL. There's no reason it couldn't be done, and it'd instantly have all of the supposed benefits of Fresco (and implementing X Render would be much simpler) and also have some useful side-effects, such as automatic visual conversion (one of the more annoying aspects of X11, insofar as I've never seen a server which will actually convert colorspaces for you, even though the protocol allows for it to an extent).

BTW, Fresco == Berlin == Y Windows. They love themselves some name changes. The way you worded things made it sound like you weren't aware of that. :)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Audio v. video & Jakob Neilsen (none / 0) (#184)
by kmself on Sat Apr 12, 2003 at 08:19:54 PM EST

Just a coda to my comment that device independence is pie-in-the-sky when it comes to video vs. audio interfaces. See Alternative Interfaces for Accessibility (useit.com):

The key difference between user interfaces for sighted users and blind users is not that between graphics and text; it's the difference between 2-D and 1-D. Optimal usability for users with disabilities requires new approaches and new user interfaces.

It's a design problem. Not an issue that can be addressed with a toolkit.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Yes, I hope so (3.00 / 1) (#148)
by drquick on Mon Mar 24, 2003 at 04:55:47 AM EST

Fresco would be an awesome API improvement over X11R6. The advantage with OSS is that a major port of existing codebase to Fresco is possible. I don't think Fresco is dead. It would be enough to port GTK+ and Metacity to Fresco. XFree86 has great HW support but a lousy API. I'd like to see Fresco really shake the X11 clergy!

[ Parent ]
From someone who's tried to get involved: (4.75 / 20) (#13)
by fluffy grue on Fri Mar 21, 2003 at 03:12:12 PM EST

A big problem is that there's a lot of rampant elitism. They don't want patches from people who haven't contributed significant amounts to the codebase, but the way to get recognized is to submit patches! (My specific issue is that I wanted to fix one stupid little bug in the Radeon driver, but there was no documentation aside from what was under NDA, but since I wasn't willing to fix bugs in parts of XFree which I don't use and nobody else thought this bug was important, I ended up trying random stuff in the driver before I finally gave up and just bought a newer Radeon with vendor-supported drivers.)

Combine this with the fact that a lot of the code really isn't all that good, but it's all held true-and-dear, and that XFree itself is so horribly monolithic.

XFree's strength is that it has a lot of pretty good video drivers and a decent architecture for hardware acceleration (both in 2D and 3D). Its weakness is that the drivers are tied to X11.

From a user perspective, the primary problem with XFree is that configuring devices is a major pain in the ass, especially if you have multiple pointers such as tablets and joysticks and so on (especially on USB).

Personally, I'd like to see "XFree" turn into a microkernel of sorts, which delegates messages between various drivers and devices and so on. Have a nice input layer which is designed for sending input messages to the kernel, have a protocol layer which handles communication with user interfaces (and have different layers for various protocols, such as X11, VNC, Fresco, Windows Terminal Server, etc.)... while we're at it, why not finally make audio part of X11? There's already extensions for that, so why not support them, instead of further promoting the extreme crappiness of esound?

By modularizing things, then XFree can finally become a decent platform for a modern operating system, and not something which is just "good enough" in its backwards compatability.

I see no reason to throw out X11, but I also see no reason to be limited by it. And IMO, X11 is "good enough" for the most part, but there's no reason to have everything bundled into a single process with a single codebase where you have to totally recompile everything just to update, say, the Wacom driver.

Also, by modularizing things, it'd make it much friendlier for embedded systems and so on because you could just support, say, embedded Qt as the sole "protocol" and only have to worry about including drivers for your stylus and so on.

Oh, and it'd make it easier to put in support for more exotic hardware, such as
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators


other disadvantages (2.50 / 6) (#21)
by zzzeek on Fri Mar 21, 2003 at 04:05:35 PM EST

that it is slow as shit, uses a ton of memory, and is not particularly stable.

[ Parent ]
Not really (4.28 / 7) (#25)
by fluffy grue on Fri Mar 21, 2003 at 04:40:15 PM EST

I find XFree to be far more responsive than Windows XP or MacOS X (of course, it's hard NOT to be more responsive than OSX), and it really doesn't take that much memory on its own. Most of the "memory usage" shown on PCI and AGP graphics cards is where it's actually mapping the card's memory into its own address space, which makes the address space larger (but doesn't actually boost the system RAM usage).

It is definitely bloated, though, but its actual memory usage at any given time is pretty minimal.

Oh, and another thing I forgot to mention in my rant above: XFree's font management FUCKING SUCKS, especially with how you actually have to restart X to install a new font (and even figuring out how to install it can be a complete pain in the ass, and the various distribution-specific font managers such as defoma seem to only add more complexity without actually resolving the problems). It's not a limitation of the X11 protocol (like, theoretically, at worst you would only need to restart xfs, but restarting xfs without restarting XFree just makes it go wonky), it's a limitation of their broken implementation.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

ohyah, fonts, did they ever add anti-aliased? [nt] (4.00 / 4) (#30)
by zzzeek on Fri Mar 21, 2003 at 04:59:40 PM EST

[ Parent ]
Sort of (4.75 / 4) (#32)
by fluffy grue on Fri Mar 21, 2003 at 05:08:29 PM EST

There's no AA support in X proper, but there's a common truetype rendering library which does it client-side, which makes it take up a fuckton of bandwidth if you're running it remotely. The X Render extension was supposed to address AA issues, but that seems to be in permanent vaporware stasis.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

ya see ? X sucks :) [nt] (3.00 / 2) (#33)
by zzzeek on Fri Mar 21, 2003 at 05:10:44 PM EST

[ Parent ]
Not really (5.00 / 4) (#34)
by fluffy grue on Fri Mar 21, 2003 at 05:14:58 PM EST

That's what extensions are for. MIT-SHM and GLX and so on are great and have been around for a while and seem like a natural part of X (even though they're only incrementally-available). The problem with XRender isn't that it's an extension to the protocol, but that it's never been finished up or made useful.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

fine, XFree proper doenst suck... (3.75 / 4) (#36)
by zzzeek on Fri Mar 21, 2003 at 05:19:07 PM EST

but the point is, features that are standard for the rest of the world are not pre-configured into it, and the extensions to allow the desired behavior are difficult and/or not completed.  from a bottom line perspective (i.e., not can it do it, but does it do it without any effort), this is the kind of thing that causes a project to become irrelevant and fracture into smaller projects that eventaully disappear.

[ Parent ]
No, XFree proper does suck (4.80 / 5) (#37)
by fluffy grue on Fri Mar 21, 2003 at 05:30:01 PM EST

X11 as a protocol does not. XFree != X11; XFree is an implementation of X11.

In any case: extensions are the best way to handle things. The software can fall back if the extension is not available, and later protocol versions will assimilate the extension into the protocol proper. (This happens with OpenGL all the time, for example.) Also, in a proper architecture, the extension wrangling will happen at a higher level; for example, in theory, GDK (the underlying drawing abstraction for GTK) would use XRender if it's available, and client-side software-rendering if not.

The idea in X11 is to have an intermediate layer of abstraction on top of it. X11 is the underlying low-level protocol, and it's up to the toolkits (not the applications) to manage the extensions and talking to X11.

So, with the assumption that the toolkits are updated to take advantage of the extensions, then all applications using those toolkits are updated automatically, and will use the extension if it's available (but if it's not available, it won't).

In theory, all that XFree needs to do in order to support a protocol extension is for someone to write a module which implements it (and propose whatever changes have to happen at the driver interface level). In practice it's not so simple.

But X11 as a protocol handles these issues perfectly well. It's the XFree implementation of X11 — or, more accurately, the attitude of the core development team of XFree in terms of how to actually develop XFree — which sucks.

"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

What's not complete for RENDER (4.00 / 1) (#114)
by tzanger on Sun Mar 23, 2003 at 07:50:31 AM EST

What's not complete in the RENDER extension? As for a "fuckton of bandwidth" -- that's what compression's for. X11 and ssh -XC were designed for each other.

[ Parent ]
The reference implementation was never finished (4.00 / 1) (#121)
by fluffy grue on Sun Mar 23, 2003 at 12:28:31 PM EST

The protocol extension itself is great, but so far as I can tell it's never actually been fully implemented except to the point of saying, "Hey, here's a proof of concept. Look at the pretty alpha-blended triangle!"

Compression can't do a lot to anti-aliased text, and it's still a lot less efficient than just sending the character string, especially when working with big fonts. Also, doing it in software makes it rather slow. Also, you have to keep in mind that a lot of text operations go to server-side drawables (such as Pixmaps), and so if you want to do client-side rendering you have to do a horrible round-trip where you copy the entire server-side drawable to client-side space, do the client-side rendering, and then send it back to server-side. Even when you're running the client and server on the same system this really sucks, speed-wise.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

xft2 / RENDER (none / 0) (#162)
by alge on Mon Mar 24, 2003 at 07:20:07 PM EST

quote fontconfig.org:
The current version of Xft (2.0) provides a client-side font API for X applications. It uses Fontconfig to select fonts and the X protocol for rendering them. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers.
.. wouldn't that suggest that it actually uses serverside rendering if it can?

vi er ikke lenger elsket her

[ Parent ]
Yes, that would (5.00 / 1) (#163)
by fluffy grue on Mon Mar 24, 2003 at 08:15:02 PM EST

And in that case, xft2 does it the Right Way. But it still requires an actual implementation of Render. :P
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

compression overhead / latency (none / 0) (#161)
by alge on Mon Mar 24, 2003 at 07:16:42 PM EST

My poor celeron 300 serverthingie doesn't like compressing 10mbit/s, and I guess the thin clients at school don't like uncompressing it either. Never bothered to scientifically check the latency though... For what BWs/MHz is compression actually positive?

vi er ikke lenger elsket her

[ Parent ]
I don't think that's your bottleneck. (none / 0) (#178)
by tzanger on Wed Mar 26, 2003 at 03:00:47 PM EST

A Cel/300 should have absolutely no problem doing that, as you're not doing it at 10mbps (I'd be surprised if it's sustained at all), and I'm also pretty sure that you wouldn't be using gzip -9 for it... gzip -1 is more than enough to take the bulk of the edge off. You say you haven't done benchmarks, so how can you be sure that your cel/300 doesn't like it? My P2/233 seems to have no issue with it at all.

[ Parent ]
I really doubt gzipping ssh works wonders.. (none / 0) (#181)
by alge on Tue Apr 01, 2003 at 09:35:51 AM EST

quote man ssh:
Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP/IP connections). The compression algorithm is the same used by gzip(1), and the ``level'' can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option.
Also: I ran time gzip -1 on a divx, it ran at about 0.95MB/s. Add the overhead of encryption, and you get a fairly stressed cpu.


[ Parent ]
Um, "xset fp+ fontpath; xset fp rehash"? (4.50 / 2) (#91)
by _Quinn on Sun Mar 23, 2003 at 01:22:49 AM EST

Works fine for me.  No restart involved.  (XFree86 4.1, with the sucky have-to-make fonts.scale and fonts.dir manually stuff.  4.3's supposed to eliminate that.)  Did I miss something?

- _Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]

Oh, huh (3.00 / 1) (#94)
by fluffy grue on Sun Mar 23, 2003 at 01:28:37 AM EST

I never knew about the fp option to xset. I'd always just restarted xfs (which is what all the docs said to do when installing new fonts), which always made the server go apeshit.

So, that's more of a documentation problem with XFree than an implementation problem. Thanks. :)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

No problem. (4.00 / 1) (#96)
by _Quinn on Sun Mar 23, 2003 at 01:40:31 AM EST

It's just that X has enough problems without inventing ones. ;)  (Just be careful to append  (fp+, not +fp) directories to your fontpath; otherwise, a font specifier might suddenly mean a different font.  I'm not sure if it would cause X to go apeshit, but it's probably worth avoiding.)

- _Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]

Old rant (5.00 / 1) (#113)
by tzanger on Sun Mar 23, 2003 at 07:49:04 AM EST

You do not need to restart X to have new fonts come up, at least not in 4.3.x. fontconfig does this for you on the fly, just as cursor changes now do as well.

And RANDR lets you (finally) resize the screen a la Win32.

Yes, X11 is taking its sweet-ass time, but it's fast and stable and 100% network transparent, which is something you just can't say for anything from the win32 camp (not that you were claiming that).

[ Parent ]
XFS (4.00 / 2) (#117)
by miah on Sun Mar 23, 2003 at 12:08:02 PM EST

As to my knowledge you don't have to restart X to get new fonts under 4.2 either. Use XFS and when you add fonts to your font directory just reload (not restart, that'll crash X) your font server.

Religion is not the opiate of the masses. It is the biker grade crystal meth of the masses.
[ Parent ]
Yes, and as I replied to the other response: (4.00 / 1) (#122)
by fluffy grue on Sun Mar 23, 2003 at 12:30:00 PM EST

I never knew about the mechanism for telling X or XFS to reload the font path, and all the documentation I'd read in my 12 years of using UNIX had always indicated that I just need to restart things. Poor documentation is probably the second-biggest problem wtih XFree86. :)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Disadvantages (4.66 / 3) (#29)
by Znork on Fri Mar 21, 2003 at 04:54:36 PM EST

Slow? Can you clarify?

Uses a ton of memory? If you're referring to the size you see in top or other memory monitoring programs it includes things like graphics card memory, large chunks of mmaped io regions, some or all graphics like bitmaps from applications, etc. That's a problem with memory reporting tools, not with X. It just looks huge, while in reality it isnt very large at all. X itself can be run on PDA devices, which notably do not have very much memory.

If you're having stability problems with X you either have a really bad driver, or maybe a computer with the good old speculative write bug. I'm running it for month on end on without having to log out-log in cycle.

[ Parent ]

XFree86 uses tons of memory? (5.00 / 1) (#165)
by dasunt on Mon Mar 24, 2003 at 09:27:31 PM EST

The parent post states that XFree86 uses tons of memory. So, lets see what my system thinks:

First off, the environment: Debian stable (woody), XFree 4.1.0.

To do this test, I just did "top", then hit M to sort by memory usage, then looked for XFree86. Size of memory usage would be in 16092, or roughly 16 megs. Lets put this in perspective - galeon-bin uses 24M, roughly.

Quite frankly, I don't consider X bloated. As for slow, its speedy enough on my pentium 166 (80M of memory), and I've seen it usable on a 486 100Mhz machine (64M of memory). For stability, I haven't seen X crash in a long time, but I don't tend to buy cutting edge video cards with buggy drivers, or crappy hardware.

Now I'm not an expert at the X protocol, XFree86, nor video cards, but from my perspective, X seems to get blamed for a lot more then it deserves.

[ Parent ]
NDAs - the roots of all evil ;) (3.00 / 1) (#135)
by qbwiz on Sun Mar 23, 2003 at 06:37:49 PM EST

there was no documentation aside from what was under NDA
I've often heard that many of the problems with XFree86 development were caused by these NDAs.  Something about the fact that because you need an NDAs, an elite group of core developers are necessary to sign them and get things done.  This, of course, locks out other people, but there's nothing the core developers can really do to help them.

[ Parent ]
XFreeDesktop86? (2.00 / 1) (#172)
by damballah on Tue Mar 25, 2003 at 01:28:02 AM EST

i hope this makes sense - From a user's point of view, shouldn't there be a subset protocol called XDesktop that provides all the eye-candy, etc? cause no matter how u rewrite/implement X, its first purpose was to display graphical applications over an entire network, not applications on a pc. it was not concerned about playing 3d games and all that stuff that the home user loves so much, because the home user was not the target audience. it was a simple tool for the tech/scientific world that was very flexible. so flexible that the home user could use it for fun. fun as in when he had time to kill, really

so maybe the less painful way to improve X for the desktop is to create a new subset adapted to the home-user market. i'm hoping that that's what Packard does. of course i have no idea how he can achieve that, so anyone w/ suggestions is welcomed to make some. also no need for him to shun XFree86 people, they've been around and they will be around for a long time. their implementation of X is the most widely used and besides, it's already there. now i hear that their code is not gpled so that might be a problem...

" I apologize for this long comment. I didn't have the time to make it any shorter. " - Blaise Pascal

" zombie accounts promote an unhealthy interest in the occult among our younger readers. " - [ Parent ]

it raises valid concerns about OSS in general (2.00 / 34) (#14)
by turmeric on Fri Mar 21, 2003 at 03:13:05 PM EST

the people who run it are arrogant bloated ego freaks who love control and power. they couldnt understand democracy if they read everything ever written about it. their whole attitude is that 'we are the smartest so we decide everything'. even when users tell them their product sucks and doesnt work as advertised and is of shitty quality. the OSS people continue with their dismissal of any criticism , because after all they are the smartest and got beat up in school alot so why shouldnt they be the natural rulers?

every single last OSS project works exactly like this. the so called 'meritocracy' is actually a cluster fuck population contest to rival the worst junior high school love triangle. and the end result is that it has nothing to do with 'merit' of anything and has everything to do with ego and reputation.

these splits dont serve the users. these splits are because programmers are constnatly trying to prove how big their cock is compared to other programmers. they dont give a shit about the users. they just care about fighting amongst themselves.

what we need is a way to end this feudalistic bullshit system. we need a democratic system for governing open source software, where the patches and direction of the project are decided BY THE USERS, not by some little elitist cabal of assholes who cut themselves off from the rest of the world and obsess over each other like 5th graders fighting on a playground.

Sometimes it makes me shiver (4.50 / 4) (#23)
by Rogerborg on Fri Mar 21, 2003 at 04:17:35 PM EST

Thinking what you might do if you ever choose to use your powers for evil.

"Exterminate all rational thought." - W.S. Burroughs
[ Parent ]

I'm not sure what you mean by (4.00 / 1) (#31)
by 5pectre on Fri Mar 21, 2003 at 05:04:21 PM EST

a cluster fuck population contest

But as far as I can see, it works on whoever is the best coder or has contributed the most code, besides, if you are unhappy you can always fork it.

"Let us kill the English, their concept of individual rights might undermine the power of our beloved tyrants!!" - Lisa Simpson [ -1.50 / -7.74]

[ Parent ]

wow (4.00 / 6) (#47)
by martingale on Fri Mar 21, 2003 at 08:53:25 PM EST

a cluster fuck population contest
Imagine a Beowulf cluster of these...

[ Parent ]
it is decided by users (5.00 / 2) (#136)
by ryochiji on Sun Mar 23, 2003 at 06:43:13 PM EST

>direction of the project are decided BY THE USERS

It is. Because every user has the right to modify the code to exactly suit his or her needs. If you don't like the direction a project's going and the developer won't listen to you, you switch to a different one, or modify it so that it is going in the direction you want.

You make it sound as if developing OSS is a responsibility or something. It's not. Developers do it for themselves, and if it happens to help others, great. If not, that's fine too. Whether or not developers listen to users, and to what degree, is solely up to their disgression. If you have a problem with that, look for a different project or start your own (or pay someone to write it for you).

With my own project (see sig) I try to listen to users as much as possible, within reason. But it still pisses me off when users approach me as if I have an obligation to do what they ask (fortunately, this doesn't happen very often).

IlohaMail: Webmail that works.
[ Parent ]

XFree86 is Dead (2.00 / 15) (#15)
by egg troll on Fri Mar 21, 2003 at 03:15:27 PM EST

Now that Apple has created Aqua to run atop FreeBSD, I'm baffled why people continue to use XFree86. Sure, I can understand maintaining it as people transition to the Quartz engine but further development strikes me as rather pointless.

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

Except (4.50 / 4) (#26)
by kjb on Fri Mar 21, 2003 at 04:44:26 PM EST

that Aqua wasn't created to "run atop FreeBSD", it was created to run on a Macintosh. It is tied to the Mac's hardware and ROM.

Now watch this drive.
[ Parent ]

That's a common misconception (2.12 / 8) (#27)
by egg troll on Fri Mar 21, 2003 at 04:52:40 PM EST

However, Aqua was designed to be an abstraction layer between the FreeBSD layer and the "Darwin" layer.

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

[ Parent ]

What FreeBSD layer? (4.00 / 8) (#38)
by buck on Fri Mar 21, 2003 at 05:37:13 PM EST

Aqua is just the UI running above Quartz running above Darwin. Darwin is the Unix-like core based on NetBSD and FreeBSD code, but it is not FreeBSD. There is no FreeBSD layer.

“You, on the other hand, just spew forth your mental phlegmwads all over the place and don't have the goddamned courtesy to throw us a tissue afterwards.” -- kitten
[ Parent ]
Close (2.66 / 3) (#85)
by G hoti on Sat Mar 22, 2003 at 08:46:14 PM EST

The kernel is a mach (3 based?) kernel. The graphical end talks to it and runs atop it. Quartz is  the rendering system that has all the fancy vector/3d/eye candy stuff. Quartz Extreme is an alternative display engine that does Quartz work with the 3d card.

The FreeBSD *system* that everyone keeps talking about is an optional subsystem included. When you boot darwin it will start up into freebsd *system environment* I forget which version though. When you boot up osx you also boot into this FreeBSD layer however this is totally optional, Its basicly on the same level as Aqua in terms of layering of the system


[ Parent ]

That is irrelevant (4.40 / 5) (#40)
by BlackFireBullet on Fri Mar 21, 2003 at 06:32:22 PM EST

Aqua/Quartz are tied to Apples hardware, as Apple will not release the code, nor binaries for an x86 system, thus it is not a viable alternative, because many of us still want to use x86 hardware.

[ Parent ]
But it *is* opened (1.28 / 7) (#46)
by egg troll on Fri Mar 21, 2003 at 08:45:03 PM EST

...as Apple will not release the code...

Please. Apple has already released the code as part of the Darwin project. Simply because X86 coders are too lazy/ignorant/pretentious to port it to their platform is no reason to blame Apple.

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

[ Parent ]

Really? (3.00 / 1) (#48)
by BlackFireBullet on Fri Mar 21, 2003 at 09:02:26 PM EST

I was under the impression that Aqua/Quartz would remain closed source, as they are the major additions that OS X brings to UNIX.

I am still skeptical though, as I have not seen any trace of the source code anywhere else, nor have I heard any mention of it. Would you be so kind as to point me in the direction on the source, or a webpage that details the source's release?

[ Parent ]

Google is your friend (2.25 / 8) (#50)
by egg troll on Fri Mar 21, 2003 at 09:53:28 PM EST

If you Google for "Darwin" and "OS X" you should find what you're looking for.

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

[ Parent ]

Darwin != Aqua/Quartz (4.60 / 5) (#58)
by BlackFireBullet on Sat Mar 22, 2003 at 02:51:29 AM EST

I did spend a fair while searching that page before I asked my question the first time, as I am capable of using google.

Darwin and the graphical components of OS X are very different. Apple makes a point of claiming Darwin is Open source, I have seen nothing similar for any other component. I think you may have been mistaken, because I am 99% sure Aqua and Quartz are still closed, as I have yet to see a single claim elsewhere that they are open.

[ Parent ]

His name is egg troll... (4.66 / 3) (#59)
by carbon on Sat Mar 22, 2003 at 03:41:23 AM EST

...for a reason.

Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
No More ROM (none / 0) (#177)
by haydentech on Wed Mar 26, 2003 at 12:55:09 PM EST

Modern Macs do not have a ROM in the historical Mac-related sense of the word. From the blue & white G3 series and newer, the "ROM" is a file in your System Folder in MacOS 9, or in the case of OS X, there is no ROM used at all.

[ Parent ]
Why did they *ever* use it? (1.14 / 7) (#42)
by DesiredUsername on Fri Mar 21, 2003 at 07:21:53 PM EST

"Because it's not Windows."

People will continue to use X for the same reason they've always used X. Not because it works better (far from it). Because Microsoft didn't make it. The same "reasoning" applies to Apple, who are positioning themselves to take over the Linux world (with MacOS X) as much as Microsoft is (with WinXP).

Play 囲碁
[ Parent ]

X was around before Windows became popular (4.00 / 3) (#44)
by HidingMyName on Fri Mar 21, 2003 at 07:37:51 PM EST

In fact, Xwindows has one feature that made it extremely attractive in the days where computers were expensive, in that dedicated desk top devices or workstations could run jobs on big beefy servers that had memory (used to be way more expensive and limited) and only worry about handling the display end. Unfortunately, the X protocol is really a fairly low level interface (from the point of view of GUI programming) and hard to work in. Only recently (last 5 years or so) have tool kits really made GUI development easier (e.g. QT/KDE and GNOME/GTK).

However the client server model does need an accelerated interface so that when the client and server are on the same machine the system is more lively. My biggest beef seems to be that my machines get X memory leaks (either in the window manager or X itself, I can't tell for sure) so that I log out of my WM every week or so to reclaim a few hundred meg of swap.

[ Parent ]

Client/Server communications are not the problem. (4.33 / 3) (#115)
by tzanger on Sun Mar 23, 2003 at 07:57:07 AM EST

However the client server model does need an accelerated interface so that when the client and server are on the same machine the system is more lively.

Actually you might want to run some benchmarks on the client/server interface when on the same machine -- the current system does not add significant delay or overhead to the command path at all, and as such it'd be ridiculous to optimize it.

[ Parent ]
Localhost optimizations already exist (none / 0) (#140)
by derobert on Sun Mar 23, 2003 at 07:52:16 PM EST

However the client server model does need an accelerated interface so that when the client and server are on the same machine the system is more lively.
A bunch of optimizations already exist where needed. Thing like XShm, XVideo, etc.

[ Parent ]
Please distinguish X11 from XFree86 (none / 0) (#143)
by phliar on Sun Mar 23, 2003 at 08:56:54 PM EST

My biggest beef seems to be that my machines get X memory leaks...
You're not getting memory leaks from X11, but from some implementation of X11. Remember that there are implementations of X11 for SunOS4, Solaris, HP-UX, ... and of course Linux/*BSD, where the implementation is XFree86. You also say you're not sure if it's the window manager; which WM? This is like saying "Web browsers suck! Mine crashes all the time."

Also, the pedantic might want to keep this in mind:

The X Consortium requests that the following names be used when referring to this software:

X Window System
X Version 11
X Window System, Version 11

(Not on this list: "Xwindows" or "X Windows.")

Also, you don't have to use Qt or GTK; writing code at the lowest level i.e. Xlib is not too painful, just very verbose. Xt is easier, and Xaw is a little easier still. Once you have the basic boilerplate code you can crank out application code without too much pain.

Faster, faster, until the thrill of...
[ Parent ]

I love Xaw (none / 0) (#151)
by fluffy grue on Mon Mar 24, 2003 at 09:21:16 AM EST

Xaw is my favorite widget set for X. It's simple, it's easy, it doesn't abstract stuff too far away, and it actually uses X resources like a good X toolkit should. (WTF is with gtk and gnome and their own stupid configuration engines which aren't even a tiny fraction as powerful and flexible as X resources?!)

Sure, the default look is fugly, but no serious Linux distribution comes with the classic monochrome-friendly Xaw configuration by default anymore. (Oh, and that's another thing - Xaw is actually monochrome-friendly!)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Apple's version of XFree86 (3.50 / 2) (#88)
by ensignyu on Sat Mar 22, 2003 at 10:56:00 PM EST

Apple created Aqua. And then they ported XFree86 to run on top of Aqua. XFree86 doesn't sound like it's dead to me.

[ Parent ]
I'll just run OS X on my Intel . . . oh, wait (none / 0) (#170)
by hardburn on Mon Mar 24, 2003 at 11:45:56 PM EST

People will continue to use X because Intel-based hardware is a lot cheeper than anything out of Apple. If/when OS X is ported to an i586, you might have a point.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
X should die. (3.00 / 8) (#24)
by SleepDirt on Fri Mar 21, 2003 at 04:34:41 PM EST

I understand all the various technical arguments people use in defense of X. Some of them are legit, some aren't. The bottom line is simply that the drawbacks to X's design impact people FAR more than the so-called features of X.

I like being able to export displays in X but I find using Microsoft's RDP is faster and easier to setup these days. I almost never use X anymore.

"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson

X issues (4.80 / 5) (#41)
by Znork on Fri Mar 21, 2003 at 07:08:28 PM EST

What drawbacks to X's design?

RDP being faster and easier to set up is not an intrinsic problem with X. One way to solve it is to use ssh X11 forwarding and public/private keys to authenticate between the hosts you access. Instantly you get compressed X and can easily launch any app from anywhere in your network from an icon or commandline. It doesnt really get much easier than that.

I'll be the first to agree that current X implementations have some serious problems, especially around configuration and management, but implementation issues are not X design issues. And configuration has undergone some really major improvements since the bad old days of modelines. Now the xfree config files are almost sane, and if we're really lucky maybe the distribution vendors will improve upon GUI X configuration.

Then there are distribution issues like the lack of good ways to add drivers. Or toolkit issues like the lack of widespread support of certain extensions.

But if you're talking about actual problems in X's design, I'd really like to know what you think those problems are. To develop something else makes sense if there are real problems with X11, but if it's just the implementations that have some serious problems, or the distribution vendors  or toolkit writers that cant get their acts together then it's much more constructive to criticise the areas where the actual problem is than to criticise X11.

Forking XFree86 to become a more publically accessible project if the situation cannot be resolved otherwise may be a good start. Splitting it up and modularizing the parts may be another, because it's apparently far too huge for the XFree86 core to efficiently manage by now.

[ Parent ]

lbxproxy (4.00 / 1) (#124)
by Piquan on Sun Mar 23, 2003 at 03:54:53 PM EST

While ssh compression is good, I'm a big fan of lbxproxy. Unfortunately, it requires some surrounding glue to work well, and that hasn't been written yet. (I use ten lines of shell script for the glue, but it's not made to be used by everybody.)

[ Parent ]
X and networking (4.33 / 3) (#62)
by cpatrick on Sat Mar 22, 2003 at 06:20:56 AM EST

I like being able to export displays in X

X doesn't export displays in the same manner as VNC or RDP, though. On my machine, I have several little WM dockapps showing CPU & network load; only one of these is running locally. The dockapps running on other machines appear just like the ones running locally without needing to export an entire desktop a la RDP/VNC.

The ability to have windows running on different machines on the same desktop is, to my mind, the best feature of X. I think its abstraction layer is too low - it would be great if there was a standard "X toolkit manager" which could be replaced independently on applications, just like window managers can, allowing you to easily select between KDE/GTK/Windows/Mac-style widgets in windows, without having to worry about individual applications wanting to use KDE or GTK or Qt or god-knows-what-else, and thus looking and behaving completely different to other programs.

[ Parent ]

Modularise, componentise. (4.87 / 8) (#35)
by golrien on Fri Mar 21, 2003 at 05:16:33 PM EST

What XFree86 wants is splitting up, into a bunch of parts. Not only would this would simplify development (one group maintains the core, there's people maintaining the utilities (xf86config, xterm, etc), and drivers can be completely seperate) but it would save the hours of downloading and compiling, and fix the fact that I have like 20MB of video drivers, 99% of which I will never, ever use. Granted, it's not as simple as "everyone takes one driver" because of interdependencies, but it would be a hell of a lot better than the current system.

If one replaced X (4.16 / 6) (#61)
by locke baron on Sat Mar 22, 2003 at 04:38:08 AM EST

There would be a lot of problems, not the least of which would be the fact that there would be NO GUI apps on UNIX anymore. None. They all use X. You could, I suppose, retool all the major libraries to use the new GUI system on the backend, but that is decidedly non-trivial.

This ignores the side issues that would result if the replacement for X prevented users from replacing the default desktop and window manager. (I agree that a decent standard should be provided, and AFAIC, KDE is good enough for that purpose, but it should be changeable.)

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy

Choice is good (4.33 / 6) (#63)
by cpatrick on Sat Mar 22, 2003 at 06:24:46 AM EST

KDE is good enough for that purpose, but it should be changeable.

Indeed. Even Windows allows you to change which shell you are running, and there are several free shell replacements around whose supporters all claim are better than Explorer. I've heard several people suggest that X should standardise on just one window manager and rip out the network transparency; such people seem to be missing the point. The proliferation of DEs for Unix isn't a problem for "normal users", because "normal users" don't fiddle with the internals of their computer and use whatever it comes with. So long as distributions provide something reasonable to begin with, there isn't a problem.

[ Parent ]

Allowing for backward compatibility (4.00 / 2) (#90)
by izogi on Sun Mar 23, 2003 at 01:17:12 AM EST

There would be a lot of problems, not the least of which would be the fact that there would be NO GUI apps on UNIX anymore. None. They all use X. You could, I suppose, retool all the major libraries to use the new GUI system on the backend, but that is decidedly non-trivial.

Is there any reason why you couldn't just run an X server emulator on top of the new GUI system? It'd provide backward compatibility, and that's really all that's needed initially.

I know it's klunky, but it provides a time buffer where users can at least get started using the new system with all their old X apps while application and library vendors work to develop more native versions of them. Once the main applications support the new GUI natively, the X server can be thrown away.

This would only work if enough vendors decided it was going to be popular and worth supporting, of course.

- izogi

[ Parent ]
And therein lies the rub. (3.00 / 2) (#97)
by locke baron on Sun Mar 23, 2003 at 01:42:24 AM EST

Is there any reason why you couldn't just run an X server emulator on top of the new GUI system? It'd provide backward compatibility, and that's really all that's needed initially.

Well, the klunkiness could be a problem. You could run that emulator, but emulation tends to have speed, stability and completeness issues. If you replace X, just to have X apps run slowly on the new system, people will complain about how much the new system sucks. Also, integration of X and 'new system' apps would probably be less than perfect.

It's a good idea, but might prove problematic.

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

Not necessarily... (4.50 / 2) (#110)
by Keepiru on Sun Mar 23, 2003 at 06:29:11 AM EST

For instance, Exceed, which is an X server for Windows.  It's pretty decently fast, despite the fact that it's translating between Windows and X.

Emulation is slow for CPUs because there's no really good way to do it quickly.  Higher level functions like X are a lot easier to emulate.

[ Parent ]

Hrm, good point. (4.00 / 1) (#112)
by locke baron on Sun Mar 23, 2003 at 06:52:50 AM EST

See my comment entitled 'D'oh!' above...

Yeah, Exceed is decently fast. The slowness I see is due to the fact that the remote machines are pokey (PA-RISC 120) and the network sucks (10Mbps ether with many users).

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

You mean... (4.75 / 4) (#98)
by jreilly on Sun Mar 23, 2003 at 01:55:54 AM EST

something like this? http://www.apple.com/macosx/x11/
It's quite possible to have a X server that renders not to a video card, but to another gui. There were projects to do this for OS X almost as soon as it came out, and I imagine there are commercial offerings for Windows, and other OSs. In fact, for a good laugh, check out the XNest X server(part of XFree86). It's an X server that runs on top of another X server. So yeah, definately doable, definately been done.

[ Parent ]
D'oh! (3.00 / 1) (#101)
by locke baron on Sun Mar 23, 2003 at 02:34:59 AM EST

How did that not occur to me? (*tears out hair*)

The only catch in this case would be making copy/paste and drag-n-drop between X and 'the new X' apps work at least as well as it does between X apps, so that people would not perceive that the new system sucks more than X.

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

Umm... (3.75 / 4) (#99)
by regeya on Sun Mar 23, 2003 at 02:01:06 AM EST

I hate to point it out, but most of those apps you see on a daily basis don't date back any farther than 1999, and more than a few of those have gone through a major rewrite or two. I don't think it'd be as big a big deal as you think if all the XFree86 developers just threw their hands up and said, "Okay, guys, just go use Fresco now." Well, except for that business of next to no drivers for Fresco. ;-D

[ yokelpunk | kuro5hin diary ]
[ Parent ]

Oh, and the drivers... (4.50 / 2) (#100)
by locke baron on Sun Mar 23, 2003 at 02:29:37 AM EST

Meh. Yeah, those could be a fairly significant sticking point.

The fact that the apps have been re-written isn't really as much of a factor as the back-end libraries. One would have to rewrite, for example, GTK and Motif and QT without changing the API significantly (just extending it to take advantage of new features). Maybe that's easier than I think, but it seems to me that all the recent library rewrites have a) taken forever, and b) resulted in a library which isn't API-compatible with the old one.  (it only has to be source-compatible, too. Binary compatibility would be nice, but isn't essential).

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

BAH! (none / 0) (#164)
by regeya on Mon Mar 24, 2003 at 08:50:47 PM EST

Konqueror and X-Chat have been ported to other operating system, and in the case of X-Chat, IIRC it didn't require a port of GTK+.

If porting your app requires porting the toolkit it's based on, then, hm, I don't know; perhaps there's something wrong? Note that I know next to nothing about separation of UI from the rest of the codebase, but I can't help but question the need of porting toolkits to other display systems when the right thing, IMHO, would be to port the apps to the available API.

Foisting a dozen toolkits on Fresco would be the Wrong Thing, IMHO.

[ yokelpunk | kuro5hin diary ]
[ Parent ]

Backwards (none / 0) (#168)
by hardburn on Mon Mar 24, 2003 at 11:39:27 PM EST

Idealy, the only thing you have to port is the toolkit. In theory, once that is done, you only need to recompile your app for the new platform. With the right compatibility layers, you may not even need to do that.

One of the reasons for using an API like GTK+ or qt is that your application can work anywhere the API is ported to.

Of course, theory and practice are often at odds with each other. Even in the most well-written but reasonably complex software will probably need a few changes.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
Ah, yes. (none / 0) (#173)
by regeya on Tue Mar 25, 2003 at 02:59:44 AM EST

We all know how well that BeOS GTK+ port went.

[ yokelpunk | kuro5hin diary ]
[ Parent ]

Depends on the app (none / 0) (#169)
by locke baron on Mon Mar 24, 2003 at 11:40:52 PM EST

Some apps, like AbiWord, aren't very closely coupled to their UIs at all, while others would be a lot more work to port over (think of things like GIMP - on Windows, it still needs GTK+). For that reason I kinda wonder if abandoning X in favor of Fresco (or similar) would be akin to throwing the baby out with the bathwater.

As for porting apps to the new API, that's kinda like switching toolkits (pretty close, actually) - think about what a pain it would be, for example, to make all GTK+ apps use Motif instead, and that's why losing X could be such a hassle.

I'm not saying that X is the best solution, or even necessarily a good solution, just that it works well enough that it might not be worth the trouble to lose it entirely. What about another version of X (X12 instead of X11, say) which addresses most of the major shortcomings?

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

Partly true, but (4.00 / 1) (#147)
by drquick on Mon Mar 24, 2003 at 04:45:33 AM EST

NO GUI apps on UNIX anymore. None. They all use X.
Many of them use a desktop environment. A KDE or Gnome application can well get away with no X11R6 calls at all. Take an applications like Abiword or Gnumeric. Probably all of the application code relies on widgets and no direct X11 calls are made. But, you are partly right because some applications use X11 calls anyhow.

My point is, that it would go a long way to port GTK+ and the window manager to say... Fresco. Not all the way, some applications would be left in the cold, unless you could have a X11 compatibility layer.

[ Parent ]

Only somewhat relevant, I guess (4.60 / 5) (#65)
by Anonymous 7324 on Sat Mar 22, 2003 at 08:46:35 AM EST

One question that you raise is the 'fork' biz, and how successful different kinds of forks are. I'm actually more interested in this question perhaps than the specifics of the XF86 politics.

Unfortunately, I know little about forks and would appreciate others' stories...


XEmacs, I understand it, was a fork from GNU Emacs after the original group was too slow to implement some features that users demanded -- it seems to be going strong as a separate branch.

Mozilla obviously encourages what can be looked upon as 'forks' into projects like Phoenix, Camino (which rocks my world), and Galeon, Skipstone, etc. These also seem successful.

OpenBSD was forked from NetBSD after Theo had a spat with the rest of core, and I'm still not sure who was at fault. Obviously both NetBSD and OpenBSD are very successful in their respective environments, and that both groups seem to be some really nice people.

Distro-wise, Mandrake, while not at the project level, obviously forked from RedHat, to great success, dire financial news or otherwise. There's also gazillions of lesser RH distros like CRUD, etc. Debian has also obviously been the base for lots of other new and more 'user-friendly' distros, and seems to hold a relationship similar to the Mozilla vs. Phoenix/Camino/Galeon biz. (Except that IMHO none of the 'forks' are improvements on the original, but that's just me).

Then there's stuff that fails miserably like what was it, MicroBSD that actually managed to violate the BSD license? There's others too, but failing miserably usually gets you forgotten, not famous, so I don't know very much about those.

In any case, can anyone jump in to correct me on the facts and add more stories?

egcs (4.50 / 4) (#66)
by enterfornone on Sat Mar 22, 2003 at 11:09:41 AM EST

forked gcc and was later declared the official gcc

and not forgetting everything that forked mosaic

efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]

some things aren't forks (2.00 / 1) (#104)
by martingale on Sun Mar 23, 2003 at 04:46:21 AM EST

A fork needs to share the same basic source code though. Wasn't egcs a complete rewrite or something like that? I'll admit I'm not up on the details.

[ Parent ]
No, it was a fork (5.00 / 1) (#166)
by hardburn on Mon Mar 24, 2003 at 11:30:40 PM EST

egcs forked to take GCC into a Bazzar-type development, as laied out in Eric S. Raymond's seminal "The Cathedral and the Bazzar". Whatever you might say about ESR, his insights on software development seem to have worked for GCC/egcs.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
successful forks (3.66 / 3) (#67)
by damballah on Sat Mar 22, 2003 at 12:23:41 PM EST

it might also help to talk about some high-profile unsuccessful forks, if there r any. anybody know something about these?

" I apologize for this long comment. I didn't have the time to make it any shorter. " - Blaise Pascal

" zombie accounts promote an unhealthy interest in the occult among our younger readers. " - [ Parent ]

Modular Design (4.11 / 9) (#70)
by jd on Sat Mar 22, 2003 at 02:15:10 PM EST

Ultimately, software will migrate away from both a layered and a client-server model, and towards a modular design. The reasons are that:

  • Modular construction allows modules to be up and running without a working system (so lower initial ramp)
  • Modular designs can shed out-dated components without disturbing the system as a whole, thus remaining current
  • Different modules can be designed under different licences (as per Linux), so allowing companies with different policies to be involved

In the end, X may be thought of as a series of modules which interact as necessary but which don't otherwise have anything to do with each other.

The X protocol is one such example. You bring in the data, and you then process it. But how that data is brought in is irrelevent for the purpose of displaying it. Define the protocol as a pluggable module, and allow others to write other protocols which can also be plugged in.

Toolkits are definitely modules. Think about Open Motif versus Lesstif. These do the same thing, and have the same API, but the implementation is very very different. At present, these are usually plugged in by symlinks, or by only installing one, but developing a dynamically pluggable architecture would be much better IMHO.

Same is true of the window manager, except people are used to having those pluggable.

X, then, can be reduced to a core engine which interrelates input and output streams, with groupings for those streams which may (or may not) overlap, plus the module support engine.

I would also take out the assumption that data is pixel-based. That's a characteristic of the display, and is something X shouldn't concern itself with except in the act of displaying.

I would devise a new base library, replacing Xt. This is only real developer-visible change in the entire idea. Instead of using a fixed stack of pixel frames, many of which will likely never be used, have each layer type as a module. Pull in only the layer types that are required, and generate a window linked list, rather than a stack. Let the application writer re-thread the list in any order they like.

I'd also have six basic graphics engines, based in text, pixels, voxels, vectors, polynomials and splines. Any layer can be keyed to one engine. The pixel and text engines combined would give you the functions in Xt, so you could easily write a backwards-compatibility layer.

For solid-fill 3D graphics, you'd probably use the voxel engine. That's how most work, anyway. But because it's now a direct layer, rather than parsed through Xt, it would be much faster. You'd also not be constrained by any limits of Xt.

Wire-frame 3D, charts, CAD, plotting, etc, would all be doable via the vector, polynomial and spline engines. Again, all the fancy footwork needed to get things into X wouldn't be required, so these libraries could be pretty sleek.

Because everything doable in X would be doable in this system, all historic applications would remain 100% usable. That is an important consideration, when trying to usurp an accepted standard.

However, you could do much much more. Remember, I'm thinking of bundling inputs and outputs together, dynamically. That means I can have two terminals connect to the same screen, or one terminal connect to many screens, etc. You could therefore exploit protocols such as reliable multicasting, mobile IP, etc. Something that X would currently have a heart attack trying to cope with.

What about "true" 3D? Remember our linked list of layers? What if a layer was, in fact, a list of cross-sectional views of voxel layers? You then have "real" depth, and the display engine would need to take care of the presentation. The same goes for 4D, or higher orders. Each extra dimension is merely an array of some size, holding that many copies of the previous order's space. You program arrays in most languages this way all the time, so it's nothing new.

Ok, I said that all historic software would still run, exactly as it always had. This is true, though it would probably run faster under this architecture, as it's a much cleaner design. It would be possible, though, to take ANY library from an existing code base (eg: Gtk or Qt), rewrite it for the new architecture to get maximum advantage, and STILL have everything work, even though it's now hybrid between old and new.

Obviously, the "ultimate" would be to port an application fully to the new design. Once enough key libraries had been so ported, you could probably dispense with the Xt compatibility code completely.

The reason Berlin isn't installed on everyone's Linux box has nothing to do with it being incomplete. There are plenty of incomplete, unstable packages in widespread use. Windows, for example. No, Berlin isn't in common use because it's non-trivial to run existing code on it and because it's not modular enough to use bits of the code inside an X-based environment and outside of Berlin's main display code.

IMHO, whether you have a widget set, a 2D or 3D library, or the coolest window manager on Earth, you design it for an API, not a system. Anything that supports that API should work just fine, with no other assumptions made. And it should be able to build a software patch-cable from one API to another, if they do essentially the same thing. It's when you make an API too complex, to the point where you can't easily make things compatiable, that you have problems.

Interesting options... (3.75 / 4) (#78)
by Hatamoto on Sat Mar 22, 2003 at 04:42:40 PM EST

However, you could do much much more. Remember, I'm thinking of bundling inputs and outputs together, dynamically. That means I can have two terminals connect to the same screen, or one terminal connect to many screens, etc. You could therefore exploit protocols such as reliable multicasting, mobile IP, etc. Something that X would currently have a heart attack trying to cope with.
I recently saw a suggestion that one might plug multiple monitors, kb's and mice into a box and have a 'true' double headed computer... essentially a box that would allow 2 or more peope to directly operate on a single machine. A redesigned X which allowed more separation between inputs would be far more easily bent to this task than the current bohoemoth.

"Innocence is no defense." - Federal District Judge William H. Yohn (People v. Mumia Abu-Jamal)
[ Parent ]
Uh, X terminals? (4.00 / 1) (#87)
by arthurpsmith on Sat Mar 22, 2003 at 10:03:07 PM EST

We have about 80 X terminals at work running off one Sun box. Isn't that effectively what you're talking about?

I don't really see the point though - local CPU's are so inexpensive these days (especially relative to the cost of nice displays) - why share a machine that way any more?

Energy - our most critical problem; the solution may be in space.

[ Parent ]
Sunrays (4.00 / 1) (#103)
by ph317 on Sun Mar 23, 2003 at 03:10:09 AM EST

I've found Sunrays to be very viable in a Sun environment.  It's a lot cheaper and easier to put $500 (brand new, much cheaper if you buy em used) Sunray terminals on people's desks which compute on a single larger racked machine off in your datacenter than to buy and manage hordes of little ultra 5's on people's desks.  Sunrays are essentially modern X-terminals.  The differences are:
  1. Proprietary protocol - only works with Solaris and Sun's Sunray Server Software atm.  (Sucks, I wish someone would reverse engineer this to make sunray server software for linux.  I might some day when I gather up enough willpower and free time)
  2. Network seperation is closer to i/o devices than X.  Whereas an X-terminal sends and receives higher-level events to save network bandwidth, the Sunray protocol is really just sending basic keyboard/mouse information and receiving screen updates - much closer to the network model of things like Citrix.  It takes more bandwidth and is much more latency sensitive, but it's a win today as any modern switched 100mbps lan can handle it (X was designed for much slower networks).
  3. Support for i/o devices other than kvm.  The sunray comes with integrated audio, a smartcard reader, a video capture port (RCA jack analog video in), and a few USB ports to hook up USB printers and other such devices.  This is a much richer i/o environment than an X terminal can offer.  The Sunray Server Software of course uses the smartcard reader for authentication.
Anyways, I'll stop ramblinf - they're great devices and a very nice architecture, I just wish there was progress on linuxification of them :)

[ Parent ]
Re: Sunrays (none / 0) (#157)
by Argel on Mon Mar 24, 2003 at 01:32:27 PM EST

Couple comments/nitpicks:
  • Given the power problems of early models you should be careful buying used units. Go with 380-0299-05 or higher revisions (where 05 is the revision). Or be even safer and go with 07 or higher. I think al lof the 380-0428 models are okay.
  • Smart cards are used for session identification. That's it. Nothing else. Nada. Even with registered smart cards there is nothing that ties that smard card to your UNIX account. The best you can do is say this smart card is allowed to use this Sun Ray server. That's not authentication in my book.
  • With that said in the 2.0 software Smart Card Frameworks are supported so it might be possible to work some magic (at least at the application level) to overcome this.
  • It's "Sun Ray" (two words).
The Sun Ray system isn't perfect, but we're very happy with it.

[ Parent ]
Well ok (none / 0) (#174)
by ph317 on Tue Mar 25, 2003 at 02:57:13 PM EST

True, they don't actually authenticate with the smart card.  However, in the right configuration you can only allow sessions to be initiated by people holding smartcards you've pre-registered as an administrator.  Once they slip the card, in, they can log in as anyone.  However you can attach a name to a smartcard which can be seen with administrative commandline commands, and you could conceivably script something to compare this to the login username to check for people using other's smartcards every few minutes.

Something much better but a little more difficult (why hasn't Sun done this?) would be to write a PAM module for solaris that checks the username associated with the inserted smartcard id and only allows a user of that name to login under that card.  You may (I've only ever written one PAM module, so I'm not really sure) be able to also force the correct username without the user typing it.

Maybe I should try this today, I'm bored :)

[ Parent ]

A rewrite of the input and output layers is needed (5.00 / 3) (#95)
by fluffy grue on Sun Mar 23, 2003 at 01:36:35 AM EST

But not for the reasons you think. :)

Ever play with a USB tablet?

Under Windows, you plug it in, it gets recognized, it can be used.

Under MacOS, you plug it in, it gets recognized, it can be used.

Under XFree, you plug it in, you edit your /etc/X11/XF86Config-4 file, wonder which /dev/usb/event* file and XFree module it maps to, restart XFree (after closing all your applications, especially xemacs which throws a shitfit if you exit XFree without closing xemacs first), find out it doesn't work, recompile your kernel, discover that you don't have the latest tablet driver, recompile all of XFree to update the tablet driver, restart your computer, start XFree, watch your display not come up because of some weird interaction between the compile-time argument you missed and the idiosyncracy of how DDC is implemented in your video card, try to find a working snapshot of XFree which does have the tablet driver, get things working "well enough" only with the tablet's position 300x as sensitive as you want and no pressure sensitivity at all, and decide that's good enough for now. Then you turn off your monitor when you go to bed which deactivates your hub, then when you turn it back on, the devices get enumerated differently, so suddenly your mouse and tablet have swapped device nodes and XFree throws a shitfit, so you have to ctrl-alt-backspace the server, edit /etc/X11/XF86Config-4 again to swap the device nodes back, start it up again, and then discover that your mouse doesn't work at all anymore, and the tablet driver is way too inaccurate for you to actually use it. Finally, you break down and go back to a PS/2 mouse and your ancient 4x5" serial Wacom tablet with the worn-down nub and no eraser because they might not be the best but at least they motherfucking work.

The input layer really needs to be separated out into a separate process. gpm is a good idea. Abstracting gpm and putting all of the device management there would be a great idea.

"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

X or XFree? (4.00 / 1) (#111)
by BlackFireBullet on Sun Mar 23, 2003 at 06:50:47 AM EST

I know earlier you attacked XF86 as being a broken implimentation of X11, however is the problem you described a part of XF86 or the X11 protocol?

I am unsure of where the X protocol starts and stops, however I would have thought that the horrible way in which XF86 treats input and output devices was someone inbuilt into the protocol, as detection of input and processing/formating the output are rather important components of a system like X.

I am quite possibly wrong, as all I know about XF86 and the X11 protocol is how to blugeon it into working on my gentoo box, which means I know very little at all.

[ Parent ]

X protocol (4.00 / 1) (#118)
by Znork on Sun Mar 23, 2003 at 12:17:30 PM EST

Very definitely XF86.

The X protocol is basically Xlib. It defines how to communicate basic drawables to the display device and how input will be presented to your application.  Things like 'clear this area', 'draw a rectangle', 'you just recieved an input event saying that a pointer device moved here and clicked'.

These are usually further abstracted by libraries like Gtk and Qt which give you things like 'draw a button here' and 'your button just got clicked'.

The responsibility of the X server proper is to talk to the hardware and translate the requests of the applications into actual output on the screen and to harness and encode the various input devices data and deliver it formatted in a way the application (or the applications supporting GUI libraries) can understand. How it does that, and how you configure devices, is entirely up to the implementation, and there is nothing in the actual X specification that enforces how it's done. It only enforces how it should be communicated to and from the applications.

[ Parent ]

It's in XFree that it's broken (5.00 / 2) (#120)
by fluffy grue on Sun Mar 23, 2003 at 12:22:27 PM EST

Witness that an X server running on, say, Windows or MacOS will inherit the proper driver detection. :)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Very different experience (none / 0) (#149)
by Ranieri on Mon Mar 24, 2003 at 06:52:24 AM EST

With mandrake, I plugged in my USB Graphire, it made funny rattly disk noises for a while and the tables just worked.
With XP it was properly detected, but i still had to navigate a horrible website to get the drivers, and installing them required clicking through alarmist dialog boxes (this driver is not certified by Microsoft! YOU MIGHT DIE A FLAMING DEATH!) and a reboot.
Taste cold steel, feeble cannon restraint rope!
[ Parent ]
By "just worked" (none / 0) (#150)
by fluffy grue on Mon Mar 24, 2003 at 09:17:49 AM EST

do you mean "worked like a very expensive mouse" or "worked like a tablet with absolute coordinates and pressure sensitivity?" Sure, getting it to work like a very expensive mouse is easy, but that doesn't make it very useful for the whole reason I got a tablet to begin with.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

The absolute coords worked. (none / 0) (#152)
by Ranieri on Mon Mar 24, 2003 at 11:37:03 AM EST

Haven't tried pressure sensitivity yet.

I must admit I was dumbfounded.
Taste cold steel, feeble cannon restraint rope!
[ Parent ]

Amazing (none / 0) (#154)
by fluffy grue on Mon Mar 24, 2003 at 01:16:03 PM EST

Actually, I have three tablets, an old Wacom ArtPad, a Wacom Intuos2 (or is it a graphire2? meh, tablet itself doesn't say) and an Aiptek 12000U. I can't even get the Graphire to work in Linux at all; it just makes the mouse cursor totally wig out. The Aiptek only works as an ultra-sensitive mouse right now, but that's because the driver is still in early development (supposedly the latest version will work properly, but it requires a total recompile of XFree to install it for now). So I still use the old ArtPad.

I wonder if Mandrake does the Right Thing and just uses gpm for everything. Though I don't think gpm supports pressure events or XInput or whatever.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

I have no idea (none / 0) (#158)
by Ranieri on Mon Mar 24, 2003 at 01:49:08 PM EST

I wonder if Mandrake does the Right Thing and just uses gpm for everything. Though I don't think gpm supports pressure events or XInput or whatever.

I have no idea how this remarkable feat is accomplished. When I witnessed it for the first time, it was not unlike a miracle.

I know however that Madrake even detects the Graphire upon first boot and lets you install using it as the pointing device.
Taste cold steel, feeble cannon restraint rope!
[ Parent ]

Definitely gpm then (none / 0) (#160)
by fluffy grue on Mon Mar 24, 2003 at 02:24:05 PM EST

If it's supported in the console. Unfortunately, that means it's highly unlikely it'll work with pressure-sensitivity, which is a major reason for having a tablet to begin with. Still, I think I might play around with Mandrake in the future, especially if rpmdrake has filled in the function which apt provides in Debian (apt being Debian's greatest strength, but also sometimes its greatest weakness!).
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

mandrake has it going on (none / 0) (#159)
by damballah on Mon Mar 24, 2003 at 02:00:26 PM EST

i'm using mandrake 9.0 and it's really a pleasure. diskdrake( their hardware detection program) got al my stuff right the first time w/ *updated* a driver for my monitor. i have winxp on the same machine and it had problem understanding that my monitor was a 17' samsung nf blah-blah. that really impressed me. iahven't tried usb cause i don't have time to play games :( yet.

also for easy updates and new package downloads, rpmdrake is the perfect tool: easy to specify new sources and easy to do security updates.

users have been complaining that mandrake doesn't do enough pr for those 2 amazing tools and i agree! red hat sux as a desktop (not enough fun stuff) and suse is 2 rigid (used at work). the other ones just suck from my joedumbuser-pragmatist point-of-view.

" I apologize for this long comment. I didn't have the time to make it any shorter. " - Blaise Pascal

" zombie accounts promote an unhealthy interest in the occult among our younger readers. " - [ Parent ]

Wacom tablets (none / 0) (#167)
by phliar on Mon Mar 24, 2003 at 11:37:03 PM EST

I have a large (11x15 if I remember right) Wacom Intuos tablet (serial, not USB). With Mandrake 8 it was all set up correctly at system install, including absolute position and pressure. I use it with The Gimp. It wrote the correct XInput magic to the config file. (I don't know if stylus tilt works yet... I haven't been able to get it to work.)

BTW, I have to say the Wacoms with the cordless non-battery stylus are really cool.

Faster, faster, until the thrill of...
[ Parent ]

All Wacoms are like that (none / 0) (#171)
by fluffy grue on Mon Mar 24, 2003 at 11:47:27 PM EST

And yeah, Wacoms are great. I still use my 4x5" ArtPad quite a bit, and would probably use it alongside my 4x5" whatever-the-hell-the-newer-one-is (it's either intuos or graphire, I don't remember which) if I could get it to work in Linux. (Multiple tablets → multiple tool schemes! Very convenient.) And when/if I get the Aiptek working, that'll be even neater. The only problem with the Aiptek (assuming the current jitter problems are a driver issue) is that it needs a battery in the stylus (Wacom has a patent on the induction-powering stuff and doesn't want to license it out to cheapo brands like Aiptek, or maybe Aiptek just doesn't want to pay enough to license it), but a single AAA battery supposedly lasts a whole year, so I'm not too worried. :)
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

Done, what next? (4.00 / 2) (#123)
by miah on Sun Mar 23, 2003 at 12:31:31 PM EST

This can already be done with 4.2 (or less, check the docs). You just have to start multiple instances of X on different graphics cards. This is only limited by the amount RAM that you have, PCI slots (for graphics cards) and how many USB keyboards and mice you can get your grubby little hands on.

I could see this scaling well for places that don't need to put a computer on every desktop but need to have data entry and manipulation (think: call center). Instead of having a thin client on every desktop you could have a cheap PC running out to four or five monitor/keyboard/mouse 'stations'. If these machines network booted and mounted their filesystems from one main server they wouldn't even need disks. This would be a gignormous savings in hardware.

All of this is possible. X is that flexible. You just have to associate the different keyboards and mice to the correct terminals. Just don't ask me how to get devfs to put five of the same mice onto the same /dev/ entry!

Religion is not the opiate of the masses. It is the biker grade crystal meth of the masses.
[ Parent ]

Modules (3.50 / 2) (#92)
by bugmaster on Sun Mar 23, 2003 at 01:23:03 AM EST

The problem with modules is that they are slow. For example, consider typing this sentence in the textarea. How would it work with modules ?

I press a button, and the input module receives the event. It then looks for the associated language module, to translate the hardware keypress into the character code. The language module sends a signal to the associated network module, which transmits the code over the network to the desired application (even if it's just Eventually we get to the GUI module, which talks to the window toolkit module, which talks to the vector graphics module, which talks to...

Every time one module calls another, it has to do table lookups, and call APIs. Even for a simple thing like pressing a key, there is a chain of modules a mile long, and so a major amount of resources is spent on overhead. As the result, everything is slow.

Of course, a monolithic Graphics/GUI system is not good either, since it would be rigid and messy. A good balance needs to be found between modularity and speed.
[ Parent ]

Yes, no and maybe (4.00 / 2) (#127)
by jd on Sun Mar 23, 2003 at 04:10:50 PM EST

You have interfaces between blocks of code already - the function call stack. By calling a funcion, you push the current address and parameters onto the stack, then do a table lookup to see where the function you're calling is located. (Assuming you're using relocatable code.)

The question is - can you devise a module system where the cost is of the same order as the stack system?

I believe the answer is yes, provided you can cut down on the layers. The keyboard is an output-only streaming device (from the perspective of the machine). Your client engine needs to have a series of connectors that'll take such device output, wrap it in a TCP tunnel, and send it to the X server.

This doesn't begin to look nearly so bad. Any device needs, therefore, an encaps/decaps layer, one unique IP tunnel and a specific device to self-describing data layer. Four modules. Doable, perhaps.

The self-describing data is important. That means that the server doesn't care about the source of data, all data is processed the same. So only one module is needed there, which can understand data in such a format.

[ Parent ]

TCP (5.00 / 1) (#130)
by Znork on Sun Mar 23, 2003 at 04:41:22 PM EST

Interesting, but dont get stuck on using TCP. X will use Unix Domain Sockets for local communication (or  SHM, or to the extreme of DGA, depending on applications and the viability of using the method in any particular circumstance), which pretty much removes the commonly forwarded argument against Xlib abstraction being slow.

Your suggestion would, as far as I understand it, be entirely possible to implement as shared memory area and simple pointer passing between the modules as input and output is formatted and ready to leave/enter the abstraction layer, with networked transmission used only as a fallback position as in X.

[ Parent ]

Very true (4.00 / 2) (#153)
by jd on Mon Mar 24, 2003 at 01:07:35 PM EST

I'd not thought of it that way, but you are correct. Shared memory would be an excellent way to implement this kind of system. (The only catch being that you couldn't cluster the X server, using standard shared memory implementations.)

[ Parent ]
Stack (5.00 / 1) (#131)
by bugmaster on Sun Mar 23, 2003 at 04:56:08 PM EST

Actually, a highly modularized system will bog down even with the simple call stack system. I agree that, in principle, four modules could be doable. However, I was under the impression that the original proposal would make dozens of modules. Input devices, graphics hardware layers, graphics draw surfaces, polygon methods, UI toolkits, window managers, sound mixers, etc... all these would be modules (and most of them would be part of X). If you wrap every function call in a TCP/IP layer, everything would bog down.
[ Parent ]
You're making my head hurt (5.00 / 10) (#93)
by fluffy grue on Sun Mar 23, 2003 at 01:25:48 AM EST

Out of curiosity, what sorts of graphics and UI programming have you done? You start out with some pretty good basic bits (which are almost truisms), but then delve into territories which show a lack of a grasp on how graphics programming actually works.

Why would you separate pixels, lines, splines, etc. into different "layers?" That just makes no sense at all, unless you think that we're all going to use CAD programs for all of our daily work.

Why would you represent all 3D stuff as display-generic application-independent volumetric stuff? Volumetric data takes a LOT of memory (256x256x256x32bpp takes 256MB of memory at a minimum) and is a pain in the ass to render. Graphics hardware isn't optimized for rendering voxels, and it's not anything that's really worth optimizing for either (unless you think that everyone in the world is going to be looking at MRI scans or something).

Why would you rewrite Xt? Xt itself is still a toolkit on top of Xlib. GTK is not based on Xt. Qt is not based on Xt. They both call Xlib directly (well, in GTK's case it calls GDK which calls Xlib on X11, or GDI on Windows, and so on). There's no need to replace Xt because it's already been replaced.

You also don't seem to understand what Xt actually does.

In any case, you can run Qt apps without X, thanks to embedded Qt. Which exemplifies the point I think you're trying to make - that you code to an API, not to a protocol, which is true.

But the rest of what you said seems to be a lot of aimless Slashdot-style ego-wank from someone who has just enough knowledge to be dangerous...

"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

My degree is in maths & computing, (4.00 / 3) (#125)
by jd on Sun Mar 23, 2003 at 04:02:27 PM EST

And a full 1/3 of the honors course was in computer graphics and computer vision.

The reason for keeping algorithm methods seperate is that you then have a clean way of removing lines. You don't redraw them in background, pixel by pixel, redraw any other points that overlap, and then hope you didn't miss anything.

Drawing a layer at a time - not unlike the way Disney animations were originally constructed - allow you to cleanly move specific shapes without reference to other shapes they may overlap with.

Ideally, you'd have exactly one layer per algorithm per sprite, where a sprite is one definable image unit. However, cycling through that many layers would kill most procesors, even though it would be the cleanest of all.

[ Parent ]

Modern graphics hardware doesn't work that way (5.00 / 3) (#126)
by fluffy grue on Sun Mar 23, 2003 at 04:07:12 PM EST

You'd have to recomposite everything anyway, and it's much more powerful and flexible to just have the application say how to redraw the thing rather than by putting things into "layers" like that.

I think your honors courses didn't do a very good job of teaching you this stuff. You should ask for your money back.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

How is it more powerful? (3.00 / 3) (#128)
by jd on Sun Mar 23, 2003 at 04:27:46 PM EST

With a layer system, pixels are differentiated from vectors from curves, etc.

Why sych differentiation? Because without it, you DO need to tell the graphics system how to redraw your image. With differentiation, the computational aspect of redrawing is kept distinct from the computational aspect of composing.

Most monitors are 2D and pixel-based, which means that drawing on monitors is limited to pixels. Right? Actually, wrong. Anti-aliasing operates by super-sampling, and then merging boundary pixels together, so no actual boundary layer exists. Here, we are using pixels, but we are definitely operating beyond mere point-based images.

Most monitors are this way. Some aren't. Vector displays do exist, and at present you're not going to see X running on them. They're unusual, though. Plotters are more common, and this time aren't even vector based. They take functions.

What's all of this got to do with displays, though? This is a hard one to describe well, but I'll do my best. The longer you hold off turning your abstract image data into an actual image, in the "correct" format, the more formats you can display in.

In other words, if your graphics data remains a mix of all formats, right up until the point at which it gets transferred to the output device, and THEN gets translated, you don't have to care what that device is, how it operates, etc. Your image, at all other points, is utterly display-independent.

Moving images are another problem. How do you know what part(s) of an image to update? The idea here is that you don't care what parts you need to update, until you do the display. Until that point, there's nothing visible to look at. If you alter the function of a spline, you don't care. You only care that, when the image is turned into a displayable, that any change(s) that cancel out don't get updated, and those that don't do.

You can't do that with a pixel-driven system, because of the blanking that you've got to do to eliminate the old segment. If you update two components at the same time, you get a race condition. An element is displayed only if it processed AFTER any other necessary blankings that would have incorrectly erased it.

You've seen the "trail" effects of rapid motion on terminals, where image borders aren't correctly cleared. That's because they turned things into pixels too soon, and therefore had no way of knowing for certain what pixels needed to be changed.

This system is 100% proof against that, because the internals retain image-specific data that has no meaning in a pixel-specific presentation.

[ Parent ]

Please stop spewing, and learn about this stuff (5.00 / 5) (#132)
by fluffy grue on Sun Mar 23, 2003 at 05:00:27 PM EST

You "tell the display how to redraw" through a callback or event loop or whatever. The days of using displaylist processing are long gone.

The problem with displaylist processing stuff is that you become very limited in your expressiveness. What if you want to intermingle pixel- and vector-based stuff? If you use "layers" then it becomes very difficult to do so. If you just use primitives, then it's extremely easy to do.

Also, earlier you said that "most 3D applications use voxels." This is total bullshit. Almost NO 3D applications use voxels. They are cumbersome, slow, require a LOT of memory, and not nearly as expressive as rendering things as polygons.

As far as "format conversion" and so on, that's just a function of your rasterizing/vectorizing/whatever backend. Typically the way it works is you send a bunch of primitives to your display and then tell it when you're done, and then the display driver figures out the way to draw it.

"This system" is 100% proof against NOTHING, and it's just a return to the crappy Tektronix way of dealing with things in displaylists.

Basically, you have no idea what you're talking about, and yet you keep on spewing off on these topics trying to look intelligent and insightful as though you actually do understand these things.

Implement a GUI toolkit the way you propose. Then implement a drawing program on top of that GUI toolkit. Good luck not suddenly realizing how utterly fucking STUPID your assertions of "perfection" they are.

Also, different applications demand different ways of interacting with the display.

Also, the "trail" effect is something which is excruciatingly easy to solve using double-buffering. You might not have figured out how to fix it without rewriting the entire graphics processing methodology, but that doesn't mean it hasn't been fixed many, many times!

If you want my credentials on this, I am working on a PhD in realtime 3D graphics, and I have been coding realtime 3D graphics stuff since before OpenGL even existed, and when "hardware acceleration" meant having a coprocessor for drawing lines and maybe overlays. The first software-rasterizing 3D engine I wrote is still a wet dream by the standards of most of the people who post their stupid landscape rendering screenshots to Flipcode, and even then, a stupid, trivial landscape renderer is something which can't be handled by what you propose.

I have worked in HCI, and have done GUI programming for various small commercial companies. I have written GUI toolkits for performing nice fast low-latency windowing under DOS. I have worked with more windowing toolkits than many people even realize exist. I have worked with displaylist-based terminals such as Tektronix. I know what works, and what doesn't work. What you propose doesn't work.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

You rock, (5.00 / 1) (#176)
by Slothrop on Wed Mar 26, 2003 at 08:52:32 AM EST

and you're 100% right.  But I think that you might be falling victim to a troll.
Provide, provide!
[ Parent ]
Linux: the hype is over (1.28 / 52) (#73)
by A Proud American on Sat Mar 22, 2003 at 02:52:33 PM EST

According to the latest Gartner group research report, the Linux hype is finally over. Research shows that market share of linux-driven production servers on the internet has finally declined to a single-digit number. The reasons for this are clear:
  • Linux is very unstable
  • Linux has a very unreliable filesystem
  • Everybody uses Windows or BSD, nowadays
Research has clearly pointed out, that although there are still hordes of pinguin-dressed geeks running around MIS departments, the management has grown wise and doesn't even allow Linux workstations anymore, since the costs in maintaining these machines turned out to be astronomically high. The reasons for this are clear as well.
  • Installation is a pain in the ass and it usually takes a whole support team to install a geeks' workstation
  • Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require
  • Linux was deliberately made completely incompatible and inoperable with turnkey solutions like MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.
  • Web applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable and headaching complicated. Once developed and debugged, nobody is able to understand the code.
Therefore, it has been statistically proven that most companies have already moved away from Linux. All the 'geeks' wearing tux t-shirts re actually MIS support guys who are still studying for their MCSE exam. 'The screaming fast linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production net since every linux (l)user seems to need nmap to perform normal work-related computer operations. All the 'cool' apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. ) And, for the rare instance where a free unix is actually used in a production environment, management has smartened up and BSD is usually installed.

The weak are killed and eaten...

Rated: 1 (Delusional) n/t (2.00 / 2) (#74)
by Hatamoto on Sat Mar 22, 2003 at 03:31:30 PM EST

"Innocence is no defense." - Federal District Judge William H. Yohn (People v. Mumia Abu-Jamal)
[ Parent ]
"statistically proven"!! lol, nice troll (4.00 / 2) (#75)
by lurker4hire on Sat Mar 22, 2003 at 03:37:41 PM EST

... a bit blunt though. Although I guess that goes with your style.

[ Parent ]
on a sample size of 1 I'm sure [n/t] (1.00 / 1) (#106)
by martingale on Sun Mar 23, 2003 at 04:53:09 AM EST

[ Parent ]
Linux was deliberately made incompatible.. (3.00 / 2) (#76)
by porkchop_d_clown on Sat Mar 22, 2003 at 03:39:32 PM EST

Well, Duh!

Except you forgot to mention that it's been MS that has been working to make Linux incompatible, not the Linux community.

You can lead a horse to water, but you can't make him go off the high dive.

[ Parent ]
You forgot Solaris (2.50 / 2) (#77)
by yosef on Sat Mar 22, 2003 at 03:57:10 PM EST

Thus proving your head is up your ass.

[ Parent ]
K5 getting trolls now? (4.00 / 2) (#83)
by phobos18 on Sat Mar 22, 2003 at 06:47:07 PM EST

Whats the world comming too... Seriously!.....

[ Parent ]
uhm... (3.00 / 1) (#89)
by Work on Sun Mar 23, 2003 at 12:35:28 AM EST

id venture to say the majority of posters fit the troll category. Certainly the most prolific ones.

[ Parent ]
This MUST be a joke, right? (2.50 / 2) (#105)
by MalTheElder on Sun Mar 23, 2003 at 04:47:23 AM EST

Because it is pretty funny if you don't take it seriously. Of course, if our Proud American IS serious, then he/she/it is quite deluded. If this were /. instead of K5 I'd mod it up based on its humor.

Have a nice war,

[ Parent ]

From A Proud Slackware User (none / 0) (#182)
by mmsmatt on Fri Apr 04, 2003 at 10:39:08 PM EST

Sorry man, but half the web still runs Apache.

Slashdot had an intriguing article a few months back about how IIS and IE cooperate to mess things up, why don't you slide on over there and check it out.

Here's a nickel. Buy Gartner some gcc.

[ Parent ]

Isn't forking the essence of GPL? (4.00 / 2) (#107)
by levsen on Sun Mar 23, 2003 at 05:38:34 AM EST

Unless I understood it completely wrong, the point about the GPL that OSS people are constantly droning about is that licensees can take the code and modify it, that's how it's free in speech vs. free in beer. And you can obviously do it AGAINST the will of the copyright holder, there is no point in coming up with a license where you need the copyright holder's approval for anything.

But isn't that what forking is? So some people are taking the FSF/GPL by their words and treating GPL'ed code as free as in speech, not only free as in beer, and all of a ruckus starts about it.

The GPL is PRECISELY there to keep competition up, this gives Richard Stallman in the linked letter away as a complete hypocrite (see near the end where he denounces competition).

This comment is printed on 100% recycled electrons.

XFree86 isn't under the GPL (nt) (4.00 / 2) (#119)
by fluffy grue on Sun Mar 23, 2003 at 12:21:11 PM EST

[ Parent ]
Ok but even GPL'ed projects ... (n/t) (4.00 / 1) (#141)
by levsen on Sun Mar 23, 2003 at 08:23:57 PM EST

... complain about forking, such as the mentioned XEmacs/Emacs.
This comment is printed on 100% recycled electrons.
[ Parent ]
Well, yeah (5.00 / 1) (#145)
by fluffy grue on Sun Mar 23, 2003 at 09:12:19 PM EST

But a better comparison is *BSD or Apache, since XFree86 is under the MIT/X11 license (which is basically BSDL). Also, XFree86 has forked many times in the past, by commercial vendors; Metrowerks AcceleratedX, Xi Graphics, Apple X11.App, Cygwin/X11, and I'm sure many others are all forks of XFree86, and so far Cygwin/X11 is the only one to actually still be opensource.
"Is a hyperlink" is a hyperlink.
"Is not a quine" is not a quine.

Cats: Nature's entropy generators

[ [ Parent ]

not quite (4.50 / 2) (#134)
by ryochiji on Sun Mar 23, 2003 at 06:18:27 PM EST

>licensees can take the code and modify it, that's how it's free in speech vs. free in beer. And you can obviously do it AGAINST the will of the copyright holder

But isn't that what forking is?

No, that's not what forking is. Forking is when a project branches off from the main project in a completely separate direction, usually due to disagreements in the direction of the project that can not be reconciled. In many aspects, it's kind of like a civil war, or one chunk of a country seceding from the other. In other words, it's usually a bad thing.

Why is it a bad thing? It's not necessarily the competition that makes it bad, but the mere fact that a project being broken in two is usually a bad thing, both for the project and for the users. The project loses because both the original and the fork will have less developers than they did before, yet the scale of the project remains the same. It's bad for users because, all of a sudden, you have two separate products that may not be compatible with each other in the future (this might not be a problem with some software, but with others like X, it could be).

BTW, I would disagree with the author of the original story who said that Phoenix and Camino are forks of Mozilla. I don't know if that's what the official position is, but at least with Camino, it's a completely separate browser that happens to use the Gecko rendering engine. Since it never started with the entire code-base of Mozilla (AFAIK), I wouldn't consider it a fork.

IlohaMail: Webmail that works.
[ Parent ]

Well I don't know (5.00 / 2) (#144)
by levsen on Sun Mar 23, 2003 at 08:58:22 PM EST

your point is not coming across very strong. Is it a question of the magnitude of the differences between the two pieces of software? Then maybe you are also one of those people that complain about 52 different cereals in the supermarket and say that this choice doesn't add much to your quality of life. But you can't say that the "scale remains the same" since the two things will later do more than the one thing before.

Or is forking defined in terms of people, i.e. it's only forking when the forked piece of software is developed by some of the original people on the project, whose resources are not available to the original project anymore? In that case you are forgetting that people "fork" because their ideas and concerns haven't recieved much attention in the original project, and were therefore wasted.

See also my other comment.
This comment is printed on 100% recycled electrons.
[ Parent ]

Wrong, X got it wrong (3.00 / 2) (#108)
by levsen on Sun Mar 23, 2003 at 05:44:37 AM EST

In any cooperation between two pieces of software (communicating over a wire or not), both pieces "provide" something, i.e. in your definition are they servers.

X "clients" are usually applications. Let's say it's a calculator program. Then the calculater app "provides" the computing resources to add 1 + 1 and the X terminal provides the display resources to display the result.

The definition hinges more on who initiates the cooperation. The one who initiates is the client, servers sit there and wait for request from clients to which then they respond.

In any X environment, this cooperation is usually started by the terminal side, because that's where the user sits. The terminal is therefore the client.

P.S. Similar the definition of "upload" and "download".
This comment is printed on 100% recycled electrons.

Ok beat me (2.00 / 1) (#109)
by levsen on Sun Mar 23, 2003 at 05:54:07 AM EST

This comment was supposed to be in reply to this.
This comment is printed on 100% recycled electrons.
[ Parent ]
Heh. (4.00 / 1) (#139)
by Znork on Sun Mar 23, 2003 at 07:38:35 PM EST

Well, I noticed it anyway.

Anyways, in X programming the client ("application") requests access to the resources the server provides. It requests a display context and that input events pertaining to its display context be sent to it. The display server provides and mediates access to display and input resources for many such clients. This perfectly fits the generaly accepted client/server relationship, and matches your description well.

Where this cooperation is physically triggered does not really bear upon the relationship between the pieces of software. The X server itself is not involved in the launching of an application when the user clicks his launch icon. It merely sends an event to the program displaying the icon, which then launches the application, which in its own turn will connect independently and request access to the X display server.

[ Parent ]

X Server (4.00 / 2) (#146)
by drquick on Mon Mar 24, 2003 at 03:58:11 AM EST

There is one X server providing services to many clients. That's why the realtionship is the way it is. Most other graphics systems accept only one client. In X the networking of clients over the LAN is done by the X server, thus its a server. The whole X server/client thing is a network perspective on things.

[ Parent ]
Fork because only API is outdated. (3.00 / 4) (#116)
by drquick on Sun Mar 23, 2003 at 10:25:04 AM EST

"This fork also raises the question of how relevant the X Window system really is. Do we need another implementation of this window system? Many think that it is at best outdated technology. Why not develop a single windowing system for Linux that fully takes advantage of the latest hardware?"
I happen to believe X is outdated! But a fork can solve all the problems. The problem in X is the API. given the API calls that are in the X11R6 standard you simply cannot write code that fully uses the potential hardware accelerators offer. You need more informnation in the API, such as move and pan commands. 3D commands in the API would also be welcome. Rendering of fonts would need a better control of the font type, size etc. While we are at it, maybe (just maybe) remove all those slow bitmapped X calls that some applications use. X could have hierarchical display objects. All of this is just an API issue, adding another layer of code on top of XFree86.

As such XFree86 is not badly written. In fact i think the code is great! X11R6 standard is not. It would be possible to rewrite the API part of it, and leave the parts close to hardware intact. You might argue that X is the API. Umm... as for the X11R6 standard yes, but as for XFree86 code base not.

It's there, and it's called GLX (2.00 / 1) (#175)
by avery on Tue Mar 25, 2003 at 09:05:42 PM EST

..thank you very much.

[ Parent ]
So what the hell is wrong with X? (4.60 / 10) (#137)
by kmself on Sun Mar 23, 2003 at 06:54:20 PM EST

I've just been engaged in a discussion of what's wrong with X and XFree86 at zIWETHEY. Lightly adapted.

I've seen a lot of instances of people grousing about X. I've seen few suggestions for improving the situation which seem to be both better and workable. In particular, cutting network transparancy from the graphics subsystem, or positing projects like Fresco as replacements, seem very poor alternatives.

The suggestions in this discussion that problems with XFree86 with XFree86 be addressed by opening up the development effort (or possibly forking it), and by modularizing the system further, do seem like useful ideas.

While (some of) the XFree86 folks seem to think that network transparency is irrelevant to "the majority" of desktop GNU/Linux users (that would be accomplished by 50%+1 users), I'd say that this isn's something I'd toss lightly. Network transparency is very useful, and lends itself to numerous neat hacks.

Among them:

  • Dickless (diskless) workstations. Suck your apps over a remote link, display locally.
  • Local users sharing displays.
  • Multiple users sharing displays.
  • XNest. Running X-in-X sounds pointless...until you need to run at a different color depth, want to try another WM, or otherwise need to put a graphic environment in its own sandbox.
  • Display of remote apps on a local display.
  • Above. Tunneled through SSH.
  • Moving applications between displays (xmove).

The main complaints I've seen articulated regarding X appear to be:

  1. The development process has some lumps. This isn't an indictment of X, but of the XFree86 team. I won't say that this is fully independent of other aspects of development (e.g.: architecture, licensing, code quality), but it's a loose corrolary.
  2. New hardware is supported slowly. I don't know enough of what's going on here to comment meaningfully. The problem appears to be, however, a mix of vendor fuckwittedness, XF86's own internal methods and conflicts, and fnord knows what. When support does emerge, it generally appears to be pretty good -- high resolutions, many colors, good refresh rates. Not sure if there are driver goodies that GNU/Linux doesn't see, but all I want is my 1200x1600 @32bpp, 85Hz.
  3. Performance bogs. I don't run high-end enough video to note this. Peter's the gamer, and doesn't complain about this (and Peter is of course loath to complain about anything that doesn't suit him perfectly...) And Peter responds:
    Aside - On the same hardware, Windows XP's OpenGL performance is slower than that achieved under X. Test application is Quake III Arena. I get 100FPS at 1024x768x32 (full detail + trilinear + 2xAA) while I only hit 90-95 under Windows with the same settings. This is a dual boot box, so hardware parity is absolute :-)
  4. Configuration. In particularly, on-the-fly reconfiguration of X resolution and refresh [Note: I've just learned of XRAND in this topic today, need to look into it]. Somewhat obviated by the ability to use XNest and multiple displays. I don't use the latest'n'greatest GNOME/KDE stuff, just Debian's dpkg-reconfigure xserver-xfree86, which walks through some pretty clear menu-driven options. I'll grant though that this remains a disadvantage, largely minimal though. Knoppix addresses this by managing everything automagically -- even lets you specify your resolution and/or refresh at boot, and configures to spec. Well, sometimes. I've found resolution specs tend to be followed, but my refresh preference (85Hz) usually isn't.
  5. Inconsistent interfaces. This speaks more to X's history, longevity, and success than anything else. X has Been Around the Block. And survived. There have been a number of different toolkits -- Athena, Motif, Gtk, Qt, Tk -- each being suited to its time. While there's a level of confusion and configuration complexity which results, this argument boils down to the premise "choice is bad". Sorry, I don't ride that bus.
  6. Display postscript / AA fonts. Again, this appears to be something that's being addressed, possibly in piecemeal fashion. But there are now desktops with integrated DPS (e.g.: GNUStep) and AA font support (e.g.: KDE).
  7. Programming interface. I hear a lot of grousing over this, but there are tons and tons of apps written for X. I can't speak to this as I'm not a programmer, but the problem hardly seems insurmountable.

Anything else I'm missing?

Any replacement for X would have to address several issues:

  • Backward compatibility. X apps would have to be runable. Preferably transparently, not in a separate box ("unmanaged mode", in the typical lingo of X server vendors). There's a huge library of existing X apps, and none for any of the potential replacement system.

    It's suggested that this can be addressed in a replacement system. Possibly, but this creates a hornet's nest. Andrew Grygus writes:

    In any case, I see no reason why people who need the capabilities of X can't continue using X, but for "normal desktop users", much of the X stuff isn't useful, but raw performance, smoothness and ease of programming are very useful for a number of application types.

    If apps need to be specifically targetted at one system or the other, and if Fresco doesn't provide network transparency in a model at least superficially similar to X (e.g.: client -display host:0), this isn't sufficient, as there's now the very significant threshold barrier of either writing network-transparent apps, or apps for the system which aren't backwards-compatible to X. I see this as a killer.

    And Peter Whysall notes:

    Microsoft are starting to wedge ideas from X into Windows - witness the emergence of RDP and, on a more useful level, the ability of Citrix Metaframe XP to throw a single application window across the network.

    [Network transparancy is] irrelevant to most users, my arse. Irrelevant to *home* users, I'd buy. App servers and Citrix products are starting to become common again in corporate computing. Gryge - one bloke's disillusionment with a dead development model is NOT an insightful comment into the state of the art of graphical user interfaces.

    Andrew again:
    "Choice" is what open source is supposed to be about, and if a good measure of compatibility can be maintained between two environments designed for users with different needs, I think that would be excellent.

    Absolutely. I don't think you're interpreting my comments as opposing choice or dictating X. I'm not doing either. Rather, I'm indicating that any alternative will be dead in the water until it addresses (or overcomes by other means, e.g.: massive cash infusions from elsewhere) these structural / systemic issues.
  • Network transparency. The new system will have to be network transparent. Otherwise, you're writing apps for either X or the new system. And network transparancy is sufficiently useful (see above) that it's going to persist, or the replacement won't be adopted. The issue of apps being bidirectionally compatible may be an issue as well. More significantly: network transparency is most valued by skilled, technical, and power users. These are the same folks who do the bulk of development. This will impact uptake and architecture in no small way.
  • Seperation of mechanism and policy. X is a useful model for developing displays for many types of platforms -- the GNU/Linux-based handhelds, for example, run X. If GNOME is overkill for a 260x140mm display, rather than rewriting all your apps, you just slap a different WM on top of it. And despite the prevalence of GNOME and KDE, there are many people who prefer different window managers (I'm highly partial to WindowMaker. Tilly likes FVWM2, Peter was fond of XFCE, but he changes desktops faster than I swap grilfs). Of course, seperation of mechanism/policy is one of the frequently iterated criticisms of X. Grossly misplaced. Uniformity buys, well, uniformity. At a huge loss of flexibility. Approximately 100%
  • It most be overwhelmingly superior. Free software vastly favors incremental enhancement, particularly over core, and deeply-integrated components, over revolutionary development. Even where options can be fairly painlessly swapped out, say filesystems, migration is slow. Look at the uptake of journaling filesystems. This changes virtually nothing in the day-to-day use of a GNU/Linux system, but I'd still warrant use of ext2fs is the majority. Switching to ext3fs is transparent (well, with kernel support). Reiserfs offers more benefits for a one-time copy-off-and-restore penalty. My bet is this: $100 says X11 is still the basis of the predominant GNU/Linux desktops in ten years. Too much inertia, too few benefits, too much uncertainty.

And I really am interested in responses, commentary, criticisms, or corrections. I keep seeing this matter raised. I see little clear articulation or benefit from alternatives I've seen posed though.

Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

Good idea, bad design (4.00 / 2) (#156)
by hardburn on Mon Mar 24, 2003 at 01:30:30 PM EST

I agree with you about the network transparancy. With cheep, high-powered computers combined with old equiptment and low-cost networking, we're just getting to the point where the network transparancy can be useful to home users (the setup has to be made easier for most people to use it, though). Let's keep the network stuff in any replacement to X.

What I hate is the overall design of X. "Obsolete" is an understatement--it didn't even look that good to begin with. It should have stayed as an academic undertaking in windowing systems, not as a commerical GUI for typicall users. Look at all the problems that GNOME and KDE have historically had with cut-and-paste operations, just for starters.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
OSS develop (4.00 / 1) (#142)
by levsen on Sun Mar 23, 2003 at 08:52:03 PM EST

Yes I know XFree isn't GPL, but since those people's attitudes seem to be in line with what I've seen elsewhere (the XEmacs issue was mentioned) I'd like to comment on something more general here:

I really don't like the whole complaining about forking, since there seems to be an underlying, unspoken suggestion that OSS development is in a constant state of crisis, the Davids having to beat the Goliaths, and "we therefore need to cooperate by all means", even if it means having to accept minor annoyances such as working under a dictator (project boss, i.e. Richard for Emacs), because "we can't afford" competition within the OSS community. That's exactly the same mindset that made communism work.

I bet the GPL was forged with a commercial vs. OSS black-and-white world in mind, and its only concern was that the commercial world doesn't exploit the OSS world. Now when some OSS developers are now taking the GPL by its word and take the code to compete with other OSS developers, they act surprised. Go back and read the letter by Richard about XEmacs and tell me if you see the same.

I haven't done any OSS development yet, but I am thinking about it, and primarily because of the competition issue. I have seen huge commercial projects go down that IMHO could have been saved if only there was a little internal competition.

This comment is printed on 100% recycled electrons.

GPL not forged as an OSS license (4.00 / 1) (#155)
by hardburn on Mon Mar 24, 2003 at 01:23:52 PM EST

The GPL was written before the OSS term was coined.

"Free Software" and "Open Source" are not synonyms. Free Software says that making code free to use is an end to itself. OSS says that freedom can have financial incentives. If, in a specific case, freedom doesn't give financial gain, then OSS says it's OK to dump it in favor of something propreitary. In short, OSS is pragmatic, and Free Sofware is altruistic.

The Open Source Initiative maintains a definition of what a license has to do to be considered "Open Source" ("Open Source" is a trademark, and illegal to use to describe your license unless it conforms to the OSS definition). This definition is based on the Debian Free Software Guidelines. The GNU project also maintains a Free Software definition. You'll notice that the differences between the OSS definition and Free Software definition are minimal. OSS tends to interpret them more liberaly, so if your license falls under Free Software, you should have no problems getting it OSS-approved. But an OSS-approved license may or may not work under Free Software.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
Sorry for the confusion, but ... (none / 0) (#183)
by levsen on Sun Apr 06, 2003 at 08:51:52 AM EST

does this difference matter with respect to my original comment?
This comment is printed on 100% recycled electrons.
[ Parent ]
Nothing is wrong with network transperancy (3.00 / 1) (#179)
by jeremyn on Thu Mar 27, 2003 at 01:45:17 AM EST

If there would just be a _modern_ graphical system(not X, not windoze) that had network transperancy, and real hardware accleration, and maybe a plugin interface(compression for using X over dial-up, even 100mbps ethernet could do with it) then I'd be using it. And that uses autoconf. *ahem*

Another point of view. (4.00 / 1) (#180)
by avery on Sun Mar 30, 2003 at 10:09:45 AM EST


The Future Of XFree86 | 184 comments (150 topical, 34 editorial, 0 hidden)
Display: Sort:


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!