The XFree86 Fork() Saga Continues 580
Mortimer.CA writes "An article up on OSNews about the XFree story
mentioned earlier. Included is: replacing fontconfig with Sun's stsf; XFree86 co-founder David Wexelblat saying that XFree is today obsolete and should be changed; Keith Packard replying, and more."
All I can say is..... (Score:5, Interesting)
You know what? (Score:5, Interesting)
Or another possibility: maybe the way XFree86 is currently implemented by the major *nix vendors is overly complex by default.
Either way, both the situation and the implementation are starting to look really messy.
Do you recall Armageddon ? (Score:2, Interesting)
well you could easily come up and tell me to simply not use GNOME and let them do whatever they like. Well, you are right with that but things are more complicated nowadays. GNOME is influencing a lot of third party projects such as XFree86 which recently added a lot of GNOME components into their CVS repository. Please know that with the next coming XFree86 version you get a lot of GNOME components without even knowing it. code like, GNOME-XML, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into GNOME development. Also the GIMP is maturing more and more into getting the look and feel of a native GNOME application. The CVS version of the GIMP has a lot of GNOME pixmaps inside and they are heavily working on integrate the GIMP into GNOME. If not today but the direction is sure and i fear the day this gonna happen.
And this will happen with an Forked XFREE. It matures more and more into a GNOME dependant piece of Software. Exactly that guy who's responsible adding all sorts of GNOME material to it will now make XFREE mature into some GNOME dependant component.
Havoc Pennington (GNOME) works on XFREE,
Owen Taylor (GTK+) works on XFREE,
Jim Gettys (XFREE) and GNOME FOUNDATION president,
Keith Packard (XFREE) and GNOME developer.
Video-Card-Centric clearing houses (Score:5, Interesting)
The thing is, drivers can be released independently of X itself. For ATI Radeons, for example, there are at least 3 different drivers they can use. It would be nice if somebody set up a website with a page for each video card (or family of cards) that had links to all of the available video drivers for that card. Even better would be if such a website could act as a catalyst for uniting these independent driver developers so that, for example, the GATOS radeon driver developers and the DRI radeon driver developers could combine the best aspects of their drivers. This could possibly help route around the blockage that the XFree86 project too often represents.
Actually, I think that such "hardware-centric clearing houses" would be useful for all kinds of hardware, not just video cards. Look at linuxprinting.org to see how well it can work.
-DA
Obsolete? (Score:2, Interesting)
X is obviously turning obsolete (Score:5, Interesting)
I still remember the transition from X10 to X11.
However, version 11 is almost 15 years old and we
never saw any version 12 (not that I beleive version numbering is any important).
Although I saw some nice extensions being added to the X protocol, there are many parts of the X window system that are now obsolete.
For instance the standard X11 font rendering system looks like it has been kept in the stone age (only recently the Xft extension solved part of the problem).
I really like the network transparency of X and the client-server model, because of all it's advantages and, if you look at it in detail, you will be surprised that it doesn't impose any performance penalty: because of the way the X protocol is implemented, commands are queued by the client and are sent to the server in batches, in order to minimize client/server context switching.
However, in the last 12 years we have seen the graphics hardware improove a lotm but the core X system didn't improove almost anything.
Now we have hardware capable of displaying full motion video, hardware video decompressing, anti-aliasing, alhpa-blending and transparency, 3D, etc.
Meanwhile, X got some extensions to support some of these features, but there are no "standard" APIs and the evolution has been very slow.
X is great, and many of the complaints about X that I regularly read here in
Re:STSF Looks Pretty Cool (Score:4, Interesting)
Maintaining XFree86 (Score:5, Interesting)
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB [directfb.org] without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
Can you feel the Love? (Score:2, Interesting)
David Wexelblat (a XFree86 founder) writing of Keith P:
"What Keith has done is among the most low-class, unprofessional, and
tactless things I have ever experienced in my professional career. While
still a member of the XFree86 Core Team, he has explicitly attempted to
subvert XFree86 by soliciting individuals and corporations to create an
alternative to XFree86. Including inviting certain Core Team members to join
him. At no time did Keith ever discuss his issues with the Core Team or
Board of Directors. When confronted with his actions earlier this week, he
blatantly lied to the Core Team about what he was doing. When his
solicitation email was sent into the Core Team list, showing the blatant
lies in his previous assertions, he stopped responding.
But what Keith is doing, at least how he's handled it, is just flat out
wrong. It's literally dishonest, and morally repugnant."
Go Keith! (Score:5, Interesting)
Linux is utterly irrelevant to the majority of "real-world computer users", people running MS Windows and MS Office. But client-server displays are highly relevant to the core areas where Linux and UNIX is being used: scientific and engineering apps, large multi-user servers, compute clusters, large business apps, public computer terminals, and server applications.
X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented.
Does Wexelblat even have a clue what he is talking about? What is more "direct rendered" about the graphics subsystems of other desktop operating systems? All display subsystems these days run in separate address spaces, all of them involve context switches for rendering, and all of them (including X11) can use shared memory and direct hardware accesses when it makes sense. Microsoft and Apple are finally beginning to catch up with X11, except that their systems are burdened with much more junk that is necessary for them to be able to pretend to being a 1970's style frame buffer library. Furthermore, in terms of the graphics subsystem, those supposedly "direct" systems can easily be remoted--the reason why they aren't is because they lack all the other conventions and infrastructure that X11 has for multiple displays and client communication.
And these kinds of replacements have been tried numerous times before. People have always chosen X11, even if it meant uninstalling vendor-supplied GUIs and installing MIT X11 from sources (which is no mean feat). X11 has survived against all odds, because it satisfies the needs of its users well.
That is not to say that X11 is perfect--far from it. Its protocol has warts and it has its own share of historical baggage. But those problems have nothing to do with "direct rendering".
I had no opinion about whether Keith's leaving XFree86 made sense or whether it was justified before reading Wexelblat's posting, but Wexelblat has removed all doubt: with idiots like Wexelblat on the XFree86 team, XFree86 has no future. All I can say: Go Keith!
Maybe a stupid question... but: (Score:2, Interesting)
Just some thoughts anyway...
Re:Origins of XFree86 - been there, done that! (Score:5, Interesting)
Is it just me or is it a little bit cheeky that David W has a say in this at all. It's not like A) he is hacking Xfree anymore, or even using UNIX for that matter. He's been using Windows since Myst came out, for crying out loud. I read the emails, and when you have folks like Keith, Alan, Owen, and Havoc complaining about how XFree is run then isn't it likely that something is actually wrong?
Re:fork() power (Score:1, Interesting)
Re:Video-Card-Centric clearing houses (Score:2, Interesting)
The point of this is that the folks actively involved with the bigger picture of a project are going to be more aware as to how various pieces need to fit and work together. That's why there's a need for a hiearchy and commit control within any project. I would think this to be especially true for one as large and complex as XFree86.
"""
In many cases I would agree with your point, but in the case of a new driver it's essentially a distinct entity. The author is basically asking for the right to associate his work with the project, not change anybody else's work. If the developers trust him enough to accept his original work it seems silly not to let him make the changes that he feels are necessary after the driver is accepted.
Will he break things with his commits? Maybe, but developers break things all the time, and his breakage will be isolated to his driver and will be his responsibility to fix. If he took the time to write a driver and is asking for commit priveledges then there's good evidence that he'll act in the interest of improving that driver.
Still, I don't disagree with you entirely, which is one reason why I think the clearing-house approach would be valuable. It would allow drivers to be developed independently without forcing users to go scavenging for information all across the web. I suspect it would also encourage better unification for things like installing drivers. Again, see linuxprinting.org for an example of this.
-DA
Re:my suggestion (Score:5, Interesting)
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
Re:You know what? (Score:1, Interesting)
Just because you don't understand how to build XFree86, and think it takes a long time, you claim that XFree itself is flawed?
Hmm, maybe I should stop using FreeBSD then, because compiling world on that takes a very long time and I don't understand all of what exactly happens.
Then you complain about the monolithic nature of the X build process and what you'd like to see happen. Well, the source is there, man. Make it better if you can. I dare you. Impress us. Oh, and while you're at it, split up teTeX as well, it's a whale too.
On the other hand, there are packages (.deb/.rpm/whathaveyou) or (heh) ports/pkgsrc/fink entries for most operating systems. Try installing just the X11 libs from packages, the development headers, the base fonts and the server you need, leave the contrib packages alone, have a coke and a smile, and shut the hell up.
I've seen Keith's code, and it's very tidy and neat (well, neater than the crap I usually pull). He might not like GNU autoconf/automake, I don't either. Just because an application doesn't use GNU autoconf to "aid" in it's build process, doesn't mean the app itself is crap.
[\rant reason="irritated by cluelessness"]
Dear Keith... (Score:5, Interesting)
...after reading your long message, and also reading David Wexelblat's message, and reading all the stuff that came before, it's pretty clear to me: the X Core Team doesn't want to talk. They don't want outside input, they've deluded themselves into thinking that other Open Source projects are just as closed as they are, and they really don't see where all these outsiders get the right to have an opinion. They ask why you (Keith) didn't open a discussion with them, but then act hostile to nearly everything that is discussed.
I don't know how to write a driver for X, but I do know people. And you're banging your head against a wall as long as you try to work within their system. Good luck with whatever you decide.
Re:The Killer App (Score:5, Interesting)
Here at home I have one high-powered machine. Some of the time I access it directly. Some of the time I access it from the kitchen or the living room via JavaStations (
At work we have a pair of high-powered servers. One is a production box; the other is development. 9 people work on it all day, ever day. Some just ssh in and use screen; some ssh in and then run X apps remotely; some run full-on KDE sessions. All are using cheap, throwaway PCs from other departments. How? Because X is NETWORK TRANSPORT designed to make EFFICIENT USE of POWERFUL MACHINES for MULTIPLE USERS.
The quote goes: "Those who do not understand UNIX are doomed to reimplement it, badly." I propose a corollary: "Those who do not understand X are doomed to bitch about it unto Eternity."
Re:Maintaining XFree86 (Score:4, Interesting)
Before anyone gets confused, lets be clear and point out that this is the IT equivalent of a theory. Basically, we are told the client should be just smart enough to render controls and pass input events back to the server. This is theory because there are no implementations of this in widespread use.
The quote suggests that Bonobo or Kparts would implement the client side controls. These controls are then driven from the server via RPC or some other mechanism.
Some argue that web browsers could do this. Perhaps. The inherent statelessness of web clients preclude large classes of GUI applications and makes others very difficult. Can you imagine a browser based implementation of, say, Paint? (activex/java doesn't count.) Lots of applications have grids with re-sizable columns, yet common browsers have never provided this without add-ons or substantial hackery.
There have been and are real attempts to make this theory work, however. An excellent example is XWT [xwt.org]. Check it out. There are others, but they're even more obscure and even less likely to ever actually matter.
Why is this? Lots of people have this notion of half-smart clients that provide 99% of "direct" GUI fidelity by rendering controls on behalf of some server somewhere. There is nothing new under the sun. Yet it doesn't happen.
Here is my contribution: Z Windows (I think there is a Y Windows out there,) an evolution of X Windows:
- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.
- It's obvious audio must be integral. Integrate it.
- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.
- Create a standard window manager. All others accept the consequences of being weird. Life is short.
- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.
Now you have a clean, straightforward system that has a good API, sound, good fonts and drivers that are easy(er) to implement. Applications arrive shortly thereafter because your using a worthwhile API.
What about network transparency? Well, in case you haven't noticed, the most widespread use of network transparent GUI is Citrix. It works well, thank you very much. It would work even better if it had been incorporated from the start by the underlying GUI. Citrix is nothing more than a highly optimized screen scraper, much like VNC. It turns out, despite the best thinking on the matter, that this is sufficient for 99.9999% of all remote GUI purposes, and the remaining 0.0001% (high performance graphics work) you want local anyhow.
Congratulations. You now have a worthy GUI system for the next 15 years. Now wake up.
Phooey on network transparency (Score:5, Interesting)
- pluggable implementations (on Linux alone, there's XFree86, MetroX, Accelerated-X,
...)
- better opportunity for security (though I grant it's not often taken)
- cleaner interaction between applications displaying on the same desktop-- most of the "hacks" won't let applications running in different places share a desktop transparently
For that matter, most desktops released within the last 8 years are so slow and bloaty themselves they can't afford a wire protocol abstraction layer between them and the display driver! Try something truly lightweight, like twm or one of the early incarnations of fvwm with something better than those miserable default configurations, and watch your desktop scream, even with X's supposed weight.Re:my suggestion (Score:4, Interesting)
There are other costs. Encoding/Decoding are the big ones. Context switching is another.
The real question is, if you removed these two sources of inefficiency, what would be the actual speedup in terms of graphics performance. For 3D it was lots, therefore the creation of the DRI to provide direct rendering. For 2D? Best guess is almost no improvement at all; the hardware is not capable of going faster. The only exceptions are bandwidth beasts like video that have been solved in other ways.
If somebody wanted to prove the point they could write DRI/X11 as a complement to DRI/MESA.
Re:Choice? (Score:1, Interesting)
Yet we are at an impass. Half of the Unix population loves X for the network transparency, the other half could care less and just want it to draw fast and look nice.
IMHO, we need to ditch XFree completely. Don't ditch the X protocol, just ditch XFree. If we could get a system that supported nice modular drivers, had lightning fast redraws and event handling, and yet still had legacy support for apps using X11, then we'd have something worth using.
Personally, I'm not that impressed by X's network transparency. Sure, I can run an app over the network, but a) I better have all the right fonts; and b) I better hope my system doesn't hang or lose my net connection, because if my system stops responding to all of those X packets, the app on the remote system is killed. I'd be happier to see a clean session detach that could reattached at my leisure. Automatic font transfer would be nice too. Don't have a font installed locally? No problem! I'll just auto install it for your user account.
But, regardless of my bitching, we don't have MagicDisplay(tm) right now. We have X. And being that I use linux as my desktop system, I'm greatful to the XFree team for getting us this far.
X needs a fork (Score:4, Interesting)
KeithP is one of the few people who could make a fork work.
I have a hard time with David Wexelblat who doesn't work on XFree86 and doesn't even believe in it, insulting one of the key developers.
Re:Wexelblat is right, network transparency pointl (Score:2, Interesting)
Re:X design decisions (Score:5, Interesting)
It doesn't have to be a "thin-client" environment. All you need is a networked environment. At my work we are split about 50/50% UNIX and Windows developers. Windows developers are almost literally tied down to their workstations. That's where their environment is so that's where they have to work. They don't even notice it, because it is so ingrained into their thinking.
On the other hand, I have a Solaris and FreeBSD machine in my cubicle, and I can use them from *anywhere* in the company. In fact, I can use them anywhere in the *world* if I would ever bother signing up for remote access authorization. My cubicle is not my prison. I do a lot of work in the development lab, and it is extremely nice to be able to treat any random workstation there as my own personal environment. I can edit code in XEmacs, peruse its documentation in FrameMaker, check it in with ClearCase, and then move on to the next bug with ClearQuest, all while browing the web and checking my email with Mozilla. This is because of X11. My Windows coworkers can't do that. They're always running back to their cubicles to do their work.
Here's another example. A lot of my coworkers use both UNIX and Windows. They all have KVM switches. I hear they're very popular. But since I don't use Windows, I've never seen the need for one. I can run multiple applications from multiple machines on whatever display I happen to be sitting in front of. Without having to beg IT for permission to buy to the software or hardware to do it.
There are two paradigms at work here. One is the "single user on a single machine running locally." The other is "multiple users on multiple machines running anywhere they want." X11 supports both paradigms. Windows supports only the first. Please don't dumb down X11 to the Windows level.
Re:let me add to that... (Score:1, Interesting)
You keep stating that frame-buffer is junk. But if I were Bill or Steve (or any other in charge of technical decisions), I would choose, without hesitation, PDF-based composition engine instead of network-transparancy, because its benefit is way more than that of network-transparency (I prefer ssh and console). Although Apple seems to show off its engine's capability overusing it in all the UI elements, a good example of the benefit is iDVD3 themes which heavily employs transparancy and floating-point based graphics. I will really be suprized and impressed if I see such an app on XFree in NEAR FUTURE. Moreover, I'm not expert at this, but Apple is improve its performance setting the composition engine upon HW accelerated "OpenGL" (Quarts Extream).
It certainly deserves better than 'junk'.
Yes, XFree isn't necessarily slower(despite its unnecesarily large code base and complexity), but is there any reason for it to be significantly faster than, say, that of GDI or Quarts?
XFree has its own strengh, and others do too.
Re:fork() power (Score:2, Interesting)
Compatibility at the X layer is overblown, how many people really run apps from so long ago? Sooner or later you need to cut the ties. A new GUI system compatible with QT libs or GTK would be good enough for most people. The people who want to keep using X can, its not like X11 will completely disappear just because focus shifts to something else...
Re:The key issue (Score:3, Interesting)
-- genuine differences of opinion regarding direction
-- unclear leadership
-- poor interpersonal issue resolution
In any case if you look at his resume [keithp.com] this guy is the kind of guy who should be on an X core team.
So I don't see whether Keith lied or not to be a key issue. His technical issues should stand on there own entirely seperate from whether his tecnique was driven more by anger/hurt or frustration.
Re:X design decisions (Score:5, Interesting)
a) tremendously reliable
b) very easy to maintain
c) offered users tons of freedom
Contrast this with your typical Windows corporate setup. Anything other than total lockdown makes the system entirely unmaintainable. As a result user / desktop support ratios are very high and users and constantly frustrated by how little they can do. Virtually every corporation should be running dumb X terminals. It really would cut costs and empower employees.
Take a simple example like software installation. On a Unix system I can safely let users install anything. The apps they install can't run with any more privs then they have and they can't hurt the system.
On windows OTOH letting people use any printer in the building means they have to have permission to install drivers. Letting people install drivers is:
a) hard because they are forced to understand details of printer models
b) allows them to completely muck their system up
Re:Maintaining XFree86 (Score:5, Interesting)
Here are my suggestions for XFree86:
1. Simplify the server.. let me guess that 90% of the code is redundent, out of date, etc. Really, a nice re-organization of the codebase would make it a lot more coherent. The framebuffer rewrite got me excited, but lets keep going. A basic tree might look like this:
You get the idea.
2. Get rid of font servers. Seriously, integrate font management into X. I mean adding and removing fonts from the server at the user level too.
3. Replace the base rendering model with XRender (or allow a mixture). It's time some of the extenstions moved into the core server (Shape anyone??)
4. Let the server cache graphics list. This will help abstract gtk and qt toolkits from the rendering. That way, a server can be loaded with a description of a button, and take care of the drawing and refresh of that button. I'm _not_ talking NeWS here.. I'm talking "what graphic primitives redraw this component." These lists could be shared between KDE and GNOME. You could create them in SVG and they could be translated to X primitives by the toolkits. Then, toolkits only need to manage a single SVG file. Wanna new look for your desktop, just drop in a new SVG.
5. Modularize the core. Ouch, that will hurt.. but sometimes people want to use X just for a device setup and a framebuffer. (Think embedded). Re-architect around the idea that X is an orchestrator of devices, inputs, and graphics primitives. That was the original spirit of X, and should carry on.
6. With all that in mind, kill imake. Seriously, who uses imake besides X? Bueler? Bueler?
7. Clean up Xlib. Merge the other libs into the library. We have smart linkers these days, ya know. Since we killed imake, we can use configure or something along those lines to fix this.
8. Document it all. Document how a window is created, and what parts there are all the way down to the rectangle lists. How this list is translated into graphics onto a screen. XAA is fairly well documented. XVideo is a bit rough. XRender has somewhat real documentation, and you can read the thoughts of the designers on the public lists.
Let me know when the revolution starts..
Pan
Re:Could this be it? (Score:3, Interesting)
Well, what do you imagine would be the alternative to "sending commands over the wire"? X11 and NT do pretty much the same thing when you run them locally.
Under NT, the window system lives in the kernel, and graphics is usually drawn by a co-processor. If you call that "local native API" on Windows, be it for 2D graphics or 3D graphics, it enqueues your request in some buffer somewhere, eventually it switches to the graphics subsystem, the graphics subsystem enqueues the request with the graphics co-processor, and eventually, it gets executed and you probably get an acknowledgement.
Under X11, you call an Xlib function and it enqueues your request somewhere. Eventually, the system switches to the X11 server, which gets the request out of the queue, enqueues it with the graphics co-processor, and eventually it gets executed and you get back an acknowledgement. X11 servers on UNIX/Linux usually happen to use unix-domain sockets as the mechanism by which to get the enqueued requests from the clients to the display server (in addition to shared memory for bulk data transfers); that's because unix domain sockets are pretty much as efficient as you can get for this purpose. If NT had invented some mechanism that was faster (and I don't think it has), one could use that with X11; then, you might connect to maybe "super-duper-comm/:0" as your display, instead of ":0".
Note that if you use "localhost:0" instead of ":0", your X11 server will run much slower, because "localhost:0" really does have to go through parts of the TCP/IP stack. But ":0" really does use a very efficient IPC mechanism.
Now, both X11 and NT, and I mean both, give you some additional hooks (DRI, DirectX) that let user-mode programs ask nicely and get some "direct" access to the hardware. But that is obviously not a tradeoff many non-game programs make, and for good, practical reasons.
Note in particular that for 3D rendering, all of this has been worked out and happens transparently under X11 * [sourceforge.net]:
Basically, X11's capabilities and performance are a superset of those of NT's graphics system: X11 handles the local case as efficiently as NT, using shared memory and "direct" hardware and memory access where possible, but falling back to other communications channels when needed.Re:X design decisions (Score:4, Interesting)
It's true that this (application) client/server paradigm is tilted heavily toward the idea of centralized servers accessed by smaller clients. And where this topology exists and is necessary, people use X this way and it matters. For average users, it doesn't.
But that's the status quo, and it won't last.
We're going to inevitably move to a distributed computing model, and it only makes sense to do this on a per-application basis as a first step. Almost all the pieces are there. The piece that isn't there is a mechanism that matches slack to need transparently.
In my (years past, not current) daily use of UNIX workstations, I would manually spread my workload around to different boxes just because it made sense to do so. But it was a pain. Imagine if that were automatic and transparent.
In my opinion, X's network transparency will once again become incredibly useful. It's utility just needs to be properly leveraged.
Re:You know what? (Score:4, Interesting)
Thankfully, I seek out documentation OUTSIDE the XFree source. The archaic imake system, the need for 121 files in xc/config/cf! What's up with that? How is that supposed to be better than configure --prefix etc.etc?
I sure was lucky to find out about WORLDOPTS="", otherwise, if the compilation had hit a snag, I may have never known, because the XFree compile would happily chum along. Fine maybe for some systems. Maybe it is cool to grep an 11 megabyte &> log file. Maybe it is old school.
Keith's code is nice, is creative and works well, it is just the XFree86 World system he's fitting into. Fontconfig package 2.1 took me a long time to get right.
Re:Choice? (Score:5, Interesting)
As usual, the people who bitch about X are going to have to find some new reason to bitch about X.
Re:XFree Obsolete? (Score:3, Interesting)
Re:Maintaining XFree86 (Score:3, Interesting)
Why is that obvious? I, for one, don't see it at all. XFree86 sends stuff to your video card and your monitor, the audio drivers send stuff to your sound card and your speakers.
X is network transparency. It should not just be about graphics, it should be about providing a standard means by which the end-user experience can be piped to any display anywhere easily.
This is not to say that X should give up speed for flexibility. Rather, I believe that X should continue to strive towards this goal. My concern is that we have a standard method of interleaving the audio with the video stream.
This is, again, not to say that it should be required that the audio stream be always sent with the video. Rather, that there be a standard means by which this data can be transferred, and a central authority for routing this data.
(GStream.)
The problem I see, and the problem I'd like to see avoided, is wherein you need to forward a whole ream of ports back and forth all the way through in order to get a remote desktop running. I should be able to just forward one port, and have all of my X experience flow through that.
Then I could pipe all of my data through encryption at once, instead of having to set it up for each individually.
(Stop me if I'm talking out of my ass, here.)
Re:All I can say is..... (Score:5, Interesting)
And Multimedia extensions would be nice. It'd be cool if there was a network transparent sound protocol that ran in parallel with X to deliver the sound portion of apps.
Maybe I just haven't been following it much, but it seems like it just disappeared.
XFree86.org = ICANN (Score:5, Interesting)
The actions of XFree86.org convince me that they want to restrict user choice in the GNU/Linux world, and prevent anyone else from running any X11-implementations other than XFree86. Their refusal to modularize drivers is one thing convincing me of this.
I can not think of any major projects which are as poor as XFree86 in regards to including the community and being accountable to the community. Many of the people within that "organization" are in fact figureheads who don't even believe in XFree86, like one of the founders linked to. If you don't use XFree86 at all, and only use Windows, then imo, you have no business being part of an XFree86 team.
Keith is right to fork off XFree86. He has tried to address his concerns from within the organization, and has been unable to do so. Just like Auerbach. There is only so much one crusader within an organization can do when the rest of the organization is bent on corruption.
XFree86 is proof that even a project covered under a license approved by the OSI and the FSF can be corrupt and non-transparent.
At attempt at reason (Score:4, Interesting)
Keith, if you are listening, may I suggest that you formally and thoroughly document your objections to current XFree86 development and provide constructive criticism on how it might be improved? If there are technical complaints, such as relating to performance, perhaps you can write code to prove the need for change.
XFree86 team, if you are listening, may I suggest that a patch tracking feature be added to the official web site? For example, if a patch is submitted to support a new XRender feature but not yet committed to CVS, show this and offer the patch for download right there. As a user, it greatly frustrates me to not have any idea when new features and support will be added and you must admit, the XFree86 release cycle is rather slow. As a user/developer, it would be greatly beneficial to me if I could see precisely where the work is being done. And if extra help is needed in some area, advertise this openly. Relating specifically to driver patches, may I suggest that driver changes be added with far less caution than changes to core libraries? I personally believe that if someone like responsible like ATI submits a patch to support their latest hardware, there is absolutely no need to sit on that patch. Get it out there and get it tested ASAP.
Re:let me add to that... (Score:3, Interesting)
Incidentally, a colleague of mine has done work on VNC for Windows, and it is appallingly difficult. You either have to scrape the framebuffer continuously (kiss performance goodbye), or you have to hook GDI calls to figure out what regions of the screen were updated.
Re:Choice? (Score:2, Interesting)
They do say that RANDR-extension should finally give the potential for implementing this capability.
Hmm Interesting (Score:3, Interesting)
This implies to me that there is a limitation on the number of requests per second that the X-server (irrespective of driver) can do, and that perhaps should be addressed. Either that, or a G400 really is the same speed as radeon 8500... The link to 'tanelorn' is via ssh as well (so it's encrypting and decrypting everything in the protocol stream...)
[simon@atlantis ~]$ x11perf -eschertilerect500
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on
from atlantis.mythology.gornall.net
Sat Mar 22 11:03:29 2003
Sync time adjustment is 0.0537 msecs.
8000 reps @ 0.6795 msec ( 1470.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6850 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6794 msec ( 1470.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.7947 msec ( 1260.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6966 msec ( 1440.0/sec): 500x500 tiled rectangle (216x208 tile)
40000 trep @ 0.7070 msec ( 1410.0/sec): 500x500 tiled rectangle (216x208 tile)
[root@tanelorn denyaccess]# x11perf -eschertilerect500
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on localhost:11.0
from tanelorn.mythology.gornall.net
Sun Mar 23 11:10:28 2003
Sync time adjustment is 1.1608 msecs.
8000 reps @ 0.6954 msec ( 1440.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.7964 msec ( 1260.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6852 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6833 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
8000 reps @ 0.6844 msec ( 1460.0/sec): 500x500 tiled rectangle (216x208 tile)
40000 trep @ 0.7089 msec ( 1410.0/sec): 500x500 tiled rectangle (216x208 tile)
One other thing. I *like* X. I really couldn't live without the network transparency - editing files in co-located facilities via ssh with X-forwarding is just *so* much nicer than using 'vi'...
Simon.
Re:Hmm. That's not right... (Score:1, Interesting)
It clearly look that, as alan cox said, david have lost contact with X. He is now an open-source advocate, a free software hater (he says that in the thread) and an exclusive windows user.
That beeing said, the motivations for the fork() are not clear either. What I beleive is the problem, is that the XFree core team is overloaded with work because part of the team went working on other things. Young wolfes are pressing them to resign the control of the project, which they are not ready to do.
IMNSHO, they are right. Slow dev is better than fast and loose. Wanabees generally think that can do the right thing, without understanding that managing people (because core is about mangement) and driving a project is hard. And the more people commit, the harder it is.
Users message to the XFree team/project (Score:2, Interesting)
Re:Myth of X slowness (Score:4, Interesting)
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything, and that many users think this looks kewl, and that in any case Mac OS X and other systems seem to exploit the video card's hardware to do this stuff quickly, wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
Re:Hmm Interesting (Score:2, Interesting)
Yes. I agree.
However, I have noticed that on some newer linux (perhaps much newer emacs), command "emacs" tend too take too long time to start, so I ended to quite often to use "emacs -nw".
Well, these newer emacs tend to be slower on startup even on text mode (but not that bad than on X11) compared to machines where software is about 5 year old.
(these all: ssh with X-forwarding)
Re:Go Keith! (Score:1, Interesting)
So now, we are still locked into a xfree-does-every-low-level-including-video-driver
Sucks.
Re:You know what? (Score:2, Interesting)
Fast GUI vs Network Transparency? (Score:3, Interesting)
I agree. In my previous job my main working machine was a Win2k box with PuTTY and a commercial X server installed. It's actually a very nice environment to work in -- I could use Explorer to administer and manage files on my remote linux server, editing PHP code with my favourite Win text editor (ConTEXT) and at the same time using Outlook (not my fave, but the company standard), and develop Win32 code. Best of both worlds. Plus I got to wow all my surrounding Windoze-only colleagues with impressive looking KDE themes!
Without X's network transparency, I'd be upstairs on the linux box half the time, separated from colleagues, and reducing my efficiency.
The only downside -- having to walk upstairs to change CDs occasionally!
However, I also see the need for a slimmer, leaner, meaner X, with a fast (perhaps even kernel-level?) direct rendering system, with less cruft. I have a lowly PIII 550 256Mb at home, and X is a bit of a pig; whereas Win2K's GUI just whizzes along nicely.
I don't necessarily think that network transparency + a fast GUI are mutually exclusive. Surely it's possible to come up with a high-speed rendering and input API that could be controlled remotely via a swappable
I can envisage something like an OpenGL-like pipeline, with a serialised command input, that could be streamed to a specialised hardware accelerated layer on the local machine, or via network to a remote display server? The remote server could afford to be quite minimal in this scenario - a glorified video driver with support for input devices. Surely most of the code necessary for a prototype of this system is already out there?
Re:Go Keith! (Score:2, Interesting)
Re:Myth of X slowness (Score:2, Interesting)
If my display hardware can shunt polygons and surfaces around with hardware alpha channels, bi- and tri-linear filtering, and my cpu is capable of rotozooming entire screenfuls of pixels with bilinear filtering, then I think it can probably cope with a few anti-aliased fonts. Especially as there are so many clever tricks that can be used to accelerate this process.
To highlight this point, I am posting this message using 600% zoom using Opera under Win32
Re:Maintaining XFree86 (Score:3, Interesting)
Basically, X has become pretty irrelevant for Linux on the desktop. I mean, today, it's necessary, but in the future, anything that has a working backend for Qt and Gtk is a viable starting point, since it's source level compatible out of the box with the vast majority of modern Unix desktop apps. Whether it's a kludge or thunk layer doesn't matter to me, I just want those apps to work now, and a "one true way" to build apps for the future (a native toolkit integrated into the windowing system). The separation of policy from rendering and window management was a nice experiment, but it results in so much added complexity, with so few benefits. I think a reasonable skinning mechanism and the ability to create custom windows with custom features for "exception conditions" is really all you need to satisfy all the desktop apps requirements.
Re:I find it funny... (Score:3, Interesting)
- Politics: The group is closed and controlled from topside the way old companies do things.
- Tech Vision: XFree's top ppl are wishing to move away from what makes X interesting and follow what has been popular and easier to do (yes, it has also been faster).
This group should be split. I only hope that they come back together or that ideas merge. Perhaps the X group will become more open in the future.The truth about STSF (Score:1, Interesting)
I don't agree with the people who say that X is bloated, lacks performance, and cannot be fixed, so we need to throw it out and start over. But if STSF were added to it then it WOULD be time to take it out back and put a bullet in it. In many situations the current versions of STSF can reduce text processing to a snail's pace.
Re:Go Keith! (Score:3, Interesting)
Every kind of driver is in the kernel. What's so different about video? As it stands now, XFree86 goes probing around directly to the hardware (which is why it requires root to run, there's another security risk). This is not a stable approach. XFree86 is often the reason Linux "locks up". Video is not inherently unstable. This stupid architecture is.
We have the Linux Framebuffer video today. It doesn't have many drivers yet, and only works for 2D, but it is stable. The only time I've had it crash is when I run XFree86 also, because then the kernel and X end up conflicting over the same video memory. If X would go through the kernel for the video, then this whole setup would be a lot less error prone. Also, the Linux Framebuffer solves the root-permission problem by giving you
Switching to this model would drastically simplify XFree86, since they wouldn't have to worry about drivers anymore (which is about all they do these days anyway, the X11 protocol itself hasn't changed in 15 years). The Linux kernel has a better driver development model. I'd rather see these video drivers in the hands of Alan Cox and other competent kernel hackers. I'm positive we'd see a gain in stability by taking this road.