Slashdot Mirror


Berlin Packages Released For Debian

A reader writes: "Berlin ? testing packages for Debian are available from the Debian website and should soon be moved to unstable, according to their the Berlin consortium website." The Berlin website (which looks great, IMHO) has an excellent architecture FAQ - the Berlin vs. X is very well done.Update: 09/01 12:41 PM GMT by H : A number of people have e-mailed me about some....wonkiness...if you view the Berlin vs X page using Internet Explorer. I'd advise using something else.

23 of 349 comments (clear)

  1. Interesting decisions they made by throx · · Score: 3, Informative

    The biggest shock to me was the Berlin team decided to use CORBA. Despite several instances in the FAQ of people gasping in astonishment and wanting to know what possessed them to use this heavyweight logic in a display layer, they gloss over any performance issues and seem to shrug off any suggestions of overhead (by either saying the function calls themselves are "almost" native without mentioning the setup times, or comparing to other CORBA based systems). I'd be interested to see some comparisons in display speed between this and XF86 4.0 or Windows just to get an idea of their true overhead.

    If I recall correctly the KDE team were originally intending to use CORBA for all their communications but quickly dropped back to their own KOM (based on Microsoft's COM) for their local communication to improve speed and memory usage of the system. Surely Berlin has come up against at least some of the problems the KDE team did and I wonder what their defense for sticking out with CORBA is?

    Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".

    Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!! Wouldn't a far better way to go be to leave at least the current window square with the screen (and possibly tap into the 2D performance of your hardware) and at least have some methodical way to place other windows in 3D (if you must), while having severe restrictions on their ability to update...

    While very cute and all, I just don't see this becoming a successor to X, Windows or Mac user interfaces.

    --

    Fear: When you see B8 00 4C CD 21 and know what it means

    1. Re:Interesting decisions they made by Yokaze · · Score: 3, Informative

      KOM is based on CORBA as you may see on this slide, but probably thats why KDE is so slow :).

      Most current gfx-cards are more 3d-cards with a little 2D-engine as extra and none of them is slow in 2D.
      They can render several 10^6-triangles per second, a window has a astounding 2 triangles. So that won't be a problem.

      Furthermore it's a open and evolving standard which even supports rendering videos. (aviplay can use opengl to accelerate videodisplay)
      It's a well documented and powerful interface to the gfx-hardware with vendor-support and drivers..

      Transparency in 2D is nearly unsupported by hardware (at least I don't know of such things).

      The 3D desktop is surely not very useful, but you get it for free, and you don't have to use it.

      --
      "Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
    2. Re:Interesting decisions they made by Anonymous Coward · · Score: 5, Informative

      To the use of CORBA:
      We have hardly any communication between client and server: The client creates graphic objects inside the serverprocess. Those are used to redraw and can handle almost every event that happens (only those that change state in the client get send over the wire). You can manipulate the server not to test for the clients existance. Afterwards the GUI of a client stays around after killing the client itself. You can still move the window, rotate it, set the alpha channel, ...

      Running inside the same address space the CORBA-overhead basically is reduced to a virtual function call.I think we can handle that:-)

      Yes, the KDE example is so often flung at us: Yes, the way KDE used CORBA they are way better of with the KOM they invented. But they need way less functionality then we do.

      To graphics via openGL:
      you can render anything to openGL, you can although render the graphics to libArt (which dumps a raster to the screen) and is the default nowadays. A PostscriptDrawingKit is in the works too: That way you can print anything that can get displayed on the screen. The printout will of course use whichever resolution and colors your printer has to offer;-)

      Oh, Berlin _is_ slow right now. But not for the two reasons you give: We have not yet optimized anything and we have _NO_ hardware acceleration at all.

      About screen-aligned windows: In the berlin architecture it would be hard work to have only those:-) A window is just another graphic, you expect a line in a graphics program to be reotateable/zoomable/... so we have to support those operations. Nobody forces you to do it. We do it right now mostly to show off.

      Regards,
      Tobias Hunger

    3. Re:Interesting decisions they made by sigwinch · · Score: 3, Informative
      Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".


      The 3D stuff is used because it lets you do neat 2D stuff really fast, and not to make animated 3D windows fly around in space. To support games, the 3D hardware can scale and otherwise transform bitmaps to random locations and orientations on the screen. This is used, e.g., to apply a brick texture to the side of a building in a game. You can draw the application window into a 'texture' and let the video card draw it anywhere on the screen at any size. (With rotation and perspective, if you're *really* feeling silly.)

      You can also align the texture buffer on page boundaries, and map the window's "frame buffer" directly into the app's address space. This lets programs have near-direct access to the frame buffer without any danger of blowing away the system.

      --

      --
      Kuro5hin.org: where the good times never end. ;-)

    4. Re:Interesting decisions they made by smunt · · Score: 3, Informative

      1. Maybe, we might come up with a solution. And you can always run your program in a nested Xserver.

      2. Berlin does not include any drivers for graphic-card. Instead, it relies on other programs to do that. Currently everybody uses GGI because it has a working implementation working in a X-window. It also works on SDL, GLUT (OpenGL) and framebuffers. Support for other interfaces should be very easy to add.

  2. Entire desktop?? by Bullschmidt · · Score: 5, Funny

    Furthermore, Berlin's archicture allows for anything to be transparent, from a single widget to the entire desktop

    So.. if the entire desktop is transparent.. what do you see.. the inside of your monitor??

    --
    "Of all days, the day on which one has not laughed is the most surely the one wasted." -Sebastian Roch Nicol
  3. Berlin is a nice concept... by jd · · Score: 3, Troll
    But even if it works, and works well, it -still- has to overcome the nausiating, frustrating barrier of becoming accepted.


    There's nothing out there for it! People are working on porting Gtk/Glib over, but can they port enough of Gnome to be useful, and still offer any advantage over using X in the first place?


    Then, there's KDE. I know of no work on porting Qt or KDE over to Berlin, although that might actually be easier than Gtk, as I think Berlin is C++.


    As for the other window managers & environments (CDE, Motif, OpenLook, QVWM, WindowMaker, 3dwm, etc), you're going to irritate a lot of people if these don't get ported. And I'm not just talking a simple Berlin->X11 layer, either. Nobody is going to put up with the speed loss.


    Using OpenGL as a central element was interesting, and potentially very useful, but how well can you make use of it? If you've still got a 2D world, but a 3D algorithm generating it, you've just blown a whole lot of clock-cycles on nothing. It doesn't even have a coolness factor. Now, if you can rotate -into- the screen, -that- would be cool.


    Last, but by no means least -- CORBA as the communications layer???? And I thought I could be stupid, at times. CORBA is a wash-out, due to too many corporations wanting to have proprietary extensions to make it usable. It would have been a great technology, but either you use the standard and have a gazillion lines of code to work round the limitations, OR you "enhance" the standard, making it impossible for other systems to talk with it.


    Also, with CORBA, the overheads are VAST. X is bad enough, but CORBA is a nightmare. One of the important considerations in a system like this is who will use it. If you're talking home users, then you need a protocol with as close to zero overhead as possible, whilst still allowing as much flexibility & dynamicism as possible. CORBA doesn't cut it, either way.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:Berlin is a nice concept... by Doomdark · · Score: 4, Insightful

      Using OpenGL as a central element was interesting, and potentially very useful, but how well can
      you make use of it? If you've still got a 2D world, but a 3D algorithm generating it, you've just
      blown a whole lot of clock-cycles on nothing. It doesn't even have a coolness factor. Now, if you
      can rotate -into- the screen, -that- would be cool.

      Last, but by no means least -- CORBA as the communications layer???? And I thought I could be
      stupid, at times. CORBA is a wash-out, due to too many corporations wanting to have
      proprietary extensions to make it usable. It would have been a great technology, but either you
      use the standard and have a gazillion lines of code to work round the limitations, OR you
      "enhance" the standard, making it impossible for other systems to talk with it.

      Also, with CORBA, the overheads are VAST. X is bad enough, but CORBA is a nightmare. One of the
      important considerations in a system like this is who will use it. If you're talking home users,
      then you need a protocol with as close to zero overhead as possible, whilst still allowing as much
      flexibility & dynamicism as possible. CORBA doesn't cut it, either way.


      You have some valid points about acceptance, but I think your complaints about Corba and OpenGL are based on prejudice and FUD than facts. Did you actually read any article about Berlin before commenting? I understand that first impression might be "those are slow", but the story doesn't (have to) end there.


      It has already been said by n+1 people here that not only can OpenGL easily do 2D too (degenerate case of 3D), but that it may actually be faster; not because it's inherently faster but because gfx card makers have lately concentrated on 3D acceleration, and many advanced features (from basic texture mapping to transparency) are only available via 3D rendering. Thus, it need not be slower to use OpenGL. It might be faster, but what is reasonably sure is it'll be fast enough (ie. not order of magnitude slower). Another thing that helps is that h/w acceleration is easier to use with higher-level rendering requests (that Berlin uses, see below).


      As to Corba; whether implementation is in the order of virtual method call (in local app/server case) or 10 times slower is not as relevant as with X-windows because the atomic operations being sent are much higher-level (read: bigger) on Berlin. That's what is on their FAQ; you don't draw bits on screen, you more likely transform more complicated (vector) graphics objects. Much of the stuff can also be made on server-side, thanks to integrated toolkit, removing the need to use Corba at all for much of the stuff X-protocol would need to use messaging.

      --
      I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
  4. Resolution Independence by Salamander · · Score: 4, Insightful

    Some of the advantages touted for Berlin vs. X actually sound like disadvantages to me. Consider:

    One of the problems with the X Window System's flexibility was the accumulation of several inconsistant GUI toolkits...Berlin takes care of the user interface by itself without calling upon the use of GUI toolkits

    In other words, Berlin takes the Mac approach of taking UI decisions away from app developers. Themes, schmemes, that's not real choice. Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin. When you take decisions away from people you reduce flexibility, gaining the advantage of consistency at the expense of stifling creativity.

    Here's another example:

    the size of an object on a 15 inch screen is the same as its size on paper, which is the size of an object on the big viewscreen at NASA...users would be compelled to use the highest resolution/color depth possible for the visual quality rather than for the space on their desktop

    Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution. Maybe I want all those annoying little dialog boxes to shrink so I have more room for that big image window, which I can resize and zoom in/out just fine without your help, but now you've scaled them right back up so they're in the way again.

    OK, maybe that's overstating the case a bit. The point remains, though, that they have strong assumed that there's one "right way" to do things. Even Windows lets you specify lots of things in either pixels or inches (or centimeters, maybe - I don't remember). As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.

    I don't think Berlin's bad. I don't even think they've made bad decisions on the aspects I've mentioned. I just wouldn't go touting them as advantages vs. X when they might just as easily be considered neutral or negative.

    --
    Slashdot - News for Herds. Stuff that Splatters.
    1. Re:Resolution Independence by smack.addict · · Score: 5, Interesting

      Some of the advantages touted for Berlin vs. X actually sound like disadvantages to me.... In other words, Berlin takes the Mac approach of taking UI decisions away from app developers.


      There is a reason the Mac is considered a good user interface and all X Window UI's bad. Funny how that works.


      Seriously, though, if nothing else, a user experience must be consistent. All X Window UI's are nothing close to consistent. Windows is at least somewhat consistent. The Mac, of course, deals best with consistency.

    2. Re:Resolution Independence by j7953 · · Score: 5, Informative
      Maybe I want to free up screen real estate by switching to a higher resolution.

      No. You want to free up screen real estate by switching to a smaller appearance setting. You want to make things appear in more detail by switching to a higher resolution. That's two different settings instead of just one, so this actually gives you more flexibility. At least if the Berlin developers got that right, I haven't looked at how it actually works yet.

      Running a lower resolution to "zoom into your desktop" is like slowing down your processor to watch a movie in slow motion. The idea is just wrong. Time and performance are two different (but related) things, and so are size and resolution.

      --
      Sig (appended to the end of comments I post, 54 chars)
    3. Re:Resolution Independence by hey! · · Score: 4, Insightful

      In other words, Berlin takes the Mac approach of taking UI decisions away from app developers

      ...

      And giving it to the users.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    4. Re:Resolution Independence by extrasolar · · Score: 3, Insightful

      First, I am the one who wrote that document that somehow got linked on the front page of slashdot. I am not a Berlin developer and in fact the main Berlin developers had several problems with what I posted (which was a very long time ago) which they must have found good enough to link from their FAQ.

      Second, I don't see how anyone one is forcing you to do anything. At least I am not aware of any kind of license agreement forbidding you to resize your applications and dialogue boxes. The point of me saying that about resolution independence was to show where the Berlin desktop will probably be heading. For omnipotent being's sake, even PNG and CSS have absolute sizes in their specifications. So it makes sense for this to show up at the desktop level. How can a desktop make sense of a PNG image that is 5 cm across if it doesn't have any useful conversion from pixels to centimeters? And lets say you have two monitors showing the same PNG image but at different screen sizes and resolutions, should both images appear as the same size?

      Third, conceptually there is a difference between resizing (what you do when you resize a window and the window contents realign themselves to fit in the window) and scaling which can be used to get your extra screen real estate. By when you scale, you need to scale by a factor. That is, you need to scale by twice or one-third the original. But the problem here is what the original size is. Is it expressed in resolution dependent terms (pixels) or resolution independent terms (centimeters, inches)?

      Fourth, the consistant UI theme in the article is yet in a plan-to-do stage, I believe. While it seems to be the intention of the Berlin developers to have this in their design, the vehicle for this "taskets" which is like a meta-widget that allows the application to ask what from the user rather than how. An example is on the wiki (http://www2.berlin-consortium.org/wiki/html/Berli n/Taskets.htm). But from what I've seen, there isn't anything restricting the application developer.

      But the main point I want to get at is that changing the setting of a system always require more advanced users. I think the idea of a desktop being consistant and nice by default is a good idea. The more advanced user is free to screw it all up, if you like. :-)

      Best regards,
      Kevin Holmes

    5. Re:Resolution Independence by marxmarv · · Score: 5, Interesting
      In other words, Berlin takes the Mac approach of taking UI decisions away from app developers
      ... and putting it into the hands of users where they belong. The user is more important than the whims of some clueless artiste who happens to have the time and the energy to bang some segfaulting piece of code together with artsy-fartsy skins and inconsistent mouse controls. Get off your high horse, little boy.
      Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin.
      The beauty of Berlin is that UI innovations can be applied systemwide because the application developer is forced to pull his head out of their ass and think in terms of abstract actions and the UI developer is limited to thinking in terms of right-double-clicks. This is a superior way to do real UI innovation (as opposed to developer self-aggrandizement), as new paradigms can be explored globally with the flick of a switch, evaluated on how and where they work best and worst, tweaked to improvement, and again.

      An application demanding that a double-right-click behave in a particular fashion is only an innovation in the Microsoft sense of the term.

      As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.
      Berlin's message is this: application software micromanaging the user interface is a dead end, and rude too. Introducing a level of indirection gives the user control by plugging and unplugging toolkits to do things the app programmer never thought of. If the UI toolkit becomes scriptable, every well-formed Berlin client program becomes scriptable. If the UI toolkit supports blind users' I/O devices, every well-formed Berlin client supports blind users' I/O devices.

      If you want to innovate, then innovate a new toolkit. I suspect you're less interested in innovation than shoving your ideas down the users' throats.

      -jhp

      --
      /. -- the Free Republic of technology.
  5. Re:Wait a minute... by renoX · · Score: 4, Interesting

    > It's a combination windowing system with
    > toolkits for a consisten user interface?
    > ...and I thought X was bloated. No thanks, guys.

    The X server is quite lightweight, but the clients are not: think at the number of toolkit you use simultaneously: Qt, GTK+, Tk, Lesstiff..
    This is memory bloat!!

    Worse, those toolkit has usually some troubles working with the others: cut-copy-paste problems sometimes, poor look&feel integration etc..

    And think about communications between the client and the server:
    - with X you have LOTS of very low level communications between the client and the server (draw a rectangle here, etc..).
    Have you done XLib programming?
    If no, you'd be surprised to see how many events the X server send to the clients..
    - with Berlin, usually a client would use higher level primitives that the server which would manage: less bandwith usage, improved latency.

    X main's advantage is that it works now, but I feel that Berlin's design is cleaner IMHO.

  6. OpenGL for 2D Graphics by Shelrem · · Score: 3, Interesting

    You talk about the amazing (my word) performance of your 2D hardware and how using OpenGL will toss all that out the window.

    Well, I'm gonna let you on to a little secret that game programmers know all too well. Doing 2D graphics is usually faster if you use the 3D hardware to do it. Now, it does depend on what you're doing, but overall, putting sprites onto polygons and blitting the polygons to the screen is faster than drawing the sprites on the screen directly.

    I know these seems odd, but it's really just a fact of the video cards being great for 3D (or bad for 2D, if you want to look at it that way). There's just been so much of a push for 3D in cards, and not too many people have been asking for better 2D performance, so the current crop of video cards is kinda lop-sided.

    Microsoft even stopped developing new versions of DirectDraw. They say that if you want to make 2D applications, use Direct3D. This wasn't because DirectDraw was done, or because they want all new games to be 3D, but because 2D graphics API's are becoming insufficient.

    Unless i missed something, no one was talking about moving the windows around in 3D. It's strictly a performance thing.

    ben.c

  7. A few bits about Berlin by ..... · · Score: 5, Insightful
    All right, I am not a Berlin developer, but I have been interested in this project for quite a while, and I have read through most of the stuff on their website.

    I see a lot of things being thrown around, without any real understanding (although anyone from the Berlin project is welcome to smack me around). Here are some clarifications:

    1. OpenGL.
      Why use OpenGL? Well, according to the FAQ, it is because it is a stable API that already does a bunch of what they want. But that is missing the point -- Berlin is not OpneGL-only. OpenGL is one of the several available toolkits used by the server to render the app. In fact, the most advanced toolkit currently bundled with Berlin doesn't use OpenGL at all.
    2. Toolkits.
      People here are talking about QT, GTK, etc. The purpose of these toolkits is
      • to make X programming less painful. OK, in the future, there could be some sort of Xtoolkit->Berlin wrapper that would 'port' over applications with a recompile. But an important but unheralded aspect of Berlin is that it is designed to present a consistent programming interface that is not painful to work with.
      • to give consistent looknfeel to apps. Berlin would do this at the server level. Berlin uses a single consistent set of widgets (a 'toolkit') to render the entire screen. That is why they talk about universal theming -- it would be like in installing GTK and then having the ability to switch all your applications to use GTK on the fly. Want QT? Install QT. Flip a switch. Now all you apps render with QT.
      • to integrate with a desktop. Berlin doesn't deal with this, but it could be easily extended.
    3. Corba.
      Berlin uses corba. Yes. Corba can be slow. Yes. But the trick is to see how they are using corba. For local operation, the call to the orb can be highly optimized... Just a couple of pointer jumps. (This is not much different than with X, where it uses TCP/IP to communicate with internally, even on a standalone machine). For remote operation, the corba orb shouldn't be the bottleneck the network should. But using corba gives the option to redirect displays, just like X.
      The difference is that, whereas X sends thousands (or millions!) of directions over the wire saying 'Paint pixel(x,y) green', Berlin says something like 'Put a button a this point in the screen graph' (where the screen graph is part of the Berlin prgramming model). The server has enough smarts to draw and position the button itself. Hence, Berlin has the possibility of being faster than X, even with Corba, because it has to give fewer commands to the server .. sometimes many orders of magnitude fewer commands.
    Well, that is all I can think of for now. But I think Berlin is one of the coolest projects in a long while, and has the ability to transform Linux just like Aqua/Quartz did for BSD.
  8. Just make X(Free86) better, prettier and easier. by thefogger · · Score: 3, Interesting
    Note: I only have experience with XFree86, so when I say 'X' I really mean XFree86.

    I don't think there's a need for an replacement for X. It's great, and it works. But, most of the time I deal with X, I find it confusing, difficult to install and really hard to handle. First of all, it needs good setup tools. Correct me if I'm wrong, but I haven't found any good, complete ones for XFree86 4.1.0. There's xf86cfg but that didn't really work, uses the highest screen res it finds which makes it flicker and almost unreadable and is far from complete. It doesn't cover all features of X. There's XFsetup, but the readme said that it wasn't compatible with 4.1.0. There's of course xf86config but that's a joke in terms of usability. And the config generated by XFree86 -configure - a config file doesn't tell me what I have to do, it doesn't help me in any way.


    Setting up DRI must be easy. Like copy binary, tell which driver to load. But, I have to recompile stuff and get Glide3 for Voodoos. That's annoying.

    X needs better mouse support, I think it's just ridiculus that I have to edit config files just to get my mouse wheel working. And for the mouse pointers, where's color, alpha blending, shadows and whatso ever?


    My last point is that X has all this stuff for exporting a screen over a network included. Much of the (great) functionalty of X is not used on home computers because people usually don't need it. What about a cut down version of XFree86, streamlined, compact with a decent setup tool that uses NCurses? That would, in my opinion, be sufficent to eliminate the need for things like Berlin. I respect those peoples work but I think they shouldn't "re-invent the wheel", like they taught me in my OOP class :-)

    --


    Um... I didn't do it!
  9. Who's choice? (was Re:Resolution Independence) by glenebob · · Score: 5, Insightful
    In other words, Berlin takes the Mac approach of taking UI decisions away from app developers. Themes, schmemes, that's not real choice.

    It is real choice, just not so much on the part of the developer. This approach takes the choice away from the developer and hands it to the user (in the form of theming). The user gets consistency and choice - isn't that who is supposed to be controlling his/her own desktop?

    Personally, as a developer, I don't want the choice of look at feel. I want to choose an API and I want to design the data bindings to UI components, and a default layout for the UI. I want the user to worry about the rest; how the pretty widgets look, key bindings, even how the UI is layed out if he/she wishes to go that far. I don't want my apps to stand out as being visually different any more than needed. There is absolutely no logical reason for one button to look and behave differently from any other button.

  10. Did this happen to anyone else? by Skuld-Chan · · Score: 5, Insightful

    I clicked on "Berlin vs. X" faq where it proceded to open up 10 trillion browser windows. Wierd - luckily I was able to gain control of the system again.

    1. Re:Did this happen to anyone else? by jovlinger · · Score: 4, Insightful

      heh.
      slashdot links to browser forkbomb.

      cute.

      Me, I had to reboot; I was unable to get control before the windows had spawned to infinity, and beyond!

  11. DirectX 8's Direct2d is a special case of Direct3d by yerricde · · Score: 3, Interesting

    Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window.

    As Yokaze mentioned, a rectangular window is two triangles. Two. The fact that DirectX 8's 2D API is simply Direct3D 8 with orthographic projection shows that Microsoft has begun to understand this, as Shelrem mentioned. Besides, "OpenGL" != "3D"; OpenGL is just a Graphics Language with an Open specification.

    The only difference between rotation and scaling of textures in 2D and in 3D is that in 3D perspective projection, there's a divide by z every few pixels to fixup textures if the plane isn't parallel to the x axis. In 3D parallel projection (of which 2D is a special case), or in 3D perspective with the triangle's plane parallel to the x axis (reminiscent of Super NES Mode 7), it's just an affine transformation (two adds per pixel), that is, unless you count elliptical filtering.

    Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!!

    You'd be surprised what you can do with the middle mouse button mapped to toggle between the x-y and x-z plane, especially if you map the mouse's x-axis to theta and rotate the view. With the typical 90 degree field-of-view of most FPS game engines, you already have four desktops.

    --
    Will I retire or break 10K?
  12. What's wrong with competition?! by defile · · Score: 5, Insightful

    I'm suprised that so many people are not only unsupportive (which is sort of reasonable, if you don't care you don't care), but that they go as far as being outright hostile.

    These folks are trying to push the state of the art. You may think they're misguided, you may think they suck, but that doesn't invalidate what they're doing or who they are. They have their dreams and seem like they may just realize them. Who the fuck are any of you to insult them? At least they're trying something.

    If X is a better system, it will still be here in spite of Berlin. I don't see why anyone is so threatened. Berlin could be a smash success without ever displacing a single X installation.

    Also, competition is good

    I'll never understand how some people who scream about civil liberty, free speech, intellectual property issues, and the rejection of old-world dogma/family-values-crap can still be so closed minded about competing open source technologies that they consider a threat to established traditional technology.

    You'd think that the general Slashdot reading population would be more supportive of change.