Slashdot Mirror
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."
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.
Help me. I've been modbombed by a few people with entirely too much time on their hands.
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.
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.
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
Computers are useless. They can only give you answers.
-- Pablo Picasso
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.
mogorific carpentry experiments
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.
--
make install -not war
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
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.
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."
Bít, zabít, jen proto, ze su liska!
"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.
--
make install -not war
You mean something like Android?
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.
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.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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 :)
"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.
Arbitrary sig
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.
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.
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.
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.
I thnk you'll find that Linux (and Solaris) WILL beat Longhorn to the 3D desktop:
http://wwws.sun.com/software/looking_glass/
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.
/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.
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
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
Live today, because you never know what tomorrow brings
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.
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.
Give me Classic Slashdot or give me death!