Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
X GUI

Berlin Packages Released For Debian 349

Posted by Hemos from the more-fun-with-graphical-displays dept.
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.
This discussion has been archived. No new comments can be posted.

Berlin Packages Released For Debian More

Berlin Packages Released For Debian

Comments Filter:
  • An often wanted feature of XFree86 has been support for true alpha transparency. The Free Software community has worked around this limitation in various ways from copying the background image into the X terminal to a very alpha translucent GTK+ theme. The Enlightenment (www.enlightenment.org) window manager has been able to achieve the translucent moving of windows. But real alpha transparency has yet to be added.

    Berlin has alpha transparency today. You can see this on Berlin's screenshots page (www.berlin-consortium.org/screenshots.shtml). Notice that everything can be seen behind a transparent window, not just the background image. Furthermore, Berlin's archicture allows for anything to be transparent, from a single widget to the entire desktop


    Well, that's reason enough to load debian on this spare machine and try it ... Yes, it's a sad, pathetic reason, but I've really got nothing better to do with my time, and I'd kinda like to see berlin in action ...

    On another note, the site seems to be responding slower now (/.'ing beginning to take effect?), so I cant seem to find information about support. Does berlin build on *BSD?
  • now that would rock

    there doesn't seem to be much movement on Berlin,

    I've kept my eye on it for a while,

    last news item was June 28th

    X must die :)

  • Interesting decisions they made (Score:3, Informative)

    by throx ( 42621 ) on Friday August 31, 2001 @04:57PM (#2240936) Homepage
    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.

    • Re:Interesting decisions they made (Score:1, Flamebait)

      by Anonymous Coward
      KDE dropped Corba because their implementation sucked. It abused C++ templates which autogenerate code up the wazoo, resulting in huge ass libraries that took up too much memory.
    • "KOM (based on Microsoft's COM)"


      Wheres my clue stick... ah here it is, SMACK SMACK. :-)


      Dcop is used for inter-process comms with in KDE and its not based on M$ COM.

    • Re:Interesting decisions they made (Score:2, Informative)

      by Anonymous Coward
      CORBA is NOT heavywieght. Or at least, it doens't have to be. It's about the same overhead of a virtual function call in C++, if done right.

      KDE were using CORBA, but found that it was too big and slow. But that was because they were using a big and slow ORB!

      D'OH!

      There's no reason that the 2D hardware can't be used to optimise the imaging subset of opengl, often neglected by driver writers, who focus on optimising opengl's 3d performance. OpenGL is a 2D/3D API, not just 2D.

      And anyway, truth to tell, only Matrox makes 2D hardware that's any good these days. NVidia 2D performance sucks suprisingly badly.

      • CORBA is NOT heavywieght. Or at least, it doens't have to be. It's about the same overhead of a virtual function call in C++, if done right.

        KDE were using CORBA, but found that it was too big and slow. But that was because they were using a big and slow ORB!


        The size of the ORB was not the problem, I believe the size of the resulting executables was. Mico is STL based, and I think the problem may have something to do with template bloat (the STL classes that ship with gcc compile to 50-100k *per instance*)

    • Uhh, OpenGL accelerates 2D operations as well. Just because it's used for mostly 3d stuff that doesn't mean its all it can do.
    • KOM is based on CORBA as you may see on this slide [kde.org], 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.

      • KOM is not what KDE uses. KDE dropped all CORBA-based stuff early on after the performance problems became evident. What KDE uses is DCOP, a lightweight inter-process messaging protocol of their own design. For fun, on your KDE desktop press Alt-F2 and run "kdcop." Then you can look at all the things you can do with DCOP. There are DCOP bindings for several languages (Python, Perl, Java, etc) and the "dcop" program allows calling DCOP functions from shell scripts, making almost all of KDE fully scriptable! Funny that almost no one uses this capability.

        Back on topic, OpenGL is NOT simply a 3D toolkit, it provides hardware-accelerated 2D functions as well, making it a perfect choice for Berlin.

      • Another thing you forgot. OpenML is quite heavily tied to OpenGL, so a server that uses OpenGL for display will have a leg up in integrating ML's functionality into the system.
    • Perhaps they should have used SOAP instead. Sending display data over XML would be something to see :-)

    • Re:Interesting decisions they made (Score:5, Informative)

      by Anonymous Coward on Friday August 31, 2001 @05:28PM (#2241067)
      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
      • Which bring those questions to mind:

        1. You mention in your FAQ that a developer can use a wrapper around QT and GTK+ - nice idea, but what about Motif stuff? wrapper around those also? same for TCL/TK, FLTK, and native xlib stuff? This will make everything VERY slow..

        2. As for drivers for the cards - your best chance would be to write somehow a convertor of X server driver to Berlin. Without this you'll need to sign NDA to all the graphics companies and start writing drivers from scratch - that is of course if you want to use the accelerated features. You can use always the VESA to give the basic stuff (unaccelerated) - what are your plans?
        • 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.
        • 1. You mention in your FAQ that a developer can use a wrapper around QT and GTK+ - nice idea, but what about Motif stuff? wrapper around those also? same for TCL/TK, FLTK, and native xlib stuff? This will make everything VERY slow..
          >>>>>>>>>>
          Sorry to break this to ya, but Qt, GTK+, etc are essentially just wrappers around X anyway. Its not fast the way it is NOW.

    • OpenGL for 2D Graphics (Score:3, Interesting)

      by Shelrem ( 34273 )
      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
    • 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.

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

    • In case Tobias wasn't clear enough: OpenGL is just an implmentation detail of the server nowadays. In the default implementation actually, there's no OpenGL at all anymore. (I think.) Use DirectX or PDF, if you want. The client (application) won't notice.
    • The 3Dwm project does not aim to create the "be-all-end-all" 3D user interface. There is little sense in arbitrarily choosing from a number of 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

      Perhaps you're referring to the 3Dwm project [3dwm.org]? Of course, what you're talking about above has little relevance if that is the case. From the 3Dwm introduction [3dwm.org]: "The 3Dwm project does not aim to create the 'be-all-end-all' 3D user interface ... To the contrary, the mission is to build a solid research platform with the necessary primitives to support just about any kind of user interface."

      The fine folks working on 3dwm are not claiming to have some great desktop. They are simply making the tools that will allow ambitious developers to write 3D interfaces. Not to mention the fact that they are squarely against the oddly angled 2D windows you are complaining about. Running current apps in a 3D environment is just a migration nicety. Apps that take full advantage of living in a 3D environment should (hopefully) provide read gains over 2D interfaces. Think Borders Books vs. one very very very long bookshelf.

      -Erik

  • Entire desktop?? (Score:5, Funny)

    by Bullschmidt ( 69408 ) on Friday August 31, 2001 @04:57PM (#2240940)
    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??

  • Berlin is a nice concept... (Score:3, Troll)

    by jd ( 1658 ) <imipak@ y a hoo.com> on Friday August 31, 2001 @04:57PM (#2240941) Homepage Journal
    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.

    • You obviously have never programmed in OpenGL, or you'd know that its 2d as well as 3d.

    • There's nothing out there for it! People are working on porting Gtk/Glib over.

      In their X vs Berlin page the say that one of the advantages is that all applications have the same "look & feel" because they use the same widget set.

      So, if to have applications in Berlin you have to port your widget set so applications that use that set can run on Berlin, what's the point of their point?

      I think that it will be extremely difficult for them to have as much applications as you have with Motif/GTK/Qt, even if the speed is good (has anyone really tested it?). The code base of other projects is big, and a lot of time has been spent on them, so it's not really going to be dumped that easily...

    • Re:Berlin is a nice concept... (Score:4, Insightful)

      by Doomdark ( 136619 ) on Friday August 31, 2001 @06:34PM (#2241329) Homepage Journal

      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.

      • CORBA itself is neither slow nor bloated. Baroque and annoying, yes, mostly due to the lack of ORBs that implement anything close to a friendly API that glosses over all the necessary bookkeeping (that bookkeeping is worse with DCOM but MS did a good job of making it transparent). What is slow and bloated and evil is IIOP. I sincerely hope Berlin is not planning on using IIOP for its client/server communication...
      • I've said it n+1 times, OpenGL has it's own accelerated primitives for 2D drawing, it isn't just slapping a texture that looks like a window on a polygon.
    • you've just blown a whole lot of clock-cycles on nothing
      >>>>>>>>>>
      A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.

      B) This is hardware accelerated, courtesy of OpenGL. Transparency, for example, is painful in 2D cards (since its done in software) but OpenGL cards are built to handle this. Trust me, if a run of the mill TNT-1 can handle Carmack's love creations, it'll have no trouble handling a simple (or complex) desktop.
      • A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.

        No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.

        EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire.
        • A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.

          No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.
          >>>>>>>>>
          However, many more apps have accelerated OpenGL drivers than XRender drivers.

          EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire
          >>>>>>>>>>
          Sorry to break this to ya, but XRender is the non-standard method. OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.
          • However, many more apps have accelerated OpenGL drivers than XRender drivers.

            OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.

            Again, flat difference of opinion. I disagrre with you. Xrender does things like text the way they were always done with a few improvements (ie, rgb becomes rgba).

  • Resolution Independence (Score:4, Insightful)

    by Salamander ( 33735 ) <jeff AT pl DOT atyp DOT us> on Friday August 31, 2001 @04:59PM (#2240947) Homepage Journal

    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.

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

      I'm sure you can make things whatever size you want be it in the form of a little slidder to change the size of everything or just lying and saying you have a monitor twice as big as it really is.

    • Re:Resolution Independence (Score:5, Interesting)

      by smack.addict ( 116174 ) on Friday August 31, 2001 @05:11PM (#2241002)

      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.


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


      That's just the point: you shouldn't have to switch to a higher resolution to shrink the dialog boxes. If you want the dialog boxes to be smaller, the GUI should give you an option to do this without increasing the screen resolution. Similar, you should be able to make text appear larger without dropping to 800x600.


      Think of how Windows lets you choose between 'Large fonts' and 'Small fonts', then pretend that they got it right so you don't have to reboot the computer whenever you switch, and you'll get the rough idea.

      • Yes, perhaps it should provide such an option. Does it? Should/does it apply globally, or can you set it differently per-application? Per-dialog? Is it as flexible as .Xresources, which lets you set things this way for emacs and that way for everything else? How would that relate to themes?

        It's all very well to talk about "should" but in the end it doesn't count for much if the default behavior is annoying.

    • Re:Resolution Independence (Score:5, Informative)

      by j7953 ( 457666 ) on Friday August 31, 2001 @05:28PM (#2241065)
      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.

      • You have misinterpreted what he wrote.

        1) My desktop doesnt hold too many fixed pixel width apps visible at 640x480. By switching to 1280x1024, it contains many more of those applications visible at any given time. Berlin would negate this by scaling applications back up to "6in across" instead of staying at "180pixels" ... this would be VERY annoying. Things *wouldnt* end up looking more detailed at a higher resolution. They would be scaled bigger, and still look big and chunky.

        2) He wasnt talking about zooming in by lowering his resolution back down (to 640x480). He was talking about in a paint application, and being able to zoom in/out of the image.

        His point is 100% completely valid, I have the same concerns. You just missed it is all.

        Thanks for playing though.

        CyberKnet
        • My desktop doesnt hold too many fixed pixel width apps visible at 640x480. By switching to 1280x1024, it contains many more of those applications visible at any given time.


          You're the one who missed it: Berlin doesn't work in either units of pixels or centimeters. It works in abstract length units which default to being centimeters. If the window manager is sanely designed, it will let you change the scale factor however you want. If you want a Netscape window that is scaled down to the size of a postage stamp with 3-pixel-tall fonts, just shrink it. Want another Netscape on the same screen to be normal size? No problem.

          This is unspeakably nice. Neither X nor Win32 handle scaling properly. (And don't say Windows does it right because you can choose font sizes. If you choose a good font size for a 1600x1200 display, it will warn you that nothing will work and that you are completely fucked.)

          Thanks for playing though.


          And here are some lovely parting gifts for you too. ;-)
        • Berlin would negate this by scaling applications back up to "6in across" instead of staying at "180pixels" ... this would be VERY annoying.


          No, it wouldn't. If you wanted everything to take up less screen space, you could just dial down the scaling. Moving away from explicit pixel-based graphics allows you to do that sort of thing.



          Things *wouldnt* end up looking more detailed at a higher resolution. They would be scaled bigger, and still look big and chunky.

          They would take up the same number of centimeters on the screen, so they would be no bigger or smaller than before. Since they are based on vectors instead of rasters, they wouldn't look jaggy; in fact they would look smoother than they did at lower resolution, since the pixels that make them up are smaller relative to the size of the objects.

        • No, you missed it. Look at your printer... if it has a resolution of 600dpi, and you change the setting to 300dpi in the driver, what happens? Everything is four times as large? Nope, things just appear in a worse quality. You also can't fit more text on a page by increasing the resolution to 1200dpi, if you want to fit more text on a page, you'll have to use a smaller font size. This shouldn't be any different for a screen.

          Berlin would negate this by scaling applications back up to "6in across" instead of staying at "180pixels"

          That's correct, but by changing the size setting (as I said, there would be two settings), you can just make the app smaller if you want. The nice thing is, you can even make it that small at 640x480 (it might not look that good, though). Imagine making a screenshot of your application, sizing it down in a picture editor, than putting it back on your desktop and continue to work.

    • Re:Resolution Independence (Score:4, Insightful)

      by hey! ( 33014 ) on Friday August 31, 2001 @05:36PM (#2241091) Homepage Journal
      In other words, Berlin takes the Mac approach of taking UI decisions away from app developers

      ...

      And giving it to the users.

      • Wrong. Themes can't be that detailed, to cover all the decisions the app developer makes. Even if they could, they'd be so incredibly large and complicated that nobody could create new ones. I know themes and skins are the height of fashion right now, but they're no substitute for UI flexibility.

        • Huh? How do themes relate to this? Themes are usually on the users end, so how do they relate to developers? I heard the word "flexibility." I don't like the word "flexibility." It usually means that some developer wants to mess with my desktop...
          • Huh? How do themes relate to this?

            They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it. They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.

            When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here? That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular. Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin? Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?

            • You aren't going to persuade be-fan no matter how flawed and miss-informed his ideas are. He's been spouting this nonsense for years and years now.

              You and I know that if we let people standardise on just one tool kit they will pick the most butt ugly, bug ridden piece of trash they can find [opengroup.org]. But that's the exact thing that be-fan would love.

              Quite frankly, I think Apple's user interface is overrated. Sure, it's not as bad as windows but if that's your measure of the quality of a user interface then just about everyone is Jakob Nielsen.

              Give developers freedom and don't use the ugly apps. It's not that complicated...

            • They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it.
              >>>>>>>>
              Entirely true. However, nobody said that themes were the only thing. There is configurability too. With the combination of the two, you get a good deal of power for the user. Also, nobody says that the toolkit must be the same in every case. Since Berlin is interfaced through Corba, it is entirely plausible that somebody would rip out the standard toolkit and implement a different one in its place. All app would still work, since the CORBA interface would remain unchanged.

              They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
              >>>>>>>
              Are you honestly deluded enough to believe that application developers can USE all that flexibility? If that was true, Linux would be full of incredible great desktop applications. Its not. The problem with your thinking is that you want to give all the power to the developers, assuming that they somehow know more than the users. Besides, if a particular interface really is RIGHT for a particular application, nothing prevents that developer from implementing it himself. As long as you can still do raw drawing and get raw access to the interface devices, you can make whatever type of interface you want. True, that makes it harder for a developer to make a custom interface, but that's probably a good thing. If the app really needs that interface, then they'll go the extra mile to implement it. If it really doesn't, there is no point in breaking the standardization, now is there?

              When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here?
              >>>>>>>>
              Its called society. Look outside the window. Conformity allows the world to run smoothly. I'm not saying that you should always conform, but you'd better have a good reason not to.

              That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular.
              >>>>>>>>>>
              BS. UNIX is EXTREMELY standardized. Take the whole text-stream paradigm. It allows all apps to work together, no matter what they do. You think UNIX's CLI would have achieved the same level of usefulness if every developer had decided to use a different "but, it fits my app better!" method of exchanging text data?

              Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin?
              >>>>>>>>
              Yes, as long as the grognards want them, they'll get ported. However, many people DON'T like transparent, oddly-shaped title bars. Many people LIKE coherence and conformity. With Berlin, the rest of us aren't forced to pay for your weird sense of asthetics.

              Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
              >>>>>>>>
              Yes, that's why Windows apps have NO personality and inefficient interfaces. 3D Studio, Fireworks, Dreamweaver, Poser, Truespace, and Bryce are really just figments of my imaginiation and don't really exist.

    • Who's choice? (was Re:Resolution Independence) (Score:5, Insightful)

      by glenebob ( 414078 ) on Friday August 31, 2001 @06:16PM (#2241251)
      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.

    • In other words, Berlin takes the Mac approach of taking UI decisions away from app developers.
      >>>>>>>>>
      Yea, and it gives the decision back to the user! I like the Blue Metal theme, but my Athena apps don't look like that! And the KDE Blue Metal theme is a little different and the buttons look wierd. I don't give a rat's ass what the developer thinks looks nice, I want it the way I want it!

      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.
      >>>>>
      Honestly, most developers aren't smart enough to be innovative. In a one-toolkit system, there is still room for innovation, since nothing prevents you from adding your own widgets. For example, TrueSpace and Bryce have pretty imaginative interfaces. True, it's more work to implement custom widgets, but that's a good thing. That way, people who really have good ideas can work a little harder to impelement them, while people who are just lazy (and would have created inconsistant rather than innovative interfaces otherwise) can just use the default. For desktop OSs, its probably good to dictate policy this way because people really don't want inconsistancy without really tangible benifets.

      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.
      >>>>>>>>
      Dude, its called a third generation graphics layer. Anything that uses virtual coordinates has this "problem." If you want to do it differently, just change the mapping (its very easy in OpenGL).

      OK, maybe that's overstating the case a bit.
      >>>>>>>
      What case ;)

      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).
      >>>>>>>>>
      If its in inches, its the same thing as using virtual coordinates. Pixels are an ancient relic that really need to be discarded. Font-sensitive GUI layout libraries all the way baby.

      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.
      >>>>>>>>>>
      And if an app really does have the need to change a default, they can do it, they just have to do a little more work. You really have to ask yourself, does my app really need to make something 3.1" when 3.0" is the default? If it does, then go ahead and override the defaults. If it doesn't, just go with the flow. In a system that doesn't impelment some policy, you have people using 3.5" and 3.52" 9cm, just because the developer liked it better, not because of any real merit. The mere fact that most people consider KDE and GNOME to be functionaly equal attests to the fact that (in that case) competition doesn't make things better, just different.
    • 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

    • Re:Resolution Independence (Score:5, Interesting)

      by marxmarv ( 30295 ) on Saturday September 01, 2001 @05:20AM (#2242493) Homepage
      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

  • Seems like when (if) Berlin is finally out there Aqua and Cocoa will look like some simplified Berlin-light. Berlin obviously will look even cooler than Aqua but support more programming languages, network support etc.

    But Aqua/Cocoa may well be successful because it is quite simple and uniform, always primarily focusing on usability, functionality and user experience. To be really successful Berlin must both be simple to use and configure, yet support powerful functions.

    Did anyone find what hardware is required to test it on an i386-debain machine?

  • sure... (Score:1, Funny)

    by Anonymous Coward
    In version 0.2 there will be a terminal application with 100% true transparency.

    it's there! trust us!

  • According to their FAQ, the project started out as a lightweight replacement for X. This makes sense: Windoze graphics run fast because they took out the abstraction layers, threw a lot of it into the kernel, and run it all right on top of the hardware (at the expense of flexibility and functionality, of course).

    So now that Berlin is a heavyweight replacement for X, with obviously different goals, what else is out there that's lightweight?

    I was thinking about this when trying to run SuSE 7.2/KDE on an old P133 laptop with 32MB of RAM. It'd be great to have a fully functioning modern Linux on this box, but it couldn't handle the graphics overhead (it ran, but way slow). If there were a graphics system that didn't tax the system any more than Windows' does, this poor machine might not be put out to router pasture or some other text-only use.

  • Sounds a lot like Apple's Quartz (Score:2, Informative)

    by Anonymous Coward
    Don't you think? (Quartz is the graphic engine in Mac OS X)

    I mean, resolution independance and the fact that it is not pixel based. It feels like it's using vectorial representation of the graphics to be displayed.

    Unicode support, that is a big plus and one of the few real advantages of Mac OS X. Integrating this is a good idea. Even if unicode has it's flaws, it's still better.

    And of course alpha blending... this is the first thing you really notice in Mac OS X's Quartz and it's one of the major features of Berlin.

    I must say, these are good features, and a number of other nice ones. It's good news that graphic engines similar to Mac OS X's are now (will be) available in open source!
  • <flamebait>First off, let me say that I am among those who believe that the XFree86 project has become bloated to the point of being grossly inefficient.</flamebait>

    That said, Berlin looks like a nice, promising idea, but the feeling I get from their web site and the screenshots I've seen is that this is still a fledgling project that is getting all excited about the wrong things. It seems to me that the developers are far more excited about 3d rotating windows and alpha channel transparencies than actually producing a functional, reliable graphical user interface. Much of that stuff is good and I know a lot of X users have been looking for features like these for a while, but if this project is to gather any momentum, they need to concentrate on more important issues like speed and stability. One thing I would like to see them do, for example is find a more efficient solution to X's complex network client/server layers which I believe are wonderful but have a significant speed cost. When that happens, I'll start thinking of trying it out on my PC.
  • Reading their Berlin vs. X paper certainly explains why such a project is worthwhile, despite the fact that X is plenty good at what it does. However, I was a little shocked to see that it is has been under development for 5 years, and they are only on version 0.2, with hardly any of the features that they tout implemented.

    Given this, it seems likely that a usable release is at least another ten years off, and then don't forget the five or ten years it's going to take for common applications to be ported over and kinks to be worked out.

    In other words, this truly is the "GUI of the future"...the very distant future.
  • I don't see why I should apt-get this if I can't use gnome or ximian gnome. Sure, maybe Berlin is an improvement over X in some areas. However, X can be used in practically any *DE. Berlin? I read of no support of their site.

  • I thought it was sort of interesting that many of the X vs Berlin features actually said X does this too. That doesn't make it very much of a "vs" argument.

    The key thing that many people seem to forget is that X has a nice extension mechanism. Everything Berlin is doing could be done as extensions to X. The alpha compositing is already being done via the RENDER extension. The Resize and Rotate extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted.

    The big advantage of extending X is that you don't throw the baby out with the bath water. All the old applications still work. Applications can decide which extensions to use when they are ready. This makes it easy to see what works and what doesn't and to let each application progress at it's own pace.

  • A few bits about Berlin (Score:5, Insightful)

    by ..... ( 133478 ) on Friday August 31, 2001 @05:52PM (#2241152)
    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.
  • Uhmm, forgive me for saying so, but every time we addressed CORBA in academia, it was addressed that CORBA was GREAT for rapid prototyping and LOWSY for finished products because of the overhead involved with it (sockets being more lightweight for similar purposes). Can anybody shed some light onto this? It would seem to me that for unix domain connections a unix socket or even an IP based socket would be much much more appropriate in a finished product. Does Berlin happen to be one of those "special cases," like the way NFS treats CORBA, that is somehow optimized?

    Also, it would seem to me that the way X handles itself would be suboptimal speed-wise for a single machine, making Berlin more suitable for the standard desktop, yet not for a client-server pair operating over a network, in which case X would excel.
  • "The Berlin website (which looks great, IMHO)"

    Are you kidding? I can't tell...I hope so, because these two things, as well as the incredibly poor navigation, fonts and colors, make this a horrid website. Almost as bad as this one.

    From the site:
    1.:>>"<!-- This document was created with Latte version 2.1 -->
    <!-- For information on Latte, see http://www.latte.org/ -->"

    2.:>"This is just a filler page for now; check out the links on the left.
    Last modified: Sat Apr 29 10:48:25 2000 UTC"

    pathetic...

  • Just make X(Free86) better, prettier and easier. (Score:3, Interesting)

    by thefogger ( 455551 ) on Friday August 31, 2001 @06:14PM (#2241244)
    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 :-)

  • Did this happen to anyone else? (Score:5, Insightful)

    by Skuld-Chan ( 302449 ) on Friday August 31, 2001 @07:18PM (#2241458)
    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.
  • ...so do they have a firewall included in the package?
  • Anyone know if they have fixed the problems with the FreeBSD compile? After a TON of hacking [10.0.1.90], I eventually gave up and decided to wait a bit. Now I've waited long enough that Linux 2.4 made me decide to switch from BSD to Linux, and so now maybe I can try Berlin after all...

  • What's wrong with competition?! (Score:5, Insightful)

    by defile ( 1059 ) on Friday August 31, 2001 @09:28PM (#2241842) Homepage Journal

    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.

  • Some ideas in Berlin look similar to NeWS, an old Sun windowing system based on a home-grown Sun implementation of PostScript. It failed because it was proprietary and trying to compete with X which was free, and its implementation was slow and crufty. But its design was very cool--it was more consistent than Display PostScript, which NeXT used.



    I wonder if the Berlin designers are familiar with NeWS and could make a further comparison.

    • Actually the original NeWS implementation was quite clean and fast (it was slower than X at that time due to things like outline fonts and dithered images which X did not even attempt at that time).

      The slow and crufty one which most people used was the "X11/NeWS" merge. This was a horrid mess where both the PostScript and X were implemented in paralell C code, and a low-lying renderer which was bloated with if's so that it could render pixel-accurate emulation of X11 and not break PostScript too badly (it still failed to fill any shape other than rectangles correctly). The attempts to make a NeWS toolkit were also seriously hurt by the need to have the windows reusable by X and the need to write all the horrors of an X window manager implementation in PostScript code. The PostScript interpreter was also slowed down quite a bit by peoples rabid insistance that it copy every single bug and misfeature of the Apple LaserWriter (too many people thought NeWS's only purpose was to preview documents before printing...)

      They should have emulated X11 atop PostScript, but it was already know that Sun was killing NeWS so they were forced to do it this way so X11 performance was not hurt at all.

      Of course the real reason it died was that Sun tried to sell it when there was an open-source (not free though, a tape and license cost $120, although that cost was trivial) alternative.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close