Slashdot Log In
Miguel Says Unix Sucks!
Posted by
CmdrTaco
on Thu Jul 20, 2000 08:15 AM
from the but-think-of-the-alternatives dept.
from the but-think-of-the-alternatives dept.
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).
This discussion has been archived.
No new comments can be posted.
Miguel Says Unix sucks!
|
Log In/Create an Account
| Top
| 478 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Sounds like Mac OS-X (Score:4)
All of these resources are shared by all applications, where possible, to conserve resources. Most of them are very easy to use and many require no coding to setup. For instance, to add retractable drawers to the sides of your windows, you just drag-connect lines from the drawer instance to the window instance, to the view to be contained inside the drawer, and a line from the button/actuator-widget to the drawer instance and boom you are in business. No coding...
Apple certainly has the best reputation for this. All of these details are specified in a UI guidelines document and standard menu configurations are built into InterfaceBuilder. X has a nice built-in software installer. When you install it leaves a receipt you can click on to uninstall or just compress some software.X has a very powerful "Bundle" system (from NeXT). A bundle is a directory containing various subdirctories that contain application resources (binaries, source, headers, documentation, images, sounds, strings to be displayed the user, UI's, etc..). Localizable resources (like string, images, UI's) are kept in seperate directories for the region/language the resources are specific to. The Bundle class automatically fetches the proper localized resource based on the user's localization preferences. The Application itself is a bundle and there are bundles known as "Frameworks" for shared libraries. Frameworks can contain anything (code, headers, source, docs, images, sounds, etc...) and are stored together and are versioned (two or more different versions coexist peacefully: no more problems of a newly installed app installing an incompatible version on top of an existing version).
No API is needed for putting icons into the dock since the user can simply drag the application icon there himself; no having to drag icons into some obscure folder deep inside the system hierarchy.
Oh yeah, it's all running on BSD Unix with a Mach kernel. The sources of which are available here [apple.com].
So you see, Unix can be made into a modern operating environment for all users, with a consistent user interface, and an API that is a joy to use for developers. However, they didn't build it on X and you'll probably have to buy a Mac to get it for now.
Burris
Unix works like a free market (Score:3)
Consider that Unix and Open Source development is working like a free market: while there is a lot of variety, and while that causes problems, the benefit is that people do want simpler solutions, but instead of 'staying with' some simpler solution imposed upon them, people choose the best are available (e.g. Red Hat), and run with it, and then so does everyone else, and the bad solutions die.
The interesting comment about people developing Windows Manager skins reflects this: people get fed up with too many window managers, and start to develop skins. Then it becomes possible to have any 'style' window manager, sitting above a 'core' window manager : so then everyone starts to choose the best 'core' window manager. At the end of the day, you have the best solution: an excellent 'core' window manager, and an excellent freedom of different 'styles'.
The free market has decided.
Only half the story (Score:3)
At Usenix, his talk started from the premise that "the kernel sucks" but only as a springboard to cover extensively the approach, the philosophy really, of moving away from kernel-centric development to a component focus.
Now as a relative old schooler in all this I applaud the notion that every generation needs to overthrow the excesses and cruft of the previous one, so to that extent Miguel's to-the-barricades rhetoric is welcome. Unix, and Linux, have become a sprawling pasted-together mess, which is evident if you compare, say, Aeleen Frisch's first system admin book in 1991 with what there is now.
And some of the principles Microsoft has embraced in software architecture may also be applauded. Although I hasten to add that their implementation of those foundations has broken every conceivable rule of software architecture/engineering, not to mention common sense. Nevertheless, I think Miguel's willingness to learn from good principles wherever they may be found is also welcome.
But where I part ways is with his proposed grand solution space, which basically amounts to: CORBA.
CORBA is yet another sprawling, somewhat incoherent and definitely incomplete attempt to Make the World Behave Like We Say It Should Or We'll Stamp Our Little Feet. I have long felt that the dependence on CORBA, not merely the availability, is a millstone around the neck of both GNOME and KDE.
I've read quite a bit of CORBA and component model advocacy, and it reminds me all too much of IBM-think circa the mid-1980s. "You will use SNA because it's good for you. Here, just implement this spec that comes on four bookshelves of binders."
The brilliance of the UNIX philosophy is scalability built on self-evolving systems, not based on universal frameworks that try to provide order through mapping. As has often been noted, the map is not the territory. And it should not be.
But mapping (metaphorically, if not in its strict technical sense) is what component architectures are all about.
DLL Hell was just the first phase of this. You can argue that DLLs are not "components" by the standard definition, but they are component-like and function in many ways as if they were in such a framework. COM rationalizes and makes DLL World somewhat more orthogonal to the component model, and that is the positive sense that Miguel seems to respond to. I can see some merit to the reuse and iterability inherent in this approach.
But that is entirely a developer-centric approach, and this is where I think Miguel's vision will be sorely tested, and emerge as at best mixed bag: one part fixing some rather sticky issues for GUI development and near-field reusability, one part creating a whole new layer of complexity and frustration for the user, the system planner and the sysadmin.
Components are not static; they evolve, and they evolve both in form and function. In other words, wish as much as you might for a static API for a given component (as Miguel sort of did during his Usenix speech), but it's not gonna happen. Both what the component does and what hooks and appearances it presents to the world are destined -- in fact must -- change over time. That's the lesson we learned as soon as Microsoft put out the first revision to the first DLL.
It is simply impossible to imagine some Component World Authority that has the job of telling every component architect and developer: this is your feature set, this is your quest: go forth (or go C++ or go Java ) and Make It So, and Thus Shall It Always Be! Nuh uh, not gonna happen.
The advantage of reusable libraries as in C compilers is that while some variation in them may be permitted (whether this is a good thing or not is circumstance-dependent), you are basically faced with a binary result: either the code compiles or it doesn't. Once it does, you have a static binary that will continue to work as long as most of the underlying OS stuff remains the same.
In Component World, you are now at the mercy of component dependence every single time you run code. And since the component framework is both (1) more dynamic and (2) more distributed than we are used to with our desktop computers these days, this is going to pose major problems. Some of these have already been noted by the GNOME skeptics who have posted here (including at least one well known GNOME developer).
The problems are inherent in component architecture: compatibility, resilience, security. This is less of an issue when all the components reside in devices connected to one backplane, usually inside one metal box. But with distributed apps and, probably more importantly, mobile apps, this is increasingly going to pose problems.
Remember when you installed some random program in Win 9x and it changed a DLL so that your email didn't work any more? At least you have the ability to reinstall DLLs/programs/the system itself (depending on the severity) to deal with the compatibility problem.
W2K supposedly deals with this by creating its own little mini-World Component Authority backed by an internal database subject to all the usual database reliability and performance issues (plus of course it's closed source). All this does is allow a bigger mess to be made at some point.
But what about this? You're running a nice little cell phone/PIM gadget that is built on GNOME and CORBA, and suddenly you can't get your email any more because some schmucko at a service center upgraded to the latest/spiffiest version of a component your handheld relies on via its mobile link to do its work.
Welcome to Component Hell.
As a non-developer and mere observer of the passing landscape, I would be happy to have someone come along and explain exactly why I am all wet. But for the moment, I am persuaded by Miguel's disdain for the suckiness of the kernel, and completely unpersuaded why components, as instantiated by CORBA and GNOME, are a universal solution rather than a local fix.
-------
Miguel Says Unix Sucks! (Score:3)
Miguel Says Unix Sucks! -- SlashDot News Headline
Now if I posted to SlashDot that Unix Sucks! I would get -1 troll....
Not saying I would knock Unix, though.
Re:Less than what?... (Score:4)
Another one:
There's a town in MI outside Detroit called Novi. Everyone uses emacs there.
Wrong. (Score:4)
No, most of the world's commercial desktop software was written for Windows, because *big drum roll here*... most of the world's commercial desktops run Windows!
And that's not because of API standardization, or you would have seen people fleeing in droves at the Win16->Win32 switch which forced everyone to rewrite all their software. Borland's OWL libraries and Microsoft's MFC would have destroyed the Windows programming "community".
That's simply because Microsoft managed to get contracts which put their software on the majority of clone computers, because clone computers, and because Microsoft allowed (some might say forced) network effects to turn that majority into a monopoly.
The problem with Linux above the kernel level is that you can run into a situation of multiple competing API's for most everything, which can become a bit of a programming nightmare.
Bullshit. Name one GUI Linux program you've written. Did you try to write it using two toolkits? If not, then exactly how did the existance of whatever toolkits you didn't use make your life a "nightmare". All it did was give you extra choices to find an API you liked best before you started to program.
Remember, if programmers were forced to use one toolkit, we might be stuck using Xaw, Motif, or even Win32...
How do you define "easier"? (Score:3)
As for vi versus Notepad... well, a friend of mine has a good ease of use formula. The proper measure of ease of use is the total time spent doing a task. The formula for this is T(l) + nT(d), where T(l) is the time required to learn a task, T(d) is the time required to perform it, and n is the number of times it is performed. So for tasks you rarely do, T(l) dominates. But for tasks you do often (like, say, the several hours a day i spend in text editors), T(d) dominates.
The essence of this is that while vi is much harder to *learn* than Notepad, it is much more powerful as well, reducing use time. And if you spend several hours a day editing text (like most programmers do), the time to learn a more powerful editor is paid for many times over by the speed gain for complex tasks.
This is why i recommend to friends who use computers daily, even non-programmers, that they take the time to learn Linux. Not because it's more cool or politically correct, but because it's more *productive*. The learning curve in the short term is paid for by productivity in the long term.
And THAT, Young Jedi, is ease of use.
--
Noone ever claimed that unix doesn't suck. (Score:5)
Fuck Miguel (Score:5)
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>
--
OOP (Score:3)
We're all different.
Miguel de Icaza is an Idiot (Score:4)
I maintain that Unix does not suck, but rather that it is beautiful in it's flexability. This bozo claims that it's weakness is "not deciding policy"
Go program for M$, Miguel.
Unix (and for that matter the entire Open Source movement) is about freedom, not about having mission-critical decisions made by some corporate suit who, incidentally, is only interested in making their company more $$.
I repeat, Go program for M$, Miguel.
Miguel claims that a weakness of Unix is in not sharing more code between applications. M$ shares code extensively betwen applications
Miguel obviously has a LOT of trust in M$
that and
Making decisions (good or bad) and taking responsibility for them is part of being an functioning adult. The ability to make decisions is essential. To have the decisions already made and have no control over them is unacceptable. Any competent Unix sysadmin knows that security is his responsibility. A Unix sysadmin who has his boxes repeatedly compromised is likely to be out of a job before too long. When a M$ box gets compromised, it is no great shock, in fact the sysadmin of that box can't be held accountable for a system in which he has no control
I can't believe this idiot sucked me in and made me waste time stating the obvious...
</rant>
Red Hat's Gnome sucks (Score:3)
Why does the default desktop supplied by Red Hat have to be so uggly? The icons on the taskbar aren't event lined up properly for christssakes, but seem to be placed by random. The theme is most boring one possbile, and the settings of the windowmanager is enough drive anyone mad. When you've installed the latest Red Hat you have to spend at least an hour to get the settings somewhat usable. Don't even get me started on the *totally* messed up Netscape fonts. What are people new to Linux going to think! They can't be expected to mess around with fontpaths and fontservers.
The point I'm trying to make is that Red Hat has just slapped the latest version of GNOME available at the time, compiled it straight from its pristine sources and added two links to redhat.com on the desktop. That's just not going to cut it, not this century. If you want to see how a desktop *should* look , straight out of the box, take a look at Helix Code's GNOME version [helixcode.com]. Now *that* is a good looking and behaving desktop, a desktop I wouldn't be ashamed to show a user who knows nothing about Linux. First impressions are important! If Red Hat has any clue they'll be using Helix's versions from on. They are VAR after all, so how about adding some value to the product! It costs them nothing.
Okay, I'm done ranting now.
Re:Lack of a graphics design (Score:5)
True. When I read this:
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:
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.
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
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...
Re:How do you define "easier"? (Score:3)
I would say that if you can do this problem you are too skilled a computer user to really judge ease of use issues. Ease of use is not for those of us who already know how to make a computer sit up and bark. It's for democratizing the power of the computer and offering it to that other 99% of the human race, the clueless (with the assumption that as a result, some of them will get a clue).
Paridigmns for a new OS? (Score:5)
I think UNIX [bell-labs.com]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 [bell-labs.com] are doing alot now with Plan9 [bell-labs.com] 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
Re:Lack of a graphics design (Score:3)
You can flame Microsoft all you want, but the fact that Windows has a singular WIN32 API drastically simplifies program development and software driver development. Because of that standardization, that's why most of the world's commercial software for desktop machines -are- being written for Windows.
The problem with Linux above the kernel level is that you can run into a situation of multiple competing API's for most everything, which can become a bit of a programming nightmare. That's why people are gravitating towards supporting Red Hat, Caldera, S.u.S.E. and TurboLinux commercial distributions, because at least you'll know what API's to program for with each commercial distribution of Linux. Is it small wonder why Red Hat has become the "de facto" standard for Linux almost everywhere?
Why Unix is the way it is. (Score:3)
Think about how easy life would be if only we could reuse existing components. For example I'll build my life by taking the 'Bill Gates wealth component', the 'Alan Cox programming component', the 'Jean Claude Van Dam appearance component', the 'James Bond suave component', and the 'Sarah Michele Gellar girlfriend component'. Nice life huh?
Of course, if everyone else gets to build their life the same way, it becomes a mediocre life not worth living. If everyone gets to choose to be as wealthy as Bill Gates then everyone is equally poor; prices would sky rocket until a loaf of bread was a billion dollars.
If everyone could program like Alan Cox there would be no demand, or use, for you as a programmer. Why would anyone get you to do the coding when they could get any of 6 billion people to do it?
Unix provides a stable base and a uniform API for applications, good design decisions flourish, bad ones die out.
The problem with the reusable component approach is that it requires bad design decisions to flourish. If there is a poor design decision made in a commonly used component it can't be corrected because of the number of programs it would break if it were changed. Instead of the fittest surviving, the most popular survive. What is worse, there is no basis for comparison and improvement, all programs take on a uniform boring sameness; there is no good or bad to choose from, and learn from. No evolution can take place.
What the component approach does is guarantee that bad design decisions live forever, because no one knows they are bad.
Component programming is like a good looking, but heartless woman; looks great at the start of the relationship, but the marriage is a horrible one.
UNIX's central idea: low level reusable components (Score:3)
Everything Sucks (Score:3)
I love Linux for its flexibility. Drop the kernel in and everything else is optional. Want the standard UNIX utilities? Add 'em. It's optional. It's all optional. No one dictates that policy. That means I can install Linux on my embedded device and leave off 98% of the crap you get in a standard distribution, hack some sort of GUI out. GGI or X on GGI or X on custom hardware. It doesn't care. No one set a policy dictating things. But wait! I don't want a window manager on my embedded hardware! NO PROBLEM! I can make my own UI!
Griping about the flexibility that makes the system great is stupid. Remember the Chinese guy from UHF? Lets all face Miguel and say it together "STOOOOPID! YOU SO STOOOOPID!"
Tongue firmly in cheek, of course.
Anyway, now that we've got that out of our systems, the point about component programming is valid. The text tools are designed to be simple and flexible, but the GUI is a relatively new add-on and is in some ways more primative than Windows 3.1. I've complained about the lack of a decent print subsystem myself. And GUI apps tend to try to do more than the simple text based ones. I think many people view X as nothing more than a way to keep 10 or 15 text terminals in view at once.
Thing is, this is all going to get fixed. Several companies are working on the printing problem. Once they all screw it up and present 15 different conflicting standards, some group of free programmers will get pissed off enough to write one from scratch. X could go away as well. Much of the new software is GTK based, and porting GTK should be as easy as porting GDK and a bit of other stuff. ORBit doesn't rely on X, and most of the Gnome stuff builds on GTK.
UNIX may suck, but unlike the competition, UNIX is going to get better.
Do something about it (Score:5)
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
Lack of a graphics design (Score:4)
The terminal does just fine with the components it has. There are quite a few shared libraries, and for (for instance) printing, everything uses lpr - plain and simple. But a drawing model like X does not a application kit make.
Personally, I think that the best approach for an application development framework is a server-based model like BeOS. In Windows, programs duplicate functionality that's handled by one server in BeOS. Linux (and UNIX) is a great command-line environment, and provides a rich environment on top of that. Just don't use X for anything more than xterm, xclock, and xload.
Console based stuff is reusable (Score:3)
Today, people want to build GUI apps and he is right to say that UNIX lags behind Windows in reusability in that regard. But this is clearly not a "design flaw" just a lack of a widely used toolkit of common objects.
Miguel is also ignoring the fact that a closed, tightly controlled platform like Windows will always have a higher level of uniformity (and reusabilty) than an open platform which must rely on de facto standards rather than the "king's edict" so to speak. In that sense then openness is a design flaw. No, I don't buy it either... Gnome is on track to provide the kind of high level reusable objects he wants. He should stop whining and write code.
--
Not really accurate statement (Score:4)
What he said is that there is no innovation going on in UNIX and that number of its fundamental features while attractive to our community, are preventing the whole world from using the operating system.
He cited Apple's work on MacOS X as an example of a team that changed some of the fundamental kernel designs on behalf of "end-users".
Miguel's big point is that there isn't a component model and code reuse simply doesn't happen. He is right on the money with that.
However I don't know about the solution of just copying COM/ActiveX/OLE, especially when Microsoft is now dumping COM in favour its
I suspect Java is in the Linux desktop future whether people want to admit it or not. The Java2 integration on MacOS X that was demonstrated at JavaOne proves how much Microsofts component model for applications is obsolete.
In the rest of his keynote he talked about innovation in specific applications such as mail and the whole INBOX/foldering problem. I hope GNOME (and now SUN and StarOffice/OpenOffice) can address some of the design problems with Microsoft Office.
He did say UNIX sucks, and he is correct, many things about it do, but there is suckage on every platform. His point was we have to fix the things that suck on UNIX and he is not advocating re-doing it from scratch.
Oh brother. Can't see the forest... (Score:5)
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.
Components are not the be-all and end-all (Score:3)
Taken to extremes - like our good friends in Redmond - you wind up with many, many applications depending on a large number of common components, with (here's the kicker) at times incompatible APIs. Need BeltchWord 5.0 and FlatuanceDraw 6.2? Can't do that if they each want different versions of the same component.
And then you get situations where an application upgrades a component that the OS/Window Manager depends on.... version control lunacy.
I believe this is called "DLL Hell" in Windows circles.
No thanks Miguel. I like and use GNOME, and I look forward to useful things like a common GNOME printing model, but I also very much indeed like the current UNIX way of doing things with regards to the window manager, X, and the kernel.
Some may see 20 years of development as "stagnant" but I see 20 years of continuous evolution. Cockroaches haven't changed much in 20 million years, because they don't have to - they're pretty damned efficiant as shipped.
Why isn't he doing his part, then? (Score:3)
But if Miguel wanted to help improve the situation, why did he go off developing such a huge software project in C on UNIX? It is C that makes component based development such a pain. C lacks even minimal support for component based development (e.g., no dynamic typing, no reflection), and it is impossible to make large, component based systems in C both robust and efficient: there is no fault isolation--a bad pointer in one component will crash other components unless you put them in separate processes.
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Microsoft does not have the answer. Microsoft's component model, COM, has very serious problems. It's complex because the languages it is based on don't have any support for component based development. And despite its complexity, it is still dumbed down because anything else would be umanageable in C/C++. And it has no fault isolation, meaning that if you load a bunch of COM components and your program dies, you have no idea what went wrong.
In fact, UNIX had an excellent, reusable component model: command line programs that interchange data with files. That's no good for building a graphical desktop, but it was excellent for the UNIX user community--people manipulating lots of data. And that model has been extended to graphical desktops and networked systems in Plan 9 and Inferno, which also address many of the other problems with C/C++ through Alef and Limbo. Or, alternatively, Objective-C and OpenStep managed to build something that support powerful reuse and component based development on top of UNIX. And Java is excellent at supporting both component-based programming, reuse, and fault isolation.
If Miguel genuinely wants to improve the situation, why isn't he using the tools that will let him do so? Why isn't he learning from the long history of component-based development that preceded both him and Microsoft? Why is he copying Microsoft's mistakes and mediocrity? Why isn't he supporting tools that genuinely make a difference rather than encouraging the use of tools (C/C++) that were never intended for this kind of work?
People say about democracy that "it is the worst form of government, until you have tried the others". I think the same is true about UNIX. Gnome and GTK help improve the usability of a flawed tool. As such they are really welcome. But by not addressing the root causes of the problems, we'll probably be here discussing the very same problems again in another 15 years, because everything people complain about UNIX was known 15 years ago, nobody fixed it, and it (and its clone--Windows) still became immensely popular.
Re:Linux = No Innovation (Score:3)
All this innovation for the sake of innovation is stupid. Innovations must solve problems. Go ask Ross Anderson if he how he designed the system. Did he slap code together and say - there I call it the StegFS, or did he pose a problem about the issue that of encryption does not address, and then propose a solution.
OTOH, MS coming out with "focus" control technology is just that - a hammer in search of a nail. MS, in their backwards marketing-directed software development, is causing the software inductry to go in circles - going nowhere.
We do not need reusable stock libraries... (Score:3)
My point is that most people here are saying we need a complete set of standard libraries. I am saying we need acomplete document describing how a standard libaries should interact. Then we build hundreds of libraries to this standard. The unix way, where everything is a file is a very basic implimentation of this - say I do something like: someprog | sed | cut | awk > file (flags striped), for some task, but find that set|cut|awk is not poweful eneugh. An hour later I can do someprog | perl > file. No changes to someprog no changes to the file. No changes to the mythical pion who depends on post processing the output of someprog.
I want options. I do not want some idiotic stock library designed my some fool.
Re:Unix was there first. (Score:3)
unix wasn't the first operating system in the world
unix will not be the last either
as time goes by better ways of implementing things are discovered. Whilst windoze might not have the best underlying operating system I feel that it does have a far better user interface than any linux/unix variant. Sure gnome looks pretty but that's just your aforementioned flash.
To be fair windows does make it possible for end users to set up and work a pc without the amount of technical knowledge required to install linux.
Lets face it, most people do find dragging files into a bin easier than remembering to use "rm -r foldername". Personally i like command line stuff but that's just me.
If windows is so bad then why do more people use it than linux?
He's right. (Score:3)
Most Unix applications share little or nothing with each other, save for the C library and X libraries. Everything else appears to be an attempt to re-invent the wheel, sometimes coming up with an eccentric triangle instead.
The main advantage is that if a security hole or bug is discovered in a library, an replacement library will resolve the majority of problems. A certain $oftware company does this a lot. The other advantage is that it saves memory.
Gmome appears to be doing more than KDE in this field. Run ldd against a typical Gnome application, and a whole host of component librarires will be linked in - Imlib and others for image rendering, GTKXmHTML for HTML, Gtk and libgnome of course, and so on.
Gnome is standardising on which libraries to use. Unix libraries have become fragmented, with many features duplicated between competing libraries. The present situation elsewhere is a mess, due to it not being controlled.
The only other environment I can see that does something very simillar is Perl, with standard modules available on CPAN. Python may do the same, but I havn't looked at Python closely enough.
OOP Reuse Myth (Score:4)
Althought you don't expicitly state it, you seem to be implying that OOP encorages more reuse than other programming paradigms, now, while OOP does encorage more reusable code to be written, it had not been shown that this actually generates more reuse in practice.
Thad
Re:Unix was there first. (Score:3)
UNIX did a lot of things right. If you look at what Martin had to say, he's looking for more code reusability. Unix did it at the program level, now he's asking for it to be done at the functionality (sub-application) level. He's actually asking for an extension/deepening of a core UNIX principle to where we could/should have been working it a long time ago.
It just got a bit stagnated because of the closed-sourcing of UNIX back in the '80s.
Intresting..... (Score:5)
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
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.
Duh!! (Score:4)
ls ???? | grep ?????
You want to combine a whole bunch of components? You can use a shell script or even perl.
We've got reusable code running out our ears.
"Everything is a file" (Score:3)
That's not really what "everything is a file" (EiaF) means. EiaF is really a pretty low-level thing, meaning that all sorts of objects - files, devices, fifos - in a common namespace and are accessed via a common set of syscalls - open, close, read, write, ioctl. This was actually an advance over earlier operating systems which often required that you use different syscalls to get different kinds of descriptors for each kind of entity, and which had multiple namespaces as well. Ew. You can see the power of EiaF not so clearly in UNIX itself, which contains many deviations from the principle, as in Plan 9, which was the "next act" for the UNIX principals.
There are a couple of other principles that you seem to be confusing with EiaF, and I think it's worth discussing them too. One is the idea that files should be unstructured. Again, this is a low-level idea, this time referring only to the "physical" layout of files and to the filesystem interfaces. As a filesystem designer and implementor, I can say this principle is very important. Filesystems have quite enough to do without having to worry about different record types and keyed access and so on - as many pre-UNIX OSes (most notably VMS) did. Man, was that a pain. What gets built in user-space, on top of that very simple kernel-space foundation, is up to you. More complex structures have been built on top of flat files since the very first days of UNIX (e.g. dbm files).
Another related principle is that data should be stored as text whenever possible. This is an idea that's gaining new life with the widespread adoption of XML to represent structured data, and again it's a good one. Doing things this way makes it much easier to write filters and editors and search tools and viewers and such (or to perform many of these tasks manually) than if the data is all binary. It makes reverse engineering of file formats easier, which is a mixed blessing, but it also makes manual recovery and repair easier. Converting to/from text also tends to avoid some of the problems - endianness, word size - that occur with binary data. Obviously there are many cases - e.g. multimedia files - where conversion to/from text is so grossly inefficient that it's not really feasible, but in very many other cases it's just a pain in the ass for the next guy when some lazy programmer decided to dump raw internal data structures in binary form instead of doing it as text.
In conclusion, I'd say that by all means people should try to retain the structure of data. Even better would be if the means for manipulating data could be provided and linked to the data itself in some standard way, like OLE/COM does in the MS world. At the very least, even without a common framework, it would be nice if more programmers would provide libraries with which to manipulate their data files. But please, let's do all this on top of text wherever possible, and let's do that in turn on top of a flat-file kernel abstraction within a single namespace. These are some of the more important principles that led to UNIX being such a success.
Re:Lack of a graphics design (Score:3)
Close, but not quite.
What's really needed is a component model (like Bonobo) and a standard URI-type reference that defines the component in terms of the content to be displayed, like OLE uses. So, if you cut-and-paste from the diagramming tool, you should get a snippet of XML that identifies the Bonobo component that is needed to display and/or edit the diagram, and the description of the diagram data. That way your componentware program can display the diagram exactly the way the diagramming tool can.
In addition, Windows permits various rendered versions of the data to be included in the clipboard structure, so in the hypothetical Linux example your XML snippet would probably define:
A text representation (required)
A Bonobo reference with data (optional)
A PNG or other graphic (encouraged)
A space for both standardized and application-defined extensions (SVG, MPEG, binary data structure, URL, etc).
That would be pretty much analogous to the Clipboard. Ideally, a negotiation could take place to prevent clipboard-overloading (just the Bonobo invocation interface and the minimal definition of the clipping bounds is passed to start, and the request is resolved between apps without the framework in the way), but that would require sharing the clipboard-access code :-)
Miguel and the rest of you are, of course, free to attend to the small matter of implementation :-
I can't decide whether to laugh or be afraid. (Score:4)
Well, duh. Did he expect independent commercial software shops to share their code with each other?
Someone please tell me this is a belated April Fools joke!
He goes on to make reasonably valid points about how "reusable components" are available under Windows. What he misses is that this puts other software shops completely at the mercy of the components' owner, Microsoft. Is he proposing a Unix where everyone is similarly dependent on GNOME's components?
OK, GTK+ and Qt provide some nice reusable components. The advantages are obvious. I use them myself. So why is he dredging up all this irrelevant/clueless/scary stuff?
I am a GNOME user, and often defend it when it is unfairly maligned, but I don't think I like the way this is headed. No, not at all. Hopefully he's just talking out his ass rather than presenting a carefully thought-out position.
--
Re:Duh!! (Score:4)
Did you read the even read the article before posting this? When he said we are lacking resuable code he mentioned APPLICATIONS like Acrobat, Staroffice, and Netscape. Aside from the C libraries, there is *NO* re-used code between any of those applications. His example was Printing. Each application has its OWN printing system, configuration, and method of working. The sad thing is, they all pretty much do the same thing... generate a Postscript file.
He isn't talking about ls, grep, cat, cut, paste, and UTILITIES like that. He's talking full-blown applications. You know, applications...the things that people have to have to USE their computers.
---
The Solution is... A Monopoly! (Score:5)
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).
Balance is Key (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 [cscmail.net]) 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.
Re:DLL hell (Score:3)
There actually was a Unix derivative that did it right, but didn't catch on: NextStep. BSD kernel, with incredible development tools and standard libraries. With it you could throw together a professional application in hours/weeks instead of months/years since it handed you all of the primitive elements you could ever need in a consistent way. Much of Java was actually inspired by Next's tools (to be honest, Objective C is actually superior in some aspects to Java, and yes, it's OS-independent). Whether they admit it or not, all of the modern development tools (KDE, Gnome, M$ Visual Studio, etc.) are using more and more of the ideas inspired/stolen from NextStep.
It will be interesting to see how Apple's move to a NextStep derivative works out. Due to the fact that they're working to maintain backward compatibility, MacOS X is probably an inferior design to the original NextStep, but certainly an improvement over existing MacOS versions.
Unix Is Not Windows (Score:3)
COM is descended from Object Linking and Embedding which was a way to have objects created in one application to be reusable by another. Basically MSFT's entire component revolution can be traced back to the "drag and drop an Excel spreadsheet into a Word document" problem. Everything that has occurred since then COM+ (reusable components independent of language), DCOM (distributed reusable components) and now
Now on the other hand, Unix applications until very recently did not have the cross communication problem that Windows apps had. Everything is a file, if I want to communicate between applications I simply use a pipe. All files I could possibly want to edit can be viewed in Emacs. To put it simply there was no need for a reusable component model simply to share data between applications.
Now decades after Unix was invented (which predates Windows and COM by over a decade) maybe time has come for that paradigm to shift.
Re:Do something about it (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.
Unix design philosophy (Score:5)
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?