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 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?
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.
And then to get rid of an application, just rm -rf
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.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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?
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.
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.
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). /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.
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
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.