Slashdot Mirror
Let's Make UNIX Not Suck
The above is a title of the talk that Miguel de Icaza of Gnome and now Helix Code fame gave at OLS concerning the look and feel of the UNIXs. From what I've heard from attendants the talk was great - and now you too, in the privacy of your own home/cube/lean-to/car can read it.
You are missing the point. CORBA does not implement policy, only a mechanism. This is policy on top of any object model you choose. That is why it is powerful.
The point is that there needs to be some sort of policy that is loose enough so that anyone can use and understand it, but rigid enough to enforce a metaphore that works and in understandable by non-computer-cluefull people.
osix system's aren't really aimed at beginners - that's what people keep forgeting
No, people keep forgetting that everyone is a beginner at some point.
Making a system good for beginners does not mean crippling it for advanced users. I think we should be past the point where complexity for complexity's sake should be attractive...
I'm an investigator. I followed a trail there.
Q.Tell me what the trail was.
Recursive: Adj. See Recursive.
Here is my point. It isn't just CORBA. Corba is a neat way to force applications to talk in a non-pointer determinate fashion. It's about the policy (that is what bonobo partially delevers).
There has to be a way that a system can serialize data, provide access control to serialized objects, and store thoose objects. This is what Linux is missing in a big way.
Componets are cool, but if we are going to add componets, lets add a constant model or policy, and flexability in. Let's also make it so that there is a common configuration interface, a block or object interface, and some heirchal or non-heirchal way of looking at it.
What he's really pointing out is UNIX doesn't have a modern middleware layer.
The history of modern middleware begins with Visual Basic "buttons", which were invented by Alan Cooper. (Microsoft bought this technology; it wasn't developed there.) Visual Basic made it possible to write medium-sized business applications with graphical user interfaces without much pain. Code reuse worked well in that environment, and it was easy to access a database. You could have the good programmers write a "button" and let the lesser programmers drag and drop the button into their app. This was a major driver in moving corporate America off the green-screen IBM mainframe terminals and onto Windows.
Programmers were pushing the "button" idea way beyond its intended uses. So Microsoft expanded it into COM, DCOM, and Active-X. It turned into a huge proprietary do-anything object system. But a lot of work gets done with that toolset, even though it's become ugly.
de Icaza has correctly identified the lack of a comparable middleware system as a serious problem in the UNIX world. Whether he can fix it remains to be seen. It's very hard to get this right. The past is littered with failed middleware environments: OpenDoc and NextStep come to mind.
A big problem is that if you let the object fanatics design the thing, it ends up too abstract and complex. If you let the UI designers design the thing, it ends up not powerful enough. CORBA and Prograph are at opposite ends of the spectrum here. (If you let the hackers design the thing, it ends up like Perl. Perl, remember, started as a tool for reading text logs. It's a special-purpose language pushed way beyond its design basis.) This requires really good engineering judgement.
For some insight on how to make design decisions here, read Weaving the Web, by Tim Berners-Lee (you know, the guy who invented HTML and the Web), page 182, where he discusses why HTML isn't a programming language like TeX. He says it better than I can, and I'm not going to repeat him here.
I hope de Icaza can pull it off. From reading his article, he has the basic good sense needed to get it right. Best of luck to that project.
We have reduced all the complexity that you have described above now. To install, setup and configure your whole system:
lynx -source go-gnome.com | sh
We take care of the library issues for you, and you can focus on compiling Galeon (which we plan on including on Helix GNOME as well in the near future).
Miguel.
Is the interface definition used to determine "compatability" of an object for a particular purpose? Can interfaces evolve? Can an object add functionality, but still be used by other, older objects for the older purposes? Must an evolving object conform to several interfaces (adding bloat), or can there be v2.0 of an interface, after the designer realizes there's a Better Way to do it?
These are hard problems, and ones I was not able to answer to my satisfaction. Evidinced by their software, it seems that M$ has not either. Do you really want to embed an editable spreadsheet in a document, and deal with the bloat and crashes that will occur? Or is there a Better Way?
Of course, I could probably answer all these questions by digging into the Bonobo and CORBA documentation, but stimulating discussion is good too.
--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Miguel de Icaza seems like an otherwise intelligent guy, so I have to assume that CORBA is forcing the use of reference counting here. If that's so, then CORBA sucks even worse than I thought.
To a Lisp hacker, XML is S-expressions in drag.
If you spend much time looking at .NET, you'd realize that it's essentially built on top of COM itself.
.NET, let alone transcending it.
You need something like DCOM implemented first before you can even think of implementing something like
DNA just wants to be free...
Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Except that GNOME is going about this entirely the wrong way. They're writing a lot of useful stuff (the canvas, html components, etc.) except they can't figure out why somebody would want to use this stuff outside of GNOME. GTK+ could benefit from the standard inclusion of some of these things and it's likie fighting for a firstborn to move them out of GNOME into GTK+.
Example: In the previous article about Miguel speaking (sorry, no reference), one poster mentioned how he had gotten flamed for taking the GNOME html component and removing the GNOME dependencies. Clearly, an html component that everybody can use is a good thing. Requiring GNOME to use this html component is not a good thing.
Write the reusable software at the right level; don't GNOMEify everything in the name of "software reuse".
-Nathan
Wow, it's always tough when a true Indian wanders off the reservation!
Well, he has a point. Unix should be the first OS to use modularized components with rampant code-reuse, not one of the last. Remember part of the Hacker Ethic: do not re-invent the wheel.
Imagine! Maybe Microsoft does do some things very well! (I know IE has much better support of CSS than Netscape does -- not to beat a dead horse, but Mozilla isn't looking all that great either on several fronts). Could it be that this modularity (even done as slipshod as it is on Microsoft OSes) is part of what encourages people to write software for Microsoft? Ease of development? (I'm not a True Programmer, so <TAKE type="salt" size="grain">
I wish the best for Helixcode -- just before you get carried away with making it "easy to use", try to get some UI experts in there to help design things. Just because it has a button doesn't mean it's easy to use. Where the button is placed is just as important as having the button.
Potato chips are a by-yourself food.
That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.
.NET for one reason only...cross language inheritance. The thought that my C++ components can be inherited by my Perl, Java or Javascript objects makes me extremely *CENSORED*.
Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Once this is done, anyone can use it regardless of what language it was written in, fast XML parsers can be written in C++ and used in from Javascript or VB. This way developers of business apps do not have to make the choice between a.) putting up with a slow app or b.) writing one themselves with all the attendant bugs therein especially if they have little C++/C skills, also they can go on towards actually creating their application instead of worrying about if they malloced() enough space for their char*'s.
Lots of *nix people believe this implies laziness but fail to realize that reinventing the wheel dozens of times over is folly.
Example I:
I am currently designing and implementing a project management system on Windows(TM) for a small business with a few of my friends. two of them are *nix hackers and they balked at using an XML based protocol to transfer data between the client and server. Now instead of simply designing our protocol then using one of the dozens of available parsers to do this, they decided that we should invent our own binary protocol and write our own parser to parse it.
Our project involves code written in both C++ and Javascript/ASP. We could have used a single COM based parser to consistly interact with the data both from the C++ and the Javascript code but instead its been 2 weeks and counting and our homegrown parser is still being written, tested and debugged. In my opinion this is nothing but a waste of time. When I ask them why not just use XML and an already existing parser their replies boil down to "It just feels wrong.". The chances that a bug or two will slip through in testing or that there is a buffer overflow in our parser is not unlikely considering that most early versions of parsers written in C++ have a few bugs like this hidden somewhere. in this situation component based programming would have allowed us to focus on building and designing our actual application instead of focusing time and energy on a tangential application.
Example II:
At work a MBA intern asked me if it was possible to create an application that housed a search engine that searched a database of MBA students based on criteria like concentration, work experience, graduation date, etc. and then displayed results with links to their resumes in MSFT Word(TM) or HTML format which could be stored on a CD to give recruiters at career fairs. Their first attempt had been to use VB and Access which turned out to be a disaster because of DLL Hell based issues. My simple solution was for them to store all the students in an XML file and to write a Javascript page that used the COM based XML parser (written in C++) to perform the search. Writing this page took less than 2 hours.
Now they have this search functionality they can press on a CD and give out at career fairs which any recruiter can view without needing more than MSIE 4.0 or greater.
Without Component based programming their request would have been impossible to fill in their time frame and would have also required that the recruiters machines would need to fulfill a stricter set of requirements (like a Webserver being installed or they'd have to install an app).
In conclusion my question is "Why has it taken so long for a major *nix push towards component based technology?". After all we've had CORBA for almost a decade but there hasn't been that much a big push towards components. Frankly I am eagerly awaiting MSFT's
FOOD FOR THOUGHT
First of all, to those of you who are criticizing Miguel by saying "Miguel is wrong because being Object Oriented isn't necessary", or "Miguel is wrong because XML isn't necessary", I hope you're keeping this in mind: Miguel's comments can be broken down into two parts("You know, there are two kinds of people in the world..."
1)We should be thinking about ways in which the UNIX philosophy is deficient, rather than continually reassuring ourselves that it's all okay. Look at it pragmatically: Who's got the biggest market penetration? Who's system is easier to learn to program in for the beginner, ignoring cost?
Okay, these are total flamebait questions, so please, please don't respond to these in particular. Use your imagination, and think of some ways in which Windows is better than UNIX, rather than touting all the advantages of your pet operating system. Otherwise, you're just brainwashing yourselves with your own marketing.
The question here isn't which way we should take things, it's how we should think about them. If you want to respond to this half of the question, address what the community should expect of UNIX, not how it should be done.
2)UNIX needs standards, reusability, etc. This is a set of recommendations to the community about where things should go specifically. If you agree to Miguel's motivations in the first part, then read on. His argument is based on looking at "the competition", and I can give you a concrete example.
He mentions IE, and how it's actually made up of a large collection of components rather than being a monolithic application. True. If I want IE's rendering capabilities in my application and I'm using something like Delphi(example because I actually had to do this once), Hell, I'll just draw myself a window and drop the browser component into it. You can argue about whether it's bloated code or not, but the end result is that I didn't have to reinvent the wheel to get something pretty momentous done. Further, I can now focus on doing something with this browser component that hasn't been done before.
For those of you who aren't interested in looking into it, Microsoft is working on something called dotNet. There's a lot of argument about what it all is, and whether it's useful, a product of the devil, etc. The thing that excited me about it is that components from one language can be used in another. And here's where I must admit that I didn't read the details about Bonobo. But my point is that Microsoft is going to have a fully operational Death Star of interoperability between languages pretty danged soon. Miguel rattles off a list of languages:
And this is exactly what isn't going to be the case with dotNet.
I know most of you have lost interest by now, and are happily moderating me down, flaming me, etc., but I have an appeal to those serious programmers and geeks amongst you who bore with me this far. It doesn't matter who came up with it, but isn't that just a bitchin' cool idea???
As you know, everyone who writes about their new features admits that you can already do the same thing in plain old C, but you also know how the rest of it goes.
By now, I've totally lost track of any other points I was going to make, if any. Please fill in the blanks with anything relavent you see:
This is a manual virus. Copy it to your sig and help me spread!