Slashdot Mirror
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. "
Since standards are made by consensus (as opposed to committees) and Berlin is still in early development, I think the obvious answer is 'no'. Nor do I think anyone is suggesting a work in progress replace proven code. Of course, three years from now, Berlin might well be worthy of the pain involved in switching standards. Actually, it is more likely that Berlin will be very friendly with the X Window standard and that pain of switching will be quite small so that even if Berlin is only slightly 'better', it will be simple for us to move to it.
This also brings up question #2 ... what's the status of Berlin? And, how is development progressing (the feeling I get is that development is slow or non-existent -- is that true?).
Givent that X is the reference point for most of us, I would be interested in hearing what the Berlin developers think the strengths and weaknesses of X are.
I thought that Berlin was started on the premise that X is bloated with gobs of features that nobody uses, and that the world needed a replacement that didn't have so much stuff. But, upon hearing their description of the architecture, with CORBA and C++ as the basis for their design, it sounds like Berlin could be much slower than the low-level protocols behind X.
[Berlin]...basically relies on a lot of high level semi-vaporware
They are aiming high. It's good for a project of this magnitude to have lofty goal. I don't think they would have much luck in recruiting developers if they wanted to make something a little better than X. So, they might have to throw away some work or
You say that X is good enough. It is good enough for right now, but what about 5 years from now? Berlin is a system for the future, not for the present.
OffiX was an interesting bit of code. Can we expect that Steffan will transfer his work over to Berlin?
One of the basic problems with X is that it's network intensive. Large sites are starting to move back to the 'run all apps on the server' model and have a ton of dumb clients. Anybody who has had to install product Y on every computer in the office know why this is useful. It's painful to do this with X because it takes up some much network bandwidth.
Windows currently has a way of doing this, thanks ot Citrix's WinFrame (the Windows Terminal Server is Citrix code that MS bought). Citrix is developing the same technology for Unix. Think about it: one beasty server + Linux + StarOffice + Citrix to server all your client PCs. The cost comes to hardware + one big check to Citrix. Definitely attractive. Citrix uses a proprietary protocol called ICA that is network efficient and allows file and sound transfer in addition to graphics. However, as I understand it, it doesn't transmit high-level events (button clicks and so on), just compressed screen images. Most of this info comes from talking to a Citrix guy I know.
As I understand Berlin, it will transmit high-level events over the network. So what you lose in your CORBA overhead you more than make up in the dramatically reduced amount of information [referencing to the Knuth article - this is what efficient optimisation is all about. Micro-optimisation is mostly worthless, it's major smart optimisations that save you heaps of time]
Now I have nothing against Citrix making tons of cash off their products. If it gets Unix into lots of offices, all the better. However I'd like an open source product to do the same thing. That OSS product seems to be Berlin, so I hope they do well.
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
For one, startup negotiation is one of CORBA's weakest areas - without the use of clumsy IORs, orbs of different vendors are unable to talk to each other. OMG is still arguing/hammering out the specifications of the Interoperable Naming Service some 8 or more years after the supposed "standard" was introduced - what a joke. They have yet to decide on a well known port for their naming service yet! Every ORB vendor has come up with their proprietary name to object resolving mechanism: orbixd, osagent, etc. And another point, CORBA's IIOP communication does not get more efficient after the connection negotiation. What you said does not make any sense at all. Are you suggesting after you connect you arbitrate some sort of proprietary asynchronous TCP socket based protocol a la X? Please explain.
I'm sorry but pronouncing the death of the command line is kinda like hanging a "Village Idiot" sign around your neck.
Whatsamatter? Don't like those cumbersome letters? Never learned the alphabet? Do you own any books without pictures in them?
The command line is just a natural extension of human language which has evolved over thousands of years to be highly efficient.
Or we could just point at what we want and go "ugh, ugh"...
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..
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?
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.
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.
Things which may seem antiquated will always have a place because they were written for a specific purpose.
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!
--
> 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
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.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
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?
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...
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."
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:
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.
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.
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
For instance, they may wind up producing a font rendering engine that could be useful elsewhere.
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...)
If you're not part of the solution, you're part of the precipitate.
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) :-)
Funny and I thought Perl == Paid employment recently located
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?
US Citizen living abroad? Register to vote!
So has CDE...
My other account has a 3-digit UID.
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.
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.
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.
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.
Davo -- Free speech, free software, AND free beer.
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.
--
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.
--
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.
As to the question "why not simply stick with X?", the berlin FAQ has this to say:
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
-Scott
"there once was a big guy named lou
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.
Jilles
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 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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
hahaha ..
some ppl are soooo programmable
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...
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.
Why not use fbcon? I thought it superceded GGI.
Hands in my pocket