Hackers on Linux's Exciting Desktop Future

Gentu writes "OSNews features two interviews with prominent open source developers: Robert Love started working at Ximian this week and he will be leading the 'effort to improve the Linux desktop experience via kernel development'. In this Q&A, he explains what he will be working on hardware integration, freedesktop.org's D-BUS & HAL, low latency optimizations, power management, X & 3D and a 'Linux answer to WinFS'. The second interview is with Red Hat's Owen Taylor. Owen speaks of GTK+ development and where he sees the project going in the Gnome 3 timeframe: freedesktop.org's new X server, Cairo support, GTK#, OpenGL & other widgets and more."

Comments

Shortfalls of GTK+

[BitchKapoor]

Many people are probably going to say that GUIs are inherently object-oriented, as they attempt to reconcile programmatic constructs with tangible objects. But the fact that GTK+ isn't implemented in, say, C++ isn't necessarily as bad as it sounds -- I don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it. What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading. Although I agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference. Unfortunately, popular object oriented languages like C++ and Java don't really add this over C -- C++ is still totally sequential at heart, and Java's threads aren't particularly lightweight, nor is its huge library.

Re:Shortfalls of GTK+

[Anonymous Coward]

don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it.

It allows for polymorphism too.

Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference.

Uhh...right...because C has all of those things...

Re:Shortfalls of GTK+

[Anonymous Coward]

Does this mean they will finally debug Gnome and relates apps. I love the stylings of Gnome, Evolution, and Nautilus but I have never had an over-all good experience with them. Konqueror is much more solid and feature rich (connects to just about anything) than Nautilus, I have weird crashes and glitches with Evolution (w/ & w/o Ximian connector), but I use it because Exchange at work. And I have experienced very odd glitches with Gnome pannel.

I have stressed KDE much more that I have Gnome with much more success. The only problem is KDE is ugly as hell and way over done with gadgetry.

I don't mean to be so negative. Both projects show much promise, but both miss the boat in very different ways. I guess I'll just keep wiating on the side-lines in geekdome and leave my friends and family on Windows [I can't even interest them in the Mac]. Who knows, every once in a while Enlightenment shows some interesting potential.

Re:Shortfalls of GTK+

[BitchKapoor]

Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference.

Uhh...right...because C has all of those things...

You're 100% right, it doesn't. But the current crop of popular programming languages is almost equally lacking in these regards -- C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works; Java's generics are still in development, but other than that Java's libraries are already a total mess. Since the least common denominator isn't much worse than the best of what's popular, might as well keep the flexibility of C so that we're not tied to a incompatible halfway solution when the right thing finally comes out and is accepted.

Re:Shortfalls of GTK+

[Roydd McWilson]

truely a tesamint to the sorry shape /.'s in when someone named "BitchKapoor" get's modded upto +5 Informative... just glad my 2-year-old can't read yet... or maybe he's just hiding it from me? anyone else wish this sight had an optinal obscenity filter for this kindof nonsense.

Re:Shortfalls of GTK+

[drix]

This is true, and if they designers of GTK+ had taken this wisdom to heart, all would be well. Instead, they made the dubious decision to write an entirely OO toolkit on top of a strictly procedural language. And the results are just horrid. The plain reality is 90% of all the UI programming is done using preconstructed widgets--button, textbox, image, whatever. Some people, myself included, think that for consistency's sake that number should be closer to 100%. Newfangled widgets tend to confuse the user unless they're done well, which they're usually not.

Re:Shortfalls of GTK+

[Fred_A]

Oddly enough I've had pretty much the exact opposite experience you've had (i.e. Gnome more stable than KDE). Usually I like Gnome more but I still regularly change to KDE because I like a change of scenery every now and then. All in all I believe they're both roughly equivalent. Most of the time they just work. And when something breaks it's just a matter of restarting the app.

Re:Shortfalls of GTK+

[Roydd McWilson]

WHEREAS, I was just kidding around,
WHEREAS, the totally lacking grammar in my above post is uncharacteristic of my previous posts, WHEREAS, BitchKapoor is actually a good friend of mine,
RESOLVED, YHBT,
RESOLVED, but I'll fuck off anyway,
RESOLVED, now IHBT.

Re:Shortfalls of GTK+

[Roydd McWilson]

LET IT FURTHER BE RESOLVED that I left off a line break. That sucks.

Re:Shortfalls of GTK+

[smittyoneeach]

C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works;

Hmmm...no, your remark refers to the pre-processor.
Here is some reading to catch you up on what's going on.
Also, Boost, the CPAN of CPP, will go a long way to improving understanding.
Mods, BK isn't insightful, mod appropriately.

Re:Shortfalls of GTK+

[Roydd McWilson]

"C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works"

Hmmm...no, your remark refers to the pre-processor.

No they don't, but I can see how the wording can make you think otherwise. My point is that when you define a template, you cannot place constraints on template arguments other than by writing code which uses them in a certain way. This is because judgment whether a particular type can be substituted into a template is on a basis of "would the code compile if we simply rewrote it with that type in place of the template parameter?" Clearly, without this capability, it's much more difficult to make a family of different templates based on properties of the type with which we are instantiating.

Re:Shortfalls of GTK+

[BitchKapoor]

Damn you, Roydd. Should've known you were signed in on my computer.

Re:Shortfalls of GTK+

[NateTech]

Most of us probably value the Freedom of Speech and the lack of censorship more than we want a censor app built into the system.

Teach your 2 year old proper values as he is growing up and he'll be able to make the same (or more likely, different but similar) value judgements you are making. If you shelter him from it, he'll just seek it out out of natural curiosity about what Dad's so freaked out about anyway.

I'd be proud of any 2 year old who could read Slashdot anyway, even if the content might have to be explained by their loving parent.

He (and you) will be fine.

Re:Shortfalls of GTK+

[Tim C]

Java's threads aren't particularly lightweight, nor is its huge library

Java has two threading models - internal or "green", and native. Internal threads are "pseudo-threads" created within the JVM, and have nothing to do with the host operating system. This was originally the default (only, iirc) model, but a couple of years ago native thread support was added. The default now is to use a native thread for each Java thread; therefore, Java threads are as light- or heavyweight as your OS's threads.

As for the "huge library", that's one of Java's strengths! The fact that the core distribution provides so much functionality makes writing and deploying code much easier. No need to choose between writing your own support libraries, or using someone else's and hoping that the target machines have it installed (and have the right version, etc). With Java, I can just write my app, create a jar file (which are now executable, at least on Windows), and tell people "JDK 1.3 or better" and that's that. If they're running Java apps, they already have everything they need, or know where to get it.

Also, you do realise that with the probable exception of classes in the java.lang package, all classes are loaded on demand? Just because there are thousands of classes in the core API, doesn't mean that you have them all loaded everytime you run a Java app. Similarly, an app I write in C isn't going to start loading up libraries that are written in C that it doesn't explicitly use...

Re:Shortfalls of GTK+

[BitchKapoor]

As for the "huge library", that's one of Java's strengths! The fact that the core distribution provides so much functionality makes writing and deploying code much easier. No need to choose between writing your own support libraries, or using someone else's and hoping that the target machines have it installed

That would be true if it weren't for the facts that (1) Java's standard libraries include all kinds of special-purpose classes/packages but lack very basic things like a Priority Queue (correct me if I'm wrong -- I couldn't find one), and (2) there are a lot of methods which handle the same kind of data but have incompatible signatures (e.g. accepting int vs. Integer), which greatly reduces synergy in the system (compare this to something like Mathematica where a lot of effort is spent to make functions interoperable via a common notion of expression trees).

Re:Shortfalls of GTK+

[Anonymous Coward]

This all sounds somewhat intelligent, but it makes very little sense at all. What in the world does "C++ is still totally sequentail at heart" mean? I think what you're really saying here is that C++ is like C is, prcedural, which of couse would be completey wrong to say.

I for one much prefer an object oriented language for GUI programming instead of a procedural. I like being able to take, say a JButton in swing, and extend it to have the properties and functionality that I want, and will use over and over several times.

GTK on the other hand really requires you to do a lot of the work that a c++ compiler would simply do for you, and with strong type checking. I mean, building a struct with a table of function pointers is fun for about 10 minutes. The whole thing about casting pointers back and forth with macros is an attempt to introduce some primitive level of polymorphism, which c++, java, c#, will simply "give" you for free.

One other thing. Qt signals/slots are synchronous, and cannot be executed in any other thread other than the main, and the same goes for java, all events are processed by the main event loop.

Re:Shortfalls of GTK+

[claes]

His points are still valid. I don't think the java libraries include many special purpose classes that are more special than a priority queue. I think it depends on the context. What is basic for you is special purpose for me.

Re:Shortfalls of GTK+

[jcupitt65]

GTK has signals and slots, it has single inheritance, it has multiple inheritance of interfaces, it has run time introspection, it has about Java's level of static typechecking (very slightly less).

People get hung up on the implementation language. It doesn't really matter (except in extreme cases). Writing in C beings many benefits (portability, ease of foreign language bindings, simplicity).

Re:Shortfalls of GTK+

[lokedhs]

But if you don't write your own widgets, much of the object orientation mess is hidden. Or rather, it's there in plain sight but you don't have to worry much about it.

And if you happen to be a fan of C++, just use the gtkmm libraries and get a "proper" C++ class hierarchy. If you like Java, use Java-GNOME and I would suppose that the Python bindings also use the languages native object orientation.

Re:Shortfalls of GTK+

[Golthar]

Indeed all classes are classloaded when referenced.
Thus if you classload a bit of code that requests an Stack, the class stack will be loaded (if not yet loaded)

This behaviour is triggered by Class.forName(classname) and import (which does the same?)

Re:Shortfalls of GTK+

[DAldredge]

And a good start would be to tell that two year old "See those people on /.? Don't act like them."

Re:Shortfalls of GTK+

[NateTech]

LOL. That deserves a +1 Insightful if I ever saw one! :-)

This is excellent

[SoIosoft]

When I first used Linux and I ran X, my thought was "damn, this is slow." This feeling is echoed by a lot of other people. It's nice to see that a replacement is on the way. Hopefully, in addition to reducing latency, an effort will be made to improve some other areas in X. Copy&paste is still inconsistent in X and just annoying. Nonetheless, fixing the problems with X is a BIG step toward Linux being viewed as acceptable on the desktop. That is the one thing that particularly caught my eye.

Re:This is excellent

[aardvarkjoe]

When I first used Linux and I ran X, my thought was "damn, this is slow."

I thought the same thing. Then, I saved my pennies and got rid of my 486.

Re:This is excellent

[BrookHarty]

When I first used Linux and I ran X, my thought was "damn, this is slow."

The only problem I have it trying to find the right modelines and configurations for higher resolutions and refresh rates. Things are better, configuration tools are almost complete.

But speed? Nope, even playing games in Vmware is fast.

Re:This is excellent

[Josh Booth]

Cut, copy, and paste is an application thing, not really so much an X thing. If the app doesn't know how to retrieve a PNG or XLS from the clipboard, no amount of X advancement or extension is going to fix that. I haven't found X to be really slow, but Xinerama definately is (well unoptimized, at least). X in general may be funky in that it seems to be very serial and synchronous, but it is not necesarily slow. I cite how my Enlightenment applets and XMMS visualizations don't update when I'm moving windows around. But then I've got 256 MB RAM and an Athlon 1333.

Oh, and the parent is not a troll!

Re:This is excellent

[be-fan]

This isn't a replacement, just another implementation of X. Not only that, but most likely it will be much more memory hungry and marginally slower (not taking into account GL acceleration). However, it will *seem* a lot faster, because it will explicitly synchronize drawing between apps and the window manager, just like OS X.

X was never slow. For the most part, KDE is faster than XP on my machine. X apps, however, have traditionally have done dumb things, and there have been problems with synchronization. Its these issues that are being addressed.

Re:This is excellent

[pliny3]

The only problem I have it trying to find the right modelines and configurations for higher resolutions and refresh rates. Things are better, configuration tools are almost complete.

I have found this modeline generator very useful.

Also, if you don't get the expected result, look at /var/log/XFree86.0.log. I recently had trouble because I had not set the correct hsync and vsync capabilities for my monitor, so despite the desired modelines being in there, the videocard refused to try them. The information in this file was invaluable in diagnosing the problem (grep for "not using default mode"

Re:This is excellent

[Dr. Photo]

Not sure about other cards, but for a Radeon (open source driver), add the following to your XF86Config file (under Section "Device")

Option "DDCMode" "true"

Any remotely modern monitor will then report its optimal refresh rates to the video card when X starts. No more modeline yuckiness. :-)

Re:This is excellent

[phoenix_rizzen]

There's a handy little Sourceforge project to solve that problem: The X Modeline Generator

Re:This is excellent

[drinkypoo]

When I first used linux and I ran X, my thought was, "wow, this is a whole lot better than windows!" And this was on my 386DX25 with 8MB ram, 120MB IDE disk, and 1MB ISA Trident VGA card. What OS were you used to at the time? GEOS? Or just DOS?

Re:This is excellent

[Anonymous Coward]

I have to agree. Native 3d apps on linux seem quite fast. However, 2d apps in general are nowhere near as fast as their windows equilvant.

If Linux zealots cant agree to its problems, then it will never progress.

Re:This is excellent

[Anonymous Coward]

Enemy Territory runs a lot better on FreeBSD with X then on Windows on my machine..
Hardware: Athlon XP 2600+
512mb DDR SDRAM (400mhz)
nvidia gforce4 mx with 64mb

FreeBSD 5.2 RC1 with latest nvidia drivers.
Windows 2000 with latest nvidia drivers.

On windows, 800x600 is simply the highest playable resolution, on FreeBSD 1280x1024 is better playable still then 800x600 on Windows.

Playing movies gives the same experience, but in that case Windows Media Player may be to blame.. interesting enough, it is definitely not the codecs snce I use the same codecs. It is possibly mediaplayer overhead, but everything seems to point at xvideo working better then its equivalent on windows on my hardware.

Re:This is excellent

[Anonymous Coward]

When I see posts like this I can only shake
my head. Even on 486 boxes with "average"
video hardware X runs well. I think posts like
this occur for one of two reasons. 1) The
person is using KDE or GNOME which are both
fairly slow and hence the user blames X.
2) The person doesn't understand X, from a
programmers perspective, and has no intention
of spending the fairly large amount of time it
takes to really understand X and therefore
declares X sucks and demands a new windowing
system to take its place in the hopes that the
new window system will be able to learned in 3
days.

Re:This is excellent

[penguin7of9]

Copy&paste is still inconsistent in X and just annoying.

Copy-and-paste is completely consistent in X. As is the selection mechanism. What is inconsistent is the support by toolkits and applications for them. Unfortunately, Gnome and KDE both are to blame here. Instead of supporting X11 conventions, Gnome and KDE are each doing their own thing, mostly like Windows but not quite, and definitely inconsistent with X11.

When I first used Linux and I ran X, my thought was "damn, this is slow." This feeling is echoed by a lot of other people. It's nice to see that a replacement is on the way.

X is not slow--it's as efficient or more efficient as Windows GDI, and it runs rings around Macintosh's Quartz. All of them are, of course, client-server system so there is no particular reason why X should be any slower than the other systems.

What makes X-based desktops slow is the desktop environments themselves. In part, that's because some desktop environments try to emulate graphics primitives in client code that X11 does not support (e.g., transparency, anti-aliasing), and in part it's because they don't take into account the client/server nature of X11. And in part, it's because they are just slow completely independent of any display-related functions (e.g., inter-application communication, huge memory footprints, etc.).

Identifying the bottlenecks correctly matters a great deal: if you are trying to fix Gnome or KDE performance by hacking around in X, you are mostly wasting your time.

The only thing on the X server side that will help a lot is the RENDER extension, because the RENDER extension for X is eliminating the need for Gnome and KDE to emulate graphics primitives client-side.

Re:This is excellent

[Anonymous Coward]

If Linux zealots cant agree to its problems, then it will never progress.

If Anti-Freedom Zealots keep this shit up, then yeah, Linux will never progress.

Re:This is excellent

[NateTech]

Actually in true X, copy and paste is very consistent - highlight any text and then focus the window you want to paste into and hit the middle mouse button. Works in just about every app out there, and definitely should CONTINUE to do so.

The fact that :
a) Many machines don't have a middle mouse button, so we have to deal with emulating it with the other two pressed at the same time...

b) Desktop architectures like Gnome and KDE try to mimic Windows silly CTRL-C, CTRL-X, CTRL-V stuff AND give right-click context menus with "Cut", "Copy" and "Paste" just like Windows... ... make up the irregularities.

Get a real three-button mouse and do it the "old-fashioned" way and forget about the silly CTRL key for this job. You'll like it - once you get used to it people wonder how the heck you're pasting stuff without touching the keyboard. Fun to watch their reactions to it if they're really paying that much attention as they look over your shoulder.

Any app or "desktop" that breaks this older tried-and-true functionality I throw out on its butt as soon as I find a replacement.

Re:This is excellent

[Overly Critical Guy]

Any remotely modern GUI wouldn't require an arcane manual text edit of some config file.

Re: This is excellent

[Marsell]

I often see the comment that X is slow, something I've never understood. I too ran linux and X on a 486. Specifically, I was running XFree86 3.3.3 (or 3.3.6?) with linux 2.0.35 (yes, I had that 486 for ages) on a 486 66MHz with 16MB ram.

You know what? It was roughly comparable to running Windows 95. I didn't think "my God, this is slow", I thought "this is rather similar to 95". FYI, running 95 on that 486 felt just like running XP on my Athlon 2Ghz, for comparison.

Of course, I was running WindowMaker on top of X, not something like KDE or GNOME. Perhaps that accounts for some people thinking X is slow, I have no idea. In any case, I _still_ don't run KDE or GNOME, even on my Athlon. They really are horribly slow, and I can't say I've missed their added functionality. Maybe my usage patterns are just different.

But no, if someone claims that X itself is slow, they either aren't being specific enough, or they're mildly ignorant of what's going under the hood.

Not to excuse GNOME or KDE. Egads, they make XP look fast on my machine, and XP really sucks.

In any case, I welcome another contender in the X arena. Keith sure knows what he's doing, and his work looks veeeery promising.

Re:This is excellent

[zsau]

This is more insightful than funny, even if it is expressed as a joke, people...

Re:This is excellent

[Anonymous Coward]

OMG! This was hilarious :)).

Re:This is excellent

[Lozzer]

