Slashdot Mirror
Xfree86 4.2.0 Out
According to david_eliasson,
Xfree86 v4.2.0 is out, but it'll probably be awhile before all
the mirror sites have sycned up with the release, so you may want
to just enjoy reading that changelog for a couple days before you
bother getting the whole archive.
so when will radeon 8500 support DRI in xfree86?
when will there be full hardware support for radeon 8500?
... lots and lots of bugfixes. Glancing through the changelog extract linked to from the story, nothing really *new* jumped out at me. Not that this is a bad thing, bugfixes and increased stability/driver support is always nice. :-) I noticed a lot of things having to do with the Xprt server and having to do with 3d accel (drm, OpenGL man pages, nv driver tuning, etc.).
News for Geeks in Austin, TX
I think we have had our share of this discussion.. =)
But what the hell, let's do it again!
There's nothing wrong with your suggestion. That'd be probably the right thing to to.. If we didn't have such a shitload of X11 applications.
Actually there is nothing _fundamentally_ wrong with X11. As you can observe, even that old architecture has lived far,far longer than anyone would have expected. What it is, 20-30 years now?
The power of X11 is in it's extensibility, XRENDER was added and traparency & antialization is now possible, Even over network, any network. TrueType fonts were needed and were added. XFree86 even had sub-pixel antialization before Windows ever had (those loonies just forgot to mention it anywhere).
X11 is perfect example of OO separation between different tasks. Server does drawing and client does it's own things. And message passing comes 'builtin'.
So what is really wrong with X11? You tell me.
fucktard is a tenderhearted description
As everyone says, though, trying to get away from X11 is very difficult as practically every GUI application on linux/Unix uses X11, so it's got a lot of momentum.
New programming environment is also there already -- and alternatives too: the GNU standard is GTK++, if you thing C++ is the ultimate truth you choose Qt, if you're into Objective C or Mac compatibility you have GNUStep... I only miss a Lisp or Scheme alternative, but it's probably I who didn't look hard enough. If you are thinking imaging, then there's Display GhostScript, DisplayPDF and Display PostScript.
And what makes you think it is bad and inefficient?
It is no backwards compatibility cruft -- there is a core API and architecture, and extensions; any part besides the core (which is clean and efficient) can be substituted, and even the core can be rewritten for efficiency if you like.
Color matching is also an extension.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Here's what's wrong: Deployment. The reason X has a bad image is that most Linux distros by default *don't* have good fonts. Not every app has antialiased text (although with Mozilla and KDE desktops, things are starting to change). There are a lot of technologies out there that, while technologically sound, have a bad image just because they're deployed poorly. If some upstart Linux distributor built a completely solid desktop experience (WITH *good* TrueType fonts, not just allowing you to import them from your Windows install), the whole image of X would change.
LKML has 1-2k emails per week. We have Kernel Traffic, Linux Weekly News kernel summary, kerneltrap.com, #kernelnewbies and there is generally one kernel update per day on linuxtoday.com. There are tons and tons of other articles about kernel development on Linux websites.
Compiling and installing a new kernel is easy enough that people are doing it on linuxnewbie.org
As a result the Linux kernel is one of the greatest pieces of software that exists today. People are willing to do a phenomenal amount of work to have their code included into the kernel.
We are at the point where even the most excelent code has to compete to be included. There were at least three different scheduler implementations for 2.5, two different VMs, and two different asynchronous io implementations. It is very good to be in the position where you can pick and choose what code will go into the kernel at this level.
On the other hand for Xfree had a closed email list until a year or so ago. There are about 250 emails per week to the Xpert mailing list. There are few websites with Xfree development articles.
Compiling and installing Xfree is difficult.
People constantly complain about X needing to be replaced. While there are real problems with Xfree, most of the stuff that people complain about to slashdot is complete crap.
To me this suggests that Xfree needs to concentrate on their PR skills. Xfree guys need to make development easier for newbies. Key developers need to have more interviews. They need to prove that developing X is just as cool as developing the kernel. There need to be more frequent updates--posted to linuxtoday hopefully.
Compiling and installing Xfree needs to be easier. I think about it this way, once you compile something, you are only one step away from developing. All it takes after that is to open up an editor and change something.
To me Xfree is as important as the kernel. Without it I would not use Linux. This is true for the great majority of Linux users. Xfree deserves more attention and credit than it currently gets.
(So am I, and I don't know anyone who is capable of doing this. Raph may, though -- he's discussed it before.)
how to invest, a novice's guide
Apps don't need to be recoded to use it. Just patch the GUI toolkit to take advantage of it, which has already been done for GTK+ and Qt. Haven't you seen any of the demos? And if you want new types of fonts, just patch the font server and all the toolkits & apps can take advantage of them automatically.
Berlin is still far from complete, and directfb doesn't actually support any rendering model. It just provides direct, unaccelerated access to the framebuffer, that's it.
Uh, yeah. Apps _do_ use XRender already. Both KDE and gtk CVS versions use XRender. framebuffer isn't a player since it would be slower and a step backwards. Berlin has far less support, and it will be a long time before it can do things that XRender does today (if ever). Plus, Berlin has horrible speed issues surrounding it's use of CORBA. Even with the work Stephen Davies did with respect to omniORB4 speedups and Berlin, this is still a huge speed problem that isn't likely to go away. They're looking at switching to TAO instead of omniORB but a lot of the problems are just architectural problems with CORBA that can't be easily optimized away. It's doubtful that Berlin will ever approach XFree/DRI in speed, let alone XRender.
That is, what video card(s) could I buy that are absolutely, unconditionally, all-features-but-the-hamster, no-problems, all dancing 3D-whizbands supported by XFree86? No recompilation, no binary-only drivers, no unexpected visits from Dr. Murphy ...
That is, what card to choose for setting up a system that it would take a concerted effort not to get right just by installing, say, Mandrake 8.1, that will run GLTron and Tuxracer without hiccoughing, that will never call attention to itself, at least in the bad way?
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
There's nothing wrong with X11. Nothing other than what a bit of tweaking can't fix. It works and it works well.
There is one major reason people bitch about X: t's big.
They're right that it is big and complex. That's they way it's supposed to be. X is a network GUI. You can run your application on one machine and have it display on another (or multiple machines). This is a very powerful feature. It's awesome. But it makes X big and complex.
If you're running a standalone desktop it doesn't do you any good. If you've come from the Windows world and think that standalone desktops are the only thing that exist, then you begin to question the sanity of using X at all. But Unix (including Linux) is not a standalone desktop OS. You simply CANNOT replace X11 because to many people are dependent upon it.
Adobe Framemaker doesn't exist on Linux or FreeBSD. But I use it on my FreeBSD box anyway. How? By logging in remotely to my Solaris box at work. Now I get to use the world's best desktop publisher at home on my PC. All because of X.
X11 isn't going to be replaced. But there is something that could happen. There could be an XFree86-Lite. An X with the same API as all the other X's, but designed and optimized for a non-networked standalone desktop. Strip out all the stuff that home PCs would never use. But make it compatible with the existing X. Hell, you could write it all as a kernel mod for all I care. But at least you would get your tiny weakling X for your desktop and I would still have my big and powerful X for my workstation and we could still use the same X applications.
A Government Is a Body of People, Usually Notably Ungoverned
Out of the top 10 things I can think of that makes it impossible for a normal person to run Linux comfortably, the lack of a display configuration tool is it. I am a programmer, I consider myself pretty knowledgeable regarding UNIX/Linux, I do all my development in vi/vim, etc. But for the life of me, every time I have tried to change how X is set-up (to switch my resolution or colors, even) I could not figure it out or I screwed up my configuration. That tells you something about the X configuration. I have used Xconfigurator with about 75% success, although I always had to quit what I was doing, go back to the shell, and restart X.
I think the solution to this problem is for some senior developers over at KDE, GNOME, and Xfree86 to get together and brainstorm an API for making dynamic changes happen. This could be implemented as a lower-level client-side X library, on top of which can be built tools for any desktop environment to modify the display on the fly. I'm not saying my implementation proposal is perfect, but I think the concept is vital to the success of the Linux/X platform in the mainstream. Windows had this in '95, and regardless of how technically superior X may be in many way, this usability roadblock goes a long way to negate it. When GNOME has a Display applet in the Control Center that can actually change the resolution on the fly, I will consider us a giant leap closer to world domination! :)
--Micko
Most of the apps are open source. Go to it if that's such a huge priority to you.
>So the option is, wait a few more years for
>Xrender to be completed, or check out stuff like
>directfb and berlin which claim to do what
>Xrender will do years from now.
Well, Berlin is at 0.2.2, and requires some sort of underlying graphic system - directfb, ggi, sdl or glut.
Both sdl and glut require an underlying graphics system as well, usually X. So those two are out if you want to do away with X.
Now on to GGI - at least the library (libGGI) is release quality. This is actually just a userspace graphics library that sits on top of an underlying system - X, svgalib, fbcon or glide.
We'll assume you want acceleration, freedom from X, and reasonable hardware support. So out go X, svgalib, and glibe. FBcon can be accelerated, as long as it used kggi, which is currently only available from CVS.
DirectFB also depends on FBcon, but it is does at least have what looks like a near final release.
So, our choices are:
Berlin on DirectFB on FBcon
Berlin on GGI on FBcon
DirectFB on FBcon
We may want to nix Berlin on GGI on FBcon, if only for the sake of having something which is SOMEWHAT near completion.
I'm not sure where you're getting this figure of "a few years" for Xrender to be completed, as Keith doesn't have timeline information on his website at all, but alpha compositing, anti-aliasing, and sub-pixel positioning are all written and included in the current XFree86 distribution. As the primary author states, the big pieces left are polygons and image transformation. Given that the initial discussions were at the 2000 USENIX Technical Conference, I'd say their progress is remarkable.
>Whats the best option? People want alpha
>channeling, scaling and OSX like effects,
>alternatives claim to be able to do it now, they
>port GTK and QT, and they claim to be compatible
>with X.
Xrender is already able to do alpha channeling and anti-aliased text, which are a major part of the deficiencies. Image transformation for things like scaling are forthcoming.
The alternatives, as discussed above, are not at a final release stage, rely on a linux only graphics layer (FBcon), have a narrower range of hardware supported (or supported well), and have a signifigantly different paradigm, thus complicating porting existing toolkits.
So is moving to a completely different toolkit, possibly with an unsolidified API, with the added headache of bringing all the drivers up to the same level of stability and performance as XFree86 already enjoys the "best option"? Or is the best option really updating toolkits to take advantage of the features available in XRender now, and planning on supporting the upcoming portions of the extension as they become available?
Matt