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.
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.
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.
A journey of a thousand miles starts with a brutal anal raping at airport security
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.
Sorry Ben, I was making an analogy about slowness of X+Desktop vs Whatever+Berlin, and that if Berlin suffered wrappers for each GTK/QT/Motif/TCL/TK/FLTK it would be in the same situation as X is today with it's X wrappers. Er sorry, I meant "X extensions" ;)
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?