Middle click is great most of the time. But I've picked up a habit of copy text from one location, and attempting to replace text in another. Of course this means that I highlight the second piece of text before replacing it.

I realise there is should be real difference in effort between

• highlight, copy, highlight, paste
• highlight, middle click, highlight, delete

But, the middle click moves the text I want to delete, so I have to locate it again.

Re:This is excellent

[jsebrech]

Gnome and kde used to do a different thing with regards to copy and paste. But ever since gnome 2.x and kde 3.x they work identically (for text).

Also, a lot of the graphical effects in gnome and kde are realised through the render extension today. However, the render extension is horribly slow. It's not even anything remotely approaching fast for a software implementation. So, yes, X is to blame for the slow speeds of kde and gnome.

Re:This is excellent

[NateTech]

I had some trouble with that for a while too -- until I learned to do it what at first seemed to be "backwards". Delete what you're going to delete FIRST. Then go highlight what you want to copy and paste it in.

The other habit is just built up from doing it with the CNTL key, I think.

There's really no "right" or "wrong" way of doing it, and the original poster's concern was that X isn't "consistent" enough.

I do know the middle-mouse paste maybe isn't the ideal solution, but it has been around as long as the other one... people seem to like the other one which takes more fingers and more movement, once you get used to doing it the X way.

Dunno, maybe I'm just really used to it.

I was happy to find that even PuTTY, a windows-based ssh client, handles middle mouse buttons (or simulated ones with both buttons pressed) with aplomb. Makes it so that when I'm working at the command line via SSH from even a Windows machine, I enjoy it.

(Just the PuTTY part and flight simulators, mind you! And I'm looking to replace my Windows/Flight Sim addiction with FlightGear, which happily runs on Linux.)

Re:This is excellent

[Anonymous Coward]

Wait till you get to replace your fvwm with something else. I did the reverse. Flipping desktops used to take seconds on a 1,7Ghz machine. Now its milliseconds.

Re:This is excellent

[CaptnMArk]

Unfortunately...

This is not cut and paste. It is selection mechanism.

The people that keep thinking this is cut/paste keep confusing matters.

Re:This is excellent

[Anonymous Coward]

I understand what you mean in the order, but I find it is more time consuming to do the target delete first in X. You visit three windows with the mouse in X:

1. Target window to delete.

2. Source window to copy

3. Target window to paste

In Windows the first step is not necessary. The time it takes to move the mouse from one window to
the other, possibly raising focus as needed, is far more than the time it takes the left hand to use Ctrl-C, Ctrl-V.

Flightgear is an interesting effort, but I've had trouble getting my gameport controller to work with it (CH rudder pedal and Logitech Extreme Digital joystick). So far I have no rudder control. However I'm working with the 2.6 kernel so perhaps this is something that will work better when the joystick config application can actually recognize the hardware as it is documented to be able to do.

Re:This is excellent

[Dr. Photo]

Any remotely modern GUI wouldn't require an arcane manual text edit of some config file.

Read the article. Most of it is about turning X into a 'remotely modern GUI'.

Re:This is excellent

[ndogg]

Copy-and-paste is completely consistent in X. As is the selection mechanism. What is inconsistent is the support by toolkits and applications for them. Unfortunately, Gnome and KDE both are to blame here. Instead of supporting X11 conventions, Gnome and KDE are each doing their own thing, mostly like Windows but not quite, and definitely inconsistent with X11.

You'd be correct if you limit yourself to just text, but copy and paste shouldn't be limited to just text. X can't handle anything that isn't plain text.

Re: This is excellent

[AvitarX]

I found on my 486 emacs OS to be the best thing to use.

I mean that literally too.
I had an emacs AIM client and and emacs Web Browser.

I would use that and CTRL-Z with lynx to check hotmail (before there was any encryption. I would also usually have a game of Millebourne running too.

I would use Black Box some, but found netscape 4.x to really really suck, and running that and gaim to really bog stuff down.

Re:This is excellent

[Anonymous Coward]

In A.D. 2003
War was beginning.
Slashbot 1: What happen ?
Slashbot 2: Somebody set up us the troll.
Slashbot 3: We get signal.
Slashbot 1: What !
Slashbot 2: Main screen turn on.
Slashbot 1: It's You !!
Overly Critical Guy: How are you gentlemen !!
Overly Critical Guy: All your base are belong to us.
Overly Critical Guy: You are on the way to destruction.
Slashbot 1: What you say !!
Overly Critical Guy: You have no chance to survive make your time.
Overly Critical Guy: HA HA HA HA ....
Slashbot 1: Take off every 'sig' !!
Slashbot 1: You know what you doing.
Slashbot 1: Move 'sig'.
Slashbot 1: For great justice.

Re:This is excellent

[damiam]

So how do you copy/cut/paste an image? A file in Nautilus or Konqueror? Formatted text? An embedded Bonobo/KParts object? You can't, without hacking around the X way and implementing your own method. That's the problem.

Re: This is excellent

[Anonymous Coward]

Blackbox + xterms/rxvts w/ lynx and emacs. 'Nuff said.

Re:This is excellent

[NateTech]

This is not cut and paste. It is selection mechanism.

Gee that's funny, I see stuff, I highlight it, I manage to copy it to another place on the screen... that pretty much looks like "copy and paste" to me.

In fact, I used it to quote you above.

What's this hooey about it being a "selection mechanism"? I can do more than just select with it.

Re:This is excellent

[Anonymous Coward]

and it runs rings around Macintosh's Quartz.

You might think that, but you're wrong.

Quartz is just as fast as X, but does a lot more. How can this be? It's pretty fucking efficient.

Re:This is excellent

[NateTech]

Maybe it's a problem if you want that functionality, sure. I'm a command-liner... I don't drag and drop widgets or pictures or anything like that.

If I want to copy pictures I fire up cp. Other than the occasional right click on a picture and saving it from Konq to a file, and that's about it.

Text copy and paste is quite fine, thanks. ;-) Not having the more Windows/Mac-like widget stuff hasn't bothered me much.

And in the cases where it's kinda nifty (fish:// protocol in Konq is dang cool) I like it but I don't need it. scp user@machine:/path/file /localpath works just as well or faster.

Re:This is excellent

[Anonymous Coward]

Well it is not that slow anymore, but it still is slower than windows or OS/X. The problem can not be traced down to a single point.
The problems I see is. The X-People say, the client server model is not the cause of the speed problems since it uses in mem operations on a local level. I guess so they are the best to knwo that. I think as far as I can see it from the outside the problems lie elsewhere. Face it Windows and OS/X use the accelerator functions of their underlying graphic cards extensivly, lots of windowing operations happen inside of the graphics memory, alpha blending and other crucial operations as well. I am fully aware that the X people are on this one, and the current generations of X-Free combined with the 2.6 kernel are not that slow anymore, I think they have reached the status of being usable and and having the speed I personally dont mind it anymore.

But Im glad with a new X-Server and Cairo the people are up to the task to improve things, especially cairo could give a good abstraction layer to being able to bypass X at all if needed.

Re: This is excellent

[56ker]

What's Millebourne?

Re: This is excellent

[Anonymous Coward]

Google. Use google. Google is your friend.

Re:This is excellent

[Anonymous Coward]

When I first used Linux and I ran X, my thought was "damn, this is slow."

Me too.

Then I stopped using the vesa drivers.

Re:This is excellent

[Wooky_linuxer]

" Actually in true X, copy and paste is very consistent - highlight any text[...] " Text. For some - actually for a lot of desktop users, since this is the subject - need more than text cut'n paste. Don't get me wrong, I love X's middle mouse button thingie. After you get used to it, CTRL C and CTRL V are just plain annoying. The question is that, for desktops users - think mp3s, graphics, games, video - we need more than text cut and paste only. I am not sure if that should be implemented in X; perhaps as a new standard to be implemented in all (freedesktop compliant?) window managers.

Re: This is excellent

[AvitarX]

A French card game I played growing up.

RedHat 5.1 (maybe newer and older ones) had a good console version.

You try to drive far faster then the computer and you can make bad stuff happen to them.

the executable was mille I believe and it was in the games folder (/usr/bin/games ?)

Re:This is excellent

[penguin7of9]

You'd be correct if you limit yourself to just text, but copy and paste shouldn't be limited to just text. X can't handle anything that isn't plain text.

X has been able to handle lots of different types for a long time. See here for a list. In addition to the older Atom-based mechanisms, you can now also indicate the type of a selection as a MIME type.

Re:This is excellent

[Anonymous Coward]

Mark, go away. We're sorry about what happened to Apple but life MUST go on. Cest la vie.

Re:This is excellent

[Lozzer]

I just dredged this article by Jamie Zawinski from my memory. Its informative about cut and paste under X.

Re:This is excellent

[dododge]

Any remotely modern monitor will then report its optimal refresh rates to the video card when X starts.

Except that sometimes the data from the monitor is not reliable or complete. My Samsung 19" tube tells the computer that it can only go up to 1600x1200, but if you take the frequency ranges from the manual, you find that it can actually sync 1920x1440. So to get the desired higher resolution I have to either put a KVM switch in the loop that blocks EDID, or explain to the driver that the monitor is a liar.

No more modeline yuckiness. :-)

Even with DDC/EDID turned off, I don't think I've had to deal with a modeline directly since XFree86 3.x. Recent servers have a bunch of "standard" modelines built into them. The only time I recall working with a modeline in the last few years was when I was using some specific oddball timings and external signal conversion hardware to trick a projector that doesn't usually work with computer video at all.

More Stolen SCO code

[Sabalon]

These advances must have been stolen from SCO...there is no way a bunch of random hackers could have thought them up an implemented themselves.

My Favorite Device Status Message!

[aheath]

I really enjoyed the Robert Love Q&A because I learned about a new device status:

"We need a simple, low overhead, fast communication channel from the kernel out to user-space, to communicate everything from device status ("your processor is overeating")..."

I finally know why I am never satisfied with the performance of any computer that I have ever used. I used to think that operating systems and applications grew increasingly bloated in order to encourage me to buy a new computer. Now I know that computers perform poorly because the process or is overeating!

Re:My Favorite Device Status Message!

[euxneks]

Now I know that computers perform poorly because the process or is overeating!

Isn't that still bloat? ;)

Re:My Favorite Device Status Message!

[cthugha]

Your processor is only overeating because your constant carping about its performance is making it depressed, you insensitive clod.

Re:My Favorite Device Status Message!

[NateTech]

I for one, welcome our new Depressed Microprocessor Overlords!

(Aww damn it, I couldn't resist.)

Can you imagine creating a Beowulf cluster of Depressed Microprocessors!?

(Help, I've fallen and I can't get up!)

Re:DebSux

[Sabalon]

So what should replace it? Why is it the worst?

It's easy to sit around and say something sucks, but to defend that reason and offer insight into why something else is better takes a little more.

Maybe more automatic testing tools for GUI?

[r6144]

Many GUI programs (in linux or otherwise) are buggy. They may crash if you use them in an unexpected way (and since you are just randomly clicking around, it is hard to generate a bugreport). Many of them also have annoyances like poor focusing (many applications are not very usable with keyboard only), inability to paste from a certain place to another certain place (copy-and-paste works in general), unnecessarily destroying the primary selection (use for middle-click pasting which is very useful against traditional X apps) without ME selecting anything, etc. There are just too many things to test, and it is cumbersome to test all of them manually before each release, while lacking a testsuite greatly lowers software quality (imagine how buggy gcc will be without a testsuite). Hopefully there will be some free tool that automate the process of "test case1: click file, click open, choose /home/xx/ss.xx, choose node33 in treeview, TAB", so that the GUI parts of GUI applications can finally be as well tested as traditional command-line applications.

Re:Maybe more automatic testing tools for GUI?

[BitchKapoor]

That's an interesting point. The only problem I see is that correctness is application-specific, so we need a compact way to define correct application behavior. For GCC, this isn't so much of a problem, because C is a widely-accepted standard; but joebob's Ogg organizing GUI is not. So I guess what you'd end up having is a standard set of requirements on the interactions between different types of widgets, along with parameterized test cases for those requirements. Then you could specify which widgets plug into which requirement-positions, e.g. "such and such custom editing widget (like for equations or something) should follow the standards for text editing" and "such and such is the editing window and that other thing is the Edit->Copy menu option". I suppose requirements could be bundled together into mega-requirements like "typical single-dialog application". You'd also probably want to be able to specify algebraic properties of operations you can perform on the application, like so the tool can derive sequences of events which should result in the same state modulo a particular feature. To do this, perhaps the user interface could be specified as a simplified state machine regarding windows/widgets which are displayed and options which are available. This would allow us to perform a large number of random interactions along a guided path for stress-testing.

Re:Maybe more automatic testing tools for GUI?

[hacker]

"Hopefully there will be some free tool that automate the process of "test case1: click file, click open, choose /home/xx/ss.xx, choose node33 in treeview, TAB", so that the GUI parts of GUI applications can finally be as well tested as traditional command-line applications."

You mean something like Android?

Android is the only open source testing tool for GUI programs. It can watch you work with a GUI program and as you do it will write a script that will enable you to precisely replicate your session. While you work with your program you can indicate testing points to android, taking snapshots of the screens that are supposed to appear. Later, when re-running the tests, android will check to see that these screens remain as expected, and will signal a test failure should any of them change.

Re:Maybe more automatic testing tools for GUI?

[!3ren]

Much as it has caused me intense irritation in the past (as a developer trying to pass QA), the fact that MS published a set of style guidelines detailing everything from widget interaction to the correct default width of a drop shadow, means that consistent UI in Windows (9x+) is the norm as opposed to the exception.

I am not overly familiar with O/S development, are there any similar style guidelines around?

I think congress on this sort of development would make a large move towards easy interoperability, which IMHO is largely lacking in the OS scene today.

Re:Maybe more automatic testing tools for GUI?

[Ian Bicking]

Testing GUI programs is a bitch. I program web interfaces, and even testing those is a pain, and they are way easier than a GUI.

But it's important to distinguish between a Unit Test (which is easy to write, even for GUI programs), and an Acceptance Test, which can be hard to write.

A GUI test shouldn't test something like "when you go to Window>Server List, and leave the window open, showing an active status message by starting a connection by right clicking the server and selecting 'Refresh', then you open the properties with Edit>Properties and change the settings that efect the server, the still-running connection works properly with the old settings until the refresh is completed". That's the kind of corner case where you're likely to find a bug, but testing that sort of thing is nigh impossible -- especially when the software is changing, and the interface is changing, and this is one among thousands of corner cases.

When you use unit tests you don't test a complete thing like that. You test each part, but you test it very completely. You may not test the GUI at all -- instead you test that the underlying server code and preference code work properly. You test that they work to spec, and not just within the bounds of the interface. Maybe in version 1 you can't select both the server window and the preferences window at the same time, so this situation is impossible. But you can still make a unit test for this case.

When you do that, you avoid a huge number of bugs. At that point you don't need to test the entire program by simulating input. Instead you rely on the fact that each component works in a controlled and correct fashion. Then, fitted together, they all work together. Sure, the people writing GTK need unit tests -- but only for what GTK does, not for the particulars of how your application uses GTK. And so it goes, we each build upon well-tested code, but we don't retest that code. We trust the upstream developer.

Of course, we've all seen bad interactions between things we wouldn't expect. Part of using unit testing is to make components that work in an isolated fashion, components that can be tested in isolation. Reducing coupling between components is essential.

Which is again a reason why GUI applications are hard to test -- coupling is encouraged, because it's usually a better user interface. You want to fit everything together based on the best metaphor for the user, the most expressive interface you can get, expected workflow, etc. That often doesn't match up with the underlying objects you are using. It's often highly coupled. But you can have that in one part of your system, so long as you really trust the pieces its built on.

I think as more areas of open source embrace unit testing and test driven development -- and it's happening rapidly! -- that we'll see some significant improvements in quality. And it's great for open and free software, because unit testing is something that's hard to bolt on later. But you can do it, it just requires a lot of refactoring. Because of the availability of the source, refactoring is an option for us. Because APIs for environments like Windows or Java are largely set, and the components largely opaque, they don't have this option.

Re:Maybe more automatic testing tools for GUI?

[krogoth]

I can see two simple ways to find and fix obscure crashes, which I have been considering for my app after discovering a crash that I couldn't reproduce:

1) Logging all events. When the app crashes, you can go to .xsession-errors and see exactly what happened, which may give you a hint.

2) Internal automated testing. If I have a little extra time before the next release, I'll make a function that will go through the standard actions a few hundred thousand times randomly, and then run it under valgrind; hopefully, this will help find crashes.

Since I'm writing a KDE app, I could add a dcop interface and script tests from the command line, or use automated Qt testing tools to get an even more detailed view of what's being done.

Re:Maybe more automatic testing tools for GUI?

[Anonymous Coward]

Let's go down the "event logging" path a little further. Just log ALL the "events" of the app, where an event is a system call.

Think about it. When a Linux program runs, every instruction is either (a) deterministic, or (b) a system call trap, or (c) a thread switch, or (d) a signal being delivered.

Almost everything in (a) is deterministic, except for really weird instructions that generate different results when they are run.
Everything in (b) can be captured by ptrace(2). That's just what strace(1) does.
All the hairy stuff happens in (c) and (d), and that's where some kernel side support would help.

Imagine if you could trace -any executable- and get a big-ass trace file and mail the trace file back to the original developer so they could replay it in a debugger.

Re:Maybe more automatic testing tools for GUI?

[bit01]

They may crash if you use them in an unexpected way (and since you are just randomly clicking around, it is hard to generate a bugreport).

I think test suites will help but not fix the "GUI reliability problem". The problem is that a large fraction of the programmer population have a poor or non-existent idea of what a race condition is and how to avoid it. Test suites usually don't test race conditions. Since GUI's are intrinsically one big mess of race conditions with essentially random timing injected by user events it's unsurprising that GUI's fail. There aren't many GUI programs out there that can't be crashed by moderately fast mouse or keyboard clicking. M$ windows GUI programs are particularly bad.

The fix? Better programmer training and better tools and techniques for controlling race conditions.

To those programmers of you who don't know what a race condition is, shame on you. It is core to any program with multi-processing or multiple threads, including non-preemptive threading and that's essentially all non-trivial programs these days.

I get a bit irritated by those whoe expound long and deeply about esoteric object programming philosophies while basic stuff like this still isn't being done right.

A race condition is a situation where changes in the relative timing between different threads in a program causes different behaviour (e.g. causing events to be delivered in a different order). That includes all "threads" such as the user, the network and the disk driver.

