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.
An often wanted feature of XFree86 has been support for true alpha transparency. The Free Software community has worked around this limitation in various ways from copying the background image into the X terminal to a very alpha translucent GTK+ theme. The Enlightenment (www.enlightenment.org) window manager has been able to achieve the translucent moving of windows. But real alpha transparency has yet to be added.
... Yes, it's a sad, pathetic reason, but I've really got nothing better to do with my time, and I'd kinda like to see berlin in action ...
Berlin has alpha transparency today. You can see this on Berlin's screenshots page (www.berlin-consortium.org/screenshots.shtml). Notice that everything can be seen behind a transparent window, not just the background image. Furthermore, Berlin's archicture allows for anything to be transparent, from a single widget to the entire desktop
Well, that's reason enough to load debian on this spare machine and try it
On another note, the site seems to be responding slower now (/.'ing beginning to take effect?), so I cant seem to find information about support. Does berlin build on *BSD?
Mooniacs for iOS and Android
now that would rock
:)
there doesn't seem to be much movement on Berlin,
I've kept my eye on it for a while,
last news item was June 28th
X must die
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The biggest shock to me was the Berlin team decided to use CORBA. Despite several instances in the FAQ of people gasping in astonishment and wanting to know what possessed them to use this heavyweight logic in a display layer, they gloss over any performance issues and seem to shrug off any suggestions of overhead (by either saying the function calls themselves are "almost" native without mentioning the setup times, or comparing to other CORBA based systems). I'd be interested to see some comparisons in display speed between this and XF86 4.0 or Windows just to get an idea of their true overhead.
If I recall correctly the KDE team were originally intending to use CORBA for all their communications but quickly dropped back to their own KOM (based on Microsoft's COM) for their local communication to improve speed and memory usage of the system. Surely Berlin has come up against at least some of the problems the KDE team did and I wonder what their defense for sticking out with CORBA is?
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".
Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!! Wouldn't a far better way to go be to leave at least the current window square with the screen (and possibly tap into the 2D performance of your hardware) and at least have some methodical way to place other windows in 3D (if you must), while having severe restrictions on their ability to update...
While very cute and all, I just don't see this becoming a successor to X, Windows or Mac user interfaces.
Fear: When you see B8 00 4C CD 21 and know what it means
Furthermore, Berlin's archicture allows for anything to be transparent, from a single widget to the entire desktop
So.. if the entire desktop is transparent.. what do you see.. the inside of your monitor??
"Of all days, the day on which one has not laughed is the most surely the one wasted." -Sebastian Roch Nicol
There's nothing out there for it! People are working on porting Gtk/Glib over, but can they port enough of Gnome to be useful, and still offer any advantage over using X in the first place?
Then, there's KDE. I know of no work on porting Qt or KDE over to Berlin, although that might actually be easier than Gtk, as I think Berlin is C++.
As for the other window managers & environments (CDE, Motif, OpenLook, QVWM, WindowMaker, 3dwm, etc), you're going to irritate a lot of people if these don't get ported. And I'm not just talking a simple Berlin->X11 layer, either. Nobody is going to put up with the speed loss.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Seems like when (if) Berlin is finally out there Aqua and Cocoa will look like some simplified Berlin-light. Berlin obviously will look even cooler than Aqua but support more programming languages, network support etc.
But Aqua/Cocoa may well be successful because it is quite simple and uniform, always primarily focusing on usability, functionality and user experience. To be really successful Berlin must both be simple to use and configure, yet support powerful functions.
Did anyone find what hardware is required to test it on an i386-debain machine?
it's there! trust us!
According to their FAQ, the project started out as a lightweight replacement for X. This makes sense: Windoze graphics run fast because they took out the abstraction layers, threw a lot of it into the kernel, and run it all right on top of the hardware (at the expense of flexibility and functionality, of course).
So now that Berlin is a heavyweight replacement for X, with obviously different goals, what else is out there that's lightweight?
I was thinking about this when trying to run SuSE 7.2/KDE on an old P133 laptop with 32MB of RAM. It'd be great to have a fully functioning modern Linux on this box, but it couldn't handle the graphics overhead (it ran, but way slow). If there were a graphics system that didn't tax the system any more than Windows' does, this poor machine might not be put out to router pasture or some other text-only use.
gnome is ported to it. =)
Uhh, OpenGL accelerates 2D operations as well. Just because it's used for mostly 3d stuff that doesn't mean its all it can do.
Don't you think? (Quartz is the graphic engine in Mac OS X)
I mean, resolution independance and the fact that it is not pixel based. It feels like it's using vectorial representation of the graphics to be displayed.
Unicode support, that is a big plus and one of the few real advantages of Mac OS X. Integrating this is a good idea. Even if unicode has it's flaws, it's still better.
And of course alpha blending... this is the first thing you really notice in Mac OS X's Quartz and it's one of the major features of Berlin.
I must say, these are good features, and a number of other nice ones. It's good news that graphic engines similar to Mac OS X's are now (will be) available in open source!
Try Mac OS X. It has transparency everywhere, and is an awesome OS. Bah, who needs the hassles of linux--and why the hell do people buy wintel boxes anyway???
First off, let me say that I am among those who believe that the XFree86 project has become bloated to the point of being grossly inefficient.
That said, Berlin looks like a nice, promising idea, but the feeling I get from their web site and the screenshots I've seen is that this is still a fledgling project that is getting all excited about the wrong things. It seems to me that the developers are far more excited about 3d rotating windows and alpha channel transparencies than actually producing a functional, reliable graphical user interface. Much of that stuff is good and I know a lot of X users have been looking for features like these for a while, but if this project is to gather any momentum, they need to concentrate on more important issues like speed and stability. One thing I would like to see them do, for example is find a more efficient solution to X's complex network client/server layers which I believe are wonderful but have a significant speed cost. When that happens, I'll start thinking of trying it out on my PC.
Am I a hipster-doofus?
> It's a combination windowing system with ...and I thought X was bloated. No thanks, guys.
> toolkits for a consisten user interface?
>
The X server is quite lightweight, but the clients are not: think at the number of toolkit you use simultaneously: Qt, GTK+, Tk, Lesstiff..
This is memory bloat!!
Worse, those toolkit has usually some troubles working with the others: cut-copy-paste problems sometimes, poor look&feel integration etc..
And think about communications between the client and the server:
- with X you have LOTS of very low level communications between the client and the server (draw a rectangle here, etc..).
Have you done XLib programming?
If no, you'd be surprised to see how many events the X server send to the clients..
- with Berlin, usually a client would use higher level primitives that the server which would manage: less bandwith usage, improved latency.
X main's advantage is that it works now, but I feel that Berlin's design is cleaner IMHO.
They mention a beos whitepaper on this. If this could be done then it would be great. In my experience the two most popular reasons people have given me for not liking linux are; 1. the interface seems slow, and 2. it is too hard to install new software. If we could get our interface as snappy as beos' it would be a big help. It all comes down to good first impressions and if it is "wow this gui is so reponsive" instead of the present "why is so slow when I do things like drag windows" half of the sale is made there.
Reading their Berlin vs. X paper certainly explains why such a project is worthwhile, despite the fact that X is plenty good at what it does. However, I was a little shocked to see that it is has been under development for 5 years, and they are only on version 0.2, with hardly any of the features that they tout implemented.
Given this, it seems likely that a usable release is at least another ten years off, and then don't forget the five or ten years it's going to take for common applications to be ported over and kinks to be worked out.
In other words, this truly is the "GUI of the future"...the very distant future.
You talk about the amazing (my word) performance of your 2D hardware and how using OpenGL will toss all that out the window.
Well, I'm gonna let you on to a little secret that game programmers know all too well. Doing 2D graphics is usually faster if you use the 3D hardware to do it. Now, it does depend on what you're doing, but overall, putting sprites onto polygons and blitting the polygons to the screen is faster than drawing the sprites on the screen directly.
I know these seems odd, but it's really just a fact of the video cards being great for 3D (or bad for 2D, if you want to look at it that way). There's just been so much of a push for 3D in cards, and not too many people have been asking for better 2D performance, so the current crop of video cards is kinda lop-sided.
Microsoft even stopped developing new versions of DirectDraw. They say that if you want to make 2D applications, use Direct3D. This wasn't because DirectDraw was done, or because they want all new games to be 3D, but because 2D graphics API's are becoming insufficient.
Unless i missed something, no one was talking about moving the windows around in 3D. It's strictly a performance thing.
ben.c
I don't see why I should apt-get this if I can't use gnome or ximian gnome. Sure, maybe Berlin is an improvement over X in some areas. However, X can be used in practically any *DE. Berlin? I read of no support of their site.
"There ought to be limits to freedom"
Most programs don't wire to the X metal; toolkits do this and porting a single toolkit immediately goes a long way to porting a desktop environment over to a new windowing system. There's already some /dev/fb versions of GTK+ being developed, and Qt is particularly well suited to window independence; look at QT/Embedded. Any bets on how quickly we'll see Konqui running under Berlin? ;) (Although I'd like to see the reaction and ensuing bloodshed when someone tells the KDE developers the whole thing's implemented on top of CORBA =) )
...i am waiting for woody. how long must i wait! =(
I thought it was sort of interesting that many of the X vs Berlin features actually said X does this too. That doesn't make it very much of a "vs" argument.
The key thing that many people seem to forget is that X has a nice extension mechanism. Everything Berlin is doing could be done as extensions to X. The alpha compositing is already being done via the RENDER extension. The Resize and Rotate extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted.
The big advantage of extending X is that you don't throw the baby out with the bath water. All the old applications still work. Applications can decide which extensions to use when they are ready. This makes it easy to see what works and what doesn't and to let each application progress at it's own pace.
Back on topic, OpenGL is NOT simply a 3D toolkit, it provides hardware-accelerated 2D functions as well, making it a perfect choice for Berlin.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Well, the only reason that I load X is to use Netscape or Mozilla. And since I have 512MB RAM, I hardly think that I'm in a position to worry over saving a handful of megabytes.
Maybe this was a good idea back when Berlin was started, but nowadays... I dunno. 256MB of RAM is cheaper than a meal at a cheap restaurant.
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
i have not been able to connect to or ping kuro5hin all day. anyone know anything about it or should i expect to see it in tommorows slashdot?
(i would try and save my karma by posting anonymously but then i would have no way of tracking this post)
Uhmm, forgive me for saying so, but every time we addressed CORBA in academia, it was addressed that CORBA was GREAT for rapid prototyping and LOWSY for finished products because of the overhead involved with it (sockets being more lightweight for similar purposes). Can anybody shed some light onto this? It would seem to me that for unix domain connections a unix socket or even an IP based socket would be much much more appropriate in a finished product. Does Berlin happen to be one of those "special cases," like the way NFS treats CORBA, that is somehow optimized?
Also, it would seem to me that the way X handles itself would be suboptimal speed-wise for a single machine, making Berlin more suitable for the standard desktop, yet not for a client-server pair operating over a network, in which case X would excel.
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".
Actually, there is one reason why you would want to have something like this: You could have hardware accelerated windowed graphics.
Traditionally you can expect to get some form of hardware acceleration or another in a graphic applications if you run them in full-screen mode (the details are complicated, and I wont bore anyone... but it essentially has to do with your applications *sometimes* being able to write directly to the screen buffer on your videocard in full-screen mode). This is pretty consistant across most OSes (Win32, Linux, etc.).
However, when you run them in windowed mode, all of a sudden your application has to deal with swapping information into and out of video memory (it no longer has exclusive rights). (This has been discussed quite fervently lately on the SDL dev mailing list).
In other words, you can have an application (not 3D, just 2D graphics mind you) go from great FPS in fullscreen mode to horrible FPS in windowed mode.
The advantage to having EVERYTHING running through OpenGL is you can then have hardware acceleration inside individual windows.
Okay, so that's an answer to the question "Why?".... but that isn't a very good reason in and of itself....
Beyond some multimedia applications and games, this really wouldn't give many benefits to the average application....
Holy shit, where do you eat?! Get to McD's like the rest of us!
--jon
Cleanstick.org: Dumb weblog about nothing
"The Berlin website (which looks great, IMHO)"
Are you kidding? I can't tell...I hope so, because these two things, as well as the incredibly poor navigation, fonts and colors, make this a horrid website. Almost as bad as this one.
From the site:
1.:>>"<!-- This document was created with Latte version 2.1 -->
<!-- For information on Latte, see http://www.latte.org/ -->"
2.:>"This is just a filler page for now; check out the links on the left.
Last modified: Sat Apr 29 10:48:25 2000 UTC"
pathetic...
I don't think there's a need for an replacement for X. It's great, and it works. But, most of the time I deal with X, I find it confusing, difficult to install and really hard to handle. First of all, it needs good setup tools. Correct me if I'm wrong, but I haven't found any good, complete ones for XFree86 4.1.0. There's xf86cfg but that didn't really work, uses the highest screen res it finds which makes it flicker and almost unreadable and is far from complete. It doesn't cover all features of X. There's XFsetup, but the readme said that it wasn't compatible with 4.1.0. There's of course xf86config but that's a joke in terms of usability. And the config generated by XFree86 -configure - a config file doesn't tell me what I have to do, it doesn't help me in any way.
Setting up DRI must be easy. Like copy binary, tell which driver to load. But, I have to recompile stuff and get Glide3 for Voodoos. That's annoying.
X needs better mouse support, I think it's just ridiculus that I have to edit config files just to get my mouse wheel working. And for the mouse pointers, where's color, alpha blending, shadows and whatso ever?
My last point is that X has all this stuff for exporting a screen over a network included. Much of the (great) functionalty of X is not used on home computers because people usually don't need it. What about a cut down version of XFree86, streamlined, compact with a decent setup tool that uses NCurses? That would, in my opinion, be sufficent to eliminate the need for things like Berlin. I respect those peoples work but I think they shouldn't "re-invent the wheel", like they taught me in my OOP class :-)
Um... I didn't do it!
Come on already-linux needs this badly. I'm not saying there should be a deadline but I would like to see more progress from time to time. And why aren't the other big linux backers behind this? If this was the standard UI for linux you'd see a lot of killer applications that you couldn't do on Windows
---
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.
Especially interesting would be KDE.
What about binary-only apps like StarOffice 5.2 or games?
What I read from the Berlin-website, it's a pretty heavy paradigm-shift, although the ideas behind it seem very reasonable, some kind of backwards-compatibility is necessary. Otherwise it won't get any wide acceptance, I fear.
QT and GTK can already work without X (frame-buffer) . So it may be worth trying to port them to the Berlin architecture too.
Berlin is an excellent framework. But an excellent framework is totally useless without any application.
If QT and GTK were ported, there would be a lot of applications already ready for it. Basically, all Gnome and KDE apps could run on it, and X-Window could be dropped.
{{.sig}}
I'd like to see sound support embedded in the protocol and server. If you want to write a Berlin display server and be in full complience with the standard, you must support the sound protocol.
Sound logically belongs with the display server (whether its handled by the same process or a different one is irrelevent to me), just like input handling belongs with the display server.
This would also allow the display server to generate sounds if it wants to. For example if you can disable a window, the server could emit a beep or ding or something when you click on it, rather than sending those clicks over the network and letting the client side generate the sounds.
This should become part of the X protocol as well. Want to play a sound in your app?
XSoundPlayFile(mydisplay, "mysoundfile.wav"); or whatever.
All mixing can then be handled in the server, so that multiple clients can be playing sounds at the same time and they all get mixed and played.
This also becomes part of the theming engine - define a bunch of sounds for different common events (error, warning, etc.), configurable in the theme system, then apps do:
XSoundPlayStdSound(mydisplay, "SOUND_ERROR");
What that sounds like (if anything) is up to the user on a global basis.
There is a reason the Mac is considered a good user interface and all X Window UI's bad.
Considered by whom?
I hate the Mac interface - it's extremely inconsistent (You drag a document to the trash to delete it, but dragging a disk doesn't format it? - or clicking the 'close' button on some program closes them, but clicking the 'close' button on others (like a web browser) just minimizes it?)
Not to mention that having only one mouse button severely limits the usefulness of the device.
People who "consider" the Mac interface to be better don't really understand human dynamics.
hell, if they just get a consistent windowing system that doesn't have screwed up focus I'll be impressed. In X when a dialog pops up, where's the focus? Does it default to "okay" or "cancel"... generally, there isn't any focus at all. It's always sort of puzzled me how UNIX hackers can prefer VI and Emacs as text editors, yet end up with a windowing system / desktop which always requires the mouse. I hate to admit this but one of the things I really like about M$ Windows is that I can easily interact with almost every aspect of windows through the keyboard. Take for instance, a simple "ok" dialog. This is something pretty fundamental, and focus should be given to the only button on the widget. I should be able to press the enter key, or the space bar (preferably both) to dismiss it. Can I in X? As far as I've ever seen, no - and certainly not with any consistency. Unfortunately this is something which I don't think Gnome or KDE can really do on their own, it has to come at the base level with X, and as it hasn't been fixed in how many years, I doubt it ever will. In my opinion if Berlin can do this much, they've already got a big selling point (so to speak) with me.
Like python wayyyyy too much. There has got to be something wrong with them if you ask me. I mean why use such an obcure piece o shit language?
Please name this mythically fast C++ CORBA ORB. It does not exist.
Everyone claims CORBA is fast fast fast - but in practical experience I've found it to be rather slow and hard to maintain through several interface generations. There is no good way to extend a CORBA API for a product once deployed. And yeah, that interface inheritance scheme crap - it's good on paper - but see how your code looks like after 4 iterations - completely unmaintainable crap.
X11 uses the X shared memory extension locally for speed - tell us another untruth.
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.
Over a network performance would really bite for Berlin/CORBA as compared to X11. Since Berlin uses blocking ('two-way' in CORBAspeak) calls which each taking about 1 millisecond on 100BaseT ethernet. As such, you can have a maximum of 1000 CORBA calls per second. The latency of the network alone kills you. The X11 protocol does not suffer from this problem because it is completely asynchronous and bi-directional and it does not have to wait for one command to complete before the next one starts. Therefore you can have several thousands of graphic events per second using X11, as compared to a maximum of 1000 CORBA Berlin two-way calls per second. It's in Revelations, people!
Fix that flicker with xvidtune.
But for what it's worth I would not consider Berlin as any serious competition to X as long as they include hostile code in one of their pages that tries to crash a visitor's browser.
n /BerlinVsX.htm. I think that's the point.
The following link attempts to crash Internet Explorer. http://www2.berlin-consortium.org/wiki/html/Berli
Infantile pranks are not the hallmark of a serious project.
Get off my virtual lawn, you damned virtual kids!
I assume there will be techniques for an app to bypass CORBA mechanisms when needed.
Accelerated X-servers also bypass a lot of code to speed things up, especially when displaying movies or playing games. When they are run over a network thing get slow again.
I think Berlin is going to use this kind of tricks too. Bypass slow code when you don't need it.
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window.
As Yokaze mentioned, a rectangular window is two triangles. Two. The fact that DirectX 8's 2D API is simply Direct3D 8 with orthographic projection shows that Microsoft has begun to understand this, as Shelrem mentioned. Besides, "OpenGL" != "3D"; OpenGL is just a Graphics Language with an Open specification.
The only difference between rotation and scaling of textures in 2D and in 3D is that in 3D perspective projection, there's a divide by z every few pixels to fixup textures if the plane isn't parallel to the x axis. In 3D parallel projection (of which 2D is a special case), or in 3D perspective with the triangle's plane parallel to the x axis (reminiscent of Super NES Mode 7), it's just an affine transformation (two adds per pixel), that is, unless you count elliptical filtering.
Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!!
You'd be surprised what you can do with the middle mouse button mapped to toggle between the x-y and x-z plane, especially if you map the mouse's x-axis to theta and rotate the view. With the typical 90 degree field-of-view of most FPS game engines, you already have four desktops.
Will I retire or break 10K?
X11 does allow for more commands per second, but Berlin's commands are "bigger". You don't need to send every fucking mouse event over the wire; only "interesting" mouse events will be sent. You don't need to send repaints or shit like that over the wire. There is a lot of intelligence on the server, so very few actions need to ask the client for help, and those that do are very broad and generic, and so likely wouldn't use up as much bandwidth (as if that's a problem anyway).
Dammit... not only did it open like 200 copies of the same thing, it made them like 50,000 by 300 (width by height) big. On my 1024x768 screen, I kept trying to pull the window over to try and close it (of course, I could have hit the control menu then close, but I'm lazy). Thank god for Alt-F4.
:-(
Interesting though, how Win2k's task manager wouldn't kill any of the IE windows. That's yet another problem here in Windows-ville.
I wish I could have read the Berlin vs. X faq. Berlin looks promising. But it'll take a while to get accepted. And in this community, getting acceptance is hard enough.
...so do they have a firewall included in the package?
+++ath0
I just wish it would come along faster. Berlin promises to be the first really modern graphics server/interface on linux/unix. X is nice for a lot of reasons but it sure would be nice to switch to a finished Berlin.
I've checked on the site from time-to-time for a couple years (it IS moving slow) but it really shows promise. I would LOVE for 1 cm or 1 inch on the screen to really mean 1 cm or 1 inch, period. Screw pixels. Make it match what gets printed by a berlin-aware app (modified gimp?) and you really have something. True-sized graphics editing onscreen. Measure with a ruler and it means what it means on the screen and when you print it.
The true alpha transparency is also really cool. Just don't trash my kde theme. The basic Berlin look right now is very motif-ish (yech!). I like my qt-ish look and friggin' HATE motif/lestif. They do indicate true theming on the way, however, so there is hope.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
I seem to recall a screenshot of twm with a bunch of xterms and xman being transparent. Kind of funny to see transparency being used as such an "advantage" over X since it obviously has that capability somehow.
:P
Personally, though I thought it was neat that it could be done, looking at that screenshot let me know in no uncertain terms that I would be unable to be productive in an environment like that. Sure it looks neat, but I prefer the window I am working in to be what I see...I don't want the mess that is behind the window frustrating my eyes.
jik-
PS. Why does an article for Berlin have the X Window icon?? Are they the same thing now? If Berlin can't even get their own slashdot icon then they must be really low key
Anyone know if they have fixed the problems with the FreeBSD compile? After a TON of hacking , I eventually gave up and decided to wait a bit. Now I've waited long enough that Linux 2.4 made me decide to switch from BSD to Linux, and so now maybe I can try Berlin after all...
The REAL sam_at_caveman_dot_org is user ID 13833.
As the main Berlin webmaster, I want to apologize for that javascript infinite-window-spawning thing that some people apparently encountered. Hemos actually linked to a page in the Berlin Wiki, and the entire point of a Wiki is that anyone can change the text of a page. (For the philosophy behind this, I'd suggest going to the WikiWeb page in our Wiki, and continuing from there. I'd rather not get into a big discussion of Wiki's in general -- ours works rather well, with occasional glaring exceptions which we try to fix...) Certainly no-one officially associated with the project put that there -- apparently someone thought it would be cute to abuse the collaborative nature of the Wiki. Sigh.
If someone can suggest a regexp or two to catch javascript to webmaster at berlin-consortium.org, I'll have the Wiki reject page edits that add javascript to a page.
Again, my apologies that some people ran into this -- the offending code is gone for the moment, and I'll be turning off javascript as soon as I can.
WOW am I a MORON. I happily cut-and-pasted a nice intranet URL :). Here is the real page caloguing my efforts with Berlin and BSD: HERE.
The REAL sam_at_caveman_dot_org is user ID 13833.
Anti-aliasing has a lot to do with alpha transparency. For example, the grey bluring at the edge of a letter is to do with the the background colour being white. Between a black letter and white background depends on transparency of that portion of vector and being able to see the background colour underneath. (don't call me up on the white/black, it's only an example of alpha)
You'll notice that MacOSX has shadows on the windows. This, as a UI element, has been shown to be an excellent guide for eye focus (to the top most window). Shadows are alpha. I'm not sure about transparent dialog boxes - I just find those annoying.
Imagine an interface that, instead of a dialog box popping up to gain your attention, it began glowing red. Annoying, isn't it? All due to alpha transparency.
Check out directfb, which seems to be similar to Berlin, but also seems to progress at a faster pace. It too features alpha transparancy, and can run apps such as Gimp:
http://www.directfb.orgOf all the comments I've ever posted, this is definately one of them
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.
RedHat's Xconfigurator works flawlessly on all the supported hardware I've tried. It does hardware detection and it even sets up the mouse wheel if you choose the right mouse type. Best of all, it does all this in a simple ncurses interface.
As for alpha-blended mouse cursors, Xrender will make those and more possible in the future.
Its because of GNU. Any C++ runs slowly on Glibs. Any. Sure, now they have a hack to make it 50% faster. CORBA is faster than The X Protocol. Ever thought about that? Berlin is not KDE. Berlin is something like X.
As the Berlin webmaster, I'd like to apologize for this -- the page linked to is part of the Berlin Wiki, which means that anyone can add content, fix links... and delete pages, add pornographic images, etc. We've so far managed to avoid an arms race of people doing stupid things and forcing us to block them, rinse, repeat, and this is the first time anyone's tried nastiness with javascript. For the moment, the page is fixed, and I'd be happy to hear any suggestions on how to prevent it happening in the future -- you can reach me at webmaster (at) berlin-consortium.org.
Once again, apologies for what happened -- while no-one involved with Berlin intended it to happen, I can understand why you're so angry, and would love to prevent this sort of thing happening in the future.
-- Nathaniel Smith, webmaster (at) berlin-consortium.org
(I'd appreciate it if this were to be modded up so it might actually be read.)
Imagine where everything runs without waiting. RAM gets cheaper, yet software gets slower. Windows 95 on 8mb ram was as fast as Windows Me on 128mb.*shug* why not we lose all the features and go with Windows 95 on 128mb?
thank you for the info
Why not just use the XFree86 RENDER extension?
Cryptnotic
My other first post is car post.
Hey those poor folks have disovered that the average shitdot reader is a lame hippie child that likes to shit in other people's sandboxes.
When will shitdot end up on fuckedcompany?
It must have taken a lot of mod points to get all these posts. I got to give the mods a hand.
SHM is only used for put/get image stuff, AFAIK. :1 ...). If you set DISPLAY=localhost:0, the xlib will use TCP. (This is occasionally useful when hacking around if you want to run an X client from inside a chroot, where the Unix-domain sockets in /tmp aren't available).
Local communication happens over Unix sockets (/tmp/.X11-unix/X0, etc.) when DISPLAY=:0 (or
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
AMEN! Thanks for saying what too many people seem to either not recognize or apologize for. One of my other pet peeves (besides what you mentioned) is copying. OK, OK - perhaps I'm just some stupid "windoze luser" or what lunix people want to call me, but JUST because I highlight something doesn't mean I want to copy it to my clipboard, erasing what's currently there. I want to specifically TELL the computer when to copy something.
Case in point - copy a URL, then go to a browser window and highlight over the old URL to paste the new one in. OOOPS! You just copied the old URL to the clipboard. What do you need to do? Either "open a new location" or position your mouse and hold DELETE.
creation science book
>> clicking the 'close' button on some program closes them, but clicking the 'close' button on others (like a web browser) just minimizes it?
Eh? On my Mac, the "close" button always closes, web browser or not. I think you're just hitting the wrong button and blaming it on the OS.
I think A.C. was referring to the fact that some Macintosh apps use only one window and die when you close them, whereas others can exist in a state with no documents open, but the application is still in memory, ready at a moment's notice.
Will I retire or break 10K?
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?
It works on printers because the physical resolution is high enough that your eye can't pick out the pixels. But monitors do, what, roughly 75dpi?
You're probably used to the blocky "nearest neighbor" form of upsampling that's common in 3D APIs' software mode but carries 6 dB/octave of aliasing into the high frequencies, causing your eyes' high-pass filters to report spurious edges at pixel boundaries. Proper linear upsampling will use bilinear interpolation (aliasing falls off at 12 dB/octave) or cubic spline interpolation (18 dB/octave).
Now, with true type or vector fonts, or something along those lines, text would look OK. Line drawn and filled components would look fine of course. But say goodbye to any bitmapped graphics looking good - icons, etc.
Who says that icons can't be "line drawn and filled" vector graphics? Besides, there are techniques to scale images while adding fake detail, such as nonlinear interpolation and fractal methods.
Will I retire or break 10K?
CORBA has been lomg plagued by the need to rebuild and redeploy clients and servers everytime you add a field to a struct, for example. How does Berlin get around this problem? How do you extend Berlin without breaking this contract? Do you have to redeploy recompiled Berlin CORBA clients endlessly? Also, there is no standard in-process binary API for CORBA. So, if you use one CORBA ORB using a given C++ compiler you cannot mix and match CORBA libraries built using another ORB vendor's ORB - even if the C++ compiler is the same. Is this an issue? What ORB must you use for Berlin if you want to achieve in-process efficient processing?
You'll be happy when KDE 3 comes out - it will finally do away with this legacy X behavior. Hooray for KDE!
Do the Berlin people need to make all new graphics card drivers, or can they use the existing XFree86 ones somehow? ---rob PS: This is somewhat offtopic. Years ago slashdot had a thing about this web page that had a Mac OS simulator written in DHTML. There also is a WindowMaker one. I can still find the WindowMaker one (not by google.com, but from a WindowMaker.org link. I can not, however, still find the Mac OS one, by google or by any other means. Does it still exist? I'd like to use the pretty blue background and the window chrome from the simulator to make a theme for my WindowMaker (since I couldn't find any more classical Mac windowmaker themes). Thank you.
I wonder if the Berlin designers are familiar with NeWS and could make a further comparison.
It's not printable
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Although you could argue that OpenGL is actually a language (depends on your definition thereof), the 'GL' in OpenGL I believe stands for "Graphics Library".
The opening sentence I got when I went to the "Berlin Vs X" page [ http://www2.berlin-consortium.org/wiki/html/Berli
"Note for slashdotters
.... further down the page I got this ---
"We've had ~3000 (not a typo) times more
stupid deletion attempts than normal since
Berlin showed up on Slashdot."
I am a LONG TIME slashdot user, *please note my #* and I must tell you that I really FEEL ASHAME of the doings of some of my fellow slashdotters.
A note to the all slashdotters -
Please, please be considerate.
Thank you !
Muchas Gracias, Señor Edward Snowden !
You do know that linux uses shared memory for unix sockets these days (at least, if you compile your kernel right)? - they're basically zero-copy across the local machine
"The key thing that many people seem to forget is that MSDOS has a nice extension mechanism. Everything NT is doing could be done as extensions to MSDOS. The multitasking is already being done via the Windows95. The NTFS and TCP/IP extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted."
Sometimes it's better to start from the scratch, otherwise you'll carry legacy baggage with you.
It sucks! I can't run any ultra-kewl Loki games with it, and it doesn't even have themes!!!! What are you people thinking? this sucks! I'll stick with X windows, thank you very much!!
Linux Rulez!!!!!!!!!!!
This is going to be amazing.. ive been following Berlin for a while, and im running debian unstable, but im still not sure i want to risk using berlin just yet.. (well in dec ;)
:/ Stick in the muds :/
Abstraction and multiple layers are a very good thing.. but ill be glad when I can just run Berlin, rather than X, Sawfish & Gnome.. sure ill miss using Gnome, just like I miss using my Amstrad...
This IS a good thing.. it's just a shame that alot of people wont use it because they are used to using X
Instead of using one of these, you should probably look into using *just* a window manager (meaning, without the whole desktop/panel/libraries/file manager shebang). This will give at least usable performance on your laptop (I used to use WindowMaker on a 32-MB laptop and it ran acceptably).
The guy at the webpage says that since he has been slashdoted tha attempts to delete the document (created with
What does that say about the slashdot community as netizens.
(Granted, perhaps his traffic was also increased proportionately, though that is most unlikely.)
It sounds a little bit from the other poster that perhaps KDE/Qt are going to do this as well.
The old X mechansim is actually equivalent to "drag&drop" but with the advantage that you can rearrange the windows in the middle of the drag. This makes the real problems with drag&drop become visible, this is what you are seeing. (it also points out the drag&drop is pretty powerful, seeing as X has survived for so long with only that, but that it is not sufficient for everything).
I do wish people would stop complaining that the mechanism sucks and then go on to complain that "X lacks drag&drop". I'm sorry, you are wrong, perhaps the mechanism sucks but that mechansim *IS* drag&drop!!!
Straight from http://www2.berlin-consortium.org/wiki/html/Berlin /ArchitectureQuestions.htm:
"The jerk who crashed a bunch of people's computers by putting malicious javascript in BerlinVsX wasn't very cool either -- I'm soliciting suggestions on how to prevent that in the future."
So you know it wasn't intended as a bomb.
...Stefan Seefeld. He's a really bright guy and a crackerjack programmer. If anyone can pull it off - it's him.