Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
X GUI Operating Systems Software

Frontiers: A New Xlib Compatible Window System 439

Posted by timothy from the but-x-is-so-versatile dept.
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?"
This discussion has been archived. No new comments can be posted.

Frontiers: A New Xlib Compatible Window System More

Frontiers: A New Xlib Compatible Window System

Comments Filter:

  • That depends... (Score:3, Funny)

    by Motherfucking Shit ( 636021 ) on Tuesday October 07, 2003 @05:12AM (#7151525) Journal
    Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility?
    If you're talking about my Pentium 75 firewall with 40 megs of RAM, I'd say that the answer is probably "no." Then again, I think I saw a pig flying on the way home from work today ;)

    • Re:That depends... (Score:5, Insightful)

      by Anonymous Coward on Tuesday October 07, 2003 @05:33AM (#7151605)
      Regardless of what computer you run it on, you had better count on the flying pigs being there before a window system based on OpenGL and XML beats X11. After all, despite all the slagging it gets on slashdot, X11 does have a reasonably sane binary wire protocol and XFree86 does utilize most of the 2D capabilities of your video card.


      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.

    • ARGGH! X isn't where the slowdown is! (Score:5, Insightful)

      by MarcQuadra ( 129430 ) * on Tuesday October 07, 2003 @05:54AM (#7151658)
      Alright, people need to listen closely. XFree86 is NOT SLOW, the toolkits you lay on top of it are what bogs it down.

      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).
      • I seriously suggest that if you think X is slow you check out a more lightweight window manager and apps.


        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.

        • Umm no, in all seriousness, it's MSWindows that's stripped down in comparison to WindowMaker. Every time I have to use Windows, I miss features that WindowMaker has, but in using WindowMaker I've never once missed something that MSWin has.

          I dare you, name any meaningful feature MSWin has that WindowMaker lacks.

        • You are correct. However that has nothing to do whatsoever with X itself. (well, some faster/better gfx drivers might help, but that is a problem of any graphics system)
        • It's you who's doing the apples/oranges comparison.

          The Windows-GUI is at the level of FVWM, actually not even that because even in FVWM you get virtual desktops.

          Anyway, even with a 2 year old machine it's a moot point anyway as there are no performance problems neither in Windows nor in KDE/Linux for me.

          • The Windows-GUI is at the level of FVWM, actually not even that because even in FVWM you get virtual desktops.


            You can get virtual desktops for Windows through a tiny app that you can download from MS (was it Powertools or something?). On the other hand, FVWM doesn't even have desktop-icons...

        • Re:ARGGH! X isn't where the slowdown is! (Score:5, Insightful)

          by MarcQuadra ( 129430 ) * on Tuesday October 07, 2003 @07:29AM (#7151980)
          That still doesn't make X slow. If you insist on KDE and GNOME you should be complaining about KDE, GNOME, Qt, and GTK+. XFree86 and Windows have similar graphics throughput, the Windows UI is a LOT lighter than KDE or GNOME, and it runs partially in kernel mode.

          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.

          • If you have issues with the performance of your linux desktop you should be looking at the applications, desktop environments, and toolkits...

            Indirectly, though, isnt' that what these guys are proposing to do? Redesigning the lowest layer so that the upper layers don't have to be the way that they are now?

            Cheap graphics cards are so much more capable these days than what they were back when X was designed. OpenGL support (or DirectX, whatever you want to call your hardware acceleration) is more common a

      • right on! (Score:3, Interesting)

        by SHEENmaster ( 581283 )
        I use OpenBox, also a slimmed down GUI.

        One unexpected benifit of switching was the increase in the speed with which I can use it. I just spin my mouse wheel, and I'm on another desktop or a window has been (un)shaded. There is no slow config app, I can do everything from the menus.

        Getting people to switch from one windowing system to another is not easy. Apple accomplished it by providing usable, if lousy, backward compatibility and a complete OS change. Microsoft accomplished it by half-ass backw

      • I agree. The problems folks think they have with X are problems with software they're running on top of X, and often with lack of decent drivers. A new system isn't going to have things easier getting drivers, that's for certain.

        It would be nice if there was an X replacement that had QT and/or GTK+ tied in more closely

        That statement, however, I cannot agree with at all. One of the great advantages of X is toolkit-agnosticism. This allows innovation, evolution, progress that other platforms with builtin

      • > Alright, people need to listen closely. XFree86 is NOT SLOW, the toolkits you lay on top of it are what bogs it down.

        So if you use a ugly looking desktop X is fast, but if you use a modern looking desktop X is slow, both with KDE and Gnome.

        There are two possibilities:
        - either KDE and Gnome are both slow
        - or X itself is not well adaptated to modern needs, so we could say that X is slow.

        BeOS feels much faster than KDE or Gnome, so it *is* possible to have a fast modern looking desktop, either it was b
        • There are two possibilities:
          - either KDE and Gnome are both slow
          - or X itself is not well adaptated to modern needs, so we could say that X is slow.

          Check out XFce [xfce.org] and you'll see that both KDE and Gnome are the bottleneck. It is definately possible to have a modern, sharp looking desktop that's easy on the memory and XFce provides this for me. It's very snappy on my p233 96 MB RAM laptop and uses GTK2 (the same toolkit Gnome uses). I've heard people with far slower boxes than mine say that XFce is snap

        • Re:ARGGH! X isn't where the slowdown is! (Score:4, Interesting)

          by irc.goatse.cx troll ( 593289 ) on Tuesday October 07, 2003 @08:35AM (#7152473) Journal
          Why is it doubtful that the kernel comes into play?
          You have no idea how much of a difference it makes (I'm not saying this to be derogatory, just expressing a point).
          A well configured kernel provides so much more usability, some examples of things to look into:
          - Anticapritory I/O Schedualer. -- Some disk read operations actually take multiple reads which get schedualed in a weird way when theres currently something being written to disk. The reads get schedualed in a way that the writes are between reads, causing the original read operation to take a lot longer due to the added latency. This patch will anticipate such situations, and cause each read to pause for a few msecs so that the next read can be schedualed instantly.
          - Interactive patches (preempt, ll, et al) -- Guess if an application is interactive based on how long it sleeps between reads. An app that constantly reads is probably not interactive, so it should have less priority. You know what they say, the slowest part of a program is the user, and that is kind of how this works. When a program sleeps for input between read its marked as interactive. This way bash responds with quickness, but gcc can wait for your interactive procceses.
          - IP QoS -- Not really X related, but really makes a huge performance diference. With QoS enabled, You can set it up so that small packets (500), then limit your outstream to a little less than your max so that SYN|ACKS can still get out. The result is that you can max your upload/download to your hearts content, but your latency NEVER takes a hit. I can even scp to my server while sshed in (both using the same sshd, which is why packet size comes in) and my ssh session still remains responsive.
          There are more, But these are just a few examples. I'm debating writing a paper on properly setting up a modern Linux system for maximum usability, as theres a huge difference and a lot of it is in the kernel.
          Sorry for any bad formatting, ironicly enough I typed this in lynx due to a few bad apps(python + wxwindows is the kiss of death, both soulseek and bittorrent tend to trash my usability). Still need to address that, heh.
          • >Why is it doubtful that the kernel comes into play?

            Because BeOs proponents usually talked about their GUI subsystem, or the multithreaded design of their apps, not of their kernel, that's why I don't think that the kernel

            >- Interactive patches (preempt, ll, et al)
            I installed the intertactive patches on the 2.4 kernel and I didn't see any difference in the responsiveness of the applications.

            >- IP QoS
            Uh? We're talking about the responsiveness of X locally..
            So IP has nothing to do with it..
            Beside
    • I never had any speed problems with X on my firewall. Then again, I never had X installed on my firewall either, especially not an X server.

  • bah. (Score:3, Interesting)

    by Anonymous Coward on Tuesday October 07, 2003 @05:17AM (#7151542)
    This will be SLOWER than X, for god's sake, at least locally. Unix domain sockets are zero-copy on Linux! XML requires full-blown parsing, X messages are fixed binary format.

    • Re:bah. (Score:3, Informative)

      by Westley ( 99238 )
      The messages aren't in textual XML format, they're in WBXML, which isn't going to require nearly as much work in parsing etc. (Whether you consider WBXML messages to be "fixed binary format" or not is up to you.)

      Jon
      • The messages aren't in textual XML format, they're in WBXML, which isn't going to require nearly as much work in parsing etc.

        Is the difference really that big? WBXML is kinda "compressed" XML, the semantics are exactly the same. You still have use either DOM trees or SAXish callbacks.

        (Whether you consider WBXML messages to be "fixed binary format" or not is up to you.)

        It's not, it has the same freedom of structure (nesting etc.) as XML.

    • Re:bah. (Score:4, Insightful)

      by Moraelin ( 679338 ) on Tuesday October 07, 2003 @07:09AM (#7151881) Journal
      Bingo. It never ceases to amaze me through how many loops people will go, just to stay "fashionable". One of them being the retarded use of XML on an _internal_ data pipeline.

      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.

  • Hrmm (Score:3, Insightful)

    by acehole ( 174372 ) on Tuesday October 07, 2003 @05:17AM (#7151544) Homepage
    I can't see how creating more X alternatives or derivatives are going to help linux become more mainstream on the desktop?

    Perhaps someone could explain that to me...

    • Re:Hrmm (Score:2, Funny)

      by ComaVN ( 325750 )
      emacs vs vi and gnome vs kde flamewars are getting old, we NEED a new one.

    • Re:Hrmm (Score:5, Insightful)

      by digitalunity ( 19107 ) <digitalunityNO@SPAMyahoo.com> on Tuesday October 07, 2003 @05:44AM (#7151633) Homepage
      The idea here isn't to create an X alternative, but an X replacement. Something modern, fast, light. I know everyone is going to chime in with 'XFree86 is good enough. And it isn't bloated or slow'. It is an excellent piece of software, but it isn't as fast as it could be. There are commercial X11 servers for Linux that really are as fast as advertised, I've seen it in person. Another of the 'problems' with XFree86, and even commercial X11 servers is that they don't take advantage of modern GPU's. Granted, OpenGL isn't an ideal method of rendering *everything*, but for some things, it would offload much of the graphics subsystem from the CPU. There are cases where OpenGL would be much slower, but with a little smart programming, this can be avoided. OpenGL also has the added benefit of adding some eye-candy features like transparency without taxing the CPU. Anti-aliased vector fonts are easy with OpenGL.

      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'.
      • Having OpenGL as the default, main rendering model absolutely stinks. It means you can not feasibly run a desktop that does not have hardware accellerated 3d. "So what?" I hear you cry. Well, a major "desktop" class of devices for Linux are PDA:s and similar handheld stuff. You would have to run something else on them as they do not have the hardware for your "light" system.

        The other major problem are laptops. I use a fairly modern laptop, with hardware 3d. Problem is, running hardware 3d absolutely kills

        • Re:Hrmm (Score:3, Informative)

          by Stiletto ( 12066 )
          NOT TRUE AT ALL.

          OpenGL is just an API. If your app sticks with 2D calls, you should be fine even on graphics chips that only support 2D. Simply implement a basic 2D path in your OpenGL driver and punt the rest to software. My hourly rate is reasonable if you're interested ;-)
    • uh, it's quite simple really. No, really it's really really simple! If you have a few alternatives that are all compatible, the only result is betterment of the system.

  • When hell freezes over. (Score:3, Insightful)

    by Anonymous Coward on Tuesday October 07, 2003 @05:19AM (#7151550)
    Replacement for X. Not bloody likely.

    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)

    by sql*kitten ( 1359 ) * on Tuesday October 07, 2003 @05:20AM (#7151556)
    XML is a good choice for storing data when you might want to extend the attributes of a record/properties of an object without breaking existing applications. That's inherent to the design of XML - so long as you query your documents in a structured way - say with a DOM parser and XPath - then "extra" tags don't make a blind bit of difference, except for taking up some memory and some processor time.

    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.

    • Re:XML (Score:5, Informative)

      by hummassa ( 157160 ) on Tuesday October 07, 2003 @05:43AM (#7151631) Homepage Journal
      a binary protocol should be used.
      A binary protocol is being used: it's WBXML over HyperQueue. RTFA. :-)

    • Re:XML (Score:3, Insightful)

      by leandrod ( 17766 )
      >
      XML is a good choice for storing data when you might want to extend the attributes of a record/properties of an object without breaking existing applications.

      No, this would be the relational model for database management -- not SQL. XML fails due to its hierarchical nature and complexity.

    • WBXML (Score:5, Interesting)

      by DrXym ( 126579 ) on Tuesday October 07, 2003 @06:06AM (#7151697)
      WBXML compresses XML down to bytecodes. It's used in WAP and other places. It works off the DTD, assigning bytes to represent the various tags and attributes.


      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.


      Besides which the transport is probably not as important as the data you are send. 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.

      • Re:WBXML (Score:4, Insightful)

        by sql*kitten ( 1359 ) * on Tuesday October 07, 2003 @06:16AM (#7151731)
        WBXML compresses XML down to bytecodes. It's used in WAP and other places. It works off the DTD, assigning bytes to represent the various tags and attributes

        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.

        • Re:WBXML (Score:5, Informative)

          by luisdom ( 560067 ) on Tuesday October 07, 2003 @09:25AM (#7152895)
          Do you ever read sources?

          That might help, but you're still shipping a lot of redundant metadata around.
          From the WBXML specification abstract: ... Meta-information, including the document type definition and conditional sections, is removed when the document is converted to the binary format.

          Not if you want to remain fully compatible with existing XLib code.
          What? They provide a library that is xlib compatible and then extend it with more drawing primitives. What it makes xlib-incompatible is applications that use that specific primitives with plain X. xlib applications are not affected.

          It seems you dismissed the whole thing just after reading the post and you are just justifying that without checking other's arguments...

  • could it be... (Score:5, Insightful)

    by SuperBanana ( 662181 ) on Tuesday October 07, 2003 @05:20AM (#7151559)
    Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility?

    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.

    • At least if an OSS project fails the code is available for other projects to scavenge and incorporate. Where's all that closed-source code written for the dot.coms now? It's GONE or in the hands of lawyers, it will do no good for anyone.

      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 (geck
    • Actually it goes like this:

      Everybody has got to invent their own wheel once, and when they realize how big amount of work is needed,
      they never finish it. This is when they might join some existing wheel-building-project.
    • You see some of us don't care about extending what's out there. Some of us do. The great thing is that we are all free to move and create as we please. Sometimes it is done for the greater good of the community sometimes it is for our own selfish reasons. Perhaps you should quit assuming that we sit up late hours pounding out code to fit in with some master plan you or others have.

      BTW I am glad there are people thinking about how to continually make the old better, maybe they will fail, but plenty will

    • Re:could it be... (Score:3, Insightful)

      by NickFortune ( 613926 )
      I do think you're trolling, but I'll byte anyway...

      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.

      That's not the failure of the open source model - that is its strength.

      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 th

  • Didn't Apple teach us anything? (Score:5, Insightful)

    by daBass ( 56811 ) on Tuesday October 07, 2003 @05:20AM (#7151560)
    "This allows for one of the goals of JourneyOS, which is eventual Win32 compatibility"
    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.

    • Re:Didn't Apple teach us anything? (Score:4, Insightful)

      by sql*kitten ( 1359 ) * on Tuesday October 07, 2003 @05:34AM (#7151607)
      When is anybody going to just start from scratch, like Apple did with OS X?/i

      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!
    • starting from scratch seems like a good idea at first to you realize that what you end up with is an OS that has no software, and is difficult to port to because you changed the API too much A.K.A beos (whoops we forgot mmap() sorry guys no mozilla for you) as far as apple doing it, well they didn't write from scratch they built on top of BSD and others and said basically "you want to write MacOS software your going to switch too it whether or not you want to because we are not supporting classic for much l

  • My prediction (Score:3, Insightful)

    by mst76 ( 629405 ) on Tuesday October 07, 2003 @05:20AM (#7151561)
    Yawn, yet another X alternative/replacement. My prediction is that 15 years from now we'll still be using X11. Probably still XFree86, even.

    • Re:My prediction (Score:3, Insightful)

      by twistedcubic ( 577194 )
      I second that. I think the only people who think xfree is "slow" are the kids who like to play those video games.

      • Re:My prediction (Score:3, Insightful)

        by mbyte ( 65875 )
        No. I think people who actually want to do *work* with linux think xfree is slow.

        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 ...
        • What aspect is slow? Rendering objects? Moving objects? I use Fluxbox, so I can't think of anything I consider slow. The "kde or gnome editor" I use is Emacs, and I can't imagine it being any faster, except for the startup time, which isn't related to X. My Mozilla speed is fine, but I think the slowness of Mozilla is caused by Mozilla, since Opera 7 renders pages faster. Also, a basic app I wrote with Imlib2 rendered images ridiculously fast. I wouldn't measure the speed of X using KDE or Gnome.

  • Slashcode lookalikes (Score:2, Insightful)

    by Pflipp ( 130638 )
    How I hate Slashcode lookalikes as frontends for project homepages. You're spending hours looking to find a simple project introduction, FAQ or screenshots...

  • Oh. my. god. (Score:4, Insightful)

    by quigonn ( 80360 ) on Tuesday October 07, 2003 @05:21AM (#7151568) Homepage
    and uses XML as the communications protocol.

    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.
  • 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

    I suppose a gimp can run faster than Carl Lewis, but it'll take an awful lot to train him...
    • I suppose a gimp can run faster than Carl Lewis, but it'll take an awful lot to train him...

      "Of course KDE can run fast, just take some SuSE CDs, tie it onto a pig, and then kick it."

    • Re:Why ask ? (Score:3, Funny)

      by hummassa ( 157160 )
      I suppose a gimp can run faster than Carl Lewis, but it'll take an awful lot to train him...
      To train Carl Lewis?

  • total vaporware (Score:5, Informative)

    by rmm4pi8 ( 680224 ) <rmiller@@@reasonablereflection...net> on Tuesday October 07, 2003 @05:30AM (#7151593) Homepage
    nobody seems to have read the project page yet, or you'd note that the 'journeyOS people' are exactly one, the 'founder', and that so far the product is a conceptual description of an OS and another of a GUI. yep, that's it, no programmers, no code.

    not that i think noble adventures dont start small, but if the tons of smart people working on wine cant keep full compatibility, and the xfree86 team is having trouble getting substantial performance improvements....well, i wish this guy luck.

    sure sometimes we need a fresh start, but it seems as though journeyOS has perhaps a little more ambition than is healthy (posix and win32 compatibility, in full, and with good performance), and little in the way of resources. perhaps he could ask hans reiser about just how hard it is to design a good FS?

    seems to have bitten off more than he could chew, and as another poster has already noted, may have made some bad strategic choices at the same time. why xml for screen drawing when metadata is so often repeated? why design the GUI for the libOS that doesnt have any programs supported, rather than those that do (ie, POSIX, win32)?

    perhaps all in all 'dream big' would be a better motto for them...
    • >
      if the tons of smart people working on wine cant keep full compatibility

      Because MS-W32 is a pain. POSIX is much easier.

      >
      sometimes we need a fresh start

      Why?

      Point is, as far as alternatives go, the GNU Hurd is a much more interesting one, and it is already here... efforts spent on pie-in-the-sky efforts should go towards helping GNU Hurd reach its 1.0 release.

    • For once, this guy is trying to do a GOOD open source project. He is starting form the ground up with design documents, sepc'ing everything he wants out before he starts coding.

      Projects that are designed properly from the beginning and stick to that design while coding are normally more robust, and the actual coding is quicker since you already solved a large number of potential difficulties during the planning phase.

  • X using sockets.. (Score:5, Informative)

    by Chris_Jefferson ( 581445 ) on Tuesday October 07, 2003 @05:30AM (#7151596) Homepage
    OK, repeat after me... X is NOT SLOW BECAUSE IT USES SOCKETS!!! Please understand this! When you are on a local machine it uses optimised sockets, which are the fastest way of streaming information between programs, and were designed into linux for that specific purpose. Also.. you say "Speed up".. and they are going to use XML?? Sending information via a bloated ASCII (or even unicode)-based protocol? Yep, that will be fast won't it.. espically if they parse all the XML they recieve to make sure it is correct.. *sigh*

    • Re:X using sockets.. (Score:4, Interesting)

      by countach ( 534280 ) on Tuesday October 07, 2003 @06:01AM (#7151679)
      I agree. I'm far from convinced that sockets have anything to do with X being slow. In any case, doesn't X have a shared memory option?

      The point is, let's see some benchmarks PROVING that sockets slow things up before going off at some tangent to replace them.
      • let's see some benchmarks PROVING that sockets slow things up

        Could it be that you didn't RTFA [sourceforge.net]

      • I agree. I'm far from convinced that sockets have anything to do with X being slow. In any case, doesn't X have a shared memory option? The point is, let's see some benchmarks PROVING that sockets slow things up before going off at some tangent to replace them.

        You are looking at things ass-backwards. These guys have written an Xlib compatibility library for an existing GUI system, which happens to have some custom message passing layer underneath.

        It's not about speeding up about X, even if the editoriali
    • OK, repeat after me... X is NOT SLOW BECAUSE IT USES SOCKETS!!! Please understand this! When you are on a local machine it uses optimised sockets, which are the fastest way of streaming information between programs

      No doubt you can explain the flaw in their benchmarking process that gave them a factor of 2 speed over sockets. Sockets are not slow. When people have gone away, produced something faster, and have figures to back it up, though, they gain some bragging rights.

      Code counts. 'Nothing can possibly

      • Re:X using sockets.. (Score:2, Interesting)

        by walter. ( 138617 )
        No doubt you can explain the flaw in their benchmarking process that gave them a factor of 2 speed over sockets. Sockets are not slow. When people have gone away, produced something faster, and have figures to back it up, though, they gain some bragging rights.

        There are no details about the benchmark on their page. A typical error is that the data isn't actually accessed on the receiving side. This may sound harmless, but it actually turns the results upside down due to cache issues.

        • There are no details about the benchmark on their page. A typical error is that the data isn't actually accessed on the receiving side. This may sound harmless, but it actually turns the results upside down due to cache issues.

          Fair point. We don't have a lot to go on, and I would be very surprised if many of us have any experience of JourneyOs. I'm just surprised that folk got caught by Tim and his 'can this make Xfree86 faster?' troll; the article isn't about Linux or XFree86.
      • The 2x speed up was comparing to sockets and sysv message queues alone. It's possible, especially if you are avoiding syscalls and the sysv message queue implementation is particularly inept. But it depends on what the overall percentage of overhead is attributable to queueing vs. rendering. If queueing is only 4% of overhead, then a 2x improvement is only going to be a 2% performance improvement. Maybe if they really are writing to X pixel by pixel.

      • No doubt you can explain the flaw in their benchmarking process that gave them a factor of 2 speed over sockets.

        Factor this or that, but I think it's a clear flaw that he has compared a full-featured production kernel (linux 2.4.20) with his own minimal kernel. It's comparing apples to oranges, IMHO.
    • Yep. Taking a look at the HyperQueue page [sourceforge.net], it seems like this nonstandard IPC technique, using not much more than shared memory pages, only manages to run about 2.2 times faster than Unix Domain Sockets. That means they can transfer a gigabyte in 0.48 seconds rather than 1.1 seconds. Well, for a GUI, who cares? Who needs to double their transfer rate at the expense of portability, especially when I really doubt transfer rate is the bottleneck in X.
    • no, X11 isn't slow because it uses sockets, X11 is slow because it uses Xlib. The density of your protocol is irrelevant if it can't support the kinds of data you're trying to send. For example, look at the Xlib traffic needed to communicate a simple button click using your favorite widget set (and the context switches involved). Sockets or not, that shit is SLOW.
  • Its most likely vapor ware, every other day there is news about a new system to replace X, but none of them ever made it out of the tech preview stage at best, X really needs to be replaced for desktop/home based systems, for server/thin client based its OK, but its far too basic to truly support all GUI functions of windows/macos what I would like to see is something similar to how qnx works with X windows apps, ware it seems to load X in the background but displays the apps as if they are normal apps, I a
  • ...uses XML as the communications protocol... Could this get rid of the speed problems?

    So the problem now is too much speed? You need to introduce a bloated text format to slow down the framerate?

    I guess to answer the question, yes all speed problems are eliminated. The graphics are all uniformly slow.

  • try Quake3 over X- THEN tell me X sucks. (Score:5, Interesting)

    by SlightOverdose ( 689181 ) on Tuesday October 07, 2003 @05:54AM (#7151659)
    Yeah sure. in THEORY, the server-client overhead of X slows it down. I have, however, yet to notice it. Hell, I get a Higher framerate with Quake3 in Linux than in win32.

    To take the quake3 thing a bit further- one day I was setting up a quake3 server on a remote machine. However instead of running q3ded (the server), I ran quake3.x86 (the client) by mistake.

    Imagine my horror when the screen goes blank and I realise what I have done, and SURELY, this would fsck both boxes. Theres no way quake3 can X over a 100mbit network link (with the overhead of SSH thrown in). Or can it?

    A few seconds later up pops the menu. It ran fine. As a quick experiment, I loaded q3dm17. It worked, and I was getting a good 15fps- quite playable.

    Dont believe me? try it for yourself.

    I think that little demo alone is enough of a demonstration. X my have it's flaws- namely bloatedness, but it CERTAINLY doesn't seem slow to me.

  • Hold on cowboy! (Score:4, Informative)

    by palad1 ( 571416 ) on Tuesday October 07, 2003 @05:56AM (#7151663)
    Before everybody and their mothers starts flaming them because they use XML as their protocol, I would like to point out that they are using WBXML [w3.org] to send their messages.
    WBXML is a packed encoding for XML, thus saving space and all those that can be highly compressed. Just have a look at the specs, it's not because it has WAP tagged to it that it's a load of crap.
    And then, to those saying that the parser will kill the perfs, I'd like to point out that this protocol doesn't rely on string parsing but _byte_ parsing..

  • Uh oh.. (Score:3, Insightful)

    by joib ( 70841 ) on Tuesday October 07, 2003 @05:59AM (#7151674)

    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.

  • How about speeding up the GUI, like KDE? (Score:3, Insightful)

    by mrb000gus ( 696332 ) on Tuesday October 07, 2003 @06:09AM (#7151708)
    My biggest speed problem on X at the moment is the startup times etc of applications. KDE takes 20 seconds to start up and each application takes a couple of seconds to load. Could this be sped up by a faster X server? Or is the problem there more likely Qt, KDE libs, etc?

  • Wasn't there just a /. article on XML... (Score:3, Insightful)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Tuesday October 07, 2003 @06:13AM (#7151720)
    ...being one of the current software fashions? This would be a point in that case I guess.
    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.
  • They plan to use WBXML and not XML. Still you need parsing. But serialization can be left out AFAIR. That's a huge improvement over Ascii XML.
    But still it is an extensible format.

    And they are looking into ways to move to ASN.1 too. See the link in the article.

  • X is fast enough (Score:5, Insightful)

    by leoboiko ( 462141 ) <leoboiko@@@gmail...com> on Tuesday October 07, 2003 @06:25AM (#7151751) Homepage
    I used to run ratpoison [sourceforge.net]. As others have already pointed, X is actually very fast, the problem are the toolkits. It's nice to have alternatives, but IMHO toolkit optimization is much more urgent.

    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.
  • Forget about xlib compatibility for a moment. This is not just some software wrapper implementing xlib on top of some crackpot graphics interface (while this is tedious and time consuming work, it can be done by any programmer).

    This is someone fusing the microkernel and exokernel concepts, which is way more exciting than fusing some implementation stuff together. This is actually computer science research what this man is doing, not just code hacking. I wish the man all the best for his work, for new di

  • XML is not a protocol! (Score:2, Insightful)

    by asb ( 1909 )

    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.

  • Which speed problem? I've been working over ssh-tunneled remote X connections without even noticing.

    All these "X sucks, we're gonna make something better" projects bore me. We've had them at a rate of about 1 per year. So far, none of them have produced anything worth a 2nd look.

    Call back when you have a tech demo.
  • This is not the project you are looking for.

    Y: A Successor to the X Window System [ic.ac.uk] is.

    Now move along.

  • Why I am tired of this "let's replace X" s&%@. (Score:4, Insightful)

    by DrWhizBang ( 5333 ) on Tuesday October 07, 2003 @08:46AM (#7152559) Homepage Journal
    "X is slow"
    "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.

    • Re:Why I am tired of this "let's replace X" s& (Score:4, Interesting)

      by benjamindees ( 441808 ) on Tuesday October 07, 2003 @01:29PM (#7155274) Homepage
      Many functions run unaccelerated on cards that have all kinds of cool acceleration features... Are you aware that gtk pushes everything as a bitmap through the X protocol for each expose event?

      Thank You. No one knows that; or seems to care. I'm currently playing around with a P200 with an S3 Trio64 that gives better (single pixel) Xperf results with the VESA driver than with the (accelerated?) S3 driver. KDE seems to run faster with the unaccelerated driver, which is completely unexpected.

      XFree has little to no information on problems like this because they discourage discussion of performance to avoid playing favorites among video card manufacturers. There needs to be someplace that Joe User can go to get realistic advice on graphics performance in Linux, something besides the usual "buy an ATI/nVidia" spiel.

      I think it's a good thing that these type of articles get posted once a week because someone needs to start talking about this; it is a serious problem that most noobs think graphics performance on Linux sucks and everyone just tells them that it doesn't or that they should use something other than KDE/Gnome. It seems that graphics and, by extension, gaming are the only areas left to hinder Linux from widespread desktop adoption by the average Windows user.

Slashdot Top Deals

Trap full -- please empty.

Close