Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 0 down vote favorite

As we know a very basic software engineering principal is loose coupling. But we know that programs in UNIX-like OSs are extremely coupled. How this can be explained/justified?

I mean from extremely coupled, a lot of dependencies between programs, even when you want install a simple application you have to consider a lot of dependencies (as you see in app manager), some time even you are unable to update a program because it will break some dependent programs. Indeed stand-alone softwares are rare in beauty world of Linux (in compare with other OSs).

share|improve this question
2  
Do you know any non-trivial environment that is not "extreme-coupled" by your definition? – Mat May 18 '12 at 6:59
2  
What other OS doesn't have dependency issues? – Mat May 18 '12 at 7:15
1  
I would argue that Linux programs are actually quite loosely coupled since the alternative is to bundle all dependencies with the program (which is extreme coupling). – Leo May 18 '12 at 11:06
1  
So, the alternative scheme you're proposing will result in the following if, for example, someone discovers a security flaw in glibc: every single thing that might have glibc statically compiled into it will need to be updated, downloaded and installed. Is this a better world than the one we currently live in? – cjc May 18 '12 at 11:08
1  
There are good points in here, but this question is worded as a rant. I suggest that you study the architecture of unix systems more (you don't seem to be applying the theoretic concepts you've just learned correctly) and ask a more focused question with fewer preconceived notions of what the answers should be. – Gilles May 18 '12 at 14:54

closed as not constructive by Mat, Gilles, mattdm♦ May 18 '12 at 15:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

3 Answers

up vote 9 down vote

It's justified simply because the alternative -- overall -- is more work for less gain.

Virtually all computing systems (could argue: all systems, period) are built in layers. Each platform makes assumptions about what's below it. ls assumes there will be a C standard library. Which assumes there will be a kernel. Which assumes there will be computing hardware. Which assumes there will be a steady voltage, etc.

By making those assumptions: I write code faster. I can do more. I don't care about bundling a C library, or a zip library, or a crypto library: someone else does that. And when someone else decides to improve or upgrade those components, I benefit transparently. And so do all other programs sharing that code. In a coherent system, it's faster, cleaner, smaller, better.

But, as you note, it is more dependent. And if crypto is upgraded in an incompatible way, I break, and package management becomes difficult. To truly decouple the kinds of deps that make package management difficult, components need to inline their deps. They need include more of the stack below them. And this is the crux of the issue: to create a program that has fewer dependences, we need a build system that understands more. And that's not where developers want to (or should) spend their time.

You describe the current predicament as "extreme coupling". People have experimented with making everything independent: checkout stali, a linux distro that aims to keep all binaries statically linked. But an extreme-decoupling would be just as debilitating: imagine one VM for every program.

The phenomenal growth of our industry is largely due to our ability to build rapidly on what's come before. Literally and metaphorically, we stand on the shoulders of giants. Maybe in the future, we'll swallow a giant as the first step of making one taller. For now, though, the compromise seems roughly correct: lets keep climbing, and make sure the giants below us play nice.

share|improve this answer
Did you mean it root in trying to reduce developing time? Perhaps developer would be more comfortable, but users (that could be serveral millions) will be in a lot of trouble and have to spent a lot of time for installing/uninstalling/updating a sofwate. – PHPst May 18 '12 at 10:45
@Reza: They may have to spend some more time installing/uninstalling/updating, but on the other hand they spend very much less time downloading since every program does not have to bundle all dependencies. They also do not have to spend as much disk-space or RAM when running the programs. – Leo May 18 '12 at 11:05
Thanks, Most of linux programs are distributed as source code that are far larger from compiled ones. When you decide to reinstall a program you have connect to Internet and download a lot of files that you previously downloaded once. But if a program was stand-alone you had not to re-download theme. Actually if your Internet connection disconnected you actually can not Install any thing. – PHPst May 18 '12 at 11:51
Another point is that nowadays HDD and RAM are cheap and capacitive. Nowadays TIME is much valuable. – PHPst May 18 '12 at 12:21
1  
You will waste far, far more time when you need to download all the statically compiled software that has to be updated, because of a security flaw found in glibc. You will have to trust every vendor to update every statically compiled software they publish in a reasonable time frame, instead of just pulling down the updated glibc package. This would be a complete nightmare. – cjc May 18 '12 at 12:32
show 1 more comment
up vote 2 down vote

Is it strongly coupled? Actually I think the 'do one thing well' principle and the use of pipes etc to build working applications suggests loose coupling. When you run, say ps axf | grep vim then ps and grep are very loosely coupled.

share|improve this answer
Thanks, but your answer is off-topic – PHPst May 18 '12 at 12:24
1  
@Reza On the contrary, this is an important point: programs are built on top of other programs and rely only on the outside behavior of these programs, not on their implementation details. This is an important point, showing loose coupling. – Gilles May 18 '12 at 14:53
@Gilles, My question is about dependencies, not programs communications and APIs that not lead to be coupling. – PHPst May 18 '12 at 15:34
up vote 2 down vote

There is no "extreme-coupling" with Unix and Unix like OSes.

Extreme-decoupling (i.e. Stand-alone software) was the norm in the beginning of Unix at a time when everything was on CLI.

The only notable coupled code were shell scripts themselves, as they needed the commands they call to be available. Most of these commands were part of the default installation though so that wasn't a issue.

The introduction of large libraries like the one used with graphic environments (X11, widget toolkits and similar) demonstrated embedding all the required libraries in a single executable was inefficient in both storage space (large executable files at a time when disk space was sparse) and in memory usage (a lot of duplication of the same code, at a time when RAM was sparse too). The shared objects were then introduced to overcome these limitations.

We are now in a situation where the dependency tree for applications can be quite complex, usually because of the required libraries and similar files. The idea is for developers to concentrate on their core applications and leverage the remainder to existing stuff, i.e. not to reinvent the wheel.

This should not pose much problems outside those caused by new version breaking compatibility with older ones and naming clashes excluding software to install together on a same machine. Both of these issues can (should) be avoided by good design and standards.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.