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.
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!
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.
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"
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
The interesting question is, just how easy would it really be to move Qt to Berlin? Berlin is designed around a model where all of the drawing and interaction code for widgets are hosted inside the display server. I haven't seen any talk of a Java VM like system for safely hosting downloadable code, so I'm not sure how well that actually works in practice, but it seems like there would be a whole lot more structural differences for a widget set written to use Berlin than just what rendering layer it's layered on top of.
Of course, I haven't done any Qt coding.. perhaps Qt is sufficiently abstract that such a very different underpinnings could be put in place. It doesn't at all seem like an easy or obvious conclusion to make, though.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
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!
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.
QT doesn't use the Windows widgets tho. It uses the Windows API to do the same work it does under X: draw its own widgets in the style of Windows ones.
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.
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.
Fix that flicker with xvidtune.
The Mac interface was designed for one button. You never need two buttons.
I personally use a five-button mouse (4 buttons+wheel by Kensignton) for Mac OS X, which is quite useful. However, nobody else than me can use that machine, because they never hit the correct button (even when I told them three times which one to use). That problem just doesn't exist on a regular Mac.
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?
It's planned for december IIRC
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.
The problem is you have to buy a mac to get macos and lose all your good games and sech. Linux/BSD should go this route. I was thinking that it was more like the way Macs handle the GUI, which, while butt-nasty with MacOS 9 and earlier, is pretty nice with the current buggy MacOS X. Macs approach unix and unix approaches the few good things about the Mac. In the middle will, perhaps, be Berlin - better than anything on either.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
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.
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.
Cuz they are faster and cheaper and (until recently) had much better graphics HW. And much better standard sound cards. And an actual choice of speakers. And Sony monitors, gotta love those Sony monitors...
A deep unwavering belief is a sure sign you're missing something...
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.
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?
Your fix must have lasted for a whole moment. I honestly believe you made the effort, but the page is doing it again. I suggest you restrict access to your web site's html if the contributors are going to pull stunts like this.
Not that it means much, but you lost at least one desktop with this. You'll never be on mine.
Get off my virtual lawn, you damned virtual kids!
Why not just use the XFree86 RENDER extension?
Cryptnotic
My other first post is car post.
Latency is a problem here, as well as bandwidth. On a large-latency link (e.g. CA*Net3, a multi-Gb/s link between several Canadian Universities), the round trip latency for light-in-fiber alone is ~80ms. This means that the program blocks for that long whenever it asks the server to do anything. Displaying a progress bar could slow down progress significantly, unless the process was multithreaded, with a thread dedicated to communicating with the server. (This would make communication asynchrounous.)
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
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?
That got it. I'll read the site once I get calmed down.
Jesus God I need to get a hobby.
Get off my virtual lawn, you damned virtual kids!
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.
Mac OS X and NextSTEP come, from the existing windowing systems, closest to Berlin.
But Mac OS X is non-free. Berlin is free software.
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 !
"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!!!!!!!!!!!
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.
I don't write code for Berlin, and I haven't even gotten around to trying it out... Maybe now that it's useful enough for someone to make a .deb of it, I'll give it a shot. Thus, I don't know the answer to your question about invokeNow(), etc.
:) (or on the remote machine, if the server is not on the same machine as the client).
You could make a progress bar async by having a display thread that drew the bar at a length corresponding to the current amount of progress. (so updates the the bar length that happened while the display thread was blocked would all be skipped, except the last one.)
So, yeah, the drawing thread still blocks, but at least it won't be slowing down your chess analysis on your dual proc machine
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Most UI experts. The couple of idiosyncrasies you mention are not in fact UI problems. As others have mentioned, they are probably not even problems at all. Nevertheless, I never claimed the Mac OS UI was perfect.
Not to mention that having only one mouse button severely limits the usefulness of the device.
Funny, I use Mac OS and I have two mouse buttons and they work just fine. And they do exactly what you would expect. Just because Apple sells machines with one mouse button does not mean that the OS is a one mouse button OS.
People who "consider" the Mac interface to be better don't really understand human dynamics.
You mean like usability engineers? What UI is better than the Mac UI from a usability perspective and what experts back up your opinion?