Slashdot Mirror


Miguel Says Unix Sucks!

alessio writes: "On the front page of Linux Weekly News there is a report from the Ottawa Linux Symposium where the adorable Miguel de Icaza supposedly states that Unix has been built wrong from the ground up." It's actually a pretty cool interview, and as always, Miguel makes his point without any candy coating! The major point is the lack of reusable code between major applications (a major problem that both KDE and GNOME have been striving to fix for some time now).

11 of 478 comments (clear)

  1. Noone ever claimed that unix doesn't suck. by Anonymous Coward · · Score: 5

    We've only ever claimed that it SUCKS LESS.

  2. Fuck Miguel by Dr.+Sp0ng · · Score: 5

    So Miguel started the Gnome project because of the licensing problems with KDE/Qt. Good for him. Gnome has some excellent ideas, but they've taken it too far. There's no reason to need a fast machine with 64+ Megs of RAM to support a desktop environment, for crying out loud. Now don't get me wrong, I like Gnome and I use it all the time, but it really is a bloated piece of software. I've even written popular software for Gnome (sorry for the shameless plug :-), but I really think it could have been done much better and require less resources. The only reasons I used Gnome for PowerShell is that I like the look and feel of GTK+ much more than Qt or Motif, and Gnome includes a terminal emulator widget which saved me a lot of work. If there was something else that provided similar functionality (of the stuff people actually use, not all of it) and looked as nice, I'd use that instead. Until then, I'll keep using Gnome, but it looks as though it's heading down the Microsoft path of bloated software with tons of rarely-used features.

    And why is it that Miguel is held in such high regard among Slashdot users? He wrote a fairly nice desktop environment. So what? So did the KDE team, but most people can't even name a single person who worked on that project. So he thinks Unix sucks? Good for him. Everybody is entitled to their own opinion, but that doesn't mean that they are right.

    </rant>
    --

  3. Re:Lack of a graphics design by BinxBolling · · Score: 5
    The problem with *NIX (and he really doesn't mean *NIX - there's quite enough shared code in a console-only system, the problem is with the X apps he named) is that X windows is just an overgrown framebuffer, not an actual graphics and development kit. If you look at something like BeOS, it provides a whole bunch of "servers" (a microkernel design) that handle different functions, but X windows was an overgrown framebuffer stuck on top of a command line to provide a clock, a load monitor, and a terminal.

    True. When I read this:

    The Unix approach of not deciding policy is "a defense system for hackers," since that way nobody has to take responsibility for a bad decision.
    I couldn't help but think of X. The lousiness of that system is the best example of the problems that come when you avoid policy decisions. And the awful arguments made in X's favor whenever the topic of its suckiness comes up in Slashdot are certainly consistent with the idea that this avoidance of policy decisions is a 'hacker defense system'.

    Probably the best example of what Miguel is talking about is the difference between what you can do with cut-and-paste in X and what you can do with cut-and-paste in Windows:

    • X has more or less followed the Unix paradigm where 'everything is a file' - which really means that everything is a flat, unstructured lump of text. Or at least, this the only way that most programs have to interface with external data. This is fine when the data you're dealing with is relatively unstructured: A csv file is tolerable for, say, a list of phone numbers, and simple text oriented tools like sed/awk/grep/perl are okay for most of the operations you'll want to do on such a file.

      But once you move to a graphical environment and thus aquire the ability to effectively represent much more structured data to the user, you need to provide higher-level interfaces to that data. Those text-oriented tools will be pretty much worthless if the file you're dealing with contains a description of a structured drawing. As a result of X's adoption of the Unix approach, all you can really cut-and-paste in X is (surprise!) flat, unstructures text strings.
    • In Windows, on the other hand, you can cut much more structured data to the clipboard. You can rip out a piece of a Visio drawing and stick it into Word, and it will retain all of its structure. This is because Windows provides facilities that make it relatively easy for programs to expose higher-level interfaces to the data they generate. This permits a degree of application interoperability that X apps can only dream of.

      This pays dividends far beyond cutting and pasting: strong application interoperability means that you can easily access and 'reuse' an existing application's functionality. An example out of my own experiences as a Windows developer, a few years back: I once spent a month working on a project whose goal was to build a graphical scripting tool for a specialized purpose: Users would draw out simple flowcharts, then our tool would generate code from these flowcharts. Rather than build our own flowchart-drawing tool, we were able to use Visio: We designed a set of custom Visio shapes that users could use to draw flowcharts. Then, the development environment we'd built would send users into Visio whenever they wanted to edit charts. When the user was done editing, the development environment would talk to Visio via OLE automation, pull out a highly structured description about the flowchart (basically, a list of all the symbols and their types (including some parameters that the user could specify, such as the conditional expression for a decision symbol), and of the links between symbols) and build a simple C++ representation of the chart that the code generator could then take as input. My job on the project was to build the layer that talked to Visio and built the code generator's input data structure, so I dealt pretty heavily with OLE. It worked out great for us, saving us an enormous amount of development time. And we ended up with a much higher-quality final product - instead of building our own mediocre tool for graphically editing flowcharts (which we would have probably ended up having to do if we were working in unix /w X), we were able to provide the user with the much more powerful, mature facilities of Visio.

    I liked Miguel's comments. I'm glad to see that someone is willing to stand up and say that while the emperor may not be completely naked, he should probably put on some pants...

  4. Paridigmns for a new OS? by shutdown+-h+now · · Score: 5

    I think UNIX did alot to change the way OS design was viewed. UNIX treats everything as a file. UNIX focused on making a system with multiple users on the same system at the same time.(multiprocessing anyone?)

    I think the boys over in Murray Hill are doing alot now with Plan9 and a few other ideas I sometimes hear they kick around.

    My question to all of you obviously more experienced coders out there:

    What's the next paridigmn for creating the next less sucky OS?

    Treat everything as a data object? a module?

    I don't know. I would love to see an OS based on a functional programming language. Something small and compact without too much bloat to it. Code up a decent GUI as well. Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.

    Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.

    Perhaps we would arrive at a new GUI or a new concept that makes either more sense to users, or perhaps is faster to operate with, with minimal learning curve.

    A natural language based OS?

    A user can type in his questions (eventually speak to the computer ala voice recognition) and receive textual and aural inpouts from the machine. I.E. "Computer, please tell me the contents of disk0." "The contents of disk0 are, foo.txt, bar.c, baz.h"

    Eventually somebody or something has to sit down and figure out a different way of looking at the data we are presented and see if it makes more, or less sense than what we currently have.

    I don't know who that somebody is but I think it won't kill me to sit down tonight and see if I can come up with a few ideas.

    I'm thinking about using a functional language because it forces me to look at things slightly differently than when I write C code.

    Anyone else have any ideas or pointers to projects currently looking at stuff like this?

    It would be a nice project to jump in to, no?

    Dan O'Shea

  5. Do something about it by codemonkey_uk · · Score: 5
    Its open source. Do something about it. If you don't like it, change it. If its broken, fix it. Its the open source mantra.

    Actually, Miguel is one of the few people who is in a position where doing something about it is actually feasable. Whatever happened to that KDE & GNOME common component archetecure? That would have been a step in the right direction.

    I do believe that there is to much ego flying about for a lot of good things to get done. It takes a big man to climb down and say, okay, lets merge. Lets reuse. You can do it better than me, and with OS development kudo is currency, and to loose ego is to loose currancy.

    Hmmm... does Miguel have the courage to take a step towards consolidation?

    Thad

    --

    Thad

    1. Re:Do something about it by angelo · · Score: 5

      And a mantra is all it is.

      There is a very small core taking care of the software. A lot of us are users who at the end of the day working with computers, perhaps just want a free OS to check mail and surf the web. For the most part we don't want to put in another 8 hours debugging un-mapped, un-documented, and un-planned code. For the most part we run the most "stabile" version in a program, collected by a package tool.

      Every once in a while we may compile something. But for the most part, we have neither the time, nor the inclination to code. This may explain the popularity of Netscape 4.x, AND the lack of programmers for Mozilla. A lack of eyeballs is due to both the "works good enough" mentality from years of commercial OS use, and the above mentioned apathy.

      If you complain, then fix it. If you can't fix it, find someone who can, or email the primary author. If they give a nasty response, then use another program. This is certainly possible with 10 ICQ programs, 5 Napster clones, 3 Gnutella clients, and 15+ browsers. There is your freedom.

  6. Oh brother. Can't see the forest... by sillysally · · Score: 5
    If we believe Miguel's opinion of Linux vs. Windows development, Linux is going to lose. In fact, his argument is so strong that we can see that Linux won't even be today where it is because five years ago Windows was even farther ahead with more reusable code.

    More evidence of Miguel's genius can be seen in his critique of Unix in general. Unix is not a platform of innovation. Take the biggest development in all software markets in the last five years: the internet. Unix could never have produced the innovation of the internet...

    Miguel's a little confused.

    It drives me nuts when people who are a little bit smarter like Miguel, start to think they are really smart, because while he can see problems, he is still not smart enough to see solutions. Allowing for many many window managers is not a mistake, it's the trend: think about skins. No, the problem is that the developers who are writing all the window managers keep starting from scratch, or pay little attention to the other window managers. For example, I like the focus to follow the mouse. I'd like to set that one time in one place, then experiment with different window managers to see which I like (today... :) But you see? That's a simple solution to a problem. There's no need to throw the baby away with the bathwater, which is what Microsoft did. Microsoft was a unix systems house back when they produced DOS, and many features of DOS were modelled from Unix. It took them years and years to reintroduce simple things like memory management and multitasking, and then they set off to create NT, an OS that nobody even wants to clone.

    Yep, it's true that some areas of Unix are very weak, like printer drivers, but that's more a reflection of the culture: Unix isn't used on office desktops much. Windows has equally glaring deficiencies: think of how much Windows code gets "reused" every day by hackers exploiting the security holes :)

    Nope, Miguel, you are not onto anything big, just another Dvorak in a different suit.

  7. Intresting..... by raptor21 · · Score: 5

    What he is saying is.....

    I have a crapy graphics card so my whole computer is a piece of crap!!!

    Just because UNIX lacks in some resuable code in it's graphical shell it sucks. What about the fact that I can do almost everything i need to maintain a system over a serial port.

    Unix needs a lot of changes inorder to become a desktop OS. UNIX was designed for mainframes Three decades ago. X and desktops came into existence decades afterwards. Miguel's analogy is like saying a 1960 automobile doesnot have airbags so it sucks. But the basic engine and chasis design is the same only todays cars have improvements.

    Resuable code.... Just count the number of OSes out there that were built using a UNIX kernel.UNIX must have done something right.

    I wouldn't say X sucks, I would say X is too old for todays standards. Just like a PDP11 is old by today's standard.

    What the *nix world needs a newer grphical shell that defines a standard API that people can utilize. You can write all the Window Managers you want as long as you confirm to that API.

    The API should include:
    1) Unified standard printing architecture.
    2) Resuable components for the primary functions of applications.
    3) a standard for user interface (menu options e.t.c) Like edit->prefrences and not tools->options and file properties and every other place .
    4) A standard method for software installation. Like src goes here and binaries go here and so on.An API to make installation easy such that icons get put in the menu and links get crated automatically on the desktop.

    All this and many more standardizations are key to Unixes entry into the desktop. Standardization doesnot mean one window manager but that the basic UI should remain consistent.
    The only reason people like windows (Yes ,seven out of ten people I talk to think windows is great) is that it functions the same every where it runs. Most people don't want to learn every option on every application and every platform. Trust me i have experience with computer novices.They want consistency.

    Till we realise this and look at it from a consumer point of view I don't see unix or linux on every desktop in the world.

  8. The Solution is... A Monopoly! by Phaid · · Score: 5

    One of the main reasons Unix is so fragmented and inconsistent, which really is what he's complaining about, is that the whole system (kernel, libs, user interface) never been under a single entity's control. Someone above cited MacOS X as a great example of what Unix can become if it's done right. This is true -- it's easy to be consistent when a single entity controls every aspect of the platform. The problem is, that's not what most Linux users want.

    Where he is completely wrong is his claim that Unix is no longer a platform for innovation. He's got that completely backwards -- indeed, the whole reason for the inconsistency of user interfaces is the very openness and relative simplicity of Unix. Each layer is separate from the next, so it's easy to write a new GUI system on top of the OS without changing any of the underlying layers. And people have done just that, which has led to several generations of X and other apps lying around (Xaw, Motif, OffiX, etc) -- people see a problem with the existing GUI and they reinvent the wheel, leading to a proliferation of incompatible interfaces.

    Hmm, just like KDE and Gnome.

    The upshot is, because it's open, we have a choice. And choice can lead to inconsistency. So if he wants to work on a platform where everything will always be consistent, he can go work for Apple or Microsoft. Otherwise, he'll just have to make Gnome so good that no one will want to use anything else, because there isn't any way to shove things down people's throats in the *nix world.

    And that's a Good Thing (tm).

  9. Balance is Key by CountZer0 · · Score: 5

    As a developer I refuse to link my applications with GNOME because it has taken a few good concepts and gone WAY overboard. GNOME initially seemed to be a set of developer guidelines to promote a common look-and-feel. A few "meta-widgets" were created on top of Gtk+ to promote this. (gnome-stock-this and gnome-stock-that)

    This was good. Then someone decided to go even further. More widgets where added. Many of these widgets should have been added at a low level (read Gtk+) but instead where added in at the GNOME level. Now you have widgets that depend on gnome-libs and a fairly incestious circle is starting to emerge where GNOME depends on GNOME and its getting so complicated that no developers I know are willing to shackle thier projects to the great beast that GNOME has become.

    Miguel and Co. can't see the forest for the trees. I recently ripped the GNOME out of GtkHTML and created CscHTML (http://www.cscmail.net/cschtml) Miguel and several of the other GNOME developers couldn't comprehend why anyone would do such a thing. They couldn't understand the need for a non-GNOME dependant HTML widget. They couldn't agree that a "Gtk Widget" (GtkHTML) shouldn't depend on GNOME. Circular dependancies are a bad thing. GNOME depends on Gtk. GtkHTML depends on GNOME. Chicken, Egg?

    Code re-use is a good thing in moderation. Not every hunk of code needs to be a re-usable object, and interdependancies can be bad if they get out of hand (which they clearly have in the case of GNOME) Miguel has stated many times that the dependancies in GNOME will only GROW as time goes on. He sees interdependancy as a wonderful thing, and is so hell bent on code re-use that he is turning GNOME into a huge monster of code that no one wants to link to because no one wants to depend on 20 or 30 different libs. GNOME needs to be split, some of its libs more appropriately belong in lower level widget sets (such as Gtk+) and some of its items should be stand alone utilities. Trim the fat from GNOME and maybe developers would start to use it again.

  10. Unix design philosophy by Chops · · Score: 5
    In my view, a lot of the things Miguel is talking about stem from people abandoning Unix's traditional lots-of-little-pieces philosophy just because what they're building is a GUI application. We need to go back to the shell-scripts-and-files analogy, instead of copying Windows' APIs-and-shared-libraries model.

    Think about it -- it's silly that GUI programs are calling something that looks "internal" to them to pop up a dialog box. They should be issuing a shell command, like 'dlgmsg "Your repartitioning is complete." -b OK'. Or 'dlgmsg "Do you want to purge your deleted messages?" -b Yes -b No'. /dev/proc/ is massively useful; why don't we have /dev/gui/? It seems to me that the whole Window Manager Bloating Wars came about because we chose to ignore the features of Unix that would have made it easy. Why do we have window handles instead of files (i.e. named pipes created by kde)? Why is changing a window's menus any more complex than 'menubar /dev/gui/win46 -m 0 File -mi 0 0 Open...'? Why is listening for window events harder than parsing /dev/gui/win46?

    I know it's a hell of a lot more complicated than that, of course, and I can see a lot of flaws and complications in the above... but hell, maybe the window manager should have to run as root anyway (sarcasm). Does anyone know of a project that tried to do something like this?