Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GUI Software Linux

Hackers on Linux's Exciting Desktop Future 338

Posted by michael from the join-the-army-see-the-world dept.
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."
This discussion has been archived. No new comments can be posted.

Hackers on Linux's Exciting Desktop Future More

Hackers on Linux's Exciting Desktop Future

Comments Filter:

  • Shortfalls of GTK+ (Score:5, Informative)

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

    • Re:Shortfalls of GTK+ (Score:3, Interesting)

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

      I have stressed KDE much more that I have Gnome with m

    • subclasses = versions (Score:4, Interesting)

      by Doc Ruby ( 173196 ) on Friday December 19, 2003 @11:47PM (#7771393) Homepage Journal
      "Derived objects", subclasses, are new versions of the subclass. Not only do subclasses allow the code factoring to a shared base functional class, they reflect the iterative development of new functionality. That includes not only added functions and revised overridden functions, but also deprecation of functionality by overriding with null methods, without breaking the API. Subclassing allows an object of an old class to call an object of a new, revised class, using the same API, getting the current functionality. It brings the main benefit of OO, calling an API without dependency on implementation details, to versioning.

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

      • Re:subclasses = versions (Score:4, Informative)

        by BitchKapoor ( 732880 ) on Saturday December 20, 2003 @12:00AM (#7771456) Homepage Journal
        Subclassing allows an object of an old class to call an object of a new, revised class, using the same API, getting the current functionality.

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

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

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

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

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

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

        • Re:subclasses = versions (Score:4, Interesting)

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

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

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

    • Re:Shortfalls of GTK+ (Score:4, Insightful)

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

    • Wrong, with my apologies. (Score:5, Informative)

      by Balinares ( 316703 ) on Saturday December 20, 2003 @02:08AM (#7771953)
      > 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 [trolltech.com] 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 [telegraph-road.org], if you'd care for a slightly different point of view on the same topic.

      • Re:Wrong, with my apologies. (Score:4, Informative)

        by IamTheRealMike ( 537420 ) * on Saturday December 20, 2003 @04:26PM (#7774527)
        Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.

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

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

        b) It's extremely poor usability wise.

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

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

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

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

  • This is excellent (Score:4, Interesting)

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

    • Re:This is excellent (Score:5, Funny)

      by aardvarkjoe ( 156801 ) on Friday December 19, 2003 @10:52PM (#7771150)
      When I first used Linux and I ran X, my thought was "damn, this is slow."

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

      • Re: This is excellent (Score:4, Insightful)

        by Marsell ( 16980 ) on Saturday December 20, 2003 @05:09AM (#7772353) Homepage
        I often see the comment that X is slow, something I've never understood. I too ran linux and X on a 486. Specifically, I was running XFree86 3.3.3 (or 3.3.6?) with linux 2.0.35 (yes, I had that 486 for ages) on a 486 66MHz with 16MB ram.

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

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

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

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

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

    • Re:This is excellent (Score:2, Insightful)

      by BrookHarty ( 9119 )
      When I first used Linux and I ran X, my thought was "damn, this is slow."

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

      But speed? Nope, even playing games in Vmware is fast.
    • Cut, copy, and paste is an application thing, not really so much an X thing. If the app doesn't know how to retrieve a PNG or XLS from the clipboard, no amount of X advancement or extension is going to fix that. I haven't found X to be really slow, but Xinerama definately is (well unoptimized, at least). X in general may be funky in that it seems to be very serial and synchronous, but it is not necesarily slow. I cite how my Enlightenment applets and XMMS visualizations don't update when I'm moving wind

      • Your Mom's a troll. (Score:2, Informative)

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

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

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

      X was never slow. For the most part, KDE is faster than XP on my machine. X apps, however, have traditionally have done dumb things, and there have been problems with synchronization.
      • Would you say that KDE is faster than Gnome on the same install? The reason I ask is that I am running Redhat 9.0 in a VMware virtual machine and quite honestly it is a little on the sluggish side (I use Gnome, haven't installed KDE yet.)

        One other completely off topic question - how the hell do I tweak the mouse speed and acceleration under X (Gnome)? I bring up settings for the mouse and it lets me pick a mouse - that's it. Bugs me to run off the edge of the desk before I get to the edge of the desktop
    • When I first used linux and I ran X, my thought was, "wow, this is a whole lot better than windows!" And this was on my 386DX25 with 8MB ram, 120MB IDE disk, and 1MB ISA Trident VGA card. What OS were you used to at the time? GEOS? Or just DOS?

    • Re:This is excellent (Score:5, Insightful)

      by penguin7of9 ( 697383 ) on Saturday December 20, 2003 @02:52AM (#7772079)
      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.

  • More Stolen SCO code (Score:5, Funny)

    by Sabalon ( 1684 ) on Friday December 19, 2003 @10:49PM (#7771131)
    These advances must have been stolen from SCO...there is no way a bunch of random hackers could have thought them up an implemented themselves.

  • My Favorite Device Status Message! (Score:5, Funny)

    by aheath ( 628369 ) * <adam,heath&comcast,net> on Friday December 19, 2003 @10:51PM (#7771138)
    I really enjoyed the Robert Love Q&A because I learned about a new device status:

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

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

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

    • Re:Maybe more automatic testing tools for GUI? (Score:4, Interesting)

      by hacker ( 14635 ) <hacker@gnu-designs.com> on Friday December 19, 2003 @11:59PM (#7771445)
      "Hopefully there will be some free tool that automate the process of "test case1: click file, click open, choose /home/xx/ss.xx, choose node33 in treeview, TAB", so that the GUI parts of GUI applications can finally be as well tested as traditional command-line applications."

      You mean something like Android [wildopensource.com]?

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

      But it's important to distinguish between a Unit Test [c2.com] (which is easy to write, even for GUI programs), and an Acceptance Test [c2.com], 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

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

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

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

  • The secret agenda? (Score:5, Insightful)

    by bjarvis354 ( 319402 ) * on Friday December 19, 2003 @10:54PM (#7771160) Homepage
    It seems that there are many here who are flaming any topic that relates to mainstream desktop penetration of Linux.

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

    • Re:The secret agenda? (Score:3, Insightful)

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

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

  • One good reason to like open-source software (Score:5, Interesting)

    by Anonymous Coward on Friday December 19, 2003 @11:10PM (#7771239)
    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.

  • Answer to WinFS (Score:5, Interesting)

    by lawpoop ( 604919 ) on Friday December 19, 2003 @11:15PM (#7771265) Homepage Journal
    This is something we really need if we are interested in getting users to convert to linux. Currently, linux apps put their crap all over the place. If we had true virtual directories* with drag&drop installation of applications, linux would be second to Mac for ease of installation and un-installation.

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

    *Not symlinks

    • Re:Answer to WinFS (Score:3, Insightful)

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

      • Re:Answer to WinFS (Score:5, Interesting)

        by lawpoop ( 604919 ) on Friday December 19, 2003 @11:39PM (#7771359) Homepage Journal
        It's not only the metadata, but the unification of virtual directories that gives the benefit.

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

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

        • Re:Answer to WinFS (Score:3, Funny)

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

        • Re:Answer to WinFS (Score:4, Insightful)

          by damiam ( 409504 ) on Saturday December 20, 2003 @12:21AM (#7771541)
          With virtual directories, you could have a setup like :
          /applications/$application/bin
          /applications/$application/conf
          /applications/$application/conf/$user
          /applications/$application/init
          And then to get rid of an application, just rm -rf /application/$application.

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

          • Re:Answer to WinFS (Score:3, Insightful)

            by lawpoop ( 604919 )
            It seems what you're talking about is our regular old hierarchical filesystem with a rdbms keeping track of locations. The idea of the dbfs is that it totally replaces a hierarchical filesystem. The user would never see a tree or a hierarchy. The rdbms decides where on the disk to put data. It then presents the data to the user in a way that closely mirrors the relationship of the data. The only reason we still use the hierarchical filesystem is pure cruft.
            • I wasn't talking about using an rdbms at all. I was talking about two different ways to organize a traditional hierarchical system, both of which require a "database" in the loosest sense of the term (i.e. could easily be a flat text file).

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

            • Re:Answer to WinFS (Score:5, Insightful)

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

              • Re:Answer to WinFS (Score:2, Interesting)

                by firewrought ( 36952 )
                Mod parent up.

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

              • Re:Answer to WinFS (Score:3, Informative)

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

                So really, you'd be getting the best of both worlds. You'd have everything related to Application X all stored in one place making dealing with it as an individual application far easier, but y

      • Re:Answer to WinFS (Score:3, Insightful)

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

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

        Sure, it may have seemed like a brilliant idea 18 hours ago when you decided
      • The directory structure containing a file is often used as metadata (used in a meaningful way other than simply as a container)... this is just a less-than-ideal way to store metadata since it's fairly brittle and often completely arbitrary.
    • Granted, this would be a step in the right direction. However, ease of use requires "developers, developers, developers" and the right tools for developers.

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

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

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

        I don't think it was so much that it wasn't free, but that it wasn't better than what was available at the time for free. I bought the personal edition of delphi when I was using Windows, and was quite prepared to buy Kylix if I felt it was worth it. I just didn't think it was though. Firstly, the look and feel. This was about the time that unified kde/gtk themes were making an appearence, th

    • Re:Answer to WinFS (Score:3, Interesting)

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

  • Desktop is good, but falls a little short for me (Score:5, Interesting)

    by wackybrit ( 321117 ) on Friday December 19, 2003 @11:25PM (#7771299) Homepage Journal
    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.
    • 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
    • That said, I still use a Windows desktop.. why?

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

  • usable drop shadows (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Friday December 19, 2003 @11:27PM (#7771310) Homepage Journal
    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.

  • Interview summary (Score:5, Funny)

    by An Anonymous Hero ( 443895 ) on Friday December 19, 2003 @11:38PM (#7771354)
    1. OSNews: (100 words)?

    R. Love: HAL

    2. OSNews: (99 words +) BeOS?

    R. Love (diplomatic): Yes and no.

    3. OSNews: (600 words)?

    R. Love: No.

    4. OSNews: (20 words)?

    R. Love: HAL.

    5. OSNews: (19 words +) HAL?

    R. Love: Yes, HAL.

    6. OSNews: (600 words)?

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

    7. OSNews: (100 words)?

    R. Love: No.

  • HAL (Score:4, Funny)

    by KoolDude ( 614134 ) on Friday December 19, 2003 @11:41PM (#7771369)

    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.

  • Stay away from the X server (Score:4, Funny)

    by drix ( 4602 ) on Friday December 19, 2003 @11:47PM (#7771394) Homepage
    Who on earth would want to use their new X server [freedesktop.org]? It's full of bugs [freedesktop.org]! (Ark ark ark).

    Couldn't resist. :)

  • Hackers on Linux's Exciting Desktop Future (Score:3, Funny)

    by Anonymous Coward on Saturday December 20, 2003 @12:17AM (#7771525)
    Translation: We'll be stealing more stuff from OS X than Microsoft!

  • The lesson to be learned (Score:5, Interesting)

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

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

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

  • kdrive is nice (Score:2, Interesting)

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

  • Sarcasm? (Score:2, Interesting)

    by DoctorHibbert ( 610548 )
    "Hackers on Linux's Exciting Desktop Future"

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

  • Translucency (Score:4, Insightful)

    by starnix ( 636547 ) on Saturday December 20, 2003 @01:33AM (#7771824)
    Who gives a flying fuck? Translucency has to be the most overhyped, useless, wasteful feature I've ever heard of. Ooooh look, I can make my menus hard to read. WTF. Can someone please explain all the effort being put into this completely useless feature?

    • Re:Translucency (Score:3, Insightful)

      by PotatoHead ( 12771 )
      I have one idea, though it has very little to do with menus.

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

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

      and

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

      B

    • Re:Translucency (Score:5, Interesting)

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

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

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

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

    • Re:Translucency (Score:4, Insightful)

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

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

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

    linux needs to stop answering, and start innovating ;)

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

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

    an opengl desktop (assuming linux) would be

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

    and would win a lot of people over :)

    also it would improve graphic driver support through neccesity, and with that comes a better foothold for the gaming in

  • Eugenia mocked up some nice interfaces (Score:3, Interesting)

    by crush ( 19364 ) on Saturday December 20, 2003 @02:05AM (#7771944)
    She only mentions/links to one example screenshot of them in her article, but they're all very nice:

  • desktop hype (Score:3, Insightful)

    by potpie ( 706881 ) on Saturday December 20, 2003 @02:29AM (#7772002) Journal
    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.

    • Freedom of choice... (Score:3, Interesting)

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

      On the other hand, when I'm looking

  • too many cooks making too many users happy (Score:4, Insightful)

    by penguin7of9 ( 697383 ) on Saturday December 20, 2003 @03:10AM (#7772123)
    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.

  • Does linux really have desktop future? (Score:3, Interesting)

    by jarek ( 2469 ) on Saturday December 20, 2003 @04:45AM (#7772284)
    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.

  • Desktop future (Score:3, Interesting)

    by Elektroschock ( 659467 ) on Saturday December 20, 2003 @06:44AM (#7772519)
    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 [urbanlizard.com].

  • Ok, they're all pretty and blazing fast... (Score:3, Insightful)

    by gregorio ( 520049 ) on Saturday December 20, 2003 @10:33AM (#7772894)
    ...but all I want is:

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

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

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

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

  • Ximian threat (Score:3, Informative)

    by G3ckoG33k ( 647276 ) on Saturday December 20, 2003 @02:35PM (#7773981)
    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.) [ximian.com]

    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! [ximian.com]

    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! [ximian.com]

    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 [trolltech.com] 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 [ximian.com]

    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 [ximian.com]. 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... ;)

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Close