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."

80 of 338 comments (clear)

  1. Shortfalls of GTK+ by BitchKapoor · · Score: 5, Informative

    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.

    1. Re:Shortfalls of GTK+ by Anonymous Coward · · Score: 3, Interesting

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

      I have stressed KDE much more that I have Gnome with much more success. The only problem is KDE is ugly as hell and way over done with gadgetry.

      I don't mean to be so negative. Both projects show much promise, but both miss the boat in very different ways. I guess I'll just keep wiating on the side-lines in geekdome and leave my friends and family on Windows [I can't even interest them in the Mac]. Who knows, every once in a while Enlightenment shows some interesting potential.

    2. Re:Shortfalls of GTK+ by BitchKapoor · · Score: 5, Insightful
      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.

      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.

    3. Re:Shortfalls of GTK+ by drix · · Score: 3, Insightful

      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.

      --

      I think there is a world market for maybe five personal web logs.
    4. Re:Shortfalls of GTK+ by smittyoneeach · · Score: 2, Interesting
      C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works;

      Hmmm...no, your remark refers to the pre-processor.
      Here is some reading to catch you up on what's going on.
      Also, Boost, the CPAN of CPP, will go a long way to improving understanding.
      Mods, BK isn't insightful, mod appropriately.
      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    5. Re:Shortfalls of GTK+ by NateTech · · Score: 2, Insightful

      Most of us probably value the Freedom of Speech and the lack of censorship more than we want a censor app built into the system.

      Teach your 2 year old proper values as he is growing up and he'll be able to make the same (or more likely, different but similar) value judgements you are making. If you shelter him from it, he'll just seek it out out of natural curiosity about what Dad's so freaked out about anyway.

      I'd be proud of any 2 year old who could read Slashdot anyway, even if the content might have to be explained by their loving parent.

      He (and you) will be fine.

      --
      +++OK ATH
  2. This is excellent by SoIosoft · · Score: 4, Interesting

    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.
    1. Re:This is excellent by aardvarkjoe · · Score: 5, Funny

      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.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    2. Re:This is excellent by Dr.+Photo · · Score: 4, Informative
      Not sure about other cards, but for a Radeon (open source driver), add the following to your XF86Config file (under Section "Device")
      Option "DDCMode" "true"
      Any remotely modern monitor will then report its optimal refresh rates to the video card when X starts. No more modeline yuckiness. :-)
    3. Re:This is excellent by penguin7of9 · · Score: 5, Insightful

      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.

    4. Re: This is excellent by Marsell · · Score: 4, Insightful

      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.

  3. More Stolen SCO code by Sabalon · · Score: 5, Funny

    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.

  4. My Favorite Device Status Message! by aheath · · Score: 5, Funny
    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!

    1. Re:My Favorite Device Status Message! by cthugha · · Score: 2, Funny

      Your processor is only overeating because your constant carping about its performance is making it depressed, you insensitive clod.

  5. Re:DebSux by Sabalon · · Score: 2, Offtopic

    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.

  6. Maybe more automatic testing tools for GUI? by r6144 · · Score: 4, Insightful

    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.

    1. Re:Maybe more automatic testing tools for GUI? by hacker · · Score: 3, Interesting
      "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?

      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.
    2. Re:Maybe more automatic testing tools for GUI? by Ian+Bicking · · Score: 2, Interesting
      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 (which is easy to write, even for GUI programs), and an Acceptance Test, which can be hard to write.

      A GUI test shouldn't test something like "when you go to Window>Server List, and leave the window open, showing an active status message by starting a connection by right clicking the server and selecting 'Refresh', then you open the properties with Edit>Properties and change the settings that efect the server, the still-running connection works properly with the old settings until the refresh is completed". That's the kind of corner case where you're likely to find a bug, but testing that sort of thing is nigh impossible -- especially when the software is changing, and the interface is changing, and this is one among thousands of corner cases.

      When you use unit tests you don't test a complete thing like that. You test each part, but you test it very completely. You may not test the GUI at all -- instead you test that the underlying server code and preference code work properly. You test that they work to spec, and not just within the bounds of the interface. Maybe in version 1 you can't select both the server window and the preferences window at the same time, so this situation is impossible. But you can still make a unit test for this case.

      When you do that, you avoid a huge number of bugs. At that point you don't need to test the entire program by simulating input. Instead you rely on the fact that each component works in a controlled and correct fashion. Then, fitted together, they all work together. Sure, the people writing GTK need unit tests -- but only for what GTK does, not for the particulars of how your application uses GTK. And so it goes, we each build upon well-tested code, but we don't retest that code. We trust the upstream developer.

      Of course, we've all seen bad interactions between things we wouldn't expect. Part of using unit testing is to make components that work in an isolated fashion, components that can be tested in isolation. Reducing coupling between components is essential.

      Which is again a reason why GUI applications are hard to test -- coupling is encouraged, because it's usually a better user interface. You want to fit everything together based on the best metaphor for the user, the most expressive interface you can get, expected workflow, etc. That often doesn't match up with the underlying objects you are using. It's often highly coupled. But you can have that in one part of your system, so long as you really trust the pieces its built on.

      I think as more areas of open source embrace unit testing and test driven development -- and it's happening rapidly! -- that we'll see some significant improvements in quality. And it's great for open and free software, because unit testing is something that's hard to bolt on later. But you can do it, it just requires a lot of refactoring. Because of the availability of the source, refactoring is an option for us. Because APIs for environments like Windows or Java are largely set, and the components largely opaque, they don't have this option.

    3. Re:Maybe more automatic testing tools for GUI? by krogoth · · Score: 2, Insightful

      I can see two simple ways to find and fix obscure crashes, which I have been considering for my app 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; hopefully, this will help find crashes.

      Since I'm writing a KDE app, I could add a dcop interface and script tests from the command line, or use automated Qt testing tools to get an even more detailed view of what's being done.

      --

      They that quote Benjamin Franklin on liberty and safety deserve neither.
  7. The secret agenda? by bjarvis354 · · Score: 5, Insightful

    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?

    1. Re:The secret agenda? by StarTux · · Score: 2, Insightful

      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?

    2. Re:The secret agenda? by bjarvis354 · · Score: 2, Insightful

      It is indeed a interesting paradox. However, is it not important to the entirety of the GNU/Linux movement in general that the ideals OSS and GNU be reconciled?

      I am not a programmer. Sure, I know some bits and parts, but in the end I am an end user who likes a powerful and flexible OS, it is awe inspiring. It has spurred me to look seriously at learning C. To me it is about learning and sharing that knowledge. While I may not be able to hack like many here, I want to extend my knowledge of programming and be able to shape the software to suit my needs. Only the fusion of Open Source Software and Free Software, together, provides that opportunity.

      The funny thing is that while I don't like the flame wars, given the other options (proprietary closed source software) all of this would be moot. You take what you are given and you like it, no discussion.

  8. One good reason to like open-source software by Anonymous Coward · · Score: 5, Interesting

    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.

  9. Answer to WinFS by lawpoop · · Score: 4, Interesting
    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

    --
    Computers are useless. They can only give you answers.
    -- Pablo Picasso
    1. Re:Answer to WinFS by Josh+Booth · · Score: 2, Insightful

      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.

    2. Re:Answer to WinFS by lawpoop · · Score: 4, Interesting
      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.

      --
      Computers are useless. They can only give you answers.
      -- Pablo Picasso
    3. Re:Answer to WinFS by timeOday · · Score: 2, Interesting

      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.

    4. Re:Answer to WinFS by Anonymous Coward · · Score: 3, Funny

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

    5. Re:Answer to WinFS by damiam · · Score: 4, Insightful
      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.

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    6. Re:Answer to WinFS by Keeper · · Score: 2, Insightful

      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 to re-organize your mp3's into folders by artist, then album, and then song. Until you come across a song with two artists in it. Or when you want to look for a specific album but don't remember who sang it.

      The point is that manually organizing your files is a cludge to do what you really want to do: be able to find what you're looking for quickly. Since it is a manual process, it is slow, error prone, and a royal pain in the ass.

    7. Re:Answer to WinFS by lawpoop · · Score: 2, Insightful

      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.

      --
      Computers are useless. They can only give you answers.
      -- Pablo Picasso
    8. Re:Answer to WinFS by pherthyl · · Score: 5, Insightful

      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.

    9. Re:Answer to WinFS by firewrought · · Score: 2, Interesting
      Mod parent up.

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

      --
      -1, Too Many Layers Of Abstraction
    10. Re:Answer to WinFS by cscx · · Score: 2, Informative

      CMD.EXE is just a command shell and won't hook into the registration info unless you tell it. Instead of "winword", at the cmd.exe prompt, type "start winword"

      start.exe will hook into the subsystem...

    11. Re:Answer to WinFS by Slack3r78 · · Score: 2, Informative

      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 you'd still have the old filesystem where all your config files, binaries, etc are grouped together as well. Sounds like a rather good idea to me.

  10. Desktop is good, but falls a little short for me by wackybrit · · Score: 4, Interesting

    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.

  11. usable drop shadows by Doc+Ruby · · Score: 3, Interesting

    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

  12. Re:DebSux by shaitand · · Score: 3, Interesting

    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

  13. Ease of use requires more than a good FS by g_bit · · Score: 2, Interesting
    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.

  14. Re:DebSux by Fancia · · Score: 2, Interesting

    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!
  15. Interview summary by An+Anonymous+Hero · · Score: 4, Funny
    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.

  16. HAL by KoolDude · · Score: 3, Funny


    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(); /* returns sexy signature */
  17. Re:Desktop is good, but falls a little short for m by shaitand · · Score: 2, Insightful

    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?

  18. subclasses = versions by Doc+Ruby · · Score: 3, Interesting

    "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

    1. Re:subclasses = versions by BitchKapoor · · Score: 4, Informative
      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.

    2. Re:subclasses = versions by BitchKapoor · · Score: 2, Interesting

      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).

    3. Re:subclasses = versions by Doc+Ruby · · Score: 3, Interesting

      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 before they even meet on the road in the wilderness, let alone join forces.

      --

      --
      make install -not war

  19. Stay away from the X server by drix · · Score: 3, Funny

    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.
  20. Your Mom's a troll. by g_bit · · Score: 2, Informative
    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."

  21. Hackers on Linux's Exciting Desktop Future by Anonymous Coward · · Score: 3, Funny

    Translation: We'll be stealing more stuff from OS X than Microsoft!

    1. Re:Hackers on Linux's Exciting Desktop Future by Sviams · · Score: 2, Insightful

      Seems to me that in order to succeed on the desktop market, a consistent and well designed UI is needed. While /. is filled to the rim with OSS hacking gurus, what about all those OSS UI designers that must be out there hiding somewhere?

      I guess all I'm saying is that while optimizing the kernel is neat and all, your average user won't recognize any more than what's in front of him, and I sincerely believe that more than good response times are needed to impress someone enough to leave an OS that already has a consistent design and style guide in it's UI (read commercially developed UI's).
      While having several options (KDE, Gnome) is nice, the lack of enforced style guides and behavior patterns will inevitably give the user a feeling of inconsistency.

      Enough trolling for one day, merry christmas.

  22. Re:DebSux by interiot · · Score: 3, Insightful
    Okay, I'll nibble.

    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.

  23. The lesson to be learned by arvindn · · Score: 4, Interesting
    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.

  24. Re:DebSux by Joe+Tie. · · Score: 4, Insightful

    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.
  25. kdrive is nice by brendan_orr · · Score: 2, Interesting

    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 :)

  26. Sarcasm? by DoctorHibbert · · Score: 2, Interesting

    "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
  27. Translucency by starnix · · Score: 4, Insightful

    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?

    1. Re:Translucency by PotatoHead · · Score: 2, Insightful

      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.

      Basically, I believe there are GUI elements that could inform people and possibly present transient choices in a manner that is not as distracting as todays "ok to..." elements.

      Think video game like instead of microsoft office like, but with some style.

      I agree totally with you on the menus. Nice eye candy, but little use at this point.

    2. Re:Translucency by caseih · · Score: 4, Interesting

      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.

    3. Re:Translucency by Tim+C · · Score: 3, Insightful

      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.

    4. Re:Translucency by firewrought · · Score: 2, Insightful
      Can someone please explain all the effort being put into this completely useless feature?

      Wow... I love how you can encounter a bad usage of a technique and dismiss it forever with one sweeping declarative statement.

      Translucency deserves to be a fundamental part of the modern windowing system. It's not a "version 1" feature, but it is important. Here's why:

      Reason 1: Eye Candy
      A good designer can get a lot of eye-candy mileage out of translucency. Agreed... there's a lot of stupid stuff that designers can do with the effect, but on the whole, it can add some remarkably classy effects to a basic GUI design. Apple OS X uses this strategically, as does some themes I've seen for KDE.

      Good, clean aesthetic design makes Linux more attractive to newbies... and, confess it, we hardcore geeks kinda like it too. Obviously, I am NOT talking about the gratitious use of hyperactive Flash animations and dorky custom GUI's for business tools (a la Kai's Powertools)... those things should crawl back to the marketing department that spawned them.

      Reason 2: Usability
      Beyond aesthetics, the appropriate use of translucency can help you convey more information to your users. One example: antialiased text. Other, better examples are waiting to be found as transparency creeps into more and more windowing systems/applicaitions.

      Reason 3: Completeness
      Deciding which features should or should not go into a toolset API can sometimes be a challenge. However, there tends to be a natural "stratification" to a lot of these features those... for instance, if you have an appliance with a "volume" feature, you generally expect it to have a "mute" feature too (even though it used to be absent in older TV sets, stereos, etc.). Likewise, if an app lets you "copy" and "delete" an object, you expect it to also give you a "cut" option, even though this is redundant. Graphics programmers must work with Red, Green, and Blue... since they are having to do a lot of work building up a raster image, they kind of expect to see Alpha there as well. If the graphics API doesn't put it there, they will have to go off and write it themselves. If the windowing system implements this, it just makes life that much easier and helps avoid some duplicate code.

      Reason 4: Inevitablity/B>
      Sometimes features have to be added to software because users demand it. You may think you've provided a good clean technical solution, but academic purity only oges so far in the real world.

      --
      -1, Too Many Layers Of Abstraction
  28. the problem with linux on the desktop is... by null-sRc · · Score: 2, Insightful

    ..'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 industry, which is also another drawback for linux :/ like it or not.

    --
    -judging another only defines yourself
  29. Copy and paste needs fixed. by crush · · Score: 2, Interesting
    Kindly explain what you mean by:
    Copy and paste needs fixed.
    By the way, I just copied and pasted that and it's one of the things I love most: left-button drag highlight, right-button paste. Works For Me.
  30. Eugenia mocked up some nice interfaces by crush · · Score: 2, Interesting
    She only mentions/links to one example screenshot of them in her article, but they're all very nice:
  31. Wrong, with my apologies. by Balinares · · Score: 4, Informative

    > 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.
    1. Re:Wrong, with my apologies. by azzy · · Score: 5, Funny

      Yeah.. maybe they would have been better off inventing a special toolkit all for themselves.

      *ducks and runs* Sorry! Couldn't resist!

    2. Re:Wrong, with my apologies. by IamTheRealMike · · Score: 3, Informative
      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.

  32. Re:DebSux by swillden · · Score: 4, Insightful

    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.
  33. desktop hype by potpie · · Score: 2, Insightful

    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.
  34. too many cooks making too many users happy by penguin7of9 · · Score: 3, Insightful

    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.

  35. Does linux really have desktop future? by jarek · · Score: 3, Interesting

    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.

  36. Desktop future by Elektroschock · · Score: 2, Interesting

    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.

  37. Re:DebSux by Anonymous Coward · · Score: 2, Insightful

    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.

  38. Freedom of choice... by Kjella · · Score: 2, Interesting

    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 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 /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.

    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
  39. Ok, they're all pretty and blazing fast... by gregorio · · Score: 3, Insightful
    ...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.

  40. Re:Question about KDE performance vs Gnome by nitehorse · · Score: 3, Insightful

    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

  41. Re:Installation/uninstallation is a solved problem by Slack3r78 · · Score: 2, Interesting

    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.

  42. Ximian threat by G3ckoG33k · · Score: 2, Informative

    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... ;)

  43. android installation by Doc+Ruby · · Score: 2, Informative
    BitchKapoor's post spurred me to download android, which looks like a simple way to start recording xevents, and stop, generating an exectuable tcl file. But the build fails:
    "./configure --prefix=<dir>" where <dir>
    is the directory where you have installed the tcl/tk you wish to use
    with android
    runs OK (with any likely --prefix values), but make produces
    cp android.tcl android
    cc -g -shared -fPIC -o android.so -L/usr/X11R6/lib -ltk -ltcl -lXtst -lXext -lXmu -lX11 -lm android.c
    android.c:22: tk.h: No such file or directory
    make: *** [android.so] Error 1
    I have tcl8.3{-dev} and tk8.3 installed as Debian packages by apt-get. What is the "tcl/tk installation directory" that configure requires? android could be a terrific way to produce demos, training, and even canned IPC for apps that offer no other API.
    --

    --
    make install -not war

  44. Re:Its all about standards by Hatta · · Score: 2, Interesting

    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!