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.
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
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
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)
Some of the advantages touted for Berlin vs. X actually sound like disadvantages to me. Consider:
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:
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.
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!
We have not tried to build it on BSD recently.
Last year there was trouble with the threading
implementation of BSD (not sure which BSD was actually tried). I heared there were a lot of improvements in that area... it might be worth to try again. Please report any finding:-)
Tobias Hunger
> It's a combination windowing system with ...and I thought X was bloated. No thanks, guys.
> toolkits for a consisten user interface?
>
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.
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.
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
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.
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.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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:
- OpenGL.
- Toolkits.
- 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.
- Corba.
.. 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.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.
People here are talking about QT, GTK, etc. The purpose of these toolkits is
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
The interesting question is, just how easy would it really be to move Qt to Berlin? Berlin is designed around a model where all of the drawing and interaction code for widgets are hosted inside the display server. I haven't seen any talk of a Java VM like system for safely hosting downloadable code, so I'm not sure how well that actually works in practice, but it seems like there would be a whole lot more structural differences for a widget set written to use Berlin than just what rendering layer it's layered on top of.
Of course, I haven't done any Qt coding.. perhaps Qt is sufficiently abstract that such a very different underpinnings could be put in place. It doesn't at all seem like an easy or obvious conclusion to make, though.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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!
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.
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.
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?
If that's the kind of shit they'll pull (on their promotional site, even) to prove a point, their code won't find its way onto any of my machines. :)
:)
If they suddenly develop angst against an OS we could maybe end up with fun little anti-BSD or anti-*nix bombs? This doesn't really inspire my trust.
Yes, I'm pissed off.
Get off my virtual lawn, you damned virtual kids!
...so do they have a firewall included in the package?
+++ath0
Anyone know if they have fixed the problems with the FreeBSD compile? After a TON of hacking , 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...
The REAL sam_at_caveman_dot_org is user ID 13833.
WOW am I a MORON. I happily cut-and-pasted a nice intranet URL :). Here is the real page caloguing my efforts with Berlin and BSD: HERE.
The REAL sam_at_caveman_dot_org is user ID 13833.
About trying to build on FreeBSD, see my comment below .
The REAL sam_at_caveman_dot_org is user ID 13833.
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.
Cuz they are faster and cheaper and (until recently) had much better graphics HW. And much better standard sound cards. And an actual choice of speakers. And Sony monitors, gotta love those Sony monitors...
A deep unwavering belief is a sure sign you're missing something...
Just checked out some of the code examples, and it looks like DirectDraw! Finally, somebody recognizes how cool the DirectX API really is!
A deep unwavering belief is a sure sign you're missing something...
Your fix must have lasted for a whole moment. I honestly believe you made the effort, but the page is doing it again. I suggest you restrict access to your web site's html if the contributors are going to pull stunts like this.
Not that it means much, but you lost at least one desktop with this. You'll never be on mine.
Get off my virtual lawn, you damned virtual kids!
AMEN! Thanks for saying what too many people seem to either not recognize or apologize for. One of my other pet peeves (besides what you mentioned) is copying. OK, OK - perhaps I'm just some stupid "windoze luser" or what lunix people want to call me, but JUST because I highlight something doesn't mean I want to copy it to my clipboard, erasing what's currently there. I want to specifically TELL the computer when to copy something.
Case in point - copy a URL, then go to a browser window and highlight over the old URL to paste the new one in. OOOPS! You just copied the old URL to the clipboard. What do you need to do? Either "open a new location" or position your mouse and hold DELETE.
creation science book
Not really true. I want "File" to ALWAYS have the same minimum components every time no matter what app it is: open, close, new, etc. There is no valid reason to dick with this. As much as possible, interfaces SHOULD be consistent to MINIMIZE the learning curve.
I agree that some standards are good. However, your widget set has to build in customizability. Some users like the menus at the top of the screen (Mac), at the top of a window (Windows, OS/2), or at the bottom of a window (Newton). Apps should see "this function creates a Menu Bar Or Tool Bar" in the API and leave the physical appearance of the menu bar to the widget set's theme engine. Same with pop-up menus: some users like ring-shaped popups; others like rectangular ones. Some users like their large virtual desktop to be four screens wide with wraparound and one screen tall, while others prefer two screens by two screens with no wrapping.
The point is that the UI should present the application with a set of abstract widgets (menu, window, etc.) and leave their presentation up to the theme, a strategh which in theory would also allow for specialized themes that work with alternative input and output devices for those with disabilities. Does this remind you any of W3C's goals in separating presentation from structure by deprecating HTML's physical markup in favor of CSS?
Will I retire or break 10K?
Then fix the problem by addressing the issue directly, not waiting. Perhaps Wiki is not a good idea to represent a serious effort? Perhaps something over on Sourceforge, or even a static web page would better represent your effort.
/. or not.
/. covered your site -- but it would have happened sooner or later. Anticipate someone pissing in your Cheerios, that's the way life works. The trick is planning around it.
Your efforts in the development of a new windowing system may be groundbreaking -- good for you. X is rather stale. Unfortunately as you are learning right now breaking ground and having your development site totally open to the revision of passers-by may not be a good idea,
If the Internet has proven anything it has proven that if someone can be an ass and get away with it, chances are good they will be. This has happened since
Get off my virtual lawn, you damned virtual kids!
I wonder if the Berlin designers are familiar with NeWS and could make a further comparison.
It sounds a little bit from the other poster that perhaps KDE/Qt are going to do this as well.
The old X mechansim is actually equivalent to "drag&drop" but with the advantage that you can rearrange the windows in the middle of the drag. This makes the real problems with drag&drop become visible, this is what you are seeing. (it also points out the drag&drop is pretty powerful, seeing as X has survived for so long with only that, but that it is not sufficient for everything).
I do wish people would stop complaining that the mechanism sucks and then go on to complain that "X lacks drag&drop". I'm sorry, you are wrong, perhaps the mechanism sucks but that mechansim *IS* drag&drop!!!
Most UI experts. The couple of idiosyncrasies you mention are not in fact UI problems. As others have mentioned, they are probably not even problems at all. Nevertheless, I never claimed the Mac OS UI was perfect.
Not to mention that having only one mouse button severely limits the usefulness of the device.
Funny, I use Mac OS and I have two mouse buttons and they work just fine. And they do exactly what you would expect. Just because Apple sells machines with one mouse button does not mean that the OS is a one mouse button OS.
People who "consider" the Mac interface to be better don't really understand human dynamics.
You mean like usability engineers? What UI is better than the Mac UI from a usability perspective and what experts back up your opinion?