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!
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.
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
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!
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();
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?
"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.
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."
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.
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
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?
..'Linux answer to WinFS'..
;)
:(
:)
:/ like it or not.
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
-judging another only defines yourself
> 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.
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.
Esoteric reference.
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.
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.
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.
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
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
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.
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...
--
make install -not war
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!