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

People joining OSS projects

[Anonymous Coward]

I like the part where one guy say that when people join they expect work to be nicely wrapped up and presented to them. In OSS it doesn't work that way. The *developer* has to take the initiative to get stuck in and figure out how things work. This seems to be the #1 problem for most OSS projects. Suppose all you can do is write as much documentation as possible..

Yes, I agree. Berliners care to explain?

[Anonymous Coward]

Considering a standard CORBA request header is around 100 bytes and the name of each remote method call is embedded as ascii within the request itself - how can Berlin/CORBA possibly be faster than (the small, terse, binary) X remotely? I have my doubts. Please correct me - what piece of the puzzle am I missing?

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.

Re:Berlin and X.

[Patrik Nordebo]

Berlin uses OmniORB, which is well out of beta, so that is not a concern.
Berlin uses OpenGL as a 2D imaging layer (yes, OpenGL is useful for 2D, too), so you won't need hardware acceleration, though that would certainly be a good thing to have.
And yes, I have seen these working well on a Linux box, as well as Berlin itself (well, as well as you can expect from version 0.1.0).
To say Berlin relies on vaporware (or semi-vaporware) is simply nowhere near the truth.

Re:conservatism

[David Greene]

Experienced software engineers are conservative because they have experience. There are many examples of fixing things that ain't broke and ending up with something worse.

Things which may seem antiquated will always have a place because they were written for a specific purpose.

• C was written to be a fast, almost assembly-level language suitable for designing operating systems. A more dynamic language can't give you the same speed (C++ comes very close, even with virtual functions, and you can always code in a procedural style).
• Lynx was designed to be an ultra-fast web browser (there are any times I'd much rather use lynx on my dailup connection than Netscape!)
• CLI's were designed to be fast, highly-efficient interfaces to the machine. I can very efficiently get a sorted (by any criteria) list of all my program files containing the keyword "switch" using a CLI.

Now this is not to say new development shouldn't be encouraged. That attitude is somewhat shortsighted. I'm arguing that dismissing existing technologies as "out of date" is just as shortsighted. Companies still use COBOL, BASIC and FORTRAN!

--

Re:Scarcity of good programmers

[Craig]

> Good programmers are a scarce resource, and good programmers who'll work for the love of it are even scarcer. This is true but misleading, rather like the greenies' projections of running out of some natural resource by year X based on "current reserves." As free software becomes more popular and widespread, the number of good programmers fiddling with it grows. Never fast enough, true; but just compare the number of talented people hacking Linux and X and other things now with the number doing so just a decade ago. Also bear in mind that programmers will, by and large, "work for the love of it" only on projects that they love; very few programmers would, for example, immerse themselves in some corner of a driver they didn't like or find interesting, just for the sake of some abstract desire to "make Linux (or *BSD or X or ....) better." People who attack this or that project as a waste of time are showing a sort of control-freak mentality; the crucial point that they're forgetting is that the time being wasted (if any) belongs to the programmers who are putatively wasting it; it does not belong to some metaphysical hacker community, much less to any self-appointed arbiter of relative project goodness. Craig [airnet.net]

Early Berlin, anyone?

[Misagon]

I have been unable to find any documents about the early Berlin, which is very different from the current. Are there any documents published on any website anywhere? Please mail me the link or the docs if you have any. It would be interesting to read, at least in retrospect. Maybe there were some wacky good ideas in there.

Re:Berlin and X.

[Froggie]

Personally I see Berlin as a piece of bluesky development. It may work, or it may not, but even if it eventually doesn't succeed we should be prepared to learn lessons from it rather than brush it under the carpet. Annoyingly, that appears to be what people are doing already; "Why are people developing Berlin when they could be doing something productive?" / "It's not the way *I'd* do it..." / "Based on my limited understanding of what they're supposed to be achieving, it's got problems x, y and z".

People should let them write what they want to write and be prepared to learn from the results rather than pooh-poohing the idea out of hand.

I can see why people would want to stop NASA doing the same sort of bluesky work (though I don't agree with it), given that it's costly, but Berlin costs nothing; why on earth do people seem to want to knock it on the head?

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, [hex.net] 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, [gnustep.org] which, it seems to me, has a strategy more likely to succeed. [hex.net]

  • 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 [tu-harburg.de] 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) :-)

