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.
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
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.
> 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.
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
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
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.
Using OpenGL as a central element was interesting, and potentially very useful, but how well can
you make use of it? If you've still got a 2D world, but a 3D algorithm generating it, you've just
blown a whole lot of clock-cycles on nothing. It doesn't even have a coolness factor. Now, if you
can rotate -into- the screen, -that- would be cool.
Last, but by no means least -- CORBA as the communications layer???? And I thought I could be
stupid, at times. CORBA is a wash-out, due to too many corporations wanting to have
proprietary extensions to make it usable. It would have been a great technology, but either you
use the standard and have a gazillion lines of code to work round the limitations, OR you
"enhance" the standard, making it impossible for other systems to talk with it.
Also, with CORBA, the overheads are VAST. X is bad enough, but CORBA is a nightmare. One of the
important considerations in a system like this is who will use it. If you're talking home users,
then you need a protocol with as close to zero overhead as possible, whilst still allowing as much
flexibility & dynamicism as possible. CORBA doesn't cut it, either way.
You have some valid points about acceptance, but I think your complaints about Corba and OpenGL are based on prejudice and FUD than facts. Did you actually read any article about Berlin before commenting? I understand that first impression might be "those are slow", but the story doesn't (have to) end there.
It has already been said by n+1 people here that not only can OpenGL easily do 2D too (degenerate case of 3D), but that it may actually be faster; not because it's inherently faster but because gfx card makers have lately concentrated on 3D acceleration, and many advanced features (from basic texture mapping to transparency) are only available via 3D rendering. Thus, it need not be slower to use OpenGL. It might be faster, but what is reasonably sure is it'll be fast enough (ie. not order of magnitude slower). Another thing that helps is that h/w acceleration is easier to use with higher-level rendering requests (that Berlin uses, see below).
As to Corba; whether implementation is in the order of virtual method call (in local app/server case) or 10 times slower is not as relevant as with X-windows because the atomic operations being sent are much higher-level (read: bigger) on Berlin. That's what is on their FAQ; you don't draw bits on screen, you more likely transform more complicated (vector) graphics objects. Much of the stuff can also be made on server-side, thanks to integrated toolkit, removing the need to use Corba at all for much of the stuff X-protocol would need to use messaging.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
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.
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.