The fix is easy to understand but sometimes hard to do. For every line of code you write, ask yourself the question: What other actions could possibly happen while this line of code is executing and could they cause a problem? Simple, but not enough programmers do it.

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an intellectual property creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA rort.

Re:Maybe more automatic testing tools for GUI?

[damiam]

I am not overly familiar with O/S development, are there any similar style guidelines around?

The GNOME Human Interface Guidelines and to a somewhat lesser extent the KDE Style Guidelines fufill the same purpose as the MS and Apple guidelines.

The secret agenda?

[bjarvis354]

It seems that there are many here who are flaming any topic that relates to mainstream desktop penetration of Linux.

I thought this was the point of the GNU system? Isn't any step forward (KDE, GNOME, etc.) towards some degree of appealing to users a win for the Freedom of GNU?

Re:The secret agenda?

[Anonymous Coward]

I thought this was the point of the GNU system? Isn't any step forward (KDE, GNOME, etc.) towards some degree of appealing to users a win for the Freedom of GNU?

Not every GNU/Linux user who posts to Slashdot consider software freedom the most important thing in computing. They might prefer Open Source because it might be efficient, cheap, stable etc. Those who prefer Free Software and software freedom in general will likely agree with your point.

Basically there are those who like the OS and those who like the GNU vision of software freedom. Even though some people might like both, these are two different groups with two different goals. (Or as RMS might say: there is the Open Source movement and Free Software movement who have entirely different philosophies even when they might agree on many practical goals.)

Re:The secret agenda?

[StarTux]

Always going to have detractors to any thought of a GNU/Linux non-Windows system actually doing well on the mainstream desktop. Ask any fellow Mac user about how long they put up with this from Windows users.

We have different flavors of icecream, why not have different flavors of operating systems or computers?

Re:The secret agenda?

[Joe Tie.]

I can't speak for anyone else, but that's not my goal. My goal, or at least hope since my contributions are pretty much nil at this point, is an environment that's usable for me and people like me. I'm not a moral crusader who thinks he needs to save the world from itself.

Re:The secret agenda?

[bjarvis354]

It is indeed a interesting paradox. However, is it not important to the entirety of the GNU/Linux movement in general that the ideals OSS and GNU be reconciled?

I am not a programmer. Sure, I know some bits and parts, but in the end I am an end user who likes a powerful and flexible OS, it is awe inspiring. It has spurred me to look seriously at learning C. To me it is about learning and sharing that knowledge. While I may not be able to hack like many here, I want to extend my knowledge of programming and be able to shape the software to suit my needs. Only the fusion of Open Source Software and Free Software, together, provides that opportunity.

The funny thing is that while I don't like the flame wars, given the other options (proprietary closed source software) all of this would be moot. You take what you are given and you like it, no discussion.

Re:The secret agenda?

[Anonymous Coward]

We had alot of computers and OS's in the '80's. Software compatibility problems were rampant. You were never sure if your computer was compatible enough (eg, could a 98% IBM compatible Tandy PC run this software?)

DebSux-Dallas.

[Anonymous Coward]

"It's easy to sit around and say something sucks"

Especially if you work in the porn industry.

"but to defend that reason and offer insight into why something else is better takes a little more."

Demonstrations are always welcome.

Re:DebSux

[cyberkahn]

"So what should replace it?"

Fedora... open source like Debian. Up to date and with the times.
I could make a long list, but it would be redundant.

"Why is it the worst?"

Debian exchanges stability for usability. No one wants to spend days installing and setting up a box (upgrading the distro to where it should be) just to get up and running on Linux.

"It's easy to sit around and say something sucks"

No it isn't because anyone who disaggrees with the pro-Debian mafia on Slashdot gets slammed as a flamebait or troll. Talk about being biased.

Tangent....
I remember Taco use to be a Suse fan. What are you using today Taco? Are you a Debian zealot now too?

Great...

[Rodrin]

Looks like even more work for linux-a-la-desktop is on the way. Sure makes for an interesting future for linux in the average user home.

oops...

[justMichael]

OK, so I went to RTFA.

Please mod my former post into the gutter, I will pick it up in the morning.

Damnit, this should be a lesson to you all, don't base your opinions on what get's posted on /. :-)

Re:oops...

[An Onerous Coward]

Congratulations. I've never seen a (-1, Interesting) before. /me goes to RTFA.

Re:oops...

[justMichael]

I'm not sure what's more entertaining, the fact that I got (-1 Interesting) or the fact that I'm not sure how to explain the math behind that ;-)

Of course then again there is the fact that the post I made after that stating that I made a stupid post and to mod the parent into hell was modded as troll...

I kinda hope that the parent stays (-1 Interesting) I'll have to save it for my scrap book. Like it matters, that and a dime will get you nothing.

Re:slips into asbestos suit...

[stealth.c]

What it sounds like is streamlining the kernel to make it faster, and give it a better capacity for making the UI experience grandma-ready.

If there are improvements that can be made to the kernel that also make it easier for people to improve the UI, I'm all for it.

That was my impression...time to go RTFA, myself. ;)

One good reason to like open-source software

[Anonymous Coward]

When someone announces they will be working on a project -- low latency optimization, for example -- you can pretty well tell that they are *actually* working on it because the code is released and you can look at it. It might have mistakes, crash a lot, or be missing features, but another developer can build on it if the original coder leaves the project because of other commitments or just out of boredom.

On the other hand, with proprietary code you are never quite sure where you stand. The company holding the source can claim they are spending the next month concentrating their resources on security issues, and if the program appears to be as insecure and bug-ridden as before you aren't sure if the developers took a month-long cruise to the Bahamas and blew it off or if they are actually inept at security. If you depend on that program for your own product, you can't even fix the problems you encounter if the developer decides to ignore or even kill the product because the source code is secret. And for those that have a paranoid bent, it's entirely possible for certain companies to sow FUD by claiming to be working on some incredibly desirable improvement they have no intention of delivering, or to leave hidden programming hooks which allow only certain products to use it.

Too bad our founding fathers could not have forseen the entire source code/copyright issue. I would like to think they would have required complete specificity with regards to programs -- if you wanted to copyright a program, you would have to show exactly how it was created using industry-standard tools. It would not only prevent monopolistic power in one programming area (*cough* operating systems *cough*) from extending to another, but it would be one heck of a lot easier to prove copyright *infringement* because the source code from various products could be compared.

Re:One good reason to like open-source software

[BitchKapoor]

(1) Only allowing copyright on the source code, but not the compiled binaries, and (2) striking down and in fact outlawing the ability to give up certain rights through click-through/shrink-wrap "licenses" might have a similar effect. Is there any kind of restriction on processed works in other areas similar to (1)? How about (2)?

Re:One good reason to like open-source software

[Lord Bitman]

I would like to know what problems would come about an absolute requirement of including source-code (or at least making available source-code) with any compiled binary product.
If source-code were required 100% of the time, you couldn't "steal" code and then hide behind your binaries- wouldnt everyone (even Microsoft) stand to benifit from that?
It couldnt be a hard-and-fast rule, obviously. Certain encryption and DRM sections of code would still need to be locked..

This isnt a troll or anything, I'd just like to know what people think of it. Why not open source everything?

Re:One good reason to like open-source software

[Bishop]

Certain encryption and DRM sections of code would still need to be locked.

The phrase "security through obscurity" was coined specifically for the practice of hideing cryptographic algorithms. As has been shown, trying to hide crypto code does not work.

In my utopia world all code would be available. It is not going to happen though. Most companies are incapable of understanding how it is possible to show the code and make a profit.

Re:One good reason to like open-source software

[Anonymous Coward]

To answer this question, you have to ask yourself how hiding the source can give a competitive advantage:

1. You can leverage the popularity of a program in one field to move into another area where you are not as competitive. Say you have a pretty good tax program and a so-so bookkeeping program. Allow the two programs to interact with the same data set, come up with a catchy name like "SlickBooks" and you'll get people to buy it because it has a longer feature list than it's competitors. If the code is hidden, it's hard to create a competing program that interacts as well.

2. You can go one step farther, and completely integrate products, effectively locking competitors out of the market. Say you have a popular operating system and are deathly afraid that an internet browser will somehow affect your monopoly. Come up with a browser, build it into the OS, and make sure it's harder to remove than it would be to repair a warp core manifold. Problem disappears.

3. You want to force people to upgrade their product every couple of years. Hide the source code, cobble together a few improvements, make your other programs so they only work with the upgrade, and rake in the money. If the code was open, others could create desirable updates and you wouldn't be locked in to a particular developer, which tends to be bad for certain companies. People tend to be less understanding when they hear that you are paying full price for a new program when there is a 5% difference in code from the old version.

4. You want to protect your intellectual property, and you are afraid that the copy protection you spent so much time developing will be ineffective.

On the other hand, opening the source would tend to benefit consumers. For example:

1. Company A decides to bundle a pretty good tax with a mediocre bookkeeping software. Company B makes a darned good bookkeeping program and nothing else. Seeing the source code for the tax program would allow it to interoperate with it. You can get the combo plate from company A, or go a la carte with the programs you want and still be assured that they are well-integrated.

2. Company A decides to merge a popular OS with a so-so browser. Company B can see the source, create a removal tool for the offending code and a link to the OS the same way with their browser. Company B stays in business and is not swallowed by company C.

3. Company A tries to force people to upgrade to their new program. Company B creates their own, much cheaper program to upgrade the features you want. Customer saves money.

4. Customer can see source code, so security through obscurity will not work. This is not as bad as it might seem, because any person technically savvy enough to compile a major program is probably smart enough to find a crack for a closed-source program. You aren't going to seen many teens burning the latest source code and passing it around, those who like to wear eyepatches and shout "Avast, ye scurvy dogs!" will still copy the executable program like they do now.

In addition, there are a several more benefits to forcing open source.

1. Companies can't hide their program's failings by compiling. This includes security failings.

2. Others can learn from and improve on the code. We might need to revamp fair-use laws, but elegant code would probably inspire programmers as much as elegant phrasing inspires writers, and with appropriate legal safeguards we can continue to study, use, and improve those algorithms

3. Customers can be assured the program they are using will have an existence independent of the company they bought it from -- they don't lose time, money, and data just because the originator of the code disappears.

There are other reasons, but this is long and probably of limited interest to others. Feel free to add to or argue with any of the points.

Re:One good reason to like open-source software

[Anonymous Coward]

Yeah, programs are probably one of the only copyrighted items which can't be understood in their distributed format. Music can be listened to and edited, videos can be watched and clipped, and books are accessible to anyone with an eyeball, a brain, and some free time, but a program is essentially a chunk of opaque binary data, which is completely incomprehensible without the source code. Meanwhile, with patents, we have machines which are in a mechanical form which is also completely incomprehensible, but then we have a requirement that the design be published in a manner which any reasonably skilled person can understand.

This just points out the glaring flaw of software copyrights. Binary code doesn't add anything to the general pool of human knowledge; only the source code is of intellectual value. The binary representation of software is like the physical representation of a blueprint. If the source code of a program is lost, the program, as a intellectual work, also becomes lost. To use an analogy, it'd be as if books read themselves, and everybody was illiterate. Once the books break down, the information contained in the books become lost. This calls into question the whole point of using copyrights to encourage and reward authors of software, since the authors of proprietary software aren't actually providing anything of value to the public except a machine (and we obviously don't give our cars copyright protection, even if the blueprints for a car does).