questions that should have been asked:

[kevin lyda]

what platforms does/will berlin support? if i write an app for berlin can a {solaris|hp/ux|sco|unixware|aix|*bsd|etc} box run it?

what architectures does/will berlin support under linux?

standard

[Per Wigren]

X has been standard on virtually *every* UNIX desktop.

So has CDE...

Scarcity of good programmers

[SimonK]

Good programmers are a scarce resource, and good programmers who'll work for the love of it are even scarcer. I think some of the conservatism is due to a desire not to see people "waste" their talents on "doomed" projects, when they could be working on yours.

Not that I think Berlin is doomed. I think it has the potential to be very interesting.

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 [linuxhacker.org] for embedded use.

Re:Berlin and X.

[Davorama]

I don't think most people will have much choice but to stick with X unless these guys get the encouragement they need to move this thing along. Right now, we can run how many chat clients, process managers, cpu meters with X? Just stick x, g, or k in front of your old favorite terminal app. I say more power to them, it can't hurt to have bchat, btop, and bterm too choose from as well.

Re:questions that should have been asked:

[Bloater]

The answer is in the interview.

Berlin is built on OpenGL (currently via the GGIMesa target of Mesa), using LibGGI to receive input. This gives an extremely flexible and fast (Yes, OpenGL is plenty fast if you're only using the 2D parts) UI system.

The component model uses CORBA, and the whole thing is written in standard C++. This all means that it will run on any system that has a good C++ compiler, a CORBA ORB (eg omniORB), and OpenGL libraries. You just need to write a bit of code to get input (which libGGI can be ported to provide).

This means when it is finished, it will run on just about any unix (and this is only their implementation - you could write your own to provide the interface they come up with), and many other OSs.

--

Re:Berlin and X.

[Bloater]

Also, when you do need low-level primitives, you can simply define a class that negotiates a connection with another one in the server and uses it's own protocol. Do this negotiation early and you've got a system that is guaranteed to have a possible latency that is *at*least* as low as X's in any given situation.

I am also concerned about how applicable it is to embedded uses - though the required core seems to be very small and fast - put a simple blitter object in the server and there's your embedded desktop. I don't think X can beat that, you have to put almost all X functionality in the server (If you don't, it's not X and you can't start comparing X to Berlin), which you don't have to do with Berlin. I'm not an expert on embedded systems though.

--

Re:Yes, I agree. Berliners care to explain?

[Bloater]

You can have more that one connection between computers you know. CORBA is an object model - it is excellent for organising and setting up and occasional operations using standard widgets in the server.

I would be suprised if a low-overhead, optionally compressed stream protocol for low-level drawing primitives *didn't* turn up soon. CORBA objects can negotiate the connection at startup and you get a low-overhead communication between points. This pretty much *guarantees* network performance better than X after only a little maturing time (except at startup which is only done once for each client :).

--

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.

[Compuser]

The irc logs for Berlin, show that they
discussed naming things with "b-" prefixes
and decided against that. They also wisely
decided not to name too many things after
cities (they got Berlin, Moscow, and others),
because noone would know what those things do.

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 [berlin-consortium.org] 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

conservatism

[jilles]

One thing that always strikes me as odd is that many experienced software engineers act very conservative towards new technologies and are hard to convince that a technology actually has some potential.
Examples:
- Each time the word Java is dropped on this site a herd of C fans jumps on it claiming that its slow and bla bla bla. They usually end saying that C is quite adequate and that we don't need all this OO shit in the first place.
- Each time browsers are discussed. An awkward program called Lynx shows up. This reflects the fact that some users don't like graphical environments.
- Each time X alternatives are discussed, people start worrying about standards.

People, X is ugly, Java like languages are the future and the command prompt has no future only a long past. (I'm being provocative now :-) )

Developments like above are called progress. I'm not saying all progress is good. But one should have an open mind towards progress. X has its limitations (see other recent threads, and yes I know its not a GUI). Berlin addresses some of these issues. No matter if Berlin is the right solution, these issues are real are not going away.

Conservatism slows down change both in politics and technology. This may be good if no change is needed but in my opinion that is rarely the case. As a techonlogy junky I like to see lots of change. I annoys the hell out of me that people are still bothering with C, discussing the beauty of X and proposing Lynx as a viable alternative for generation 5 browsers while it is so painfully obvious that all of these are relics of the past (which does not mean they won't be around much longer). Please move on.

Berlin is not a reimplementation of X - it is new!

[DragonHawk]

A lot of people have posted comments like:

(1) X works, why fix it?
(2) CORBA is slow, how can you use it?
(3) It is vaporware, ignore it.

In answer to number one: Berlin does not appear to be trying to "fix" X, or anything else. Berlin is trying a new approach to GUI implementation. Yes, they have looked at a number of existing designs, but with the attitude of looking for past mistakes and things to avoid, not "Well, ABC is broken, so we sure don't want to use that!"

In answer to number two: If Berlin was trying to wrap the X wire protocol in CORBA, you can bet it would be slow. But they are not trying to give us a new X Window System. They are trying something new.

One of the key differences is: X is basically concerned with drawing primatives (dot, line, circle, square, etc.). Berlin instead focuses on GUI concepts (window, button, list box, etc.). While X has to draw an entire dialog box pixel-by-pixel, Berlin can just say, "Give me a dialog box." [1] Thus, the slower speed of CORBA matters significantly less.

Incidentally, one of the benifits of the Berlin approach is that it uses less bandwidth. X, on the other hand, uses a lot more bandwidth. Thus, Berlin (or something like it) might be well suited to, e.g., cell phones. [2]

One person mentioned what Jim Gettys had said about Berlin in the past. I was lucky enough to be present when Mr. Gettys spoke at the GNHLUG [gnhlug.org] meeting in August. One of the other meeting-goers asked him about the Berlin project. He seemed fairly neutral on it, saying that X does many things wrong, and that new ideas are worth looking at. His main concern with the use of CORBA seemed to be W.R.T. latency, not raw throughput. In other words, you couldn't implement, e.g., Quake, using Berlin. But, as others have pointed out, there is no reason Berlin cannot incorporate a "high speed" link, negoiated with CORBA, but run outside of it. Indeed, there are already similar efforts with X, as plain X isn't fast enough for Quake, either.

In answer to number three: The Berlin people readily admit that they have a ways to go. Like any software project, it could fall apart and disappear. However, the key difference is vaporware claims to be ready Real Soon Now, and is often used to forstall competition. Berlin doesn't claim to be ready to sweep X away on its irresistable march to glory. [3]

Footnotes:
[1] This is over-simplified, but you get the idea.
[2] There are low-bandwidth X extensions that also aim to do this.
[3] Or, Berlin doesn't anymore. I have read that in the past, some Berlin people were rather more zealous. [4]
[4] But, in fairness, that was really an entirely different project.

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

--

Re:move to berlin

[xnixnix]

hahaha
some ppl are soooo programmable ..

Re:Berlin and X.

[Zurk]

yeah but do we really want to change the standard ? I mean X has been around longer than even I can remember. X has been standard on virtually *every* UNIX desktop..even PC's running doze support it. Berlin has no published open standards, is built on a lot of high level vapour, no published reference documentation endorsed by a reasonable group of companies...im not sure reference documentation even exists. UNIX has POSIX compliance. X as X/Open Group compliance. Berlin has pretty much nothing at this point of time...

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.

GGI target of Mesa?

[Craig Davison]

Why not use fbcon? I thought it superceded GGI.

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

Re:History: Things To Understand About Berlin.

[Steinar Bang]

The Berlin Architecture [berlin-consortium.org] is said to be based on
Fresco [tu-harburg.de]. If they have kept the Fresco Painter [tu-harburg.de] interface, Berlin would have a rendering model similar to PostScript, which should be interesting from a GNUStep point of view.