Slashdot Mirror
Berlin 0.2.0 Released
starseeker writes: "The Berlin people have released version 0.2.0. Check out the new screenshots.Talk about your awesome graphics!" For a project that's had a lot of smoke over the years, it's pretty nice to see something tangible.
What if your monitor's fallen over? Seems like this would be a good way to get around the problem.
That said, I think it's time I changed my
Instead of a lame spin-n-disappear, how about "spin to get your attention"? Beats the pants off of "flashing title bar" or "tiny light in the corner of the window".
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Their Berlin vs X document makes a big thing of pixel independence, but I see this as a disadvantage. Present displays, and future ones for that matter, still have pixels that are big enough to see, and the difference between a 1 pixel line and a 2 pixel line is significant. As a result I'm not ready to go for pure non-pixel metrics yet, although I grant that they are increasingly useful.
I also worry a bit about the CPU/GPU overhead of all this stuff, although I grant that this is a pretty short term concern. Modern high-end graphics cards can do this stuff at the necessary speeds without problems, so its only 2-3 years until the bog-standard consumer PCs have this capability.
Paul.
You are lost in a twisty maze of little standards, all different.
Berlin is not API compatible with X.
If it was they wouldn't have been able to do some of the cool things they are doing.
What I hope though is that some stuff can still be ported to it quite easily. For example. I don't know too much about it, but since the GTK+ ppl make the (IMHO) brilliant decision of writing GTK+ for GDK and GLIB rather than making it depend on X, they may now be in a position of writing an alternate gdk library over the berlin APIs and suddenly gnome works on Berlin!
Okay, I have made it sound simpler than it is (not least because I don't really know how complicated it is) but hopefully it's possible.
wow. just imagine that. a CHOICE of windowing systems to run a choice of desktops on might be a reality in the near future.
I like choices.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Nice screen shots. The only problem is that beauty isn't really what Berlin aims to fix. The weaknesses in X are well known but I will list them here for those who are unaware.
1. Size. X 3.x eats up 16 megs of RAM If you run it on 8 MB ( I have ) you will notice a distinct crawl caused from swapping.
2. Speed. X is fast but not quite fast enough. On a low end Pentium Linux runs wrings around NT or 95 for most things. The GUI is only a little faster however. I won't be happy until the *nix GUI is 3X the speed of the Windows GUI on the same Hardware.
3. You can't resize the desktop without shutting down X. Yes I know you can switch resolution but the Virtual desktop size will remain the same. I.e. this is good for Zooming in on fine print or small pictures. Nothing much else. If you use Mac, Windows or OS/2 you know why someone would resize a whole desktop.
4. X is not stable. Sure most of us hardly ever get a GUI lockup or spontaneous X server termination. Too many of us have seen this though. I have never seen an E-Smith server go down without massive hardware failure. Same goes for Cobalt Cube. X doesn't approach the stability of Linux or Apache or SaMBa. Bad Applications can't take down the Kernel. It can take down the GUI however. I.e. Sometimes Alpha quality KDE from CVS dose this for me.
Everything else that people see as wrong with X can be fixed at a higher level. If these problems can be fixed without ditching X then by all means do so. If X must be replaced then so be it. Berlin will still run X apps. It won't matter if it doesn't.
--= Isn't it surprising how badly I spell ?
> does itself no favours by boasting about these promising but half-finished applications
I wouldn't describe it as boasting. More like informing interestied parties of a projects existence or progress. If they hadn't posted this info, how would I or others know a new release was available to test/debug/contribute to?
I can't speak for the Berlin developers, but I think you will find many development projects who will tell you that they are not thinking so much about the image of their project when they post this kind of information. They are thinking more of their devepopers/testers and potential users. They are releasing early and releasing often to encourage as much testing/fixing/contribution as possible. It's a system that works.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
The transparency and transforms on the windows are (mostly) a nice way to show off, but they are down there in the drawing kit so will be extremely useful for other purposes.
I'm quite sure CORBA does create a slight performance hit when making calls to the display server, but the architecture should more than compensate for this. X (to a first approximation) simply handles drawing stuff on the screen and sending events to the client application, whereas Berlin handles selection, scrolling, resizing etc. on the display server, so you make a couple of calls to open a dialogue, and the next thing you have to worry about is when the user has clicked on the Ok or cancel button.
Microsoft thinks, "Well the command line is not very useful to the average computer user, let us do away with it."
Unix programmers think, "Well I do not think rotating windows in 3d is useful, but let us keep this feature, someone else may have a use for it."
Keep this in mind... it is hard to find a use for something that does not exist!!!
--
May the source be with you!
--
May the source be with you!
Jason Zwolak
Think of Berlin as something that is rather useless right now, given current hardware constraints, but will become a very nice graphical interface once we have monitors with pixel spacing more comparable to paper.
Given a future world where such hardware exists, it's easy to see where current windowing systems (X and MS Windows in particular) are woefully inadequate. Anyone who has a high-end monitor and has set the resolution to something like 1600x1200 knows what I'm talking about. All the fonts are way too small. So then you go and change the default font size. *Then* you find out that there are a lot of application developers who never tested their applications with a larger font size.
Berlin will be a good basis for a future windowing system. It's time will come.
I'm a leaf on the wind. Watch how I soar.
Hyping this as ready would surely be a mistake, but I am not sure you quite "get it". SlashDot is not a marketing forum. I don't expect my manager to come up to me later today and say, "Hey we really need to start using Berlin, I was reading about how it is no longer vapor on slashdot".
There may be a growing number of non-programmers on slashdot, but many of us code (and code and code). Interesting product announcements draw the interest of programmers, which in turn increases the speed of development (slashdot/freshmeat you decide :-). In a sence you are correct to say this is similar to trying to raise IPO capital, projects are trying to raise intellectual capital of programmers (and testers/documenters/etc) who can make a contribution.
My name is not spam, it's patrick
Home Automation & Linux -- now I know I'm a geek
Not so much marketting as communication.
Of course, there is a lot of overlap between the two concepts - good communication can often be good marketing, and vice versa. Occasionally good marketting is bad communication - e.g. selling a bad product by lying about it, or even bad communication is good marketting - selling a product by failing to explain what it is.
Whatever the terminology though, open source software is foundationally dependent on lots of communication to link developers and projects. If a project does not have a web page and obtain links from the relevent forums, then projects can never get off the ground.
If open source were to take your advice it would cease to exist.
> they should expect to succeed or fail on the basis of pure luck ...
How about succeeding on a basis of technical merit or usefulness rather than a "proper marketing strategy"?
The people who (IMO) this announcement is aimed at probably couldn't care less about marketing strategies. They are interested in good products.
Additionally, you seem to have assumes a great deal about what people see as a successful project - not everyone thinks that success==commercial_success. If I write some software and nobody uses it because it has a "fucked marketing strategy" it hasn't neccesarily failed as long as myself and others involved in the project had fun writing it. For me and many many others, that is what open source development is about.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
The most interesting Berlin idea IMO is the change in the client-server protocol : in Berlin protocol, ASAIK, the presentation details (like repainting a window when exposed ) are in charge of the server. In X, they are in charge of the client ( though they are handled by the toolkit for standard widgets ).
This should greately reduce the communication flow between client and server, therefore making it possible to implement it over low-bandwith connections ( as is the Internet for most people ).
Also, this should also make possible for applications to be truly and easily toolkit-independent.
Ciao
----
FB
My personal take on a 3d desktop is such:
/..................\
/...-----------......\
/.....Close App........\
/........................\
/..........................\
The only advantage that you get from having a third dimension (to some extent, we have a z axis.. but not really) would be in adding more desktop space.
Imagine having just one desktop with DEPTH. You want that ETerm that you started up earlier? Reach down to 30% and pull it up. It zooms into view. All the 'icons' on your 'desktop' (which is just the lowest point of the desktop) are actually just windows that appear small from perspective.
You are up here.
/..................---.......\
===============================
Desktop \
Far App
(Sorry if this won't render on non-fixed width fonts)
Neat huh?
The only real problem with this is the clutter that occurs in the back ground. My solution to this is that windows in the background are shaded 30-50% darker.
Rami James
GUI Guy
ALST R&D Center, IL
--
rJames.org - illustration
This is strange: this seems to be the same crowd that not so long ago has been actively discussing just how much X sucks: it is ancient, does very poor job displaying fonts, curves, is all crufty, etc., etc., etc.
Now, here comes the news of a project [long in development and refered to a number of times in the previous discussion] making a new (though pre-pre-pre-alpha) release, boasting numerous new advances, done in the [so much adored] OS way. And what do we see? Sceptical "well, this is all so nice but it is nott even close to become a replacement for X" or "WTF do I need those rotating/tilted windows for?".
Folks, this is about developing new things! This is about a brave new world. There were so many people who were going ooh!... and aah!.. about Apple's Aqua -- Berlin can almost do the same sort of thing (correction may be able to do the same sort of thing in future)! Why on Earth does it produce so much scepticism?
--AP
I gave this some more thought. One of the main reasons that we, at this point at least, don't need programs like 3dWM is simply because all of the CONTENT is 2d.
Any applications that you run are built around the paradigm of a 'window' and content inside a 2 dimensional box. While this idea works well for flat screens and flat OS's, this does not apply in any way to a OS(or wm) with that added dimension.
How useful is it to compile a kernel in a window that is floating at some odd off angle in the middle of virual space? Not very helpful at all. Now, imagine a program that is built with the Z in mind: my example is a file manager that has it's branches in all directions. I am POSITIVE that it is more intuitive to a user to think to himself, "I know I put the file over there, in the back to the right," over the tree system that we have now.
There are some things (most things, IMO) that work well in 2d specifically because we are used to writing in 2d. Other things (organization and such) are more suited to oriented positions and such.
Rami James
GUI Developer
ALST R&D, IL
--
rJames.org - illustration
This really looks nice. I'm not sure how much berlin can be compared to apple's aqua but it looks like it has rather similar capabilities. For those who are wondering what to do with all this functionality: it makes it really easy to write graphical applications. Graphical applications generally display lots of 2D shapes which need to be manipulated in arbitrary ways. A GUI library like Berlin does all the difficult transformations for you. Since it's all integrated, it works fairly transparently too. I admit that rotated, translucent X-terms are not a particularly exciting example (I wouldn't want one on my desktop) but you have to realize that it is only an example of how easy it is to make such graphical objects (in any case, what would make a terminal window exciting?). Note that these transformations can also be applied to objects inside a window.
Having resolution independent graphics is a particular nice feature which can for instance be used to add high quality printing functionality to applications in a very straightforward way but also allows for zooming functionality etc.
Jilles
The basic difference between X and Berlin at this level is that the Berlin system stores representations of all graphical objects on the server, whereas X only stores windows. There are swings and roundabouts here, but one of the swings is that, as the parent message points out, that Berlin does repaints on the server. However, the downside of this is that the server's memory usage is dependant on the complexity of the display, and probably higher on average than that of an X server.
This does not have much impact on bandwidth use - all display changes still have to be sent by the client to the server, and these are more frequent by far than window-damage repaints. Oddly, remote UI graphics are not especially bandwidth hungry - both LBX and Citrix's ICA use roughly modemeseue amounts of bandwidth. It does, however, have a positive impact on latencies and Berlin, if done right, should be usable over much higher latency connections than X (like the internet).
Simon
Disclaimer: I work for Citrix, but am not speaking for my employer.
Sure, the effect is silly, but what it says about the software's architecture is not.
What this is meant to demonstrate is that the software design is highly orthagonal -- that you can make a list of objects going down the page and a list of operations going across, and if you checked out which operations apply to which objects, nearly all the cells would be checked.
Orthagonality is a desirable property for two reasons. First, it implies flexibility. One of the most frustrating things when using other peeople's designs is to find out you can't do x with y because the developer never thought anyone would need to. Secondly, it eases the learning curve. When you wonder "Can I do x with y?", the answers is likely to be yes and you are less likely to have to refer to the manual on a regular basis.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Berlin is not a replacement to GTK/Qt or to GNOME/KDE or to any of the window managers that run on top of any of the previous. It is a replacement for X, an attempt to redo what X did, only more intelligently, with a knowledge of the limitations of X and taking into account the developments of the computer industry and for that matter the new needs of the computer industry.
X is powerful but there are several areas where it cannot be revised and extended without breaking all the other applications which currently depend on X. Sooner or later you need to throw out the old software and do a clean start.
The real significant developments in Berlin are the fact that it uses CORBA for brokering the API, a well thought out approach to client/server distribution of resources over the network and the support of resolution independent graphics as well as other features of modern graphics hardware.
Why not use X? Because X was designed in a far more different era than the one we have now. It is better to have a system that is optimized for modern computing uses and has room for growth.
Why would anyone switch from X? As has been commented over on the Berlin site, one can create an XLib compatibility layer, and between that and ports of GTK and Qt, which are designed to be insulating layers between programs that use a GUI and the underlying graphics API, running existing software on Berlin shouldn't be that difficult. Modular software design in the Unix world has its overhead but there are advantages to it.
Unix needs to evolve with the times. Yes, there is power in continuity and well-hammered tools that have survived the test of time, but that should not be a barrier to progress. That includes things that are technically separate from Unix but closely associated with it, such as X. Apple keeps pushing the standard for graphics forward and OS X has raised the bar for graphics technology. The Berlin people have a moving target to hit.
People may wonder at the hype of a 0.2 release, but the fact is that Berlin is slowly starting to move from the 'interesting toy' level to something more along the lines of a serious prototype for a new windowing system. Hopefully it will start reaching the point where it attracts more developers interested in a cool windowing system.
The second step is the XLib and GTK/Qt porting support, at which point the number of applications that can run on Berlin shoots up dramatically.
The real goal is to get software driver support for Berlin on the order of support for XFree86. That is going to be a pain in the neck unless someone can figure out a brilliant way to get device drivers for X to be used by Berlin. Those systems with open source drivers will probably have drivers written by motivated developers.
I'd like to see a real competition for developer mindshare between Berlin and XFree86 on the order of GTK/Qt or GNOME/KDE. Competition can only benefit the consumer.
The transforms are not that useful when applied to windows, but the same transforms can be applied to any visual in the berlin system. For example, you could have a really spiffy nested list widget (think MacOS finder), and when you click on the button to expose another sub-level, the button rotates in a visually pleasing manner, instead of simply switching to another state.
I think this is a reasonable summary:
X and Berlin are the core graphical interface programs which allow graphics to be drawn on the screen, although that isn't even a sketch of the multitude of capabilities they offer. See their documentation for a detailed description.
Things like icewm, windowmaker, twm, enlightenment, qvwm, etc. are window managers, which provide basic functionality such as windows for applications, logout prompts, menus, etc. and run on top of something like X. (Right now, most run ONLY on top of X, but that may change.)
KDE and GNOME are desktop environments, not window managers. This means that they provide advanced hints for applications which allow for a common look and feel, and advanced interface features like the GNOME panels and menus and providing common functionality to programs that request it. KDE contains its own window manager, but GNOME requires a window manager in addition to itself to function properly.
Basically, X is the only viable alternative at the low level right now. In the case of window managers there are an enormous number of choices. Right now KDE and GNOME are the two major desktop environments.
Compatibility is largely a question of having the necessary libraries for KDE and GNOME applications. You can run KDE apps under GNOME, and vice versa, if your libraries are in place. At the window manager level there shouldn't be a problem - the applications are normally seperate from the window manager and work within its framework.
Hope that is of some help. Look around the internet for more complete listings - some good initial places to start are freshmeat.net and linuxberg.com
"I object to doing things that computers can do." -- Olin Shivers, lispers.org