Domain: x.org
Stories and comments across the archive that link to x.org.
Comments · 309
-
Re:Looking foreward to modular X
I just downloaded the full X11R7. You wanted a modular X? You're in for a surprise, I'll tell ya.
I just did a "ls *.tar.bz2 | wc -l" in the directory where I downloaded X. Guess how many tarballs the complete X11R7 is? 287. Yes. two-hundred-and-eighty-frikkin-seven tarballs. There's no fucking way I'm building this on my own. Looking at the contents of the smaller ones i also noticed that some of them contain no more than a single .c and .h file along with 5-10 autotool files, this is modularization taken to a rediculous extreme. WHY the hell did they use autotools? I mean, it's great for some projects but let's not forget that autotools are a symptom of known deficiencies in "make" (Note: I'm not saying it sucks, I'm just saying it has problems and imake needed to be replaced with something).
This is too much. Not long ago some POSIX conformance changes were made to coreutils (dropped syntax like `tail -9 file` in favor of `tail -n 9`), this required tonnes of patches to autotool files and configure scripts across the board, imagine if something like that happened again? You'd need 287 patches to just make a full X build. And I havent even touched the problem dependencies between modules yet.
I pray I'm missing something here because what I'm looking at appears to be a monumental disaster. I thought R7 would be split into 10 maybe 20 tarballs, each with a toplevel configure script (alà KDE, that would've been great) but THIS?! I feel like crying, honest.
Go to http://ftp.x.org/pub/X11R7.0/src/everything/ and tell me what you see.
Then come back here smack me over the head and tell me I'm dreaming. -
more features!
This new x.org version is not just about autotooling the server
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, /dev/audio keyboard bell option
* Output-only windows
* Non-rectangular mergedfb desktops
* Update bundled fontconfig to 2.3.2 -
Re:nVidia
I think that at least couple months to get good EXA support from nVidia as they have to recode some parts their drivers. Expect faster compositation (more eye candy) with this release and better drivers. Also you can expect nv driver doing things what haven't never dream about. nv ships with the R7 so you don't have to wait support for it. 3dacceleration and nvidia. I guess you can use current drivers but I am not sure about them since we have now new acceleration architecture. nVidia has it's own system for this so I don't know if they will implement EXA or continue using their own systems. X will be somewhat faster too if I understood right everything on this page: http://wiki.x.org/wiki/ChangesSince68 that's the changelog and there are plenty of stuff to take a look at.
:) -
the correct mirror URL
-
Re:He hits the nail on the head
X isn't as bad as you say. It is improving. The next release of X.org 6.9/7.0 (monolith/module based) has various improvements. The most important is the new module based structure in 7.0. This should improve not only the installation procedure but also making the code more accessible to would-be developers. The most important next step is trying to come up with a new accelerated arch based on modern day GPUs. I refer you to Jon Smirl's paper
Jon himself left his project because the little attention it was receiving from other xorg developers. However his work was not unnoticed and him leaving actually stirred up some debate on the future of Xorg. Check the mailing lists for some interesting debate.
Anyway there is a group of developers who will continue Jon's work after the new Xorg is released. It is that right now everyone is trying to push 6.9/7.0 out the door.
Honestly, if Red Hat or some other Linux companies invested in more X coders and hired more developers to work on this project. We could have a modern desktop comparable to OS X and Vista within a year. However I doubt this will ever happen. -
Re:Only 26
Consider http://k.de/
or http://x.org/ -
Re:So wrong ...
Am I alone is thinking so what. I could not care less that I will be able to go to www.a.com. I'm actually surprised that they didn't always allow single letter domain names. Besides we already have 6 of them one of them being X.org. According to the CNN Article the only reason we haven't had access to the remainder where some outdated fears. Please tell me why this should bother me. Please tell me why I should be upset. Right now I can't think of anyway this should get me upset.
-
x.org
-
Re:But they already exist
But these already exist, don't they? Or have I been imagining websites like http://www.x.org/ all along?
I'm not sure that the latter distinction gets what is, or will be, new -- whatever that is. From the article:x.org has four letters and five characters.
Meanwhile, a handful of companies have asked ICANN to free up the single characters. Overstock.com Inc., for instance, prefers a single-letter brand of "o.com" because its newer businesses no longer fit its original mission of providing discounts on excess inventory.
How is "o.com" different than "x.org"? I just typed x.org into my browswer windown and it resolved or redirected to http://wiki.x.org/wiki/ and I got the website with the title "X.Org - Home" -
Re:But they already exist
But these already exist, don't they? Or have I been imagining websites like http://www.x.org/ all along?
I'm not sure that the latter distinction gets what is, or will be, new -- whatever that is. From the article:x.org has four letters and five characters.
Meanwhile, a handful of companies have asked ICANN to free up the single characters. Overstock.com Inc., for instance, prefers a single-letter brand of "o.com" because its newer businesses no longer fit its original mission of providing discounts on excess inventory.
How is "o.com" different than "x.org"? I just typed x.org into my browswer windown and it resolved or redirected to http://wiki.x.org/wiki/ and I got the website with the title "X.Org - Home" -
x.org
http://x.org
Enough said... -
But they already exist
But these already exist, don't they? Or have I been imagining websites like http://www.x.org/ all along?
-
Re:Multi Monitor Support?
I use a 17" Sylvania and a 15" Hitachi monitor on SuSE 9.3 here and it works just fine. The video card is a Matrox G550, a tad old.. but I don't do very much gaming on this system. The main thing I would check would be support for you're videocard, which should be available at http://www.x.org./
Dana -
Eh?
Eh? This is major news to me, to date Nvidia kit worked great in 2D but zilch for 3D. When did this change and is it a reverse effort or has Nvidia seen the light? Of course this URL http://www.x.org/X11R6.8.2/doc/nv.4.html doesn't mention it so I'll remain a bit skeptical.
-
Re:Sounds legitimate
It's the X Window System, not X-Windows as you claim.
-
Re:The Point is Simple
-
Re:Wow . . .
Your right, X11 has crap for transparency. Now Xorg, THAT has some great transparency and shadowing. http://www.x.org/
-
Re:Oh really?
Last I checked, the only difference between the two was the license and a couple of new drivers. Certainly nothing to explain a "much faster" performance. Perhaps you could explain to us in a little more detail, how your's is "much faster"? Does it have anything to do with the fact that you are using it on a newer and more powerful machine?
Not true. look here
I have both the Radeon (at home) and the Intel i810 drivers in use witht he new Xorg in Sid, and performance in 2D is a little faster.
Using transparency with the damage extension is a whole other story....
My thanks to all who worked hard on getting Xorg into debian. -
Funny But MisdirectedWhy, just last year, I tried to get you to work with my 23" Apple Cinedisplay. I was ready to return to you full-time after a long desktop-linux hiatus, if only you could have displayed properly on that Cinedisplay without screwing up the resolution. I didn't want to run you in 1024x768 on a 1920x1600 screen. Nor did I want to run 1920x1600 worth of desktop in a 1024x768 resolution where I'd have to roll the mouse all over the place to screen-off to the rest of the desktop.
Credit, where credit is due: Go here if you want to gripe about resolution issues.
And should I even mention the fiascos with various sound cards that you just didn't want to play nicely with?
Go here for support with your sound card.
Or of the hardware that you were supposed to be "known-good" on that you chose not to work with at the most inopportune moments?
Don't buy cheap hardware or anything newer than a year old. If you want bleeding-edge new stuff, stick with Windows or Mac OS.
Most of your gripes should actually be directed at the specific Linux *distribution* that you chose to use. The distribution choice is a whole religion unto itself.
;P Of course, I choose Fedora because it "just works" for me. My definition of "just works" = take the base distro and install it minimally. Hand compile everything I need. Tweak the system for what I need. Turn it into any of the following:
1. GNOME Terminal Server
2. Thin client (using cheap wireless laptop)
3. PVR/Entertainment system
4. GASP!!! A desktop computer!!
Sorry, but it "just works" for me. :)
Here is what I've found in my own informal comparison back in 1998:
-Setting up a Windows 98 box to do everything I need: six hours and about $3000 worth of extra software. (I'm not a pirate, so I buy everything I need) Considering how a lot of the functionality included with Windows XP is low grade compared to full commercial products (ripping CDs, editing images and video, etc...) and the fact that software costs even more now, I'd have to spend at least $3000 extra to do the things I want.
-Setting up RedHat 7.0 to do everything I need: six days and $0 worth of extra software because RedHat 7.0 came with everything I needed at the time. Considering that Fedora Core 3 has moved lightyears beyond RH 7.0 it's only that much easier now. So the same setup might take me three days now and probably a lot less since my knowledge has improved since 1998.
That's the key to using any Linux distro. You have to dedicate the time to learning it. Keeping in mind that the trade-off is that you wind up spending very little to no money on software. I'd say that's a significant feature that Windows can't compete with. Mac OS is in a flux right new due to the IBM to Intel CPU switch. I wouldn't touch a Mac with a ten foot pole for the next two to five years. Granted Mac OS is beautiful and can host a lot of the apps I use in Linux now, it's not worth buying a box that's only going to last a few years. Currently my Linux based GNOME terminal server is a dual P II 233 with 768 Megs of RAM from 1998 and it runs just as well as a P4 running Windows XP Pro. It can do everything that a Windows XP box can and more. So, it does "just work". -
Themes and Fonts are seperate from the ProgramsBecause of the implementation of GNOME/KDE themes and X11R6 font systems, both Themes and fonts are considered seperate from the program.
Like a browser is a viewer for HTML'ed content, KDE/GTK+/GNOME applications are also viewers for the Themes.
.The majority of KDE and GNOME themes are GPL'ed. I do not know of any non-GPL'ed GNOME Themes for a start. All the themes on Fedora are GPL'ed.The GPL applies to the source and binaries of the Themes. However, in the same way that you can run GPL'ed applications on propriety platforms such as Solaris, because of the design of the theme system, can even be used by non-GPL'ed applications. In the same way, either the X11R6 Xserver display or the applications themselves are also viewers for fonts. All the fonts shipped with the X.org implentation of X11R6 can be freely used in screen shots and printing.
-
Nope:icons, UI widget graphics,etc are all OUTPUT
The X Windowing system is a client server protocol. All such icons, UI widget graphics,etc are ALL output from the program, NOT part of the source code.
-
Solution: Wine Hosted WindowsSince the computers are already networked then the beat solution may be to run those applications under WINE on a linux server. CrossOver's Office Server Edition provides an easy way to do this, but it is possible to do the same with effort from the WINE sources without added cost.
WINE/CrossOver uses the networked X wire protocol which can be piped through a encrypted ssh or a third party encrypt/compression system like the NX Terminal Server system. In combination with some of the newer dual/multi processor servers, a Office->WINE->NX pipe line can provide a better service to more people than the same hardware hosting Microsoft Terminal Server.
-
X?! X! I cannot recall all the names...It is certainly told from an exclusively personal computing
perspective. There was a lot of activity in the workstation
market at the time, and most of those companies were in
the valley, and were likely talking to each other. It only has a screenshot of kde, completely misses all
the innovations of X (aside from mentioning separation
of mechanism from policy, which is very important.)
- network transparency, nobody touches X for that even today. http://www.x.org/X11_protocol.html
- device independence. You could fire off GUI applications from a sun workstation on an SGI or an HP, and the window would show up.... http://www.x.org/X11_xdesign.html
- X-Terminals do not exist in the PC world. They were a cost effective technology to bring bigger displays and simpler management of workstations in the 90's.
- The use of window managers and GUI toolkits meant
that there was a playing field to implement all sorts of GUIs and there were.
- Motif toolkit + mwm
- twm as a non-proprietary simple sample window manager.
- Sun! their original toolkits, with GUI APIs, bitmapped displays, and windows. (what was it called?)
- SGI (first display postscript driven windowing system.) I cannot recall the name...
- Apollo (only seen it on one station for a year or two, was quite different.)
- HP had their own motif fork...
- Sun NeWS.
- HP & Dec converged stuff to create... OSF/Motif.
- CDE came out...
- Motif toolkit + mwm
and much more... You could see what PC OS's should do
back in the early 90's but what the PC's didn't because the
hardware of the time wasn't upto it. - network transparency, nobody touches X for that even today. http://www.x.org/X11_protocol.html
-
X?! X! I cannot recall all the names...It is certainly told from an exclusively personal computing
perspective. There was a lot of activity in the workstation
market at the time, and most of those companies were in
the valley, and were likely talking to each other. It only has a screenshot of kde, completely misses all
the innovations of X (aside from mentioning separation
of mechanism from policy, which is very important.)
- network transparency, nobody touches X for that even today. http://www.x.org/X11_protocol.html
- device independence. You could fire off GUI applications from a sun workstation on an SGI or an HP, and the window would show up.... http://www.x.org/X11_xdesign.html
- X-Terminals do not exist in the PC world. They were a cost effective technology to bring bigger displays and simpler management of workstations in the 90's.
- The use of window managers and GUI toolkits meant
that there was a playing field to implement all sorts of GUIs and there were.
- Motif toolkit + mwm
- twm as a non-proprietary simple sample window manager.
- Sun! their original toolkits, with GUI APIs, bitmapped displays, and windows. (what was it called?)
- SGI (first display postscript driven windowing system.) I cannot recall the name...
- Apollo (only seen it on one station for a year or two, was quite different.)
- HP had their own motif fork...
- Sun NeWS.
- HP & Dec converged stuff to create... OSF/Motif.
- CDE came out...
- Motif toolkit + mwm
and much more... You could see what PC OS's should do
back in the early 90's but what the PC's didn't because the
hardware of the time wasn't upto it. - network transparency, nobody touches X for that even today. http://www.x.org/X11_protocol.html
-
Re:Jack of All Trades, Master of None
Just as a matter of comparison here... With my 2003 spec laptop (P4M 1.6Ghz, 256 meg RAM, 64 Meg Nvidia 4200) running Fedora Core 3, X 6.8.2, KDE 3.4 with Composite enabled, Top tells me X is using 13% memory and 2% CPU. Of course, the alpha channel and other nifty stuff is being pushed through the GPU but it still shows the alternatives out there. It would be interesting to see Longhorn running on a 2003 spec machine in 2006.
-
Re:Next generation, you say?
Does next generation mean it'll support copy and paste?
To what does "it" refer? Copy and paste is largely a matter of toolkits supporting the ICCCM conventions for the PRIMARY and CLIPBOARD selection and the X clipboard conventions, and, for non-plain-text selections, supporting appropriate conventions for non-plain-text items (or creating them if they don't exist).
-
X *WINDOW* system
This comment may be late, and my get buried, but i just wanted to correct the slashdot title for this article. (Which is strange cause
/. is so reliable for facts)
it is: X Window system
it is not: X Windows system
Can you see the difference? There is no s on 'window'. I know that MS has taught us all to use the word 'windows', but we should keep our heads and use the correct names for technology.
As a reference, i will cite the X.org Website where they make reference to the "X Window System" extensively.
Thanks Zonk. You couldn't even copy from the submitter's words, who got it correct. -
Re:X.org
-
duh
It's exactly the same in X.org, as I pointed before.
-
Changelog
Dear Taco,
Please post a link to a summary of changes when anouncing the release of a new version of any software. -
Vendor Dependent Death Marches VS Open KaizenHaving been involved in a couple of in house enterprise projects and having spoken to dozens of local developers on the subject of failed and successful projects, IMHO the three major reasons for large in house software project failure are:
1) Starting a project from scratch staffed by only inadequately experienced developers;
2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project (
/opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
-
Re:Missing or immature portions of the software st
1: I'm not sure what you concider a business tool but all the major business tools I can think of run on linux. Many of them started on unix long before windows was around. examples: autocad, wordperfect, oracle come to mind off the top of my head.
2: http://freshmeat.net/search/?q=html+editor§ion =projects&Go.x=0&Go.y=0/
3: I'm not sure how a website designed to work only with IE is a business to business tool but ok, You can design an apache website to use only IE too.
4: linux terminal servers have been around longer than windows has had that ability. The GUI, http://x.org/, was designed with that very thing in mind.
Now you say that with the linux solution, the small business can't afford to pay for the 10% that linux doesn't offer. How are you going to afford the windows solution for which they would have to pay 100% for? I think you also have the wrong idea about what a software stack is. -
Re:Mac OS/X, of course.
When will Apple release a gui for Darwin?
A GUI, or the Mac OS X GUI?
A GUI is, as far as I know, already available, although not from Apple. X.org's X server is available for Darwin, and XFree86 probably is as well, and KDE, GNOME, etc. and their corresponding toolkits probably work.
That's not the OS X GUI, however. That might not be released soon, if ever; only if Apple would be willing to act as a vendor of core GUI software for other people's hardware would that happen (and, even if that happens, that doesn't necessarily mean it'd be released as free software, as Apple might not be willing to act as a supplier of free-as-in-beer core GUI software for other people's hardware, although there might be ways of making it free-as-in-speech without being completely free-as-in-beer, e.g. releasing it under a dual license, GPL plus a license that lets non-GPLed software use the GUI libraries, with a version licensed under the second license requiring a license fee - that's a bit similar to the way Qt is licensed, although it's not the same, and I don't know whether it'd work).
Darwin is very rudimentary when compared to OS X.
Umm, yeah, that was sort of my point in the message to which you responded....
-
Vendor Dependent Death Marches VS Open KaizenHaving been involved in a couple of in house enterprise projects and having spoken to dozens of local developers on the subject of failed and successful projects, IMHO the three major reasons for large in house software project failure are:
1) Starting a project from scratch staffed by only inadequately experienced developers;
2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project (
/opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
-
Re:Remote Applications
It's 6.8.1, isn't it?
-
Re:What is X11 vs. native vs. NeoOffice.org???
native is special because it runs faster and blends in with other native apps
aqua and quartz are bad because they are made by apple
x11 is good because it is produced by the good folks over at X.org -
Re:Welcome to the Present
Look at x.org. Look at what they want to do with switching everything over to OpenGL rendering. I think you might find quite a few simularities between Longhorn, OSX, and x.org. It's the trend, and I think it's a smart desision.
So what if you won't be able to use the windowing system unless you have an accelerated graphics card? Nearly all new(er) computers have graphics acceleration capability. It opens up a WHOLE lot more possibilities with what can be done within the windowing enviroment. PLUS it makes things a whole lot simpler when you only have to worry about one driver (OpenGL for example), for 2D and 3D applications. -
Re:Don't sink to their levelExamples? How about these?
Things licensed as Open Source do better on "just the facts" vs hype. Maybe it's because their audiences would take them to task if they did otherwise, but description of things such as GCC, Wikipedia , the Linux kernel, the GIMP, to name just a few, are completely factual. Not entirely free of marketing but tolerable are the Linux site's description of Linux, OpenSSH, bzip2, Project Gutenberg, and an XWindows organization X.org.
Particularly note Wikipedia and Google. The description of Wikipedia was made and chosen by the users. I can't think of a better testament that what users really want is just the facts. And Google understood that the last thing a person wants to do when anxious to find something quick is be forced to wait for a bunch of pointless graphics and generic ads to load. Really aggravating when on dial-up. Before Google, I got to where I knew just when to hit the stop button when loading Yahoo's main search page so I'd get the text input line and search button and miss all the extra crap they used to put on their main page.
Of course open source isn't totally above marketing. FreeBSD, Mozilla Firefox, KDE, Apache, OpenOffice all lay it on. They can point to all kinds of statistics to justify their hype, but the hype is still irritating when it catches my attention. These are easy to accept in spite of the marketspeak because I've heard from elsewhere that they're good.
Bad though some of those are, Microsoft is worse. Maybe what MS does should be called extreme marketing? In a few moments of searching, I was unable to find even a badly overblown description of just what Windows XP or MS Office is and during the search was wading through hype about MS's latest whatever: "Try the new digital music experience from Microsoft. You'll love it!"
As for throwing out the baby with the bathwater, I will spend a little time trying not to do that, but when it does happen I hope it clues the promoters in to realizing they made the waters too murky. Accepting something in spite of murk is not the way to persuade them to clean up. I like to tell them about it too. You never know when commentary might actually be heeded. I'm sorry if a good thing gets short shrift, but when time is limited, books will be judged by covers. People are often asked to try to word emails so spam filters will pass them. I feel I'm not asking too much of marketing to do the analogous.
-
X.ORG + Xinerama will let you do this.
If you simply have multiple PCIE cards in the same system, X.ORG and Xinerama will allow you to do this by building a 'desktop' of four screens - you can then playback 'fullscreen' video across all four.
The dual-head functionality of some cards could let you get away with just 2 cards as well.
One drawback is that as far as I know, OpenGL is not implemented in Xinerama yet (not such a worry for video tho). -
Re:Help ! I'm all mixed up with X version numbers.
But why do we talk about a "protocol" ? Isn't X a program for displaying stuff ?
Nope. X is a protocol for sending drawing requests. An X server is a program for displaying stuff.
I know we can use remote display on a network with X, but why isn't it only a feature? Why is X so focused on network terminology?
Some features are just minor tweaks to a basic design that could exclude them, other features are fundamental to the design. Network transparency is fundamental to the design of X. Even when you're not using a remote display, you're always using the X protocol, but over UNIX sockets rather than TCP sockets.
And how about differences between XFree.org and X.org ? And OpenWindows ? Are they three implementations of functions (same ".h"s) for displaying windows and drawing things?
They're all programs that receive drawing requests in X protocol messages and then do their best to fulfill the requests by drawing stuff on a display. XFree86 and X.org are mostly the same codebase as well, but that's not really relevant to their functions as X servers. There are lots of other X servers around like OpenWindows, Hummingbird EXceed, MetroLink, Xi Graphics, XVision, and bunches more. Pretty much any X client application can use any of these X servers, locally or remotely, to display windows and draw things. Some X servers have more features than others, some have better performance than others, some support more graphics cards than others, but all implement the same standard protocol so they're all to some degree interchangeable.
But you asked about differences, not similarities.
- XFree86 and X.org are much the same programs, but XFree86 adopted a license that people didn't like, so much of the development focus shifted to X.org, and that seems to be the Free implementation that is going to be popular moving forward.
- OpenWindows is Sun's proprietary implementation that only runs on Solaris, AFAIK. It's decent but not as featureful as XFree86 and X.org.
- Hummingbird Exceed is a commercial product that runs on Windows, and exists primarily to make it possible to display on a Windows box the interface of apps running on remote UNIX boxes.
- Xi Graphics is a commercial, closed-source X server for Linux and UNIXes that focuses on providing good hardware acceleration and support for a wide variety of graphics cards. Since they get paid, and because their drivers are closed source, it's easier for them to negotiate with hardware vendors for specifications.
- Tarantella XVision Eclipse is another X server that runs on Windows and has some nifty features like the ability to suspend a session one place and resume it somewhere else.
- xnest is an X server that doesn't know how to draw anything itself, but instead sends all of the requests it gets to another X server for actual display. So you can nest an X "server" inside a window on a real X server (and you can do that as many layers deep as you like). This is a useful tool for development.
- vncserver is another X server that doesn't draw anything on physical displays. Instead, it does all of its drawing on a virtual screen, then it can send this virtual screen image over the network to VNC clients which run in a variety of windowing environments and display a copy of the virtual screen. You can even display the same virtual screen on multiple VNC clients on multiple physical screens at the same time.
- x2x is an X server that uses a pair of "real" X servers to do all of its drawing, creating a single virtual display that is made up of two physical displays on different machines. This allows the user to create a two-headed machine without a two-port graphics card, or two graphics cards in a single box.
Those are some examples of X servers and how they differ from one another. There are many, many more, particularly in the commercial X server space, but they all work with all X clients, locally or remotely, and the common thread that binds them all together is the X protocol.
-
Re:Yet again, zero innovation
OK, here http://x.org/, start programming. Oh, what, you're not going to? Then stop ranting.
-
Original or revised BSD?
I'm a bit confused as to whether you are refering to the original (see the UCB/LBL section) or the revised BSD license.
Under the revised BSD license (which is very similar to the X11 license and is what I am assuming is what you are refering to as the "MIT license") you need only mention copyrights in documentation.
Under the original BSD license you HAVE to mention the copyrights and contributors when the program is used or when the program is advertised. -
Re:It does matter...
Some usefull information (although not as clearly laid out as I would like) can be found at on x.org's freedesktop page.
Basically, they say that it started out as XFree86 4.4 RC2, and was started because the new XFree86 license may possibly be incompatible with the GPL. Since then, they have continued to improve the code, so it should be better than the version it split from. Of course, I can only imagine that xfree has been developed to about the same amount, but I don't know the exact differences. There is a changelog at the link I gave.
I don't think there are drastic performance differences between the two versions yet, although aparently work is underway to improve performance in some things that were badly implimented in xf86-4.3.
At this point, I would say that unless you are obsessed about having the latest version of everything, want to try out the new, or have run into one of the specific bugs that is fixed, I wouldn't recommend updating. But the next time you would otherwise update to a new version of XF86, I would go ahead and switch to x.org. It's definately not worse, and it seems to be the future of X on linux for time being. For all new installs I would install x.org.
That said, I just ran "emerge -C xfree" "emerge xorg-x11" so I guess I'll find out if it's worth it (in about a day when it finally finishes compiling).
-
X11 : Remote Network Backward Compatible to 1987The X Window System, more simply 'X' or 'X11', is judged worldwide to be one of the most successful open source, collaborative technologies developed to date.
Since it's public release in 1987, every new release of the display servers has remained backwards compatible to remote networked applications going back to 1986. That means that you can have a 1987 Unix server running an X application, behind an internal firewall, networked to any modern X display server on any desktop OS you care to name. It is the only graphical network protocol in current use that has remained backwards compatable. X11 display server vendors are not going to break that backward compatiblity
Building remote network X11 application servers has proven to be the most future proof, vendor independent and secureable route.
-
Re:No-risk, non-abusable
Ever heard of x.org?
-
Re:Format, install Linux...
xfree is dead
long live X.org -
What about a x.org X11R6 or NX server pluginWhat would be useful plugin would be an x.org X11R6 X server based on Xnest, or NoMachine's NX client.
Sites wanting to deliver a richer interface could just use remote X applications.
-
Partly nice, begging for the Compose extension
Well, some parts of this are nice. I have reservations about the actual 3D parts, but window scaling would come in handy.
Having another X server to mediate this stuff isn't very clean though; I understand that they went that way for early development, since there isn't really anything finished that would be better, and they apparently wanted to get to the effects stuff. On the long run, however, it seems that this stuff should be done by a Compositing Manager. Of course, this also requires that the X Composite Extension be implemented in mainstream X servers (read: X.org).
-
Re:this will be seen as an afront to capitalism
1. License cost is quite low, even Mandrake is more expensive
Err, does that mean that you can download Microsoft Windows for free and actually get money in return?
2. You are a liar. Upgrades are not mandatory. You clearly lie about that. The upgrade cycles are smaller than Linux upgrade cycles which is higher in quantity.
You do not get support for Windows NT 4 or even security patches anymore. For some new hardware devices, there are no NT drivers either. You're not forced to upgrade, but it's a necessity. It would actually be ok if they didn't charge that much money for it.
3. Open source lock in is worse, since you have to deal with many number of individuals. XFree86 problem? France can not deal with such stupid issues.
Guess what? Last week I fixed a bug in Gentoo Portage without ever having looked at the source before. Isolating the problem and fixing it too me less than an hour. Before that, I fixed a number of trivial bugs in other OSS. It's not really difficult, any capable developer can make use of the source code, although naturally it's easier for those experienced with the project. And you did notice that XFree86 has actually been forked because of a licensing dispute? OSS allows you to do that. Try it with MS Windows.
4. "Pissing off Bill Gates" This is only something an idiot like you will consider. Governments are not losers like you, they have a real business.
Glasshouse. Stones.
-
Re:Okay, I'm confused...
The X implementations in commercial Unix-like systems are almost all based on the X11R6.x code base that is the descendant of the MIT code. X.org is the maintainer of that code base, enhanced by a merge of code from XF86 4.4.0RC2, i.e. XF86 just before the license change. The initialization of the current X.org code repository is described here and the result of that merge was the release of X11R6.7 in April.
X.org did undergo a rather significant organizational revolution leading up to the import of the XFree86 code. They had seemed to be mostly dead for a couple of years, but in January the 'X.org foundation' was announced and they took off again. As with any corporate-born organization, they did up some slides and did a presentation.
In short: you had it a bit backwards. The 'official' X11 was a joint project (more or less...) that was pretty slow and closed for quite a while, slow and closed enough to make XF86 look dynamic and open. The various issues with XF86 (license, acceptance of patches, etc) triggered a rebirth of the X11R6 project, infused with XF86 code. Vendors of other non-Linux and non-x86 systems have nothing really to be concerned about, since they are effectively in control of X.org now as they were before.