To raise the DRM issue, DRM is making traditional copyrighted media more like software (can only be used, can't be reused), rather than having software become more like books and tapes.

Re:One good reason to like open-source software

[Tim C]

a program is essentially a chunk of opaque binary data, which is completely incomprehensible without the source code

Tell that to all the people who release cracks and modifications to binary-only code. (Go take a look at gamecopyworld if you don't believe me, or just consider Kazaa++ vs Kazaa)

Not having the source makes it harder, but it doesn't make modification impossible. That's why so many EULAs have clauses forbidding decompilation and reverse-engineering.

Re:One good reason to like open-source software

[Tim C]

Damn, missed a bit.

and we obviously don't give our cars copyright protection, even if the blueprints for a car does

That's because a car, by its very nature, is extremely difficult to reproduce. I can't just shove it in another machine, hit "copy" and sit back and wait. Trust me, if/when it becomes that easy, you'll see every manufacturer in the world screaming for the same protections.

To reproduce software, on the other hand, doesn't require the blueprints, tons of raw materials and a suitably equipped factory, or even the source code. It just takes the install media and a PC.

Re:One good reason to like open-source software

[Lord Bitman]

Algorhithm and code are not the same things-
at some point, somewhere, in your code, the key must either be stored or told where to be stored.

Re:One good reason to like open-source software

[Lord Bitman]

Why the AC? :/

The things about leveraging popularity are understood, but I dont quite see the point about "Company B Developes cheaper version with the same features"
Company B can't copy the code word-for-word, they'd need to develop their own methods of doing things. So for copying features, they'd be in the same place, wouldnt they?

Re:One good reason to like open-source software

[damiam]

So? If you're storing a cryto key in your actual code, you've got some serious problems. It's perfectly possible to write a completely open-source crypto program - look at GPG or OpenSSL.

Re:One good reason to like open-source software

[Lord Bitman]

I have no idea what you're trying to get at-
You require complete access to a key in order to decrypt something. Have you devised some DRM scheme which allows people to have complete access to keys, yet won't allow them to transfer those keys?

Re:One good reason to like open-source software

[damiam]

You said that "encryption and DRM sections of code would still need to be locked". That's bullshit. Encryption products can be made entirely open-source without compromising security, as GPG and OpenSSL. Those programs are typically not distributed with keys, because the user generates their own.

DRM products are a different story. Obviously, if a program can decrypt a file to play it, then a modified version of that program can dump the decrypted version to disk. That doesn't really matter though, because the kind of people stupid enough to insist on DRM would never consider open-source anyway.

Re:One good reason to like open-source software

[Bishop]

This is one of the reasons why DRM can't be secure.

Re:One good reason to like open-source software

[Lord Bitman]

Holy crap, it's like DRM uses encryption or something and you just don't get it. But that couldnt be, right?
And you say "would never consider", as if you didnt read the original post at all.. but that certainly wouldnt be the case!

Re:DebSux

[Anonymous Coward]

It's easy to sit around and say something sucks

It's sucks because it's old and not as stable as the zealots claim.

It's like the "Big Lie" propoganda technique used by the Nazis. Just say a lie long enough and it will become true. The zealots just keep saying Debian is more stable and secure, offering no proof at all, but for some reason gullible people still accept these claims uncritically.

Debian blows. Get away from the Cult Of Debian for a couple days and realize what the rest of the world is like. Newsflah: Debian ain't that great any more. Maybe in like 1999 Debian was pretty cool, but the year 2004 is coming up and the Linux community has progressed. Well accept for the Cult Of Debian, which lives in a bizarro-world. Like the people of North Korea who are brainwashed into thinking North Korea is the greatest most asvanced nation on Earth, so are the pathetic Debian zealots, they think they have the greatest distro and everything else sucks. Sorry, fella, it ain't so. At least the North Koreans don't have a choice, but you are being a brainwashed cultist by choice!

If you look at it comparatively Debian community and Church of Scientology are pretty similiar in fundamental structure.

Answer to WinFS

[lawpoop]

This is something we really need if we are interested in getting users to convert to linux. Currently, linux apps put their crap all over the place. If we had true virtual directories* with drag&drop installation of applications, linux would be second to Mac for ease of installation and un-installation.

Plus, if the filesystem is truly a relational db, then it can emulate and distro's directory tree for legacy applications that need it.

*Not symlinks

Re:Answer to WinFS

[Josh Booth]

I don't agree. While virtual directories are cool, how many files actually have that much metadata? Many audio files, some MPEG, and many office suite files (OOo, MS Word). Many other formats do, but it is inconsistant or is some useless (and inconsistant) comment, like "Created by the GIMP". Other than that, with virtual directories, you are adding massive overhead that could easily be avoided by even half-assed file organization and using a good file manager.

Re:Answer to WinFS

[lawpoop]

It's not only the metadata, but the unification of virtual directories that gives the benefit.

For any application or service you might have on your linux box, it probably has files in /bin, /usr/sbin, /usr/local/sbin, /usr/local, /etc, etc. etc. With virtual directories, you could have a setup like :
/applications/$application/bin
/applications/$application/conf
/applications/$application/conf/$user
/applications/$application/init
And then to get rid of an application, just rm -rf /application/$application. No hunting around for all the places the app put its parts! I realize this problem is already addressed by rpms and debs. But still, this crufty old hierarchical file system is in need of updating.

About the file organization -- most distros don't half-ass it; they have a rather good organization. The problem is that they're all different.

Re:Answer to WinFS

[timeOday]

My objection to "an answer to WinFS" is a bit different; I just think it's ill-conceived for a single developer to take on such a task as a side job. It takes years to develop a real filesystem. Maybe ReiserFS, with its new plug-in mechanism, should be the foundation? I don't know, I really don't see a great need for a radically different filesystem anyhow.

Re:Answer to WinFS

[Anonymous Coward]

Wait, I remember back in the DOS days, software used to install itself all in the same directory. We've come full effing circle!!!

Re:Answer to WinFS

[lawpoop]

Well, it's not really for you, it's for newbies/converts. Plus, once it's up and running right, you'll like it. ;)

Re:Answer to WinFS

[damiam]

With virtual directories, you could have a setup like :
/applications/$application/bin
/applications/$application/conf
/applications/$application/conf/$user
/applications/$application/init
And then to get rid of an application, just rm -rf /application/$application.

As I see it, there are two ways to do it. You can put binaries together in one location and keep a database of the other files in the app (what dpkg/rpm do now), or you can put all app files together in one location and keep a database of where all the different binaries are (what you're proposing). Aside from installation (and is drag-and-drop really that much easier than 'dpkg -i' or the graphical equivilant?), I don't see much benefit to switching from the current system.

Re:Answer to WinFS

[Keeper]

The point of WinFS isn't that the file formats have metadata associated with them, rather you can assign whatever metadata you want with any random file, and then organize those files based on the metadata.

The whole point of such a system is not to force the user to conceive and manually maintain a file structure. And once you create that file structure, you are limited to dealing with the data it contains by that file structure.

Sure, it may have seemed like a brilliant idea 18 hours ago when you decided to re-organize your mp3's into folders by artist, then album, and then song. Until you come across a song with two artists in it. Or when you want to look for a specific album but don't remember who sang it.

The point is that manually organizing your files is a cludge to do what you really want to do: be able to find what you're looking for quickly. Since it is a manual process, it is slow, error prone, and a royal pain in the ass.

Re:Answer to WinFS

[lawpoop]

It seems what you're talking about is our regular old hierarchical filesystem with a rdbms keeping track of locations. The idea of the dbfs is that it totally replaces a hierarchical filesystem. The user would never see a tree or a hierarchy. The rdbms decides where on the disk to put data. It then presents the data to the user in a way that closely mirrors the relationship of the data. The only reason we still use the hierarchical filesystem is pure cruft.

Re:Answer to WinFS

[rnd()]

The directory structure containing a file is often used as metadata (used in a meaningful way other than simply as a container)... this is just a less-than-ideal way to store metadata since it's fairly brittle and often completely arbitrary.

Re:Answer to WinFS

[Anonymous Coward]

Currently, linux apps put their crap all over the place.

hmm last time i checked....

./configure --help | grep prefix
--prefix=PREFIX install architecture-independent files in PREFIX
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX

seems like it was a choice made by whoever compiled or packaged you particular "linux app".

Not to pick on you but you did raise some interesting points. In the current incarnation of "linux" that we know, how would one designate the difference between a "virtual" folder and a "real' folder? How does one properly report the "size" of a virutal folder? Would a virutal folder then be readonly? Do virutal folders really make organization any easier? You (or someone else) still needs to enter/verify the meta-data (im imagining music files at the moment). How useful is it to create a new virutal folder for "Artists", browse throught the artists and then select an mp3, then it is to just type "j" in xmms and start typing the name in question.

Re:Answer to WinFS

[damiam]

I wasn't talking about using an rdbms at all. I was talking about two different ways to organize a traditional hierarchical system, both of which require a "database" in the loosest sense of the term (i.e. could easily be a flat text file).

A RDBMS for storing user data is nice, but do you want your /sbin or even /usr/bin stored in an RDBMS? Even with a true database-based system, there has to be a decent way to organize binaries outside of the database.

Re:Answer to WinFS

[Anonymous Coward]

This is nothing new.assign c: DH2:blah/blah add
assign libs: DH2:blah/blah add

etc.

Guess what... this has been around since, what, 1983-5?

Re:Answer to WinFS

[pherthyl]

How does the system know where the binaries are if you put them in application specific directories? This is one of my huge gripes with windows, you can't just type a program name in the run dialog and expect it to open (unless you add each and every program directory to your path).
I love the fact that I can run any program just by typing it's name. Usually faster than hunting for it in a menu. And its great to have all configuration in /etc Then I can back it up in one fell swoop. Having it all scattered would blow goats. Having to go to 8 different directories to change configuration files.

Re:Answer to WinFS

[RdsArts]

Drag and drop install?

Already got it.

Re:Answer to WinFS

[gen2003]

There is already such thing . it's called stow its like every file and dicrectory in my /usr/bin directory is a symlink or contains symlinks to /stow/app/ more info:
http://www.gnu.org/software/stow/stow.html

Re:Answer to WinFS

[firewrought]

Mod parent up.

Most people criticize the unix file system w/o realizing that a lot of thought has been put into its design.

Re:Answer to WinFS

[warkda rrior]

If you build it...

The point is that if the functionality is made available to end-users through a decent interface (GUI and/or CLI), then a lot more programs will improve their handling of file formats to add metadata. Once the users get the taste of it, there will be no end to the new metadata associated with each file.

Re:Answer to WinFS

[eraserewind]

I think the point is that you would install your virtual "application directories" in say /usr/local/bin, and the system would be smart enough (through the use of metadata, or location conventions or whatever) that even though at the fundamental level there are just direcories in this location, it would see that /usr/local/bin/coolapp/ contains an executable /usr/local/bin/coolapp/bin/coolapp.exe, and execute that when you typed "coolapp". Similarly for the help system, and so on.

Re:Answer to WinFS

[cscx]

This is how Win32 apps on Windows work. Notice that you can go to Start -> Run and just type in an application's name (e.g., winword) and it will load right up, without it being in the system path? This is where an overlooked but heavily used function of the Registry comes in. When a Win32 app is installed properly, it becomes "registered" with the system. Henceforth, Windows is simply aware of its presence, even if it's located in d:\programs\foo program\bin\foo.exe.

I'm certain Linux can come up with some sort of Registy-like application awareness system, perhaps using XML?

Re:Answer to WinFS

[cscx]

I wonder then, how Apple could have completely bastardized the FHS in OS X, yet people still consider it "UNIX"...?

Re:Answer to WinFS

[Mr Smidge]

Would it be such a bad idea to arrange applications as the grandparent suggested, in a logical hierarchy, and also have a suitable array of symlinks in /bin and /etc, and so on.

As in:
/etc/$app -> /applications/$app/conf
/bin/$app/$appexec -> /applications/$app/bin/$appexec

That way, we get the best of both worlds, having a logical arrangement of applications, while still having every binary/config in a global directory.

But I'm no wizard, so is there anything wrong with this idea?

Re:Answer to WinFS

[Anonymous Coward]

Ever looked at system V init on say.. solaris or redhat linux? it will show what a mess you can make with symlinks.. no, this is not the way to go.

metadata on files.. this has been tried before, and it can work.. OS/2 basicly did this 8+ years ago.

it doesn't need a radically different filesystem tho, it needs space in the filesystem to associate the metatdata and the files...

in OS/2 peopel seldom got beyond using it for attaching some comments to files, but even that made searching for specific information a lot easier.

Bottomline, how you organize data on the filesystem, and how you present it to the user are 2 different things, and alltho they often are similar, they don't have to be.

Re:Answer to WinFS

[Anonymous Coward]

You are talking about hard links. I have always organised my mp3s that way.

Windows OS file systems dissed the concept of inodes. That's why you have the overly strict file locking, needed reboots on non-kernel upgrades and why they store metadata in rdbms'.

Re:Answer to WinFS

[Anonymous Coward]

> Notice that you can go to Start -> Run and just type in an application's name (e.g., winword) and it will load right up, without it being in the system path?

I assume that's a special Start Menu hack, because it doesn't work from CMD.EXE or anywhere else that I know of.

It's also unclear if it's really looking in the registry or just caching the shortcut information.

Re:Answer to WinFS

[cscx]

CMD.EXE is just a command shell and won't hook into the registration info unless you tell it. Instead of "winword", at the cmd.exe prompt, type "start winword"

start.exe will hook into the subsystem...

Re:Answer to WinFS

[Slack3r78]

As I understand it, what the original poster is proposing would be a layer of virtual directories on top of the hierarchial file system we have now. You'd still have things physically organized into /usr/bin, /etc, /whatever, but then also linking all the files related to a program to an /applications/$APP directory.

So really, you'd be getting the best of both worlds. You'd have everything related to Application X all stored in one place making dealing with it as an individual application far easier, but you'd still have the old filesystem where all your config files, binaries, etc are grouped together as well. Sounds like a rather good idea to me.

Re:Answer to WinFS

[calica]

Or you could just use GoboLinux It stores packages in /Programs/Foo/1.0/ bin sbin lib And so on. There is a set of scripts for managing a /System/Links/* heirarchy and a legacy heirarchy.

Re:Answer to WinFS

[calica]

I have this right now using GoboLinux using symlinks. Works extremely well.

Re:Answer to WinFS

[glitchvern]

I see stow has already been mentioned. You might also want to check out the various Encap variants and also gobolinux

Re:Answer to WinFS

[Hatta]

I for one would love to be able to find the phish show where fishman's mom plays the electrolux just by asking for it.

Re:Answer to WinFS

[Slack3r78]

Interesting, though from a quick read through of their FAQ, it seems that GoboLinux is taking the opposite appoach - programs are stored physically as an individual programs, then symlinked to the old hierarchy as a sort of hack to keep backwards compatibility. Personally, I feel the orignal poster's suggestion of program directories as virtual directories would end up being a more flexible solution in the long run, but it is cool to see that the idea's being worked on in one way or another. Their rootless install also sounds like a rather intriguing project. I'll have to do some more reading about these guys.

Re:Answer to WinFS

[leandrod]

> A RDBMS for storing user data is nice, but do you want your /sbin or even /usr/bin stored in an RDBMS?

Why not? Provided the RDBMS is the primary storage component in the database. Speaking of that, not only storage: memory could also be organized in a relational manner.

In the end we'd have a situation similar to Lisp hackers' relationship with Emacs: the RDBMS is my OS, [Linux|Hurd|BSD|whatever] is my microkernel. Nicest of all is that we could even have a relational, functional ([Lisp|Scheme|ML|whatever]) language in the same level occupied by C and libc in POSIX.

> Even with a true database-based system, there has to be a decent way to organize binaries outside of the database.

A relational system would be able to efficiently give any file any number of locations in any number of hierarchical namespaces you choose to.

Just remember SQL is enough, SQL not being relational.

Re:Answer to WinFS

[sagei]

My objection to "an answer to WinFS" is a bit different; I just think it's ill-conceived for a single developer to take on such a task as a side job. It takes years to develop a real filesystem. Maybe ReiserFS, with its new plug-in mechanism, should be the foundation? I don't know, I really don't see a great need for a radically different filesystem anyhow.

Two points.

First, I actually do not intend to work on WinFS, at least right now. In the interview, the items under "other things are important", those are items I feel are important but am not planning on working on right now.

Second, WinFS is not actually a different filesystem. It is a database built on top of NTFS (I think it can work on top of raw Yukon partitions, too). There are no filesystem changes. Or, at least, there need not be.

Re:DebSux

[cyberkahn]

Someone should mod this up. The best post in this thread.

Desktop is good, but falls a little short for me

[wackybrit]

This is a bit of a ramble, and not necessarily meant to be modded up :-)

I'm an advocate for Linux in many situations. I've bugged everyone to hell since about 1997 to use it in server applications (not much of a BSD guy). I think it works great in masquerading situations. For quite some time I've felt that no Windows machine should be allowed directly onto the Internet, and that a non-Windows machine should masquerade traffic onto the net. I also think Linux is a far superior development environment to any other. That said, I still use a Windows desktop.. why?

For me the Linux desktop (or X with KDE or GNOME, as we're talking here) lacks a dock application. It also can't run everything I want without any hassles.. whereas I can just use VMWare/Virtual PC on Windows. Running Simcity 4 in VMWare under Linux, however, is not a great option ;-)

As a developer, the Linux desktop also seems pretty scary. You've got KDE and you've got GNOME.. and the applications from the system you're not using can end up looking like ass. Of course, it's a lot better than developing for Windows, but we need more integration, and I'm glad OpenDesktop is trying to do this, and that GNOME and KDE are trying to work together.

Also, I find Redhat 9 to be deadly slow on the desktop. SuSE 8 has proven to be much better (a KDE vs GNOME here?).. but I'm waiting for Fedora Core 2 (with the 2.6.0 kernel) until I make my next foray into trying Linux as a desktop OS. (I continue to use SuSE 8 via emulation for development purposes)

But make no bones about it. Linux is using the right methods. Windows is not. Linux might still be behind Windows and OS X in many areas, but they have a far better foundation, and I'm confident the Linux desktop will prevail. And.. I can't wait.

usable drop shadows

[Doc Ruby]

I like widget drop shadows with hard edges. That lets my eye automatically simulate the Z offset of the widget from its underlying surface, because the widget and shadow have identical silhouettes. When the shadow is blurred, it's just cosmetic; when it's edged, it helps me keep the widgets organized.

Re:usable drop shadows

[BiggerIsBetter]

Too bad about the freedesktop shadows then. Hard edges abound, but the screenshots shown don't render shadows with layered windows correctly. Eg, the shadow dropping onto a lower layer window isn't thinner than the shadow dropping all the way to the desktop.

Re:usable drop shadows

[Doc Ruby]

Well, it's open source. And the current version, with hard edges (unrealistic as they are), is available. So we can revise the release in favor of hard edges. And add the shadow projection code from some open source 3D package. I'd love to have a "thumbdial" widget on the desktop that would scale the spacing of the cast shadows to get the best separations/scaling for the sense of depth. And some widget for placing the lightsource apparently casting the shadows.

Re:DebSux

[shaitand]

Hell I'll do it. Debian has precisely ONE thing going for it. A good package management system, and that package management system has been ported to run on top of RPM, thus eliminating the only good reason to use debian that's left.

Redhat or a redhat based distribution has two good features. It's solid and easy, pretty much any task is at least 90% of the way configured how you want it out of the box and ready to go for most people.

And of course hardware detection, the redhat installer is great and all (despite assuming anyone who is formatting in fat would want something other than fat32 and not even offering said filesystem in the installer) but the real bonus of course is the hardware detection, which surpasses all but MacOS (yes that includes windows, granted windows supports more devices, but not as many out of the box, if you insert a driver disc that's NOT out of the box, the ones windows does detect out of the box do NOT generally configure as smoothly as with anaconda).

When I apt-get install squid on redhat, it installs squid and deps, squid is already in a functional configuration and just works. At that point of course I can change any aspect of the configuration I like. When I install a debian deb, I then have to configure squid, PERIOD.

90% of the prebuilt packages out there that are NOT in apt repositories (things pretty much anyone will run into a time or two) are rpm's with no deb's available. So the redhat system provides a better handle here too.

Now moving past hardware detection and package management. There is the matter of the rest of the installation. A text based installer is great and needed often (due to any distro's apparent lack of ability to make a generic x configuration which actually boots some lowest common denominiator gui on 99.99999% of video+monitor combinations like windows somehow manages to do, this can be done with X I know, because I've done it) and network installs. Redhat however has a text based installer as well that rivals debians (surpasses it if you refer back to hardware detection) AND has a graphical installer for those who don't actually feel they should have to read the screen because they perform numerous installs on varied hardware.

Next you have the gui, redhat and debian have gone to fly a kite on this one. Although redhat is obviously closer with bluecurve. The first thing needed of course is a network neighborhood type thingy that does NOT try to integrate ftp and everything else on god's green earth. A simple samba configurator that DOES NOT reflect the options in the samba conf files and instead simply asks if the system is part of a workgroup or a domain, the computer name and the user name and password to use for windows networking. Then throw in an advanced button. When windows network ing support is chosen in the install then items should be added to the menu's to support sharing printers by right clicking, the same with folders.

The options for user and password security should be available in the sharing window for an object as well as the ability to let anyone use it, phrased that way, not as guest.

When you right click on the desktop there should be an option to create new text documents, folders, and the ability to create shortcuts needs to be more cleanly implemented. Create symlink should be in a seperate submenu under advanced, create shortcut should actually create a clickable shortcut on the desktop and try to create a short shell script and shortcut to cli executables.

Copy and paste needs fixed. An standard co developed effort needs undertaken to develop something equivelent to install shield wizard. The distribution should not accept any software which does not include not only a binary package but an installer which finishes with said application or game in a FUNCTIONING state. In the cases of critical must have applications this could mean writing the installer, but for most should just mean providing libs we suited for this that the project can depen

Ease of use requires more than a good FS

[g_bit]

Granted, this would be a step in the right direction. However, ease of use requires "developers, developers, developers" and the right tools for developers.

Linux is coming along, but until there's something as easy to use as Visual Studio for Linux, I don't see it edging past Windows in the desktop arena.

Borland gave it a shot with Kylix, but we all saw what happened with that. Nobody wanted it because it wasn't free.

Re:Ease of use requires more than a good FS

[Joe Tie.]

Borland gave it a shot with Kylix, but we all saw what happened with that. Nobody wanted it because it wasn't free.

I don't think it was so much that it wasn't free, but that it wasn't better than what was available at the time for free. I bought the personal edition of delphi when I was using Windows, and was quite prepared to buy Kylix if I felt it was worth it. I just didn't think it was though. Firstly, the look and feel. This was about the time that unified kde/gtk themes were making an appearence, things were finally starting to get some uniformity in look! But everything I made in Kylix would not only take yet another look, but one that I felt was ugly. Though that was my biggest annnoyence, I had enough that there was little chance I'd spend any money on it, let alone what they were asking.

Re:Ease of use requires more than a good FS

[Anonymous Coward]

Kylix was ported with wine, looks like a Windows program, and was quite slow and unstable.

Re:DebSux

[Fancia]

As a Debian user fairly new to Linux, I find that Debian a) is stable, b) runs all the software I've tried (except that which has issues with my PowerPC procsesor) and c) is the easiest to install software for. I may not be a highly technical user, but for everything I've tried to do, Debian far from "sucks."

Interview summary

[An Anonymous Hero]

1. OSNews: (100 words)?

R. Love: HAL

2. OSNews: (99 words +) BeOS?

R. Love (diplomatic): Yes and no.

3. OSNews: (600 words)?

R. Love: No.

4. OSNews: (20 words)?

R. Love: HAL.

5. OSNews: (19 words +) HAL?

R. Love: Yes, HAL.

6. OSNews: (600 words)?

R. Love: Dunno what you're talking about.

7. OSNews: (100 words)?

R. Love: No.

HAL

[KoolDude]

This means things like udev and HAL are a reality in 2.6.

Hurry up HAL, you're already 2 years late for your space odyssey.

Re:HAL

[7-Vodka]

yeah well...
We saw the movie and decided it was best to go without him.

Re:Desktop is good, but falls a little short for m

[shaitand]

I don't think the question is really whether or not linux is the superior solution or whether or not it has the potential to swarm this area of computing as it has every other.

I think the issue is really about whether or not it can do it fast enough. Not just because windows is already entrenched and uprooting it is harder than it would be to beat it in even competition. But because When the next release of windows comes out with it's DRM and included bios and the boards stop having them, all the sudden you can't run linux anymore and then linux is dead. on the server and embedded side there will always be reasonable options for this I'm sure. But on the desktop?

subclasses = versions

[Doc Ruby]

"Derived objects", subclasses, are new versions of the subclass. Not only do subclasses allow the code factoring to a shared base functional class, they reflect the iterative development of new functionality. That includes not only added functions and revised overridden functions, but also deprecation of functionality by overriding with null methods, without breaking the API. Subclassing allows an object of an old class to call an object of a new, revised class, using the same API, getting the current functionality. It brings the main benefit of OO, calling an API without dependency on implementation details, to versioning.

Subclassing with multi-inheritance allows new classes with combined behavior of old ones, without necessarily writing any new code. Old objects can call the new objects by their old class APIs, successfully ignoring the extra APIs. GUIs are the code with which the user directly interacts; to most unsophisticated users, the GUI *is* the application - out of sight: out of mind. So as not to require users to retrain when they get new functionality or switch apps (back and forth), GUI design and execution requires tremendous discipline. Subclassing reflects disciplined versioning, and is all too often disregarded, at the peril of the application's fate.

Re:subclasses = versions

[BitchKapoor]

Subclassing allows an object of an old class to call an object of a new, revised class, using the same API, getting the current functionality.

Ok, that's fine, but in this case the parent class doesn't have to contain any code, i.e. it can just be an interface. I think that meshes with what I said earlier.

Subclassing with multi-inheritance allows new classes with combined behavior of old ones, without necessarily writing any new code.

Is this necessarily a good thing, considering that interfacing two separately-designed objects, especially those which use the same resource, i.e. a particular window on the screen, almost always requires some consideratin? And in that case, how is multiple inheritance any better than creating an object containing the two other objects? In my experience, multiple inheritance is most used to patch over a lacking type system.

Subclassing reflects disciplined versioning, and is all too often disregarded, at the peril of the application's fate.

That is certainly a valid point, and versioning systems would do well to take into accoutn semantic information.

Re:subclasses = versions

[BitchKapoor]

I'd just like to note that I'm not arguing against subclasses, rather I'm arguing for other things which I think are also valuable by pretending we don't have some of the things we do (like subclasses).

Re:subclasses = versions

[Doc Ruby]

Some people would say that interfaces are code, just minimal. It's hard for me to say that (although I believe it), in light of my comment about multi-inherited classes not requiring new code :). What I'm getting at is the ability of subclassing techniques to offer a programmer maximum code reuse with minimal production, with all the productivity benefits (at that version, and rippling into future versions). Another nuance: not writing any new code does not equal no new design; in fact, production of design and code are usually inversely proportional, with a great scaling factor in favor of design (after some overhead).

Encapsulation vs. subclassing is a design decision dependent on the phenomenae being modelled. Often the container class is extra overhead which doesn't reflect the real thing. Often the container class offers efficiency to the model. Even in nature, sometimes cells gain organelles, and sometimes cells gain new protein codons. It depends on the most economical options at development time of the iteration in question. Starting from scratch, especially with (visible) GUIs, I'd start with encapsulation reflecting only the physical structure of the metaphorical visual interface, and inheritance reflecting only code factoring. Then I'd look at the constraints of the event passing hierarchies. Any leftover gaps in message passing would be resolved in terms of the requirements and features of the design thus far. If filling those gaps required leaps of code disproportionate to their functional roles, or at odds with the approaches of the already specified design, or maintenance costs disproportionate to their benefit, I'd rework the design with which they interoperate in favor of simplicity.

I too would love to see versioning systems which included language semantics in their version semantics. But I've been trying to get someone to work with me on "DBFS", a SQL database with a filesystem interface, for years, mainly so I can program metadata relations among my data that recognize that their relations' complexity is greater than a hierarchical tree. Proper version expression and version control each have a long way to go before they even meet on the road in the wilderness, let alone join forces.

Stay away from the X server

[drix]

Who on earth would want to use their new X server? It's full of bugs! (Ark ark ark).

Couldn't resist. :)

Re:./ - Cheap publicity for OSnews.com

[Anonymous Coward]

Probably because of idiots like you. Everyone is sending links to their articles to similar publications, it is not an unethical thing to do, it is just business.

Re:Michael is a horrible editor who should be fire

[Anonymous Coward]

No, he is referring to the editor's comments after the submitted text and the deptartment line.

Slashdot is not a blog. It is a news website that should adhere to much higher standards of journalistic integrity.

GUI eventlog?

[Doc Ruby]

Is there an event logger for Linux? I'd love to install a Debian package that would capture all my GUI events to a log, for editing and replaying. Sure, it would make testing/debugging GUIs a lot easier (and more distributed). But it would also make me a lot more productive, by painstakingly getting certain proceeses right, and canning them for playback later. Lots of unsophisticated users would benefit from this, making them programmers. GNOME looks a lot like a Mac style desktop; why not a 21st century version of AppleEvents, with language bindings for bash, Perl, Ruby, whatever?

Re:GUI eventlog?

[BitchKapoor]

Hmm, this should be possible using XChangeWindowAttributes and possibly some grabs to listen for events on windows created by other applications. How would another application detect creation of new windows (other than the window manager for toplevels)? I think that's just part of the issue of detecting and logging "events" created in the X server by the clients, e.g. a request to draw a line doesn't create an event in a client, but you could say it does in the server. An X11 proxy might be possible, but that could make the GUI less reliable and slower, and overall seems like a hack.

"Multiple clients can select input on the same window. Their event masks are maintained separately. When an event is generated, it is reported to all interested clients. However, only one client at a time can select for SubstructureRedirectMask, ResizeRedirectMask, and ButtonPressMask. If a client attempts to select any of these event masks and some other client has already selected one, a BadAccess error results. There is only one do-not-propagate-mask for a window, not one per client."

Re:GUI eventlog?

[BitchKapoor]

Never mind. XTRAP --> XTEST, Android (as mentioned elsewhere).

Re:GUI eventlog?

[Doc Ruby]

Android looks great. How come it's not in the spotlight for making Linux scripting accessible to office users, like VB and AppleScript were? Oh, wait, this is /., where even a GUI is controversial bloat, and the massive market of new users are lusers.

Re:GUI eventlog?

[damiam]

Android (Google for it) provides a low-level way to do this. The framework is built into GTK (and QT too, I think) for much better scripting support, but it's not really implemented at the moment.

Re:GUI eventlog?

[Hatta]

How come we have a front page article for ever point release of kde & gnome then?

Re:DebSux

[AVryhof]

I think the best reason to use Debian or Slackware is simply because it doesn't try to install and run EVERYTHING included on those (3, 4, 5, what is it now?) CDs. Red Hat, Mandrake, Lycoris, Lindows, and a number of other Linux distributions I have tried seem to make that hardware detection bit work simply by trying to run drivers for everything. With Debian, I can install what I want exactly how I want, and apt keeps me from fighting Dependency Nightmares (which I have had with just about every other distro)

Re:DebSux

[Kent Recal]

Well done, nice seed for another distro-flame-thread.
Can we just say both RedHat and Debian are nice and move on?

Ah nevermind, I know we can't...

Re:DebSux

[cyberkahn]

Debian zealots you need to mod this one up. He posted something politically correct about Debian.

"As a Debian user fairly new to Linux"

A fairly new Linux user using Debian.... Liar

Your Mom's a troll.

[g_bit]

parent was telling the truth, not living in fantasy. Windows has a nice framework for cut-copy-paste, one that works. This is important for an OS to have.

Just admit it, X is slow compared to Windows on similar systems *every time*. It makes me think "Who the hell is developing these video drivers for X? Must be a guy in his basement, not the company who made the hardware."

Re:Your Mom's a troll.

[rmull]

The clipboard framework on windows is truly twisted. It's great when it works, but writing software to work with it will give you a headache.

Re:Your Mom's a troll.

[bit01]

Just admit it, X is slow compared to Windows on similar systems *every time*. It makes me think "Who the hell is developing these video drivers for X? Must be a guy in his basement, not the company who made the hardware."

Nonsense. I've used dozens, may be hundreds, of different M$ Windows and X windows machines. It varies depending on the amount of main memory, the amount of video memory, the quality of the video driver, the quality of the disk driver and the quality of the application.

In general M$ Windows applications have marginally faster window operations, not every time, probably due to, on average, better quality video drivers. On the other hand application quality and speed, particularly useless disk access, are generally worse on M$ Windows machines. It's getting worse too as M$ Windows applications feel the need to go to disk for every mouse click and the disk drivers still feel the need to lock up the machine for significant periods of time.

---

It's wrong that an intellectual property creator should not be rewarded for a piece of work. It's equally wrong that an intellectual property creator should be rewarded too many times for the one piece of work, for exactly the same reasons. Reform IP law and stop the rort by M$.

Re:Your Mom's a troll.

[TKinias]

scripsit g_bit:

Just admit it, X is slow compared to Windows on similar systems *every time*.

Just admit it: Windows is slow compared to X on similar systems *every time*.

Both are silly statements. Win9x will be much snappier than XP. X with a lightweight WM is not too far off Win9x, and definitely snappier than Win2k on my hardware. One reason I finally abandoned Windows for good was that 2k couldn't give me adequate performance on my existing hardware, but X with just about anything but Gnome/KDE/E could. YMMV.

Question about KDE performance vs Gnome

[Glonoinha]

Would you say that KDE is faster than Gnome on the same install? The reason I ask is that I am running Redhat 9.0 in a VMware virtual machine and quite honestly it is a little on the sluggish side (I use Gnome, haven't installed KDE yet.)

One other completely off topic question - how the hell do I tweak the mouse speed and acceleration under X (Gnome)? I bring up settings for the mouse and it lets me pick a mouse - that's it. Bugs me to run off the edge of the desk before I get to the edge of the desktop.

Re:Question about KDE performance vs Gnome

[Durin_Deathless]

I will probably get reamed for saying this, but for me, GNOME is faster. A lot faster. For others, KDE seems to be faster, but it is all how you use it.

Re:Question about KDE performance vs Gnome

[nitehorse]

For what it's worth, GNOME applications launch faster, but their runtime performance seems to be (subjectively) slower to a lot of people.

A common issue is the "menus paint slowly" issue - it seems and _feels_ like GTK+-based applications have slower menus because they delay the pixmap instantiation until the first menu rendering, and then the pixmaps get pulled off of the disk and actually put into RAM. So dragging your mouse across a menu bar in a GTK app right after you launch it (and waiting for each menu to render) feels laggy. Also, resizing seems to be slow in GTK+, probably due to some unoptimized routines in Pango. And the fact that they double-buffer everything that they draw has a distinctly negative effect on performance, as well.

Qt applications, and by way of inheritance, KDE applications, on the other hand, tend to be the exact opposite - slower (on average) to launch, which is being solved piece by piece at the system level (caching of vtables with things like prelink and newer smarter glibc versions has had a wonderful effect on startup time with C++ applications), and faster while running, because more things are loaded into memory at startup. Not every widget in Qt is double-buffered, as well, which makes rendering less complicated and thus faster. Also, smarter KDE developers than me have come up with some very neat tricks to make KDE applications launch and run faster, especially with KDE 3.2, so any comparison of GNOME with KDE 3.1 is going to be very out-of-date soon.

-clee

Re:Question about KDE performance vs Gnome

[be-fan]

It depends on what you mean by faster. I use KDE 3.2-beta2 (on a 2GHz P4 with 640MB of RAM), and I find KDE to be much faster. KDE apps are definately slower to startup, but once they are running they are very fast. Mostly, redraw is a lot faster. For example, even in Windows, you'll often notice "expose lag" (the lag between when you move a window over another window and the window beneath repaints). In KDE, this expose lag is relatively rare (though, its worse in 3.2-beta than it was in 3.1, but 3.2 has a new window manager that is still in the process of maturing). In GNOME, the expose lag is very common. Also, when resizing windows, only the most complex KDE windows exhibit a lag between the window contents and the border. Meanwhile, even simple GNOME windows (like GEdit) will show the window contents lagging quite far behind the frame. GTK+ widgets also feel slower. For example, if you load up a few hundred MP3s in Rhythmbox, and try resizing one of list columns, the resize will lag way behind your mouse. In JuK (the KDE equivilent of Rhythmbox), the column stays right under your mouse as it resizes.

Also, don't use VMWare as a measure of the speed of the desktop. X GUIs are very dependent on the quality of the available drivers, and running with the ATI or NVIDIA binary drivers is a world away from running in the VMWare VGA driver.

Re:More good reasons to like Closed Source Softwar

[Anonymous Coward]

If you really believe this, why did you bother laboring over such an insightful piece and then give it away free to the world? Simple logic would say -- nay, DEMAND! -- that you immediately remove your valuable and moving piece forthwith and only show it to people willing to pay for it. Anything else would be a haunting legacy of failed communism.

Re:DebSux

[Anonymous Coward]

Debian and Slackware are the past, the 90s, the fond memories of the early days, they are relics.

Sure we all loved them but times they are a changing.

Fedora and Gentoo are the distributions of the future.

Hackers on Linux's Exciting Desktop Future

[Anonymous Coward]

Translation: We'll be stealing more stuff from OS X than Microsoft!

Re:Hackers on Linux's Exciting Desktop Future

[Sviams]

Seems to me that in order to succeed on the desktop market, a consistent and well designed UI is needed. While /. is filled to the rim with OSS hacking gurus, what about all those OSS UI designers that must be out there hiding somewhere?

I guess all I'm saying is that while optimizing the kernel is neat and all, your average user won't recognize any more than what's in front of him, and I sincerely believe that more than good response times are needed to impress someone enough to leave an OS that already has a consistent design and style guide in it's UI (read commercially developed UI's).
While having several options (KDE, Gnome) is nice, the lack of enforced style guides and behavior patterns will inevitably give the user a feeling of inconsistency.

Enough trolling for one day, merry christmas.

Re:DebSux

[Fancia]

She, not he. ^.~ And, yes, I am new to Linux. AmigaOne computers currently come preinstalled with Debian, prior to AmigaOS 4's release. I've purchased a machine and have been using Debian for a couple of months now; I've not previously had very much Linux experiences.

Re:DebSux

[interiot]

Okay, I'll nibble.

The most important thing about debian isn't necessarily that apt is cool... it's that the package managers put a lot of work into producing and making sure only good packages get accepted. Like you said, the packages aren't hostile to people making changes to conf files and they try to provide as much documentation as possible about how they've set things up. Apt-on-redhat won't fix that unless you pull in all of the packages from debian package managers, at which point you've got debian anyway.

As for installing a good system with reasonable defaults... this might not be quite as well known, but try this 1) burn knoppix, 2) boot up into knoppix (notice that your hardware is autodetected just like redhat/suse/whatever), 3) run knx-hdinstall, 4) click through 19 simple dialogs, and voila, you have debian installed on your hard drive with hardware detected and tons of reasonable defaults picked. The only place it's semi-lacking i that it doesn't have a TON of things installed (but it does have quite a lot as anyone who's played with knoppix can tell you) since it's just once CD for god's sake (eg. it's missing tcsh), but as stated, it's trivial to do "apt-get install tcsh" to get whatever else you want.

The commies that run Slashdot won't let me

[g_bit]

Now that you point it out, why am I trying to help these people?

You must be much smarter than me, maybe you can tell me why I should develop open sores software? I'll pay you :)

3D Desktop

[Anonymous Coward]

They should recruit these guys to do their desktop http://www.spatialresearch.com/spaces

Re:DebSux

[DA-MAN]

Knoppicks sure is a little braindead in assuming that a network card automatically means DHCP.

MODS ON CRACK!!

[Anonymous Coward]

Who the fuck modded the parent down as a troll?

Re:MODS ON CRACK!!

[Anonymous Coward]

I hate to say this, but I think that the idiots who throw mod points around this way should be shot. Here's an explanation of what the different negative mod points are for, because apparently you don't get it!

• Offtopic: If something is not on topic. For example, this post.
• Troll: If someone is trolling. Like posting goatse ascii in a thread.
• Overrated: If something is moderated higher than you think it should be.

With that aside, the parent was insightful. He brought up a completely valid point. I'm in X right now, and I have to admit-- It is slow. Just because someone says something you don't like doesn't mean you have to should mod them down for it.

The lesson to be learned

[arvindn]

Heard of the joke that a camel is a horse designed by a committee? Well, Linux on the desktop is something like that. So far. You have disjoint teams of hackers working on different parts and there's no "unifying vision". Simple things like copy-paste wouldn't work because it requires developers to coordinate. KDE and gnome were a great step forward, but again the unity came from common underlying libraries rather than people working together.

In the light of this, the recent explosion of corporate interest in Linux on the desktop has been a huge boon. They have the resources and the need to integrate various components. There's no way freedesktop.org could have happened in the old scenario. The amount of integration work that has happened/is happening in the last couple of years is stunning. I lurk on both gnomedesktop.org and dot.kde.org, and the attitude of the developers towards integration has changed significantly.

I'll stick my neck out and predict that with the new audio infrastructure materializing by middle of next year, LotD is going to be so kick-ass by end of 2004 that the only MS can stop us is if they manage to make linux illegal.

Re:The lesson to be learned

[mixmasta]

Audio infrastructure? Why will audio put linux over the top? And to which do you refer?

Re:The lesson to be learned

[Seeker5528]

"You have disjoint teams of hackers working on different parts and there's no "unifying vision"."

I see this as a strength. These teams may be disjointed, but they do not work in a vacuum. As stuff is developed by one team they get feedback from other teams that are impacted by the changes.

Companies/teams that provide distros/solutions have a vision of what they want to provide their users/customers and the users/customers provide feedback on what needs to be added/fixed.

The disjointed development is one of the things that allows a Linux distrobution to be stipped down and built up in so many different ways.

I feel the efforts in creating the LSB and the efforts going on at freedesktop.org are plenty of evidence that when things develop enough in a particular area that a standard is needed work will be done to create one.

As for the example of copy and paste if copy and paste is not working between two applications it is most likely a bug in one or both applications and should be reported to the application developers or your distrobution provider as a bug.

Later, Seeker

Re:The lesson to be learned

[arvindn]

Look here and here.

Audio won't "put linux over the top", but if it stops sucking so bad then one more barrier to widespread linux usage will be removed :)

Re:./ - Cheap publicity for OSnews.com

[Anonymous Coward]

OSNews is a waste of bandwidth. If your in the business of duping vistors to get your impression count up to get ad revenue, then I guess its business. Its a shame that SlashDot has to sink this low. The only thing slashdot has of value is the comment section. Otherwise its the same vomit spewed forth from every other online site that can use a search engine and has a news aggregate program.

Re:Desktop is good, but falls a little short for m

[r00zky]

Running Simcity 4 in VMWare under Linux, however, is not a great option ;-)

However running Simcity 3000 under WINE works perfectly.
And Simcity 4 has the same working-score in transgaming.com but I haven't tried it yet, you could give it a try, I bet it will work good.

Re:DebSux

[Joe Tie.]

The most important thing about debian isn't necessarily that apt is cool... it's that the package managers put a lot of work into producing and making sure only good packages get accepted.

Thank you! I was just about to post the same thing. It's not just the format, or apt, it's the work that goes into the packaging as well. I used apt on suse and mandrake, as well as urpmi in mandrake. And while both were great and quite comparible in technology, I couldn't depend on them like I did apt in Debian because there just wasn't as many people putting together and updating packages. I did a dist-upgrade earlier today, and at 9pm there's already 36 packages with updates available.

Re:DebSux

[Anonymous Coward]

and at 9pm there's already 36 packages with updates available.

Ya, and those are all old versions from like a year ago, LOL, nice updates....

Re:DebSux

[Anonymous Coward]

Gentoo Linux? Ha!

Lets see, there complete binary nazis.

Instead of saving you week long compile session they prefer the shove their keyboards up there asses and not save it in any way or shape. They refuse to have binary ebuilds because of the 'evils'.

Portage? More like swiss cheese. Half the flags dont work, gentoolkit is a joke. Some real package management is needed. Ebuilds are more or less a joke now.

Which of course is really sad, its a terrific idea. IF they would take the keybaords out of there asses and realize binaries are great for backups, distrobution and just seeing if you like then damn app.

kdrive is nice

[brendan_orr]

Kdrive (freedesktop.org's X project) is nice, however, it still lacks support for nvidia. Rather, it is impossible to have accellerated support for nvidia (and no, you cannot use your binary-only nvidia drivers with kdrive). now, if only there were a way to get the various extensions+xcompmgr to work with my existing 4.3 server :\ (mmm, kde... more eye candy :)

Sarcasm?

[DoctorHibbert]

"Hackers on Linux's Exciting Desktop Future"

Did anyone else read the story title as being sarcastic? Say it out loud to yourself, I'm positive it will sound sarcastic. Actually, I think its impossble to say that sentence out loud and sound even remotely earnest.

Translucency

[starnix]

Who gives a flying fuck? Translucency has to be the most overhyped, useless, wasteful feature I've ever heard of. Ooooh look, I can make my menus hard to read. WTF. Can someone please explain all the effort being put into this completely useless feature?

Re:Translucency

[PotatoHead]

I have one idea, though it has very little to do with menus.

Say you have one of those annoying supposedly informative dialogs. (Press ok to continue, or selection invalid...) Instead of simply blasting the dialog on the screen, you could fade it in, the user notices, but does not need to click or anything because:

a: it does not obstruct what is happening, but is more easily noticed than status indicators, more intuitive than things like cursor changes,

and

b: since it is transparent, it can fade away.

Basically, I believe there are GUI elements that could inform people and possibly present transient choices in a manner that is not as distracting as todays "ok to..." elements.

Think video game like instead of microsoft office like, but with some style.

I agree totally with you on the menus. Nice eye candy, but little use at this point.

Re:Translucency

[caseih]

It's not transparent windows per se that we are looking for. It's the ability to have completely smooth, shaped edges and better anti-aliased text. It's also amazing what a little candy like a real drop shadow does to the UI. It helps your eye see the edges of ui elements better. On OS X, for example, many windows have no frame around them at all. But they still look like a window because of the light shadow that is drawn underneath it. This allows two completely white rectangles to be stacked on top of eachother and still look like separate windows.

True transparency will also help in drawing icons without resorting to the current nasty hack of having to grab the background pixmap and then blend the png into it.

Essentially translucency (true alpha-channel support) in the x server is a great boon to us all, especially those into art and drawing, but also just those of us that want a desktop with no more jaggies.

Finally, this support for alpha channel and window compositing actually makes the gui appear much faster, because redraws are virtually eliminated. If you want to go back to the old Windows 3.1 (or even GEM) interface of low-color, jagged edges, go ahead. I'll save my eyes.

Re:Translucency

[RdsArts]

THat does sound interesting. I know ROX-Session will display a program's errors for a few moments on the edge of the screen, popping up a dialog only if it takes up too much space, but if it could use this and place them in say the center of the screen with some transparent effects, that'd make a great way to give error/status messages from everything.

Man, if only Keith and crew had been able to do this stuff in XFree, imagine where we'd be by now..

Re:Translucency

[Tim C]

Someone else has discussed ust plain making the UI look less ugly, but I can think of another possible use. Say you're typing something based on a diagram - maybe some documentation, or some code, an email, whatever. It's a large diagram and takes up most/all of the screen, and a large part of it is obscured by the window yo're typing into, but you need to refer to it as you type.

Currently, you'd have to keep switching between the two, either by raising/lowering the windows, or switching desktops. With translucent windows, you could set the window you're typing into to be semi-opaque, and so see the diagram through it.

Not a huge deal, perhaps, but I can certainly think of situations where I'd have found it useful.

Re:Translucency

[firewrought]

Can someone please explain all the effort being put into this completely useless feature?

Wow... I love how you can encounter a bad usage of a technique and dismiss it forever with one sweeping declarative statement.

Translucency deserves to be a fundamental part of the modern windowing system. It's not a "version 1" feature, but it is important. Here's why:

Reason 1: Eye Candy
A good designer can get a lot of eye-candy mileage out of translucency. Agreed... there's a lot of stupid stuff that designers can do with the effect, but on the whole, it can add some remarkably classy effects to a basic GUI design. Apple OS X uses this strategically, as does some themes I've seen for KDE.

Good, clean aesthetic design makes Linux more attractive to newbies... and, confess it, we hardcore geeks kinda like it too. Obviously, I am NOT talking about the gratitious use of hyperactive Flash animations and dorky custom GUI's for business tools (a la Kai's Powertools)... those things should crawl back to the marketing department that spawned them.

Reason 2: Usability
Beyond aesthetics, the appropriate use of translucency can help you convey more information to your users. One example: antialiased text. Other, better examples are waiting to be found as transparency creeps into more and more windowing systems/applicaitions.

Reason 3: Completeness
Deciding which features should or should not go into a toolset API can sometimes be a challenge. However, there tends to be a natural "stratification" to a lot of these features those... for instance, if you have an appliance with a "volume" feature, you generally expect it to have a "mute" feature too (even though it used to be absent in older TV sets, stereos, etc.). Likewise, if an app lets you "copy" and "delete" an object, you expect it to also give you a "cut" option, even though this is redundant. Graphics programmers must work with Red, Green, and Blue... since they are having to do a lot of work building up a raster image, they kind of expect to see Alpha there as well. If the graphics API doesn't put it there, they will have to go off and write it themselves. If the windowing system implements this, it just makes life that much easier and helps avoid some duplicate code.

Reason 4: Inevitablity/B>
Sometimes features have to be added to software because users demand it. You may think you've provided a good clean technical solution, but academic purity only oges so far in the real world.

Re:Translucency

[Anonymous Coward]

Strangely enough, true translucency is the single most useful feature OS X has to offer me. As a sysadmin I very often watch a logfile in an underlying window while editing another file in a window on top of that. Being able to see (and read) changes in the log while keeping my eyes on the work at hand is invaluable for someone who's always out of screenspace.

the problem with linux on the desktop is...

[null-sRc]

..'Linux answer to WinFS'..

linux needs to stop answering, and start innovating ;)

the masses seek bleeding edge. not last year's bleeding edge :(

don't get me wrong i love gentoo, and i was hoping linux could beat windows to the 3d desktop (see longhorn's specs re: d3d)

an opengl desktop (assuming linux) would be

1. FAST FAST FAST !!! WEEEE
2. pretty

and would win a lot of people over :)

also it would improve graphic driver support through neccesity, and with that comes a better foothold for the gaming industry, which is also another drawback for linux :/ like it or not.

Re:the problem with linux on the desktop is...

[AntiOrganic]

Last estimates I heard placed Longhorn's release in 2007, so I think they'll be the ones catching up if desktop Linux development continues at anywhere near its present pace.

Re:the problem with linux on the desktop is...

[Anonymous Coward]

I thnk you'll find that Linux (and Solaris) WILL beat Longhorn to the 3D desktop:

http://wwws.sun.com/software/looking_glass/

Re:Desktop is good, but falls a little short for m

[Anonymous Coward]

Also, I find Redhat 9 to be deadly slow on the desktop. SuSE 8 has proven to be much better (a KDE vs GNOME here?).. but I'm waiting for Fedora Core 2 (with the 2.6.0 kernel) until I make my next foray into trying Linux as a desktop OS.

Lots of people say this, but I still don't get it. At work I run Slackware 8.1 with WindowMaker, and I get better compile performance and a more responsive desktop than my Windows-user coworkers, most of whom have more CPU than I do. I think people who are disappointed by the responsiveness of Linux/X11 are actually disappointed by the bloat of KDE and Gnome. Give WindowMaker or XFCE a try; you might be pleasantly surprised.

Re:DebSux

[forlornhope]

Its not a little braindead. This is a distribution setup to run on the most desktop systems and choose sane defaults without too much(none?) user interaction. Thats the point of knoppix and the fact is that most desktop systems are either on dhcp or ppp. That is a fact of life and normally those on static links ussually know how to setup the static link and its not that much work. Sure if you have a network card that doesnt come up poping up a helpful dialog that says that your network didnt come up under dhcp and ask if the user wants to leave the link down, try again, or setup a static link would be helpful, but if it bothers you Im sure knoppix would accept a patch or two from you if you did it. Dont say that the choice is braindead unless you think it through or are willing to add a brain.

Copy and paste needs fixed.

[crush]

Kindly explain what you mean by:

Copy and paste needs fixed.

By the way, I just copied and pasted that and it's one of the things I love most: left-button drag highlight, right-button paste. Works For Me.

Re:Copy and paste needs fixed.

[shaitand]

I love copy and paste on linux. The part that needs fixed is that it is not consistant.

I love highlight and middle or right button paste (althougth there we've already bumped into an inconsistantcy) and believe it's worth giving up the ability to highlight and delete and then paste, or simply highlight and paste over.

The part that needs fixed is that between some applications the data isn't carried over, you copy in one app and then can't paste in another. The other hitch is that not all applications support both the mouse based method and Ctrl+c Ctrl+v. The clipboard should be app and window manager independent and should work across all applications.

Re:Copy and paste needs fixed.

[crush]

The part that needs fixed is that between some applications the data isn't carried over, you copy in one app and then can't paste in another. The other hitch is that not all applications support both the mouse based method and Ctrl+c Ctrl+v. The clipboard should be app and window manager independent and should work across all applications.

Try this: hold down Shift and then drag the mouse selection. The paste should then work in the other app. I have never had it fail. Please let me know if you find that this still doesn't work and mention the particular application(s) in question.

Re:Copy and paste needs fixed.

[shaitand]

That's great, really it is, but it hardly means that linux no longer needs a consistant system wide clipboard in which ctrl-v ctrl-c and ctrl-x, as well as highlight middle-click ALWAYS work. This includes back and forth between console and X (not just an xterm but a true console). Shift does work and thanks for the tip, but it shouldn't be needed.

This is not as simple as it sounds while maintaining the ability to support multiple users. Because I should be able to login to X as blahuser, ctrl+alt+f1 login as root, ls -l and then highlight some of the output and alt+f7 back to X middle click paste it, this should also work between gui instances. However this should NOT interfere with other users who have logged in via gui terminals and ssh and such, their clipboards should remain consistant to themselves.

Just getting this behavior completely fixed within a single gui instance would be a start however.

Re:Copy and paste needs fixed.

[crush]

The problem is that X has three mechanisms for implementing the storage of a selection:

1. PRIMARY, SECONDARY
2. CLIPBOARD (the Ctrl-C/V/X and File->Cut/Copy/Paste)
3. CUTBUFFER

These are all handled by the clients. That is, the clients are responsible for notifying the X server that they are dealing with the selection in some manner. No one is supposed to be using the CUTBUFFER, but some still do apparently. JWZ has a good article explaining how it all works.

Eugenia mocked up some nice interfaces

[crush]

She only mentions/links to one example screenshot of them in her article, but they're all very nice:

• First
• Second
• Third
• Fourth

Re:Eugenia mocked up some nice interfaces

[ainsoph]

Has anyone made this theme yet?

Re:Eugenia mocked up some nice interfaces

[Scarblac]

Very nice? At least the second and the fourth are pretty horrible. Far too much clutter, regardless of how it looks.

Re:Eugenia mocked up some nice interfaces

[crush]

The second/fourth is a grab-bag of unrelated elements to demonstrate the graphical look of those elements. The example where she takes the Print dialogue box and reworks it two ways (one with the new theme and the other just with better layout is IMHO particularly impressive). See the third image.

Re:Eugenia mocked up some nice interfaces

[Anonymous Coward]

God, I hope those are just mockups... The "Ok", "Defaults", and "Apply" buttons all look different...

Biggest Gtk Flaw

[Anonymous Coward]

> 6. In your opinion, what is the biggest
> architectural flaw on GTK+ today and how would
> you go around it? On the same theme, what is
> GTK+ best feature?
>
> Owen Taylor: If I had to name one architectural
> flaw in GTK+ it would be the extensive use of
> pixel units in the API.

That may be one of Gtk's flaws but *the* biggest
architectual flaw in Gtk is that it wasn't
designed to interface with the X toolkit (Xt)
layer of X. (Neither does Qt for that matter).

Wrong, with my apologies.

[Balinares]

> Derived objects, on the other hand, don't seem too useful for GUIs
> so long as you have interfaces or a good implementation of generic
> functions and type inference.

That's where you're wrong, with my apologies for putting it so bluntly.

Derivation is the #1 thing that makes the difference between a good widget set and a bad one, for several reasons.

The major reason is that in any complex application, you'll need custom widgets (entry fields with browsable history, viewing pane with custom repaint, etc). If you have to provide the functionnality by manually appending it to the native widget everywhere it's needed, your LOC (and the potentiality for bugs) explodes. The right way is to derive a self-contained widget from the general case, specialize it for the need once for all, and use it instead of its parent where needed, which only requires adding code in -one- place.

Typical example is KDE's file dialogs, that all derive from a common root, but can be expanded on an as-needed basis (and without even adding bloat since the common logic is in the parent class).

Typical counter-example is the MFC, which are absolutely awful to code against, because they're based on a non-object-oriented framework and have very little extensibility (WinForms is thankfully a major improvement in that regard).

Second important reason is granularity. Derivation allows an API to provide very high-level widgets (text editors, MDI areas...) -and- their lower-level parents, which in turn allows you to use the high-level widget where it's the fitting tool, and derive your own from the parent where it isn't, all the way down to the lower level widgets if they're what you need. Lack of the extensibility derivation offers in an API means your API will either have to remain very low-level, thus requiring you to reinvent higher-level wheels everytime you'll need them, -or- overbloating the API with countless specialized widgets to try to cover most of your needs (that's the MFC approach).

Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.

Third reason is, of course, as you rightfully point out, event handling, which derivation allows to specialize as needed (for instance, tablet XInput events on a drawing widget -- see how Qt does it for a good example) -without- building a dedicated widget from the ground up -or- special-casing against XInput. Once again, Gimp 1.3 and its XInput handling problems are a good example of why it matters.

There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.

Once again, I'm sorry, but while you're right about event handling, that is a -runtime- issue and pretty much orthogonal to widget development. You'll note, by the way, that Qt provides signals and slots -precisely- so that you don't have to think about that orthogonality in the common cases -- its widgets handle events on their own and emit the appropriate signals as required, which allows you to design your code according to WHAT is to be done in response to something, as opposed to HOW that something happened. Best example is the concept of QAction, which can be triggered from a butten, a menu, a context menu, or a key shortcut. You only have one signal to slot against, regardless of which way that action was triggered.

There, that's it for now. I hope I managed to make it a bit clearer why object orientation is primordial to a good GUI toolkit?

Rosegarden developper Guillaume Laurent has a few interesting thoughts about why he switched from a GTK-based backed to some random object-oriented toolkit, if you'd care for a slightly different point of view on the same topic.

Re:Wrong, with my apologies.

[Anonymous Coward]

I agree with your points. I think gtk+ is a good toolkit for a c-based toolkit. At least the api seems consistent. But there are times when you do need to subclass, even though sometimes(for me) it's hard to know if if should subclass or encapsulate. Is there a rule of thumb that you go by?

That said and as many others have stated, OO is not a panacea for bad coding and can indeed make your code much more unmanageable done wrong. As Bjarne said, in c you can shoot your foot off, with c++ you can blow off your whole leg.

I don't want to get into a licensing flame, but I wish somebody would just buy QT and LGPL it. In reality, that's the only reason UnitedLinux and corps are turning to Gnome. They don't want to be tied down to a license with some small company where you don't know what's going to happen. The license per seat isn't bad at all, but those are the issues.

Re:Wrong, with my apologies.

[Anonymous Coward]

Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.

Guess they should have picked a better toolkit then.

Re:Wrong, with my apologies.

[azzy]

Yeah.. maybe they would have been better off inventing a special toolkit all for themselves.

*ducks and runs* Sorry! Couldn't resist!

Re:Wrong, with my apologies.

[BitchKapoor]

Ok, I guess you're right.

Re:Wrong, with my apologies.

[Anonymous Coward]

Yes. What they did is what is called in the industry "reinventing the square wheel".

Reinventing a better wheel is not a bad thing if the purpose is to get an actually improved wheel more suitable to your needs. However, in this particular case, their CVS log shows otherwise. The sad thing is that when someone offered to fork the project to give it a more modern interface, they bitched like all ungodly hell and the project was dropped. This in itself may be an indication that they know of their wheel's shortcomings, and don't want them shoved in their face, be it indirectly. That's pretty sad. At some point Gimp WAS a likely replacement for Photoshop.

Re:Wrong, with my apologies.

[IamTheRealMike]

Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.

That is completely wrong - GTK doesn't support Win32 style MDI because:

a) Most window systems don't support it (X doesn't, Quartz doesn't).

b) It's extremely poor usability wise.

c) It's a lot of extra complexity for little gain.

It has nothing to do with the way GTK is built.

There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.

Again, you are completely wrong. The Win32 widget toolkit, which is *the* industry standard, is written in C.

Re:Wrong, with my apologies.

[madmaxx]

Uh, gtk is object based in case you haven't noticed. Just because it's written in C doesn't mean it can't use objects. Gtk+ allows for very decent subclassing, as does the plain-old-C Win32 GUI Apis for that matter, though I personally find the Gtk+ approach much cleaner (they've taken the time to develop a very clean API).

The only 'bloat' in Gtk+ may be in the infrastructure required to support C-style objects, but it does give one distinct advantage over using pure C++ (or Java) for the widget set: complete (and absolute) control. Notice what Trolltech has done with their QT widgets with the signal/slot pre-compilation process (they had to work around a limitation of the language), this is a decent approach but shows a minor limitation of the toolkit language. I think that QT is a great OO-style toolkit, as is Gtk+.

Re:Wrong, with my apologies.

[Anonymous Coward]

Well, for those times there are always the OO language wrappings for GTK+.

gtkmm, gtk#, pygtk...

Re:Wrong, with my apologies.

[Stu Charlton]

The Win32 widget toolkit, which is *the* industry standard, is written in C. ...And hasn't been used for most Windows GUI's for the past 7 years in favour of VC++ (ATL or MFC) or Visual Basic.

Also remember that WinFX, the API set for Windows Longhorn, is all .NET managed code. New features will *not* be exposed through Win32. In effect, Win32 is a legacy API.

Re:Wrong, with my apologies.

[Ed Avis]

Notice what Trolltech has done with their QT widgets with the signal/slot pre-compilation process (they had to work around a limitation of the language),

Sigslot is a pure C++ implementation of the same idea, suggesting that the language isn't so deficient you _have_ to use a preprocessor (although it may have been back in the 1990s when Qt was developed).

Re:Desktop is good, but falls a little short for m

[Feztaa]

That said, I still use a Windows desktop.. why?

Judging by your username, I'd say it's because you're a wacky brit.

Re:DebSux

[swillden]

In short, debian sucks, redhat has surpassed it

So, does this mean I can now upgrade from Red Hat 7.2 to Red Hat 9 with a single command?

desktop hype

[potpie]

Everyone is always so enthusiastic about the Linux Desktop, Linux for the average user, Linux instead of Windows, etc. I understand the basic desire to share a good thing, but is it really necessary? IMHO, if Linux ever really replaced Windows as the standard desktop OS, it would just be a bigger target for greedy lawyers and corruption.

I believe that as long as the Linux community remains a sizable minority, the true spirit of the OS will remain intact. People are always talking about how to make Linux so incredibly user friendly that anyone can use it. But I've always thought of Linux as the operating system for those who care about the operating system. It seems to me that instead of trying to overthrow the big, evil corporations (though it sure would be nice from a legal perspective. IE: SCO), we should instead try to do nothing more than offer the choice of high-quality computing. I just happen to think that most Linux users use Linux BECAUSE it's not as user-friendly, BECAUSE you have to know the filesystem, and so on.

I think that the only real "Linux Revolution" will come about when the people who know what they're doing are able to choose Linux based on merrits besides "user-friendliness." It just seems to me that they're trying to dumb down the OS (take Lindows as an example, which by default only creates the root user in the installation) to accomplish a goal that is actually not necessary (market presence is good, but dominance?). I just think that some developers are lowering their standards to win more converts.

Re:desktop hype

[RdsArts]

So, to keep Linux viable, we should make it so people who use it have a hard time?

I'm sorry, but as a user of free OSes and a coder, when I'm coding something I want to make it very easy to use, so it's easy for me to use, not some mythic end user. The fact that it's easy for them to use as well is a happy accident.

The good thing here is that many coders writting free and shared code are learning good UI skills. This makes it easier for the coders and users to use. And it's the natural progression of code.

User friendliness is a perceivable thing, and that the BSDs and GNU/Linux, using the major desktops or something like XFCE or ROX-Desktop, is easier to use in many ways to the large commercial OS speaks volumes about just where time is being spent. These are good things, and are things which go into a question of what tool is better for what job. You can use a book to drive a nail, doesn't mean that if you do, you understand things better than if you'd just got a hammer out.

Now, while people can be like Lindows and do dangerous things, the inherit nature of being open makes this possible regardless. Which is why I find it best to view each distro as a OS, not a distro of similar things. It makes the fact that a etc directory on one system looks nothing like one on another make more sense, and helps put problems like that in perspective.

Re:desktop hype

[Simon Lyngshede]

I think we need to realise that there at two elements embeded in userfriendly (usability). One it ease of learning, the other is ease of use. There are very few open source system / programs out there that are actually hard to use. I agree the open source community delivers a lot of software which isn't learnt in 5 minuts, but does it really have to?

Windows is amazingly easy to learn, but I don't see it as being easier to use in the long run. I think the difference lie in the which elements of userfriendly you focus on. This leaves us with the people how take a quick look at KDE, GNOME, whatever and as a first reaction says "This is different, I not like it". We need to hit this people until they understand that it is not about first impression, it is about having a system that is easy to use and will allow you to work as fast and efficient as possible.

I could not care less about Joe Homeuser, or whatever his name is. If he doesn't understand it, well that is his problem. Let us build the best possible operating system and allow the people choose.

Re:desktop hype

[Elektroschock]

Well, the revolution is still there. Many friends of mine install Linux and are ready for a switch. I think within the next 8 month we will see huge progress.

Woot!

[Anonymous Coward]

OS4 rules!

too many cooks making too many users happy

[penguin7of9]

I think Linux is going down the Windows path: ever more junk gets added to the system in an attempt to make everybody happy. That just can't be good in the long run.

Think about how many IPC mechanisms there are now: TCP/IP, UNIX domain sockets, SystemV IPC, BSD memory mapping, various kernel-internal mechanisms, file-system based mechanisms, etc. And now we get added to that netlink and D-BUS?

Similarly with file system hacks: we get several incompatible user-level VFS implementations, numerous kernel file systems (many of which have their own non-UNIX semantics and extensions), we get WebDAV hacks on top of CODA hooks, we get NFS loopbacks for cryptography, etc.

Yes, something like netlink does make sense. I'd also put something like VFS into the kernel. But in return, a lot of stuff should be officially deprecated and eventually removed from the Linux kernel. That will break software, but it is vitally important for keeping the entire system manageable and comprehensible. (I suspect that part of the attraction of BSD is probably that it doesn't have as many features as Linux--it's simpler.)

Furthermore, creating all that wonderful functionality for Linux isn't going to do any good if systems like Gnome don't start relying on it. That is, if the Linux kernel were to offer a unified namespace, Gnome should drop VFS even though that means it won't be able to run as well on Solaris and BSD anymore.

Of course, all these things will eventually fix themselves by selection in the market place. However, I would hate to see that selection happening by Linux and Gnome going away entirely because they have become too unwieldy.

Re:too many cooks making too many users happy

[Anonymous Coward]

Actually, there aren't "all these IPC mechanisms" now. They've existed for pretty much forever, in computer time. Linux just happens to support everything that comes along. As long as they work, and don't interfere with each other, feel free to pick and choose as you like. Nobody said you had to support everything.

Re:too many cooks making too many users happy

[Anonymous Coward]

Does the term "modular kernel" mean anything at all to you?

Re:too many cooks making too many users happy

[Anonymous Coward]

Yes, it has a lot of meanings to me. For example, it means "We can't make up our mind, so we just throw all the junk that comes along at you". It also means "I have to recompile, reconfigure, and deal with hundreds of buggy, inconsistent, non-interoperable modules and mechanisms, instead of a coherent infrastructure of built-in services". What does it mean to you.

Re:too many cooks making too many users happy

[Anonymous Coward]

Actually, there aren't "all these IPC mechanisms" now. They've existed for pretty much forever, in computer time.

I'm referring to them existing in Linux.

Linux just happens to support everything that comes along.

Yes, and that's a problem.

As long as they work, and don't interfere with each other, feel free to pick and choose as you like.

But they do interfere. They interfere because every skilled Linux programmer will sooner or later encounter every single one of them and have to deal with them. They interfere because some tools need to know about all of them. They interfere because they make it harder to reason about programs. And they interfere because it means that programming, debugging, and performance tuning resources get spread out among supporting redundant mechanisms.

Re:./ - Cheap publicity for OSnews.com

[BiggerIsBetter]

"It's just business" is the most used excuse for doing unethical things.

Debian Linux: where did you want to go yesterday?

[Anonymous Coward]

Debian maintainers care more about bitching on mailing lists and creating deb packages than actually WRITING ANY SOFTWARE

Debian has the worst installer in the entire Linux world. After years of complaints, message board flames, donated code from Progeny (which they completely discarded!), and users actually recommending people use KNOPPIX as the best way to install Debian (WTF!?), they finally release a "new" installer... a piece of shit running an outdated kernel

Debian is so behind the times that they consider kernel 2.4 to be "experimental"

Debian is losing mindshare as devs and users jump ship to Fedora and Gentoo leaving behind old men who care more about open source idealism than actually writing software that works

Install a modern Linux distro and you will see why Debian sucks. In 2003 most linux distros actually fucking work out of the box. They set up X and your soundcard. They detect your hardware. Something most computer users have enjoyed since 1992 WHEN WINDOWS 3.1 WAS RELEASED. Debian, on the other hand...

Debian Linux: bringing you yesterdays technology today.

Its all about standards

[Anonymous Coward]

Why having more than one desktop solution for linux/unix? Many of you will anwser "to keep the liberty, the choice". I think that 2 teams working on two big projects like Gnome and KDE, is pure coding energy dilution.
If all the guys who like to code for a linux destkop projects, could work on the same project, same standards, same bases, this would makes "this project" good and scalable enough to really fits your needs. Then your liberty of choosing is becoming useless, you got what you want. Because you can adapt the software to your needs, you wont have to get another one or start coding another one, with diferant standards, these you thinks could be better than the already existant in the other rejected project.
If you really dont like the way the base standards of the project work, then bring your point of view and THIS will improve the application you needed improved to fits you needs. HEY, we all need the best way to acheive our goals on a computer, and throught calculation, there is ONE better way than the others. The rest is simply, bad habits! I know this sounds like utopia but thats what we need to aim for. Look at Sourceforge, this king of tool is what we need, its at least the beginning of something better.
I know my english sucks.
Peter

Re:Its all about standards

[Hatta]

I don't think they care what you think. Even if you could convince them to collaborate on a Knome desktop it would never get anywhere due to bickering over the details. By having two different projects you get the benefit of a little healthy competition. Look at a project like XFree86, it has enjoyed a monopoly on the linux desktop for quite some time, and has stagnated. Hence we don't have features like alpha blending. Then along comes directfb which does have alpha blending, and now we have an experimental branch of X that will hopefully push the envelope a little further.

Funny

[Enucite]

Where are my modpoints when I need them. :)

Does linux really have desktop future?

[jarek]

In this increasingly mobile world, you still can't roam the desktop (meaning disconnect the desktop and reconnect to it somewhere else). Even using a T1 and LBX (low bandwidth X) you have to be pretty patient in addition to slightly humiliated when you see Windows Terminal Server users do the same stuff using a regular phone line and a modem. It's sad considering that the rest of the technology has so much to offer.

Re:Does linux really have desktop future?

[Anonymous Coward]

VNC?

Re:Does linux really have desktop future?

[jarek]

VNC is even slower than X. I've run VNC from time to time (lacking alternatives) and it's not the answer. Perhaps it's the question, but the answer is NO.

Re:Does linux really have desktop future?

[juhaz]

That's true for the vanilla VNC, but TightVNC is pretty slick. Not quite as good as rdp, but a LOT faster than plain X.

Re:DebSux

[DA-MAN]

> Dont say that the choice is braindead unless you think it through or are willing to add a brain.

Wow, now theres some stupid rhetoric. What, now everything that gripes a person is not a real gripe unless someone is smart enough to make a change.

Oh Mr. Aids person, don't complain about the drugs that are killing you unless you're willing to come up with your own drugs that will fight off the virus.

You're full of shit, and you need to get off your high horse. Feedback, even if not always flattering, is always the first step to making a great product and a good sign that people are using said product.

P.S. I don't have time to figure out how Knoppix works and rewrite the part that controls networking to check to see if it got an ip, otherwise prompt. These days I'm too busy with other itches that need scratching at the moment.

Lhame!

[Anonymous Coward]

So whats Debian get out of this Desktop evolution? fvm95?

Desktop future

[Elektroschock]

Despite the fact that ximian put so much spin on Gnome (KDE-Bashing, false accusations against qt, Suse will drop KDE nonsens ecc.) I would suggest that *today* Linux desktop means KDE.

Unfortunately Gnome lacks behind. RedHat committed themselves to Gnome what turned out to be a misktake. Today they are not intrested in the desktop market anymore. RedHat never supported KDE sufficiently.

Remember Ximians said ealier this year Mono 1.0 will be there in the end of this year. Vapor-marketing.

I believe we shall better focus on a stable common desktop. We shall stop with unfair bashing of other DE. Some use gnome, others KDE, Gnustep ecc.
Nothing wrong with it. But the way Freedesktop is used in the battle for Gnome promotion shows a lack of understanding what it was for: to bridge the gap, to improve interoperability.

KDE's opinion always was that
Freedesktop shall be a common platform.

Re:Desktop future

[Anonymous Coward]

Despite the fact that ximian put so much spin on Gnome (KDE-Bashing, false accusations against qt, Suse will drop KDE nonsens ecc.)


can you provide links proving this? or are you just YET ANOTHERkde troll? i dont know what it is about kde people, but they all seem to be 16 year old virgins who cant keep their mouths shut. heh :)

Re:Desktop future

[Anonymous Coward]

It is impossible to provide links, there are so many of them. Take a look on User Linux and ask Bruce Perens why he dropped KDE, rather than for some pseudo-socialist ideals. Where is the user acceptance testing, opinions from developers (particularly Microsoft ones) to take that decision? Gnome people all seem to be 16 - 50 year old virgins with beards who seem to have some bizarre idea of what is or isn't free software. Remember what happened the last time this happened? Microsoft sailed off into the distance.

Re:Desktop future

[chez69]

it is impossible to prove what I said, but it is true!

Re:Desktop future

[juhaz]

RedHat has not lost their interest on the desktop market.

They've only moved focus from from private desktop to where money is - corporate desktop. RHEL is not all about big servers, workstation version is a significant part of the line.

Re:Desktop is good, but falls a little short for m

[Sieni]

Also, I find Redhat 9 to be deadly slow on the desktop. SuSE 8 has proven to be much better (a KDE vs GNOME here?).. but I'm waiting for Fedora Core 2 (with the 2.6.0 kernel) until I make my next foray into trying Linux as a desktop OS. (I continue to use SuSE 8 via emulation for development purposes)

I heard that Red Hat 9 has some speed and responsiveness problems of its own and that this is related somehow to the kernel they ship being heavily patched. Does anyone have any more information on this?

Re: Style Guidelines

[some guy I know]

I think congress on this sort of development ...

No, I don't think that we want to get Congress involved.

Seriously, since KDE strives to be an MS-Win clone, just use the MS-Win guidelines when developing KDE apps.

The other thing that one can do is look at what's already out there, what's being distributed with major sensible distributions (such as Slackware), and imitate what seems to be done well while discarding the rest.

the perfect desktop

[Ploum]

The perfect desktop ? Soon, I hope :)

Re:DebSux

[Anonymous Coward]

Most of your points seem to be "I want everything to work exactly like in windows". Perhaps this would be a good thing for some users, but certainly not for me! I don't see how any of these things makes debian suck...

And PLEASE, PLEASE, for gods sake - NO DAMN INSTALLSHIELD crap. I just apt-get install whatever and then it's usually ready to use.

Re:DebSux

[Anonymous Coward]

3) run knx-hdinstall,

No, no, I did this 2 weeks ago and had to fiddle hours to convert the knoppix hd-install to a native Debian system. Knoppix will install a lot of packages (read: XFree 4.3) that will conflict with those available in Debian. You will have a hard time to resolve conflicts (using dpkg --force ;)

Re:DebSux

[Anonymous Coward]

Maybe not from 7.2, but you can now update from Red Hat 8/9 to Fedora 1 with one command using apt-get or yum. And of course from Fedora 1 to Fedora 2 and so on.

Looks like you're going to have to find something else to complain about. See, unlike Debian, Red Hat and other distributions are updated twice a year and what was true in 1999 is old news today.

Freedom of choice...

[Kjella]

The great thing about Linux, is that you can peel off all those layers of userfriendlyness, if you feel like it. That you *can* do something from a point-n-click GUI doesn't mean that you have to, you can always drop to a command line and do a fancy, complicated command with pipes and flags and options and maybe a regex expression for good measure, which about three people on earth would understand on sight yet accomplishes something that'd be near impossible in the GUI.

On the other hand, when I'm looking for a) Where to set a setting or b) the optimal value for a settin on something which I'll do maybe once a year, I'd rather not have to RTFM to find out what the command is called and how to call it, but rather click a nice intuitive sequence "System settings -> kernel -> modules -> module X -> property Y" with a nice GUI and tooltips and all, not really knowing shit in advance about the other 99,9% of the hierarchy.

Like when I dropped in a couple disks in my Linux box... so where are they? Oh yeah they're now at /dev/hdc and /dev/hdd, RTFM #1. So... how do I partition them? RTFM #2. So... how do I format them? RTFM #3. So... how do I mount them permanently? RTFM #4. Right it's not really that difficult, but I'd much rather have a "user-friendly" wizard appearing with "New hardware detected - Western Digital 100gb hard disk" where one of the options is "Bug off, and don't come back". That way, I can spend my time getting to know the things which would be really useful to know well, instead of trying to be an expert at everything.

By implication that would also mean that a "normal" person can choose not to be an expert at anything, and just use the damn thing. But I don't see how that by itself limits what I can do. Dumbing down the desktop only matters as long as you have to use the dumbed down tools. Which you don't.

Kjella

Installation/uninstallation is a solved problem.

[Moderation abuser]

Package managers have made it trivial to install an application, assuming the user has administrator access all you have to do these days is double click on the rpm/deb file. De-installation is equally trivial.

WinFS is a red herring. Irrelevant.

Can you feel the innovation?

[Ciderx]

Exactly how often are developments in Linux going to be "an answer to "? There is definitely a problem of only being able to follow, not lead, within Linux development.

Re:Can you feel the innovation?

[Hatta]

It's open source, feel free to innovate all you want. I'll look forward to your patches.

Ok, they're all pretty and blazing fast...

[gregorio]

...but all I want is:

Usability: Not just "that GUI is pretty" but also "this GUI is compatible with most people way of thinking".

Consistency: Not just "look, ma! I got translucent Windows", but also "all my applications act and feel the same, I don't need to learn how to use 38674 interface styles".

Standards: Can we have solid APIs based on well documented standards? Like something that allows me to run a 4 year old binary, and not just source-based apps?.

That's all I want, not a collection of pretty demos, but a real desktop.

Java mess?

[claes]

Can you elaborate on how Java's libraries are a total mess? I don't think they are especially bad. Some deprecated old stuff could probably be removed, but I find my way around there without major difficulties. Noone uses all of it of course, but most of it is useful I would guess. What would you like to change? What need to be improved?

LotD?

[Anonymous Coward]

I too am looking forware to the Lord of the Dance being kick-ass in 2004.

rtfm

[libra-dragon]

completely bastardized

Looks close to me:

man hier

http://developer.apple.com/documentation/Darwin/Re ference/ManPages/html/hier.7.html

Sure some of it may be symlinks, but the basic provision is there --at least for the basic UNIX part of OS X.

Re:DebSux

[swillden]

you can now update from Red Hat 8/9 to Fedora 1 with one command using apt-get or yum. And of course from Fedora 1 to Fedora 2 and so on.

Very cool. One of the things I most disliked about Red Hat was the need to continually reinstall. This is good news since I may be forced to move to Red Hat in the near future.

Beyond the tool support, do Fedora package maintainers consider smooth upgradability to be an important requirement? That's at least as important as the tools.

Looks like you're going to have to find something else to complain about.

You have me confused with your fanboy-self. I'm not interested in "something to complain about", I'm interested in a low-maintenance distribution that gets the job done, and although Debian has done that admirably, if another distro can do it better, I'll switch. Actually, as I said above, it looks like I may be forced to switch anyway, so Fedora catching up with Debian in that regard is a good thing.

See, unlike Debian, Red Hat and other distributions are updated twice a year and what was true in 1999 is old news today.

What are you talking about? Debian gets updated *daily*, not every six months. My boxes are nearly always running newer software than anyone using a traditional distro. Hopefully Fedora will provide the same capability.

Re:DebSux

[shaitand]

no, not anymore than you can in debian. you have to update your package lists with those for the new version. Then you have to actually perform the apt-get update. THEN you have to apt-get dist-upgrade. All of which you can do with apt on redhat. In fact that is how I upgraded my own system.

However you missed my real point. Redhat is a bit farther along in the base, but both debian and redhat and individual distribution suck. If they all merged their strengths we would have something, but distro loving zealots like yourself would never let that happen.

Re:DebSux

[shaitand]

You mean ready to configure. That's the part where the installer comes in.

Having an easy way to install and configure software from either the command line or the gui would NOT make linux windows. Being stubborn on these things is not what makes linux linux it's the people who fight simple improvements like these who hold linux back across the board. MOST network admin's don't want to go through more effort than needed. Linux is accepted on the server and workstations because it's rock solid when setup and flexible, NOT because things are as easy to setup to begin with as they should be. There is no reason we can't have both.

Actually having a shortcut made in the gui be a shortcut which is functional in the gui will NOT corrupt the integrity of linux.

Having a consistant clipboard behavior will NOT corrupt the integrity of linux.

Having simple cli and gui installations and configuration will NOT corrupt the integrity of linux.

Having applications intelligently integrate into the gui when their installed (and only if and when their installed) will NOT corrupt the integrity of linux.

Working like windows in some respects will not destroy linux. Adopting the strengths of mac and windows without adopting their problems is what will allow linux to destroy windows.

You want linux systems to replace windows systems on a windows network, then don't make learning how to configure samba a task which requires more than 5mins study for someone who has worked with windows networks for 10yrs.

Re:Installation/uninstallation is a solved problem

[Slack3r78]

While I'm not a huge fan of the concept behind WinFS right now (though admittedly, I haven't done much research) I think your reasoning here is flawed. As far as I'm concerned, needing package managers to track application files because they're scattered everywhere is a hack, plain and simple. It makes for a good solution in the meantime, but saying that it negates the need for improvement is a rather poor view to take on the subject.

It's the same attitude that is causing IPv6 to have such a slow uptake - "NAT lets me have multiple machines behind a single IP, so who cares?" Namely, this attitude assumes that since one of the primary benefits of an improved system is already somewhat addressed by a hack on top of the old system, the new one "isn't really needed," ignoring the host of other benefits that it would provide.

If Linux is to become and stay the leader in operating systems, innovation has to occur. WinFS may not necessarily be the way of the future, but I wouldn't ignore it, and personally, would hope developers would at the very least look to it and try to take what good features they can find in it while maintaining the things linux already does well.

Where would we be now?

[PotatoHead]

Not sure really. I guess knowing the possibilities now will motivate the right folks and we will see the feature soon enough.

Computers are pretty damn fast these days. Given that, I strongly disagree with all the folks who want to get rid of X. Adding these kinds of features is a good thing, just don't break the network features at the same time....

Ximian threat

[G3ckoG33k]

Isn't Gnome's own, independent, development near being trifled since Ximian took on? And, then, where does Ximian lead us for Free Desktops?

See this:

The suggested retail price is $99 (U.S.)

In addition to the Bitstream fonts bundled with GNOME 2.2, Ximian Desktop 2 includes MS-Windows compatible fonts from AGFA*, so your applications, documents and web pages look their best. AGFA fonts available only with Ximian Professional Edition - Buy it now!

Access virtually all print, media, audio and video web content with the bundled Adobe Acrobat Reader, Real Audio Real Player, Macromedia Flash Player 6, and Java 2 Run-time Environment. Available only with Ximian Professional Edition - Buy it now!

In my view there are a lot of "By it now"s, being based on a "free desktop". When did a Windows user pay for Acrobat Reader, Real Audio Real Player, or Macromedia Flash Player 6; apart from the fancy versions?

Where is the incentive in opening the gates for Ximian hell here?! Who is duped? Perens?! Aren't Ximian just like any other money drainer?! To me, it sure looks like that. But, as always, I may be wrong again...

Adobe payed for using Qt and they can probably afford it. How many Mexicans can afford Miguel de Icaza's Ximian? 99$ for a desktop(!) with Acrobat Reader, Real Player, and Flash Player?!

How many Mexicans can afford Miguel de Icaza's Ximian, apart from Miguel himself?

Here are some brave words: "Ximian is offering a complete, low-cost productivity solution for Linux." Mike Rogers, VP and General Manager Desktop and Office Productivity Software Sun Microsystems

Hrmmmm... Somehow, my thoughts are in the direction that this LGPL talk is a setup for giving Ximian a get-go start harvesting all the multimillion dollar berries. But, I may be as wrong as many a time before.

Yes, sure: ftp://ftp.ximian.com/pub/xd2/redhat-9-i386. But, the one who has the copyright on the code does set the agenda to a large extent, and that may be what all this is about.

I have no idea who is pushing the LGPL agenda besides Perens, but Ximian seems to me being a likely candidate. Maybe, I should RTFA... ;)

android installation

[Doc Ruby]

BitchKapoor's post spurred me to download android, which looks like a simple way to start recording xevents, and stop, generating an exectuable tcl file. But the build fails:

"./configure --prefix=<dir>" where <dir>
is the directory where you have installed the tcl/tk you wish to use
with android

runs OK (with any likely --prefix values), but make produces

cp android.tcl android
cc -g -shared -fPIC -o android.so -L/usr/X11R6/lib -ltk -ltcl -lXtst -lXext -lXmu -lX11 -lm android.c
android.c:22: tk.h: No such file or directory
make: *** [android.so] Error 1

I have tcl8.3{-dev} and tk8.3 installed as Debian packages by apt-get. What is the "tcl/tk installation directory" that configure requires? android could be a terrific way to produce demos, training, and even canned IPC for apps that offer no other API.

Re:DebSux

[Joe Tie.]

Ya, and those are all old versions from like a year ago, LOL, nice updates....

I'm using Debian Unstable. Which I moved to mostly because I got tired of how slowly updates came to other distros. Updates for most programs are available almost imediatly after the developer posts them as a new release - often even before. Heck, there's cvs builds of firebird every few weeks - it's the most up to date non source based distro that I've ever come accross.

DBFS == poor performance

[Anonymous Coward]

In my experiences of trying to have a filesystem-over-SQL using MySQL, the performance was poor. For example: with 4 gigabytes of data it would consume 50% or more of my 700 mhz Athlon CPU while reading data at ~20 kilobytes a second. The average record size was about 16 kilobytes.

Re:DBFS == poor performance

[Doc Ruby]

Unless the inode database is replaced with a relational one, DBFS will be much slower, even just because MySQL tables are stored in files, which are stored in the inode database. That's why an interim hybrid, with data stored in a single directory and metadata in the tables (cached in memory) would be a lot faster, until that inode albatross is off our necks (and hard drives).

Re:DebSux

[forlornhope]

Oh wow, that was a really great comparison of order of importance. Comparing a life threatening deases to a minor announce which I exposed your grip for. My point was that it was a simple thing to setup when using knoppix if you have a static link. Also there are very few people on this earth that know how to do medical research in the area of HIV, but you on the other hand obviously know the difference between the DHCP that knoppix expects and your static link and Im sure it wouldnt be much for you to learn how to edit one file and issue one command to bring up your network. So you should really learn to not blow things out of proportion just to make yourself feel smarter and grand stand. Really dont be such an idiot.

Re:DebSux

[DA-MAN]

My point is that you never know where you truly stand unless you blow it out of proportins.

dual screens / monitor support - some surgestions?

[cel-ed]

Currently, I started to work on new VJ software (with cross-platform, open-source in mind), that really needs dual monitor support, like one monitor for controls, buttons and loading stuff, the other monitor just for the realtime (openGL) output. I used to code in 'sdl/openGL' so it could be easy to port the work to different platforms, But from what I found out recently, sdl doesn`t support a dual screen/monitor set-up with parent and child windows, so I`m lost again. Note, I`m not a great coder, but an 'artist' that wants to code. elout (google me)

Re:DebSux

[forlornhope]

Im sorry, but no you dont. My point was about a minor inconinience. You made it about life and death. There is too big of a difference there and then you made an even bigger mistake by trying to apply my opinion about a minor inconvinience to life and death. That is improper and just wrong to use that to make any point that you were trying to make. That is all Im trying to say. Its a minor inconvinence to you because a rather intelegent descision was made by the developers of knoppix. You also said you didnt have time to fix it, well maybe a bug report with a feature request with the fearture I mentioned. It doesnt sound too hard to implement. And before you say it, Im not going to do it because I dont have that problem nor do I care.

YES - X windows IS INCONSISTENT- This is why....

[Anonymous Coward]

Within the buffer funtion you are not forcing the coders to adhere to ANY standards on writing there programs to call X functions. What am I talking about??? (e.g. a buffering function)

Shift-Control-C, Control-C, Alt-C, Alt-Control-C
are used to call one function that SHOULD be the same across all GUI's and applications. Rather then writing a statement within the X windows environment stating that this buffer function can be called one and only single way across all applications.

Now do your remember exactly what is the PASTE function for the other program you are pasting to?

What about the paste function in all the other programs you don't use?!??!

My point exactly.. The beauty of the Borg OS is that on ever copy of Borg OS "Copy" is "Copy" and "Paste" is Alway the same key for "Paste"...

Granted this is not a X window manager issue or a Gnome or KDE issue but this issue could have been stopped by an X window manager in a blink of an eye. OR have a X window manager supporting module that understands what is being called and auto translate it into consistency across all applications...

Too many roads will get a person lost very quickly unless they built all the roads..

I don't need 500 ways to do something, I need one way to do it right!!!

you're confusing specification and implementation

[penguin7of9]

Gnome and kde used to do a different thing with regards to copy and paste. But ever since gnome 2.x and kde 3.x they work identically (for text).

Yes, they now both have lousy support for selections, but at least their support is identically poor. Note that the problem is mostly with application writers, who simply don't understand and don't provide good support for X's selection mechanism. Instead, many Gnome and KDE application writers seem to try their hardest to imitate the feel of Macintosh and Windows applications as closely as possible.

Also, a lot of the graphical effects in gnome and kde are realised through the render extension today. However, the render extension is horribly slow. It's not even anything remotely approaching fast for a software implementation. So, yes, X is to blame for the slow speeds of kde and gnome.

The RENDER extension is a protocol specification. It's neither slow nor fast. And every indication is that RENDER can be implemented very well, both in software and in hardware.

What may be slow is the XFree86 software implementation of RENDER. That can get fixed. XFree86 doesn't define what "X" is, and neither does any other specific implementation.

Furthermore, it was just a bad idea for Gnome and KDE to start relying on a graphics model that X didn't have support for.

Roydd McWilson==BitchKapoor

[Anonymous Coward]

BitchKapoor: C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works

smitty_one_each: Hmmm...no, your remark refers to the pre-processor.

Roydd McWilson: No they don't, but I can see how the wording can make you think otherwise. My point is that when you define a template,...

BitchKapoor: Damn you, Roydd. Should've known you were signed in on my computer.


He's logged into your account and replying as if he is you? Right..

Re:Roydd McWilson==BitchKapoor

[Roydd McWilson]

No, I had left my self logged into his machine, and he was replying on my account.

I seem to remember a slashdot article on

[Anonymous Coward]

something able to generate infinitely many packets of information on a file, all of which are different, and the end result is that a file can be reconstructed after x packets are received. The original use for this system was to prevent the "I didn't get that, send it again." thing to make downloading faster.

The biggest problem with this system is the downloading end receiving redundant packets...

If MUTE could somehow be combined with that system, each packet would be different, and downloading would be faster with more users, due to the entire network sending packets on the downloading file...

If you're happy with a lightweight WM, that's fine

[g_bit]

However, you're not going to get the same productivity from X with a lightweight WM as you do with Windows.

I guess I'm wasting my time arguing about this, so here's the bottom line for me: In Windows, I can drag a file from Explorer into almost any application, and I have a reasonable expectation of that file being opened by that app. I can cut text from any app, and paste it into any other app with confidence.

There are no such guarantees with X, and this seriously effects productivity. I don't see what the problem is. Why can't somebody get their ass in gear and build something that really works well for *nix on the desktop? I guess that's OSX, but then you're tied to hardware. Arrg!

Re:DebSux

[shaitand]

The fedora project itself typically follows suit with redhat in terms of only backporting security patches. However if you install apt for rpm from freshrpms and possibly add a few other repositories you won't be disappointed. All my packages stay up to date.

I may have spoken a bit too quickly about going from 7.3 since I haven't tried to update from that particular version and there are significant binary compatiblity problems going from it on to the other versions. However in the normal way of things you can upgrade using apt.

When you marry apt+3rd party repositories with redhat/fedora you honestly won't miss debian much (after you get used to a few files being named differently and such, which is just typical growing pains).

As I said before, the biggest advantage redhat has over debian is the hardware autodetection which is second to none and sane defaults. The worst boat you'll get into is having to do the same as you would with debian to begin with, configuring things manually. The net result in saved time is worth it's weight in gold.

Added stability in debian from what I've experienced is really just a myth, moreso than it is with BSD. All of the above equate to a rock solid system that never goes down short of hardware failure if properly configured. It's kind of ridiculous to claim additional stability over a system that has no stability issues ;)

"What are you talking about? Debian gets updated *daily*, not every six months. My boxes are nearly always running newer software than anyone using a traditional distro. Hopefully Fedora will provide the same capability."

I think he means the honest to god offical iso release. There is an official new fullblown release every 6-12months.

Re:If you're happy with a lightweight WM, that's f

[TKinias]

scripsit g_bit:

However, you're not going to get the same productivity from X with a lightweight WM as you do with Windows. If I could pick my WM and have a properly working terminal, maybe Windows would be more user-friendly, but I can't.

Again, YMMV (this is why choice is good), but I get much higher productivity with (at the moment) IceWM on Debian Sarge than I can with any version of Windows.

In Windows, I can drag a file from Explorer into almost any application, and I have a reasonable expectation of that file being opened by that app.

I personally don't have any use for drag-and-drop. It seems like a very cumbersome way of doing things to me; it's much easier to type `openoffice foo.sxc' in an xterm than fiddle around with a GUI file manager and trying to find the app in the Start menu. But many people seem to like to work this way, which is why the desktop environments (Gnome/KDE) are implementing it. I can't say what the status is, but AFAIK the basic functionality is there.

I can cut text from any app, and paste it into any other app with confidence.

This one again... I really don't know why the belief that this doesn't work under X is so prevalent. I spend most of my waking hours working on Linux desktops and have never found an app that doesn't understand highlight-to-copy and middle-click pasting. Maybe some distros that I don't use just have horribly broken X setups or something, but I can say with confidence that it Just Works with a variety of WMs on Debian systems.

Re:DebSux

[swillden]

no, not anymore than you can in debian. you have to update your package lists with those for the new version. Then you have to actually perform the apt-get update. THEN you have to apt-get dist-upgrade.

You're picking nits, so I'll pick back.

Assuming you don't use specific release names in your sources.list, you don't have to edit it. Then:

apt-get update && apt-get dist-upgrade

Done. One command line.

Re:YES - X windows IS INCONSISTENT- This is why...

[Anonymous Coward]

My point exactly.. The beauty of the Borg OS is that on ever copy of Borg OS "Copy" is "Copy" and "Paste" is Alway the same key for "Paste"...

Yes, you're exactly right. This is why when you bring up a command prompt in the Borg OS, click and drag some text with the mouse, and press CTRL-C, it copies the text to the clipboard.

Er... Oh wait.

It seems you are not right. Sorry.

Re:DebSux

[shaitand]

still two commands. You could actually edit the sources.list and still keep it in a single commandline but it would be several commands.

It'd be better to slap it in a shell script, update-distro. Then you can compact it into one. ./update-distro

Re:DebSux

[swillden]

the biggest advantage redhat has over debian is the hardware autodetection

That's an irrelevant advantage, for me. I don't get new hardware all that often.

Different methods of event handling

[Anonymous Coward]

Subclassing in windows is done with regard to event handling. It has nothing to do with C or C++.
Some frameworks on top of the interface implement the OO way (MFC, VCL and the like). A lot of confusion comes from this.
The complete underlying windows handling process in windows programming is based on the ProcessMessages call. When an event is fired in the system, it is given to the application on top, which handles the message if known, if not handles it to the parent window container.
This is mainly the reason why windows applications feel fast. Instead of dispatching messages to applications and then let the applications figure out what control is on top, messages are going the other direction.
If messages are related to specific windows drawing, this specific drawing is more to the top level of the application and not deeply down the inheritance/order.

A lot of other frameworks work with installing listeners. This is faster in getting the message to the component but the slowlyness is in deciding what listener is on top and what to do with the message then. If it is a paint operation, it needs to go down deep in the system to find its painting and reconstruction of list of listeners for each level.

This summarises as such: clear OO based interface designs are neater but feel sloppier. Sometimes clean OO design does not pay back into neater development, especially if the initial design did not take into account all possible extentions. Unfortunately this is sometimes the case.

But all theoretical exposes fall short compared to what can be obtained with detailed analysis and code optimisation. Both Windows and Quartz show that either system can be fast. Let not throw away the child if it can be made better with some simple code optimisation.