Unix: A Component Architecture?

seebs writes: "I wrote an article about Unix as a component architecture for the components 'zone' at IBM's developerWorks. They ran it. Here's an article (part four of a series) looking at how Unix has delivered on the promises of the object modules and component architectures that are so popular these days." This reminds me a lot of the book The Unix Philosophy.

Comments

simple interfaces

[selectspec]

The fact that unix is really just a chain of simple interfaces is the principle reason for Linux's existance. Linus knew what the POSIX API calls looked like and what they were supposed to do, but he had no implementation to work with. He tackled them one at a time, and was able to make progress because of the nearly linear progression of the interfaces. One builds upon another. Once he'd completed most of the system api, he was able to port GCC and then BASH. From there he was able to build the much of the early user space with little effort since that work was already accomplished in other unix environments.

The fact that unix's design is so module really is the reason it has been cloned so often. Windows and VMS on the other hand were designed reasonably ad hoc with massive sets of interfaces. Emulating the operating system is virtually impossible for these systems (my apologies to the wine folks who are braver than I).

Re:simple interfaces

[Alatar]

Wine Is Not an Emulator.

mod up

[jon_c]

my thoughts exactly! i went to the link thinking i would hear about how unix lacks a real component object model. instead i read a bunch of BS about how pipeing streams of data from one app to another is the ultimate tool.

unix badly needs something like COM. I would also agree that COM is flawed. I've spent the last 6 months at my job learning all the in's and out's, and you are right. it's very badly implemented.

-Jon

Re:mod up

[Twylite]

The GNOME team has been trying to bring some form of component model to Linux. Last time I looked (which was just under a year ago) I didn't like what I saw.

While they praised themselves on having a better idea than M$, their model (of Bonobo) was based EXACTLY on COM, with the basic interfaces being identical.

I have tried several times to engage Linux/*nix developers in conversations over component models, and they seem to "not get it". A similar problem to trying to convince this same group 5 years ago that C++ and OOP were good ideas.

We can just hope that in 5 years time they will come around. Unfortunately it is in matters like this that the community needs to be proactive in developing new standards.

Refer to the XML-RPC/SOAP developments: XML-RPC predates SOAP, but is Really Sucky (TM). Its true RPC, with no support for objects. SOAP itself is sucky - its bloated and underpowered - yet more and more effort is being put into supporting SOAP in opensource (especially the Java opensource developments), and not enough into innovation.

We have learned painfully over YEARS how to develop good protocols that are lightweight, fast (both in transfer time and processing time) and extensible. Neither SOAP nor XML-RPC fit the bill ; a couple of M$ (and associated) FUDmeisters have got even the OpenSource folks onboard with the idea that "human-readable protocols are the way to go".

Roses, noses ... you know the rest.

Tool chains versus Components

[Twylite]

I think the author of this article is failing to make an important distinction between tool chains and software components.

Unix unquestionably derives enormous power from tool chains, as described by the article. But a tool chain, or part of a tool chain, is not a component.

You COULD sort your database using sort, but you don't. You COULD select records using grep, but you don't. You COULD use a perl one-liner to total accounts in your general ledger, but you don't. The reason is that these routines need to be integrated into a software application, to prevent the mess of utilities that plague legacy applications.

The answer is components. These are not discrete tools; they cannot exist alone. A component is only meaningful when integrated into a larger application.

The author would have done a lot better to draw attention to the wealth of shared libraries available on Unix, yet even these are a poor approximatation of a reusable component model, despite their obvious value.

There are many good reasons to use COM, not the least of which being that COM offers geniunely reusable object oriented components. COM is, unfortunately, a good vision but a poor implementation. Still, it is somewhat better than DLLs (MS's equivalent of shared libraries).

The "perfect solution" is somewhere out there, not that we'll ever find it. But a step in the right direction would be a compromise between shared libraries and COM (read: shared object libraries), with effective yet simple bindings in a multitude of languages.