New, Modularized X Window Release Now Available for Download
X11R6.9 is comprised of many distinct components bonded in a single tree, based on imake. X11R7.0 splits that set of components into logically distinct modules, separately developed, built, and maintained by the community of X.Org developers. This simultaneous release gives a transition point for developers, builders, and vendors to adapt their practices to the new X.Org modular process.
X11R7.0 supports Linux and Solaris at this time, with other support pending. X11R7.1, the first modular roll-up release, is scheduled mid-2006. While the monolithic tree will continue to be fully supported and released, new feature development is expected to concentrate on the modular code base.
The X11R7.0 and X11R6.9 releases are the work of more than fifty volunteer contributors worldwide, working under the release management team of Kevin Martin (Head), Alan Coopersmith, and Adam Jackson, with the support of Red Hat, Sun Microsystems, and the unsupported, generous contribution of effort by Adam Jackson.
All X Window System Releases are available from ftp.X.Org and mirror sites worldwide (see http://wiki.x.org/Mirrors). They are distributed under the MIT ("X") License by the X.Org Foundation LLC. Information concerning organization, activities, and mailing lists can be found at www.X.Org. Membership is free and open to contributors. Sponsorship is encouraged to support the global activities of the X.Org Foundation. Current X.Org Sponsors include Sun Microsystems, HP, IBM, StarNet Communications, AttachmateWRQ, Hummingbird, and Integrated Computer Solutions Incorporated [ICS].
In continuous use for over 20 years, the X Window System provides the only standard platform-independent networked graphical window system bridging the heterogeneous platforms in today's enterprise: from network servers to desktops, thin clients, laptops, and hand-helds, independent of operating system and hardware.
* LINUX is a registered trademark of Linus Torvalds. "Solaris" is a trademark of Sun Microsystems. All company names are trademarks of their registered owners.
-------------------
Have an important announcement or article to share with Slashdot readers? Send the complete article (or a proposal) to roblimo (at) slashdot (dot) org.
This linux-related article is a stub. You can help Slashdot by expanding it.
Xfree86 continues their self-imposed slide into obscurity.
This guy is way out there
I have to admit that it's something I'm welcoming. The autotools are hard enough to learn, having to figure out imake on top of that was a bit of a hassle. Add to this the fact that it's now modular -we can work on different bits much more easily- and it's a winner...
What does this mean for me as an end user?
Give me Classic Slashdot or give me death!
If I understood the article correctly, this version is exactly like the last one, except that it is modularized, and therefore built in a different way. How is this a "major version release"?
[sig]
Am I right in saying this will not make any difference to the end users? Making X module-based seems to greatly simplify coding for developers, but does it have any effect for the end user at all?
[sig]
more autotool hell, woohoo.
I don't think there was any danger of you losing this particular contest.
Slashdot - where whining about luck is the new way to make the world you want.
http://wiki.x.org/wiki/Mirrors
On the other hand, I'd guess that for the 1% who do hack X, this will make thier lives easier. Heck, it might even mean more people decide to work on X, which OSS dogma tells us is a Good Thing(TM), and it probably is.
philcrissman.com.
-1 Troll. Linux the kernel is "Linux (R)", and X runs on top of Linux, not of GNU* (but is part of GNU). RMS does not want the Linux kernel to be called GNU/Linux. This has been explained ad nauseam .
:)
* Hmm, but now uses GNU autotools
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
... there are a few new features to expect. I'm most curious about the new drivers for ATI's R300-Chips (and newer), called "r300", which will provide GLX-Support (hardware-accelerated OpenGL) in a Free Software-only manner.
:)
Oh, and there are some minor features to be added, like 30Bit visuals for improved greyscale graphics for medical purposes, for example.
Apart from the new drivers, there's nothing to be OVERLY excited about this release - unless you're going to build yourself, I'm really looking forward to playing around with portions of the code without having to recompile the whole bloody source again.
:%s/Open Source/Free Software/g
YTARY!
I've been using Windows for years. First they started with numbers after the name, then they put "Me!" instead, then something about experience points. Now that's not enough, and they want prefixes as well.
Screw the bastards. I'm going with Linux.
Linux is a Registered trademark of Linus
:)
GNU is a registered trademark of the GNU foundation
so the GNU/Linux doen't apply
"On a normal ascii line, the only safe condition to detect is a 'BREAK' - everything else having been assigned functions
Richard Stallman may disagree with you here
So how long will it take us to get nVidia to support this with their evil, closed source drivers?
For that matter, even if there is R300 support, isn't it now 2 generations back?
The living have better things to do than to continue hating the dead.
Gnu is a trademark of CS Lewis.
And I am a huge proponent of Free software. But I sure would like to know when X will support today's new technologies and trends. rotating your screen is very difficult. and you can't have accelleration when you do. even resolution changes are difficult (xrandr helps, but you still can only move between the resolutions provided at the X server start, which doesn't help if you've plugged in a different monitor.) Switching between dual displays is hard.
can't think of anything else at the moment.
What comes first, finding a teacher or becoming a student?
Spelling tip: Grammar isn't spelled the way you think it is.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Imake is the spawn of the devil. I've used it. I've understood it. But I HATED myself in the morning.
In continuous use for over 20 years, the X Window System provides the only standard platform-independent networked graphical window system...
/. :-), but I like to suggest that either the people who are developing the X Window System work on this part of their software or drop the claim that they produce platform-independent software.
Somehow I question the claim that the X Window System is still platform-independent. To me it looks like a unix-centric development. There are other operating systems, like VMS, and they come with older versions of the X Window System, too. But the "autothis-and-that" tools all are written for Unix features, like the file specification, syntax of options, compilation tools etc.. None of the differences among various operating systems are addressed in the new scheme and somehow I doubt they will be in the future. Of course, one could adapt other operating system to Unix, but people who chose not to use Unix certainly did that because they do not want to their software to be Unix-alike. Not that I want to judge here which operating system is the best (after all this is
In any case I appreciate the X Window System very much, thanks.
Best thing since Tank Girl.
us slashdotting bastards ...
.. paranoid crackpot leftover from the days of Amiga.
Surely a new operator is in order. I nominate ^.
I remember using ^ back in the 80s. GW-BASIC, I think.
"I don't know, therefore Aliens" Wafflebox1
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I'm for one looking foreward to modular X.
I know that the changes don't mean much at the moment, not to the end user anyway. I'm curious how will this affect the developement process, if more developers will jump on the X.org wagon as the article suggests. Will we see releases more often? I'm also curious how will this affect video card menufactores, and ultimetly their curtomers. I don't know what about the rest of you. I see that there's a bit of mixed feelings about all this but, I'm excited about this. I can't wait to see what kind of an affect it fill have say... 2 year from now
Supporting imake and autotools in what is essentially the same codebase seems pretty impressive. Just one build system generally is cause for enough hair-pulling to make even RMS go bald. Shouldn't we be offering kudos to the x.org folks?
I think I'll hold out for 7.1. ;-)
Stiny! Get me a danish!
You tell 'em, Shimmer! *pat*
Everything in the Universe sucks: It's the law!
the xorg as it is now is about 110MB (binary for i686) in size. it comes out about 2 times a year. means that you have to download every year around 230MB of data to keep your X up-to-date.
BUT (!) actually, you are only 2 weeks of the whole time really up to date, because most of the libraries and drivers are outdated, just a week after the release came out. this means, that you download 230MB and are waiting the whole time for new releases hating the whole system it is organised.
new, the modularised organisation gives the developers and package maintainers the ability to update just one library at a time - to release it immediately it is known to work fine with the rest and the user has the binary of this small library (e.g. 2MB) ready for download in about a week after its release. this means you still download over the year about 200MB of updates, but you are not waiting for relases to fix your problem, because every week or month, a new release of the PARTS of xorg come out and fix problems and add features. this way, the user profits faster from the whole lot of features that come out and fixes that solve problems. (of course, in the old system, you were always able to get the whole sources (hundreds of MB) and compile them yourself (hours to days of compiling, can fail if you use wrong compiler or wrong checkout-time when getting sources))
in the modular organisaiton, also a newbie can then recompile only one part of X, because of the less time it takes and a more transperent process
==> end user gets updates more frequently, has to wait less and has much less pain updating only parts of X
But I sure would like to know when X will support today's new technologies and trends. rotating your screen is very difficult. and you can't have accelleration when you do. even resolution changes are difficult (xrandr helps, but you still can only move between the resolutions provided at the X server start, which doesn't help if you've plugged in a different monitor.) Switching between dual displays is hard.
X11 has support for all of those, plus more. It's up to driver writers and server implementors to support those features properly.
The real question is when Windows and Macintosh will catch up to X11, because they are far behind.
okay lets try this "Linux(r)" is the kernel image and assosiated /lib/modules files
(aka what you get when you run make bZImage && make modules on the archive from kernel.org)
GNU is just about everything above this point so you could say the gnus do the work but the penguin gets them going (until hurd gets to a useful point)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Yes, wait another 10 years :P
...X.org was touched by His Noodly Appendage!
I ate your fish.
I used to X with a passion when I first started using linux back in 98. Actually I still do and think its bloated and horrible but with modern hardware its doable now.
:-)
The unix haters manual has alot of nice things to say about it.
But seriously people have run X on VMS systems running in as little 3-4 megs of ram. Also ol linux users ran X fine with ONLY 8 MEGS OF RAM back in the 486 days.
X is not bad but perhaps Xorg sucks? What I want to know is if they are planning on cutting down on memory and cpu usage and adding features like sound support, transparent objects, anti-aligned fonts (I think support is added now), resolution changes that dont require a reboot, ajax/caml/dashboard or some xml and javascript support , and other technologies. Its still quite behind macosx and windows and since its free I hope it catches up. Also automatic scanning of video and monitors would be nice. Come on its 2005.
I hope Xorg moves along and creates a better X and so far its a step in teh right direction.
http://saveie6.com/
Hopefully this will mean that soon X will be able to probe more and use the config file less.
Anyway, it is great that X.org is finally bringing some more work on X. XFree was content to sit around and twiddle their thumbs for the most part.
So what are the main stream using these days? Fresco? Qt/Embedded? The Y Window System? rio?
and even there, I know many Debian users, for example, who are eager to switch to X.org.
Debian IS using xorg (only stable and maybe testing still uses Xfree86)
Since you are obviously confused, let me clarify. "X", "X11", and "The X Window System" all refers to the same thing. It is a specification for a way of displaying and interacting with graphics in windows on a computer and/or through a network.
X.org used to be the organization that coordinated that specification between various vendors of X11. It also maintained a "reference implementation" that nobody used. Then X11-innovation stagnated among the major unix vendors. X.org slowly died, and XFree86 (a "vendor", and a free implementation) became the defacto standard. Then XFree86 (the organization, not the implementation) did something stupid with their license, and the code was forked by mostly the same people that used to work on XFree86, and they decided to call themselves X.org (and their implementation xorg), since the name now was available).
Today, most everybody uses xorg, not XFree86. This is an update to xorg. To end-users it means zilch, apart from the fact that it's better for developers, and they can expect to see some innovation finally happen in the X11-world (well, in the long-term at least!)
Most unsightful comment ever.
My gnome+mozilla+gaim takes 220MB of ram.
My win32 desktop + mozilla + gaim takes 300MB of ram.
I think X is doing just fine.
Tom
Someday, I'll have a real sig.
You mean exactly like Wikipedia ;) that's how all the software should be designed, but I wonder if its possible. I remember reading Linus a while ago saying that he refuses to modulize Linux (i.e split it in relatively small modules communicating among them with a set of stable API, this also sounds like the micro kernel architecture he is notoriously againt) as long as it has not completly stabilised (not in the buggy sens), but till all the infrastrucre is not there yet. If the new X is a success may he will review his judgment, this will bring more hackers to the Kernel.
-c
"If you are an idealist it doesn't matter what you do or what goes on around you, because it isn't real anyway."-R.P.W.
Or Y?
The masses are the crack whores of religion.
Comment removed based on user account deletion
This new x.org version is not just about autotooling the server
/dev/audio keyboard bell option
From http://xorg.freedesktop.org/wiki/ChangesSince68
* New EXA acceleration architecture, with experimental support in sis(4), radeon(4), i128(4) (more to come)
* Individual extensions may be enabled or disabled on the command line using the -extension flag
* Improved chipset probing for IA64
* SecureRPC enabled on Linux by default
* Updated savage(4), including dualhead and DRI support
* Updated XRX support
* Fixes to rootless mode for Cygwin and Darwin ports
* Numerous K&R-to-ANSI C conversions
* Many Darwin fixes
* Updated XvMC support, enabling generic loading of hardware-specific drivers
* Added wsfb(4) video driver for OpenBSD and NetBSD framebuffer consoles
* Numerous ATI driver updates from the GATOS project, including TV input support
* More support for enhanced visuals like 12-bit PseudoColor and 30-bit TrueColor
* Improved ProPolice support
* Updates to nv(4) driver from XFree86 and nVIDIA
* via(4) updates from the Unichrome project, including DRI support
* i810(4) updates, including i915GM/E7721/i945G support and shadowfb support
* Improved module loader support for Alpha chips
* Added mingw port for native Win32 builds
* Updated PCI scanning
* Added DMA support to radeon(4) for Render and Xv operations
* Experimental DRI support for Radeon 9500 and above
* Updated xterm to #204 from [WWW]upstream
* Added evdev(4) input driver for generic input handling on Linux
* Switched to libdl-based module loader
* Improved acceleration for sunffb(4)
* MMX blending routines for the Render extension
* sis(4) updates
* New sisusb(4) driver for USB-attached video
* Tiled framebuffer support for radeon(4)
* Initial support for running the Xorg server without root privileges
* Improved acceleration for newport(4)
* Add DragonFly BSD support
* Update bundled Freetype to 2.1.9
* r128(4) dualhead support
* mach64(4) TV-OUT support
* ATI Theater 200 video decoder support
* SGI Altix support
* Disabled antique [WWW]DPS extension
* Support for FreeBSD/powerpc
* Enhanced software Render core
* Support for more than 12 buttons in the generic mouse(4) driver
* Better support for DRI on 64-bit platforms
* Solaris support updates: enhanced mouse driver, agpgart support, experimental AMD64 support, kbd(4) support,
* Output-only windows
* Non-rectangular mergedfb desktops
* Update bundled fontconfig to 2.3.2
Comment removed based on user account deletion
Part I
Part II
Man, I was going to write exactly the same sentence. .deb package" in a few weeks and a backport to sarge (or even etch, maybe) in a few months. If I have spare time I'll go for the build your own...
With a note. You can probably expect an "HOWTO build your own xorg7
You left out X. On my Gentoo system, X is currently using 195 MB of memory. Note, however, that this is to run KDE, Firefox, XMMS, etc (each of which consumes additional memory). On my XFCE machine at work, the memory used is less.
I've seen a lot of things, but I've never been a witness.
Please show some respect! The proper name is "GNU/X11R7.0".
Don't blame me, I didn't vote for either of them!
Of *all* the vendors I've worked with regarding driver support nVidia is easily the best. And Linux driver support is important (albeit I don't actually sweat the video drivers, but at home) to me because I build/deploy and maintain systems in a prodution environment every day. Adaptec, Supermicro, marvell, SATA RAID, SCSI adapter support, ICK. Drivers can be a real nightmare, at least give credit when credit is due.
Quack, quack.
Accoriding to the german iX magazine, building the modularized X-Server takes about 3x as long as building the "monolithic" version.
A refactor?
Does this mean my (now utterly obsolete) ATI 9600 Pro will soon work as it was supposed to?
Really? Well, my filesystem isn't GNU, my X-Windows aren't GNU...
There's no shame in that. A lot of people shop at Goodwill these days.
"I've got more toys than Teruhisa Kitahara."
Since many of the posts are talking about if the latest and greatest card from ATI or nVidia will work with their respective binary-only driver; I feel compelled to mention that there is a project with the intention of getting open spec'd, hardware accellerated video cards out: OpenGraphics. The specs may not be the bleeding edge of current tech, but I personally will appreciate having hardware that can be fully utilized by the OS of my choosing.
I guess you forgot that XFree has an unacceptable license that means few Linux distro maintainers could include it.
that's nothing to brag about
for one, no standard windows desktop should take up 300mb of ram.
You could also try running applications that use the operating system's native windowing toolkit. Gaim has a buttload of overhead on windows because it needs to load all of GTK into memory in addition to the normal Win32 windowing toolkit. Ditto for Mozilla.
A better comparison would have been
Win32 with IE and AIM versus KDE with Konqueror and whatever KDE's instant messaging program is. Once you start mixing toolkits, RAM usage goes through the roof.
-- If you try to fail and succeed, which have you done? - Uli's moose
As a PC X Server developer for one of the sponsors mentioned above, I am very glad they are phasing out imake. It is a real pain in the you-know-what. It's literally just a bunch of makefiles that make makefiles! On our product in particular, we had a trouble with it, thus generating significant hatred.
I haven't had a chance to take a look at 7.0 yet, but it's got to be good... at least, there's no way it could be worse than imake!
Are you actually bragging that your desktop requires as much memory as 3,520 Commodode 64's? Why does that make you think X-Windows is doing just fine?
A single Commodore 64 can draw a clock on the screen, with most of its 64K of memory left over. How many C64s worth of memory does X-Windows require to tell the time?
-Don
Take a look and feel free: http://www.PieMenu.com
Build time is only an issue for developers (and people with lots of time and a passion for watching gcc command lines pass by...), most importantly, usually no one needs to rebuild the whole thing: 99% of the time, you rebuild only the little part you are working on (and, notice, that little part migth have become littler with modularisation). Build time is essentially a non-issue.
It is quite boring to watch this "autotools suck" meme live on. Sure, they can be a pain, but that is usually solved by RTFM; sure they sometimes feel like you need to perform demonic invocations in order to do something, but they sure work, and do so well enough that the very people who maintain a huge beast like X.org are willing to cope with it. Come up with an alternative, good enough that people are willing to commit themselves to using it in real life projects, and then I'll listen with pleasure to your ramblings about how much autotools suck.
Great going everyone!
First of all, people who have to build and package X with their OS care too.
Second, no autotools do not work. They don't even work all the time on linux distros, nevermind less common unixes. And they were already using a superior alternative, imake.
With Xorg 7 comes the chance for the first stable composite extension! So Xcompmgr will stop crashing (as much)! Also, by using my own guide I can get an accerated desktop with a ATI 9250 card that uses EXA (which is more stable than Nvidia's renderaccel)! So maybe...just maybe...I can get a Windows 98 level stable accerated desktop before 2005 ends, thereby beating Vista out the gate by a year. And since the KDE compositor is near stable, I can enjoy menu transparancies now when I log into Kubuntu without fear of crashing!
Also the new driver interface will bring improvements to the closed Nvidia driver once they get their head around it, and my 6600 GT will hopefully give me decent performance with Skippy-xd by the time Dapper comes.
Of course, this won't help most users because composite won't be turned on by a major distro for at least a year or two but for those of us on the Linux Eye Candy edge there is a whole new world open today.
By far Xorg is the most primitave part of the Linux desktop compared to the alternatives (especially with Openoffice.org2 out there) and this release is the first step towards the wonderful desktop that OSX people have now and Vista people will have next year. I can't wait soon enough for drop shadows, real transparancies, and minimize effects that do not suck!
Open Source Sushi
It is quite sad, then, that such an important piece of software is in the hands of idiots, I guess, no?
Can your commodore display a 720x480 full colour 30fps motion picture without lag in software mode? in overlay mode [if HW present?]? Over a remote network connection?
Yeah, didn't think so.
X may be bloat [which I don't generally agree with] but it isn't a simple "linear frame buffer driver". You're just a retard who is latching on to some disgrunted 40 yr old hacks disdain for something which rightly or wrongly became popular.
Don't like the state of X? fork x.org and improve it or make constructive critisms. Any assclown can regurgitate someone elses complaints as if they're their own. It takes real inteligence to form cogent concerns and bring them up in a manner most aptly to be addressed.
Tom
Someday, I'll have a real sig.
that's for the kernel, gnome, gaim and mozilla. Not just X.
Mozilla on it's own takes up 30-50MB, gaim another 15, gnome about 50-75MB, etc.
There is more bloat out there than just what is in X. But what you peeps fail to see is X is not a single solution package. It's used by people with a variety of hardware configurations. It doesn't just provide a linear frame buffer to work with either.
Is there room for improvement? Yes. Is it in X alone? No.
Tom
Someday, I'll have a real sig.
We have an open graphics card. Its called the ATI 9250. The specs are open- it has the best open source driver in the Xorg display world. Till the OpenGraphics project can beat the power of this card.....its not worth much. And thats why it can't get off the ground!
Open Source Sushi
I'm curious how the new version will effect window managers and destkop environments like KDE and Gnome. Does anyone know if the name change (presumably directory name) will cause issues building applications, etc? Are we going to have compile headaches with existing X11 software?
These issues might effect the average linux, bsd or other *nix user.
I'm also curious on the availability and adoption of x11 r7 on *bsd and in OSX.
MidnightBSD: The BSD for Everyone
my point though
win32: moz+gaim+desktop == 300mb
linux with X: moz+gaim+gnome 300mb
Assuming moz isn't vastly different in Linux as it is in Windows I'd say that bodes well.
Tom
Someday, I'll have a real sig.
"Talk about a HUGE step backwards! X11R6.x supports dozens of platforms. X11R7 supports only two. What a shame."
Yeah, but for a near-total rewrite/restructuring of a huge-monolithic-behemoth? That ain't easy. I personally offer my own humble kudos to the Xorg team and am excited to see what lays in store for the future.
Ubuntu 5.10, the latest stable version, already uses a hybrid of X.org 6.8.2 and the modular 7.0 release. The development version (aka Dapper) is running X.org 7.0 and is fairly stable at the moment, if you're feeling adventurous.
where the comment ends and sig begins
And I JUST downloaded and compiled Xorg stable today... should've checked the /. first.
All things either change or die. If they fork from X.org, they will have to change the license issue to be able to hope to survive. Or the community will have a change of heart (highly unlikely).
I prefer the "u" in honour as it seems to be missing these days.
That Wikipedia article on sound servers you link to is only a half step above useless. Yech. I'll see if I can take a few minutes on it at some point.
Laws do not persuade just because they threaten. --Seneca
I don't know where this "X Window" thing came from. It is wrong. As you can see, the correct name is "X" or "X Window System".
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
Talk about a HUGE step backwards! X11R6.x supports dozens of platforms. X11R7 supports only two. What a shame.
No, it's a huge(ish) step forwards for Linux and Solaris. The rest have moved forward as well with R6.9.
WRT end-user features, R6.9 and R7 are essentially equal at the moment. Expect to see support for all the other systems in due time.
Please.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
I.e., one where the people who talk at meetings make it possible to play Bullshit Bingo?
the time to build would not be affected (much), because automake tools and ./configure can cache lots of things and then simply resolve them fastly while doing ./configure.
besides you do not have to build everything at once (well... once you or your package maintainers do, when you now the first time install 7.x), because later, only single pieces would be compiled and this takes only minutes for most stuff.
also don't forget that if you are building it yourself, you don't need to build a lot of drivers that you don't need. this saves a lot of time (or do you own 30 different graphic cards?)
Xlib desperately needs a lot of basic functionality only found
in extension libraries merged into the core API. For example
even double buffering (never mind any fancy graphics manipulation)
is still an extension for chrissake! In 2005!
Personally though X11.R7 is nice, I think its time we had a complete
rewrite and brought out X12 for the new millenium.
Grandparent: "resolution changes that dont require a reboot"
Parent: "Resolution changes don't require a reboot, just a restart of X"
Actually, for some time now resolution changes have been possible on the fly using the xrandr utility and associated X extension. On some platforms, xrandr also permits rotating and reflecting the screen on the fly also.
Yeah I've seen these pages too, but then I remember that they're almost fifteen years old, and X is quite different now then it was then. Some fundamental design flaws remain, but much of the other idiocies have been resolved. This new build system solves what was probably the worst design issue of the X codebase.
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
Heh, The Red Hat/Fedora way of builing X packages is actually much more sane than the FreeBSD ports way... (RPM will build everything once and split it into multiple binary sub-packages, instead of unpacking and maybe even builing all the sources once for each sub-packages like ports does (or so they tell me).)
Unless you happen to be using Firefox 1.5, in which case you cannot join because (apparently) the referrer information, or lack thereof, that's provided by Firefox is unacceptable to X.org. Anyone else have this problem?
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
99%? Are you sure? Try using generic vesa driver and see how "fast" it is. It isn't all about drivers. It's also about general architecture improvement, meaning with new driver core (currently only experimental) you will be able to use fast hardware accelerated composite extension. There are also other numerous "under th hood" improvements (brand new MESA for example)and most importantly modularisation of the whole project. Personally I feel that parallel relase of monolithic/modular version wasn't necessary. Much work implemented into something that won't be relevant in 6 months with modular-only 7.1.
Back in the mid-1980s the NeXT had a GUI that was supperior to far more powerful system, even today.
In terms of raw system power, the NeXT cube would a joke by today's standards, but it had a great interface.
"... invite a new generation of developers to contribute, building on the long tradition of the X Window System..."
Stability, Innefficent memory usage, bloated number of system calls, yeah... Perhaps some traditions should be left in the past...
-=[ Who Is John Galt? ]=-
For example
even double buffering (never mind any fancy graphics manipulation)
is still an extension for chrissake! In 2005!
So what's exactly your problem with its being a discoverable extension?
Maybe by 2015, it will be utterly obsolete, like many extensions have become now, and dropped by most then-modern X servers. As opposed to remaining as unused cruft that got stuck in the core protocol.
My exception safety is -fno-exceptions.
The X.org team will be running a booth at SCALE 4x, the 2006 Southern California Linux Expo.
FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.
Here's some nifty X10 window manager code I wrote in Forth in 1986:
X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.
I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)
The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.
Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.
Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!
Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).
-Don
Take a look and feel free: http://www.PieMenu.com
"It doesn't just provide a linear frame buffer to work with either."
The graphics model provided by X11 is that of a MicroVAX framebuffer on acid.
("What's a MicroVax"? A tiny little personal VAX. "What's a VAX?" It's an old minicomputer from DEC. "Why should I care?" Because its ancient design still deeply effects the X11 graphics model.)
-Don
Myth: X is "Device Independent"
X is extremely device dependent because all X graphics are specified in pixel coordinates. Graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's "Cheese Shop" sketch, or a grail seeker in "Monty Python and the Holy Grail." Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display, DefaultScreen(display)), WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!! (server dumps core & falls into the chasm)
Take a look and feel free: http://www.PieMenu.com
"The comment was from a book published in 1994, based on mailing list contributions from 91 an 92."
Incorrect: I originally wrote the X-Windows Disaster chapter specifically for the Unix-Haters handbook -- it wasn't ever posted to the unix-haters mailing list. It does quote a few messages from people like Jamie Zawinski and Steve Strassman, which they posted to the unix-haters mailing list, but I wrote most of the chapter later, specifically for the book, after porting multi player SimCity to X11.
The expression "X-Windows: The first fully modular software disaster" comes from an anonymous flier that was distributed at one of the original X-Windows conferences. (No I didn't write it, but I certainly agree with the sentiment!)
-Don
Official Notice
Post Immediately
X: Dangerous Virus!
First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated piblicly that "MIT assumes no resonsibility...". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.
After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X cannot even be guessed.
X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure it's up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment is being maintained on hundreds of computers, maybe even your own.
Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.
This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
Ultimately DEC and MIT must be held accountable for this heinous *software crime*, brought to justice, and made to pay for a *software cleanup*. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
Don't be fooled! Just say no to X.
X-Windows: ...A mistake carried out to perfection. ...Dissatisfaction guaranteed. ...Don't get frustrated without it. ...Even your dog won't like it. ...Flaky and built to stay that way. ...Complex nonsolutions to simple nonproblems. ...Flawed beyond belief. ...Form follows malfunction. ...Garbage at your fingertips. ...Ignorance is our most important resource. ...It could be worse, but it'll take time. ...It could happen to you. ...Japan's secret weapon. ...Let it get in *your* way. ...Live the nightmare. ...More than enough rope. ...Never had it, never will. ...No hardware is safe. ...Power tools for power fools. ...Putting new limits on productivity. ...Simplicity made complex. ...The cutting edge of obsolescence. ...The art of incompet
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
Take a look and feel free: http://www.PieMenu.com
Things that happen when you say 'X Windows':
I was digging through some old papers, and ran across a 15 year old "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2, from June 1988. Here's an article that illustrates how far the usage of the term "X Windows" has evolved over the past 15 years. (Too bad The Window System Improperly Known as X Windows itself hasn't evolved.)
The following definitive guide to the consequences of saying "X Windows" is from the June 1988 "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2:
Things That Happen When You Say 'X Windows'
THE OFFICAL NAMES
The official names of the software described herein are:
X
X Window System
X Version 11
X Window System, Version 11
X11
Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).
The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!
You are forced to explain toolkit programming to X neophytes.
Bob Schiefler says, "You should know better than that!"
The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.
Ditto for the controller board for the disk on your new Sun.
Your hair falls out.
xmh refuses to come up in a useful size, no matter what you fiddle.
You inexplicitly lose both of your complete Ultrix Doc sets.
R2 won't build.
Bob Schiefler says "Type 'man X'".
Your nifty new X screen saver just won't go away.
The window you're working in loses input focus. Permanently.
Take a look and feel free: http://www.PieMenu.com
Yeah congrats you can copy paste [probably in X no less]. Can you do anything original? Or is that the best you can come up with? Some lunatics rant from 1994.
...]
I've programmed in GTK+ and Motif and both weren't too hard to work with.
X11 may be hard but that's WHY we have things like Motif and GTK+ [and QT and Cairo and
Tom
Someday, I'll have a real sig.
The syntax of the xorg.conf file is a lot simpler than the same thing in xml - it is just different and would most likely be confusing to anyone who has not spent sixty seconds taking a look at the incredibly easy to find docs (man xorg.conf). Anyone that needs to edit the file will most likely be looking at it from a text only screen at some point, so their favourite GUI xml editing tool is most likely unavailable and they may not know how to edit the things xml syntax with vi. If you have a GUI available other tools can be used anyway - like something that can parse the file, take user input for other desired settings and then spit out the configuration file.
XML may be the flavour of the day but is not the solution to everything - look at gconf as an example of something in xml where you can't change individual settings without trepidation.
Just look at the man page - it really isn't all that hard. Simplifying it may help but xml instead of the clear section starts and finishes is only going to complicate things.
They don't have an agenda to change an old well documented configuration file format to something new. It's up to people who think the format could be a lot better to do that and produce something that is so much better that people will actually use it. If the driving force behind the new format is "dunno anything about it, didn't read the docs but I know xml" it isn't likely to get anywhere - but if the driving force is something else like a multi-purpose configuration tool it may well get adopted. A way to do it may well be like that used with sendmail - a config file is written in a simpler format and then converted into the sendmail configuration file. Users could edit your xml format config file and then have it convered into the plain text version. However, what exactly would that achieve and how less complicated would your config file be while addressing the same information? Recall that information is grouped into sections in the existing config file? Recall that a flat file can easily be modified by scripts while some xml file formats (I'm looking at you again gconf) cannot reliably be modified in this way unless that is thought of early in their life.Go on - prove me wrong. There may well be a compelling reason I am unaware of.
Oh, plus I think he may have written that rant originally... it certainly jibes with the sarcasm in his published writings about X and display architecture design.
So... what did you write in GTK+ and Motif?
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien