Interview with Berlin core developers

jregel writes "Linux.com has an interview with Stefan Steefeld and Graydon Hoare, two of the Berlin core developers. Interesting stuff that should dispel a few rumours and inaccuracies surrounding this project. "

Comments

Re:questions that should have been asked:

[Anonymous Coward]

Actually, it's even better than that. You do need a c++ compiler, but g++ has been ported everywhere. You need an ORB, but those are fairly easily ported. The really cool part is that OpenGL is _not_ needed -- the berlin drawing kit is high level, and it's fairly trivial to plug in a new backend to do the actual screen drawing. Perhaps the hardest part in some environments will be the rock-solid thread support that it needs, but that's becoming commonplace nowadays as well.

History: Things To Understand About Berlin.

[Christopher B. Brown]

• The Ancient Past

  In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.

  In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.

  Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.

  The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.

  I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...

• Berlin: The New Generation

  A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.

  I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.

  In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."

• My Take on Why They Haven't Progressed Quicker

  After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.

  I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:

  • They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.

    This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.

    This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.

    The high probability of failure completely discourages commercial investment of time/effort/money.

  • Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.

    The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.

    Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.

  • GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
  • GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.

    It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)

Good News Even If The Big Project Fails

• There may be components that are of value.

  For instance, they may wind up producing a font rendering engine that could be useful elsewhere.

• The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
• There may be some useful IDL definitions.
• Some of what appears valuable in Berlin is the recasting of Fresco ideas.

  It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)

Re:Berlin and X.

[Wiggins]

Are we ready to dismiss the whole thing though? There are plenty of things that X does well but there are also plenty of things it does poorly or aren't even planned on being supported. Don't know that much about the Berlin project but we shouldn't nip it in development if it proves to provide a new solution, and uniqueness. How many Load monitors are there written for X, lots...that is not to say that someone shouldn't write a new one to learn, or to add a feature that they cna't find in any other apps already on the market.....I can remember trying to get Enlightenment to run back when Imlib was like .10 and E itself was somewhere around .11.......but the end result has been impressive (even though I am running WM) :-)

Re:Berlin and X.

[kirk]

CORBA's smallest possible message is several times bigger than X11's smallest possible message.

The idea is that Berlin will send messages like "display dialog X with message Y" instead of doing all the low level drawing. I saw Gettys linux-kernel posting too and he seemed to gloss over that fact.

The great thing about Berlin is that you don't have to define one communication protocol like the X protocol. You can easily move the functionality between client and server in order to get the best latency/bandwidth ratio. Sure, there are X Extensions, but those aren't nearly as easy to add as new CORBA objects. And CORBA objects aren't only for graphics.

The way I see it, Berlin is just different enough that it is worth doing (the rewards could be great), yet based on enough standards that it shouldn't be too hard to get working. I'm exciting to see how it progresses.

Re:Berlin and X.

[orabidoo]

The main question is: is Berlin asynchronous enough? I've read talks by J. Gettys in linux-kernel (J. Gettys is one of the original designers of the X Window system), and he makes a very good point: that people who talk about replacing X haven't understood well enough what X's real problems are. One good thing about the X protocol is that it's fairly asynchronous: you send off your request but you don't wait for a reply to return from your library call, for most X calls. Still, a number of calls are synchronous, and they are one of X's biggest bottlenecks. CORBA is a much more general protocol than X11's, and with that comes overhead; CORBA's smallest possible message is several times bigger than X11's smallest possible message. I don't know if CORBA has async capabilities, but I'd be surprised if it had them to the level that X11 does (let alone more). All of this goes together to point to a protocol *less* suited to remote use than X11, rather than more.

From what I see, the Berlin people are planning to counter this by making the protocol higher level, including toolkit-level stuff (menus, buttons, any kind of low level widgets) in the server. This is probably a move in the right direction (at least, having the *option* to do that; there's always a case for supporitng plain X 'draw rectangle' functionality for things like themable apps), but I don't think it's nearly as important as streamlining the basic protocol.

In this interview, they also sounded ilke they didn't know what to say about embedded systems, which is very disturbing. Makes me think that they haven't really thought about making their system scalable on the lightweight end. This is IMO one of the bigger points that a new-generation GUI needs to address.

For the moment, my bet is on X11 for mainstream stuff, and NanoGUI for embedded use.

Re:GGI target of Mesa?

[Bloater]

LibGGI is a userspace library, fbcon is a kernel level text console that displays on a framebuffer from an fbdev driver. They have entirely different scope.

fbdev is a very basic graphics subsystem that is not very good ATM - James Simmons (who you can contact on the fbdev mailing list) is improving it to near the level of capability of KGI - then it still won't supercede KGI but will be a partner to KGI for the people who choose to use it.

Hopefully James will choose to merge vgacon in by simply making a vga-text16 fbdev driver which is treated specially so that X servers and DRI continue to work, while reducing the code needed to support all uses. This gives the simple vga text console that the die hards want, and allows everyone else to have their hardware handled properly for games. This has the benefits of being more maintainable, and stabler for the gamers.

This is getting offtopic now so I'll stop before it gets moderated down.

--

Re:Berlin and X.

[eldamitri]

First, the fact that the above post was moderated as flamebait (at least at the time of this posting) is ridiculous. The questions Zurk asks and the points [s]he raises seem reasonable enough.

As to the question "why not simply stick with X?", the berlin FAQ has this to say:

Why not just use X?

X-windows, although flexible, is very hard to write for, and not particularly easy to extend or maintain. Berlin is based on very easy APIs for low-level drawing, and should provide the ideal environment for easy, powerful extension. Furthermore, since the inter-component communication in Berlin is marshalled by a corba ORB, OO component technology will be with us from the beginning, enhancing the likelihood of code reuse and "glue-language" visual programming environments. Finally, by starting over again with hardware acceleration on every drawing function and modern programming techniques like multithreading and message queues, we hope to achieve a much faster, more advanced, and smaller implementation than X.

Note that I don't actually use or develop berlin. I just find the project interesting and would like to see reasonable discussions about it.

-Scott

"there once was a big guy named lou

Re:Berlin and X.

[eldamitri]

No one is changing any standard. The berlin people are working on a project they feel is useful and (probably) fun. More power to them. If it turns out to be a bust, it has done no one no harm. If it turns out to be awesome, revolutionary, and better than beer, so much the better. No one is forcing anyone to use berlin, so I can't see how people can complain about others developing it. Its not like MS forcing Internet Exploere onto Win98 users. In the end, the "market forces" of the linux community will determine if berlin will be a viable replacement for X or not. In the meantime, I intend to enjoy watching it develop.

-Scott
"there once was a big guy named lou

Re:questions that should have been asked:

[bergie]

what platforms does/will berlin support?

Actually, this was answered in the interview:

That's encouraging to hear. What environments do you expect Berlin to eventually be used?

Anything we can get to work with Berlin. Systems which are more similar to Linux will be easiest to port to but there were even voices from people thinking about porting it to Windows NT.

Since we are using high level libraries (standard C++, OpenGL, omniORB, POSIX), we are less concerned about low level differences; they should be absorbed by the libraries we depend on.

We'll certainly start with all the free OS'es around, from linux over FreeBSD to Hurd. Then let's see for the rest.

So judging from this it could be expected that they intend to make it as platform-independent as possible.

And I guess architecture indepence comes with that, too.

/Bergie

--

Berlin and X.

[Zurk]

The real problem I have with berlin is that it basically relies on a lot of high level semi-vaporware. For example has anyone seen all the technologies talked about (CORBA, OpenGL etc) actually working well together on any normal unix box ? I mean i have to install mesaGL if i want opengl on linux, install an accelerated X server (the soon-to-be-out-but-not-yet-ready Xfree 4), install something corba compatible (ORBit (?) - is it even alpha yet ?) etc etc. why not simply stick with X ? it seems to be good enough.

Re:Berlin and X.

[Terov]

What I often see, and this may be offtopic, is that new projects--not unlike Berlin, are attacked because the majority feels that status quo is just fine. The way I see it, status quo may be just fine, but when something better (at least in the perspective of a user or developer) comes along, there should be nothing hindering the switch.
"Third Standard," or in this case, "Second Standard," seem to be dirty words when something new comes along, but isn't looking for superior solutions beneficial to everyone eventually? Berlin is a perfect example of working on a better way, and isn't that what Linux is all about?


The greatest among us are those who have sacrificed their navels to the Potato God. -Terov