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."
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.
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.
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.
"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!
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.
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?
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
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.
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.
getSexySig();
"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
Who on earth would want to use their new X server? It's full of bugs! (Ark ark ark).
:)
Couldn't resist.
I think there is a world market for maybe five personal web logs.
Translation: We'll be stealing more stuff from OS X than Microsoft!
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.
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.
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.
Everything will be taken away from you.
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?
> 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.
-- B.
This sig does in fact not have the property it claims not to have.
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?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
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.
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.
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