Frontiers: A New Xlib Compatible Window System 439
alucard writes "The JourneyOS people have published this overview of their upcoming window system. It looks like it is OpenGL based and uses XML as the communications protocol. The biggest news is that it is supposed to have Xlib compatibility, but uses HyperQueues instead of Unix domain sockets. Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility? I think this is something everyone wants, but projects to create alternative GUIs such as Fresco and PicoGUI have given up any hope of compatibility with X11 or Xlib. Can we expect another alternative out there soon?"
Hrmm (Score:3, Insightful)
Perhaps someone could explain that to me...
When hell freezes over. (Score:3, Insightful)
No networking capability and difficult to port since it is tied into a x86-only features.
Anyways, remember X only uses networking IF IT HAS TO. No TCP crap if your on the same computer as the X client, it all goes thru sockets, which are plenty fast.
I wouldn't mind a replacement to X, but this isn't it.
XML (Score:4, Insightful)
But it's an extremely bad choice if you want to move lots of the same type of data around, when you know the format of the data in advance, and you do if what you're sending is drawing primitives, GUI widgets from a standard toolkit, etc etc. That is because of all the redundant metadata. If you are sending (for example) a CSV file the metadata comes once, in the header, and all the rest is pure data. An XML file stores the structure with the data - if you did this in a CSV file, it would mean repeating the header every other line, doubling the size if your file (or stream) for no advantage. It's worse with XML where you might have <somelongtagname>1</somelongtagname> - that is, your metada being far larger than your data. All compression does is add both processor and memory overhead at both ends, assuming the network isn't already saturated.
I know that XML is "trendy" but it's the wrong tool here - a binary protocol should be used.
could it be... (Score:5, Insightful)
Could it be that the poster hasn't read more than 1 page into the comments on the last dozen times this X-is-slow BS has come up? I thought we all agreed on this one, but apparently not.
This is very frustrating to see, because this makes for system #3, and things were already bad enough with 5 billion different window managers. Choice is great and all, but there's a reason some things are standardized, and "xlib compatibility" is not the same as "X"; I guarantee this new system will break all sorts of things in new and exciting ways.
Perfect example of how open-source has failed us; EVERYBODY's gotta invent their own wheel instead of helping to make the existing wheel(s) better.
Didn't Apple teach us anything? (Score:5, Insightful)
Oh no. Not just X, but also Win32 compatible.
I doubt we'll ever see this project finish. When is anybody going to just start from scratch, like Apple did with OS X? Build it and they will come.
My prediction (Score:3, Insightful)
Slashcode lookalikes (Score:2, Insightful)
Oh. my. god. (Score:4, Insightful)
Thanks, no, I never want to try this one. XML as communication protocol is a nice generalization on the paper, but in practice, it sucks. GUIs should be optimized for speed, and thus, the protocols should be specialized, too.
Re:My prediction (Score:3, Insightful)
Re:That depends... (Score:5, Insightful)
Of course XFree86 depends on the card manufacturers giving them documentation for the hardware, but if the manufacturer doesn't see any advantage in helping Linux use their cards to their fullest, don't expect for a minute that they would help some unknown group like JourneyOS.
Re:Didn't Apple teach us anything? (Score:4, Insightful)
Umm, Apple didn't start from scratch. They bought an existing platform - OpenStep - and customized it. OpenStep and NeXTStep before it were both mature products in the MCCA space (mission critical custom app) for example financial applications, telecomms, etc.
As an old NeXTStep user, in many ways OSX was a step backwards... still it is good to see that Apple are able to make a more of a mainstream success than NeXT did. NeXTStep was a great OS that should have owned the business desktop in the early 90s, if Jobs hadn't screwed up marketing it so badly. Businesses were banging on his door to buy it back then and he said no, we only sell to education, but he priced his machines at $10,000!
Re:Hrmm (Score:1, Insightful)
btw, the problem with xfree is NOT raw speed. toolkits are slow, video drivers are old/slow/incomplete/or completely non-existent, important extensions are missing or developing and adopting to slow, the development model seems stagnant, there is no or little cooperation from video card makers, etc... but the speed of xfree is NOT a problem, nor network transparency is.
Re:bah. (Score:1, Insightful)
Re:My prediction (Score:3, Insightful)
Try win2k/ultraedit/mozilla vs. linux/(kde or gnome editor)/mozilla. The win2k machine is *way* faster.
xfree as it is is slow. the culprit can be the drivers inside xfree (the nvidia driver *suck* for 2D performance !), it could be the broken toolkits (gtk2, qt), it could be something else.
I find it strange that some nvidia guys are re-inventing XAA in their latest drivers to work around some XAA speed problems
Re:Hrmm (Score:5, Insightful)
The only problem I see here, besides the usage of XML(it's flexible and easy to program, but too large as a metadata medium), is that many have tried this before and failed. Only time will tell.
I'll give it a week before declaring it 'YetAnotherDOA sourceforge project'.
Re:XML (Score:3, Insightful)
No, this would be the relational model for database management -- not SQL. XML fails due to its hierarchical nature and complexity.
ARGGH! X isn't where the slowdown is! (Score:5, Insightful)
I get full-window dragging and resizing in WindowMaker on my old 366MHz laptop, and it has an ATI Mach64 video chipset. Windows crawls when I do similar operations on the same hardware.
I seriously suggest that if you think X is slow you check out a more lightweight window manager and apps. GNOME and KDE have a LOT of overhead because they run on top of an extra layer of abstraction (GTK+ and QT, respectively). WindowMaker is written in C to interface with X more directly and it shows.
You can still use your GNOME/KDE apps under WindowMaker, I'm using konqueror as my file manager right now. Try it.
As for this project, it sounds cool to me. I think X is plenty fast as it is, but that doesn't mean I think someone should take what we've learned over the last decade and apply it to a more modern 'ground-up' solution. It would be nice if there was an X replacement that had QT and/or GTK+ tied in more closely, or if we had a quartz-extreme-like OpenGL windowing system and font renderer with postscript-esque qualities (i.e. run my desktop at high resolution, but zoom everything appropriately for 'real-world' DPI).
Uh oh.. (Score:3, Insightful)
Can we expect another alternative out there soon?
Judging from the success of all the other zillion "I'm gonna create something new which will replace X"-projects, I suspect not.
Competing wheels make better cars (Score:3, Insightful)
OSS is great because it can pull in a thousand directions at once and still end up at the destination.
Mozilla is a great example, the core application has been extended to include a bazillion features, but its actually a kickass suite. And now there's a layout engine (gecko) that can be used in other applications to provide kickass HTML support.
GNOME and KDE are another great example, the rivalry has done more to further the project than anything else. Windows has come a LOT less far in the same time that KDE and GNOME have been around.
Could we move faster if there weren't competition, sure, but we'd need a lot of MONEY and MANAGERS to keep everyone in line and on-task. Luckily we don't have the burden of pandering for money or slaving under managers to get what we want.
Re:ARGGH! X isn't where the slowdown is! (Score:3, Insightful)
You are then comparing apples to oranges. You are comparing stripped-down WM to a fully featured GUI (in this case. Windows-GUI). In order to have a GUI with similar functionality, you need to run something like KDE or Gnome. And those certainly feel more sluggish than Win-GUI does.
How about speeding up the GUI, like KDE? (Score:3, Insightful)
Wasn't there just a /. article on XML... (Score:3, Insightful)
Mind you, XML is good. Especially because it's such an extremely picky data format. It's the only way to go for flexible document formats and all that, imho. But XML to shove grafics around a 2D space?
Come on, give me a break.
No, guys, nice try, but that guy with his XFree replacement called 'Y' a few days ago was much more promising.
Next.
Re:WBXML (Score:4, Insightful)
That might help, but you're still shipping a lot of redundant metadata around.
But even if it were plain old text XML, it still poses some real advantages, not least of which you could transport it over SSL, web proxies and other barriers that would stop an X-session cold.
You can quite happily tunnel anything you want over HTTP, even X11.
If the schema had sophisticated drawing primitives ala SVG you might find it is considerably faster than X which might be forced to move bitmap data around for similar operations.
Not if you want to remain fully compatible with existing XLib code.
X is fast enough (Score:5, Insightful)
Today I'm using Gnome. It's beautiful and useful, but the feature that hooked me was the superb i18n support (now I can finally do with X11 apps what I always did with Emacs: switch the input method! No more restarting apps to write multilingual Japanese/Portuguese texts!). But it is not fast, and that's in a Duron 800, 128Mb RAM. Gnome can be great for the third world, where we still have lots of Pentium 100s hanging around. Gnome and KDE are both excellent desktops, but they need speedups.
The main problem with X is (still) video card support and configuration (ever played with Trident TGUIs 9680? I have an LTSP net full of them). There's a lot of work to do, but we have come very far in this aspect. I doubt a "modern window system" wannabe could easily offer similar support.
Re:bah. (Score:4, Insightful)
Don't get me wrong. XML is great for its original purpose: a standard format for exchanging data with other programs. Programs not made by you, nor under your control.
XML was not designed to be fast, nor to take up little memory. It was supposed to just be easy to parse, in a standard way.
It's supposed to be used in situations like, "ok, we have this program, and have to import and use the data from 20 files from 20 other companies." (E.g., a travel agency wanting to be able to use data from completely unrelated companies, like hotels or airlines.) At which point, you don't care as much how fast it is to parse, you just consider yourself lucky to have only _one_ standard data format to parse. Even if it takes all night to get that data converted, you're still happy to have it in your computers at all.
Open Office using XML to save the files makes perfect sense, for example. It's _external_ data, and it's supposed to be readable by other program. That's exactly the intended use for XML. Again, the keyword is: external data.
But using XML _internally_? Gimme a break. If that's not a syndrom of being a SFV (Stupid Fashion Victim), I don't know what is.
I thought it was bad enough to see programs where perfectly good relational data isn't just printed to the screen as such. No siree, bub. They first convert it to XML, then run through an XSLT transformation to get the same data back. _Then_ they print it.
So I was thinking, "gee, surely nothing can be a more retarded waste of memory, CPU power and development funds." Well, now I'm proven wrong. There _are_ more retarded uses for it. This here X replacement has to take that crown.
XML is not a protocol! (Score:2, Insightful)
What kind of dumbasses submit these articles?
XML is not a protocol! XML is a method of formatting structured text data. In this case the protocol seems to be HyperQueue (whetever that is) and the payload is formatted in XML (and compressed).
Using XML instead of a streamlined binary format and then compressing it to save bandwidth is double stupid.
Re:ARGGH! X isn't where the slowdown is! (Score:5, Insightful)
If you have issues with the performance of your linux desktop you should be looking at the applications, desktop environments, and toolkits, because XFree86 is definitely the wrong tree to bark up.
One thing you learn with computers is that you can speed things up only as much as the smallest bottleneck will allow. X is not at all the bottleneck for graphics performance on Linux machines.
I am a Qt Developer (Score:1, Insightful)
Here is a crude diagram of how Qt works.GTK works like this.Athena works like thisAs you can see, Qt and athena have less abstraction layers to go through, and that makes it run a lot faster. Anyone who has used konqueror recently (kde cvs or 3.2 alpha) will love the speed. Heres why its much faster
MozillaKonquerorThe reason why konqueror is much faster is because it uses native qt calls rather than a kludgy language called XUL which needs to be parsed and converted into GTK calls which goes through the usual slowdown! Thats why apple uses KHTML technology in its browser, no need to bog your new G5 with mozilla!
X is not slow, just run a app through a tracing tool and see how many library calls GTK apps make compared to KDE apps, its insane!
Hence because GTK is so slow, the gnome team had to strip their apps (read : remove features) to compensate for it.
Re:could it be... (Score:3, Insightful)
The X wheel is already round. Going through the phases of making triangular wheels, square wheels and octagonal wheels until arriving at the round wheel, again, seems redundant.
I have yet to see a let's-replace-X proposal that has succeeded in making a convincing case it would end up in any way better. This one doesnt either.
Re:could it be... (Score:3, Insightful)
Something like windows is very limited in how it can evolve for two reasons. On the one hand there is the development history which can make it very expensive to make certain changes, if they would affect a lot of code, and then there is the corporate culture behind the project that has a certain way of doing things. Both these factors tend to enforce a somewhat linear style of evolution for a system. Windows evolves, yes, but only along certain lines in one general direction. Some of the projects I've worked on - if they'd invented the wheel it'd have been triangular. "It works if you put enough power behind it. If it ain't broke, don't fix it"
The first problem is lessened with open source, A project can split in several directions at once and the most useful results will eventually be the ones to predominate. This is only possible beause there are (in general) no dealines; no financial risk involved and no one is required to use the new packages generated by this divergence.
The second probles does affect open source, but far less so. There is pressure from the community to use established methodologies and packages, but this cannot be enforced.
The upshot is that a lot of coding gets done in the open source world that would be politically impossible in a corporate environment. Which means that we see a lot of creativity. Sure a lot of that is misguided, and a lot of these divergent projects fail. Then again, a lot of corporate projects fail too - we just don't hear so much about those ones:) Meanwhile the successful ones can lead developemnt in unexpected directions, interact with other new ideas to produce even stranger offspring, or diverge into something else entirely
The thing that stops everything from diverginf completely is that there is a nequal pressure to standardise and unify packages. That's factor two again.
It's an unstable equilibrium. Divergence and convergence, Ying and Yang. Because square wheels need reinventing.
Re:could it be... (Score:3, Insightful)
hardware specs (Score:1, Insightful)
I got that on my 8Mhz RISCOS computer.. why are modern desktops so inefficient?
Re:ARGGH! X isn't where the slowdown is! (Score:4, Insightful)
What is 'desktop'? A mac metaphor, ripped off by windows, which has no place and is not needed in X.
Quit trying to make your unix box act like a toy and start using it the way it was designed to work, and you'll quickly find out it's a lot better that way.
Re:Didn't Apple teach us anything? (Score:3, Insightful)
I think what you're looking for is MacOSX.
Existing OS, rewritten GUI, standard installer, one decent app for each task -- this sounds like MacOSX to the letter. Some of the config stuff is in a directory server (NetInfo) -- like the users, lookup, etc. The vast majority of config stuff is in XML files though.
In the end, I don't think Linux is ever going to get there -- there are too many people who are independent and have no real motivation for coming together. Your best hope is one of the major distributions spending a lot of time on usability and polishing up the applications.
Personally, I got tired of waiting for a decent distro where everything just worked. I bought a PowerBook with MacOSX and haven't regretted it once. I've still got my old Linux box chugging away as a NAT/file server, though. Linux has already made great inroads for servers (especially at the low end) and I expect it'll keep doing well in that space. In the desktop market, unless you're an extreme free-software advocate, I think MacOSX is a much better choice.
-Esme
Why I am tired of this "let's replace X" s&%@. (Score:4, Insightful)
"X is bloated"
"X is old"
"X needs to be rewritten"
Blah, blah blah, blah, blah. Blah. I'm going to be honest here, workstation performance is abysmal on any of the recent flavours of Unix, expecially gnome/KDE, and expecially XF86. There are basically two reasons for this:
1) XFree86 sucks
2) and XF86 sucks
(I am not being sarcastic - please hear me out...) Xfree86 sucks because it does not have good drivers. Many functions run unaccelerated on cards that have all kinds of cool acceleration features. It seems some of these features have been written, but not added to the tree ( or so I have been told.)
XFree86 sucks because it has not been proactive in implementing the features/extensions required by the newer toolkits like gtk+/qt. Are you aware that gtk pushes everything as a bitmap through the X protocol for each expose event? XRender is probably the only instance where the toolkits waited for an X extension to be developed before added in a feature that required it - generally the toolkit authors, rather than wait for an X extension or piece of functionality, they will implement it in the toolkit so that the client just pushes the pixels dow to the X server.
Do not look to discard X. X is in fact the one thing that we have that Windows and Mac do not have. It gives us years of backwards compatiblity, and an extensible, network transparent architecture. Instead, we should put our hopes in Xouvert and similar projects that are looking to give us a world-class X server, and the pieces that the toolkit authors need to optimize their toolkits for X.