decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Thursday, March 31 2005 @ 08:58 AM EST

Coupling and the Maintainability of the Linux Kernel
~ by Dr Stupid

A recently presented paper has the following abstract, something that would certainly gain the attention of anyone interested in Linux kernel development:

Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel

Data coupling between modules, especially common coupling, has long been considered a source of concern in software design, but the issue is somewhat more complicated for products that are comprised of kernel modules together with optional nonkernel modules. This paper presents a refined categorization of common coupling based on definitions and uses between kernel and nonkernel modules and applies the categorization to a case study.

Common coupling is usually avoided when possible because of the potential for introducing risky dependencies among software modules. The relative risk of these dependencies is strongly related to the specific definition-use relationships. In a previous paper, we presented results from a longitudinal analysis of multiple versions of the open-source operating system Linux. This paper applies the new common coupling categorization to version 2.4.20 of Linux, counting the number of instances of common coupling between each of the 26 kernel modules and all the other nonkernel modules. We also categorize each coupling in terms of the definition-use relationships. Results show that the Linux kernel contains a large number of common couplings of all types, raising a concern about the long-term maintainability of Linux.

To anyone with a knowledge of software engineering terminology, whether gained through formal education or from the University of Life, the first 90% of the abstract is uneventful; this, though, serves to maximize the impact of the final sentence. A "concern about the long-term maintainability of Linux," no less. Mr A. Linux Kernel went to the effort of writing that reports of his destruction had been exaggerated, but now we find in this paper rumours are circulating of a life-threatening illness.

The full paper is only available to subscribers (note however that one of the authors makes a copy available on his personal website here [PSF]), but we were fortunate to be able to discuss the paper with Andrew Morton, one of the lead kernel developers, in two contexts: first, in a general discussion about coupling and kernel maintainability, and then, after he had read the complete paper, in specific terms related to the thoughts expressed by the authors. As you will see, despite the worries expressed in the paper, the Linux kernel is alive and well.

The researchers, in designing a theoretical model to evaluate the coupling of Linux, have of necessity made certain assumptions to reduce complexity and make the problem amenable to a mathematical, quantitative approach. However, this can lead to inaccurate results: you may recall the possibly apocryphal tale of the mathematical demonstration that bumblebees can't fly. (As an aside, there is also a parallel here with studies showing operating system X to be "more secure" than operating system Y, when on closer inspection the definition of "more secure" is a narrow and potentially misleading, but easy to calculate, statistic figure.)

What is coupling?

"Coupling", a term which uses a visual metaphor of mechanical parts coupled together by a driveshaft, is used widely in software engineering to describe a link between two parts of a system that is not part of an abstracted interface. We make this distinction because the parts of a system have to be linked in some way -- otherwise there would be no system. For the benefit of Groklaw's less technical readers, I'll try to explain the concept in non-software terms (kernel developers may skip the next few paragraphs.)

Imagine that the steering wheel of a car was like the steering wheel one can buy for playing computer driving games -- that is to say, it merely generated an electrical signal that said "a little bit left," "hard to the right," etc. and that this signal was passed to a device under the bonnet that turned the front wheels. You could replace the steering wheel with a similarly wired joystick, or anything that generated an appropriate electrical signal, and you could still drive the car. We would call this an abstracted interface. The communication between the two parts (the steering wheel and the mechanism that turns the front wheels) has been reduced to its conceptual essence of "I want to go left" and "I want to go right."

In a typical car, though (especially one without power steering) the steering wheel is directly and mechanically linked to the front wheels. You could not easily replace the steering wheel with a joystick, because the whole mechanism depends on the wheel being turned left and right. But not only is the interface less abstracted, but it is also highly coupled. You can feel bumps and vibrations coming back up from the wheels on the road. In other words, the coupled interface means that what happens to one part of the mechanism (going over a rock) has a knock-on effect on the other (giving you a pain in the wrists) that wasn't necessarily desired.

Going back to software terms, we would describe modules A and B as coupled if, to operate properly, A relies on B's internal workings to be a certain way, and vice versa. Just as a traditional steering wheel is sensitive to holes in the road, A becomes sensitive to changes inside B. That introduces a risk that when a bug is fixed in B, it may cause an unexpected problem in A. It is this "knock-on effect" result of coupling that makes software engineers -- especially when talking theoretically -- nervous of coupling. They invent approaches like "Model View Controller" to discipline themselves against thoughtless coupling.

However, I hope that the above example also shows you the other side of the coin. The high-tech electronic steering wheel was less coupled, but more complex. There are more elements to go wrong, and a fault may be harder to find. Also, some drivers would like to "feel the road" via the steering wheel, and to give this feedback in the electronic system would require more complex circuitry still. Sometimes, the costs of eliminating coupling in a system outweigh the gains.

Back to the kernel

The paper focused on data coupling; roughly speaking, this is where two or more software parts all make direct use of the same area of computer memory. This can lead to situations where a particular part can have data changed "behind its back," as it were. The developer has to bear this in mind when writing the code, which isn't always easy.

We asked Frank Sorenson to read the paper and here is his comment:

Too many dependencies between modules can obviously be viewed as a bad thing. However, no coupling/dependencies leads to multiple copies of the same thing, which is obviously more difficult to maintain. For example, the Linux kernel contains a library of common functions that may be used in the various modules. A month or so ago, someone realized that 6 different modules all implemented a 'sort' function, all with the same interface to the module. This brought about a push to standardize them, and a single 'sort' function was put into the common function library.

We've already mentioned that the costs of decoupling aren't always justified -- this is a case in point. In this instance, increasing the use of common code -- while increasing the coupling -- reduced the maintenance requirements.

Frank continues:

The article was submitted in July 2003. That's quite a while ago in Linux-kernel-time. A lot has changed since then, and 2.6.x is (in my opinion) more maintainable due to being well-engineered from the beginning. Do the authors have results for the 2.6.x kernel? How does the use of global variables change from 2.4.x to 2.6.x?

The kernel maintainers have pushed to make sure that the interface to kernel functions remains the same. For example, it would not be acceptable to change the way a common function behaves: copy_value(source, destination) should not ever change to copy_value(destination, source) (unless all references are fixed)

Linux modules are generally organized in an hierarchical fashion. This makes it much harder for a change in one area to affect other modules or portions of the kernel.

Obviously, what the authors discuss is a very real danger (not specifically to Linux, but to any sufficiently large project -- such as Longhorn!). The authors don't offer many valid suggestions on how to combat the problem. The fact that Linux is open allows them to do the research, however; the closed nature of Windows prevents people from seeing how Microsoft has addressed this problem (if at all.)

If Linux is too tightly coupled, how about Windows? Having your entire user interface dependent on a web browser -- now that's coupling!

My personal opinion is that the 2.6 is much tidier and more organised than 2.4, which in turn was tidier than 2.2, etc. The direction of the Linux kernel is towards a cleaner, less coupled architecture -- there is an active, ongoing, continuous effort to preserve maintainability. Indeed, patches are frequently rejected purely on the grounds they harm maintainability and have to be re-engineered accordingly.

Andrew Morton's comments

However, you probably didn't read this far to hear Frank and I discussing the kernel, when we have Andrew Morton available. Here's his initial comment on the abstract:

They examined a kernel (2.4.20) which is unchanged in this regard from 2.4.15. We've done three and a half years of development since then! That being said, I wouldn't be surprised if their analysis showed that linux-2.6.11 also has a lot of coupling, even though we have done a lot of improvement work in that and other areas.

But that's OK -- we often do this on purpose, because, although we are careful about internal interfaces, the kernel is optimized for speed, and when it comes to trading off speed against maintenance cost, we will opt for speed. This is because the kernel has a truly massive amount of development and testing resources. We use it.

More philosophically, I wouldn't find such a study to be directly useful, really. It represents an attempt to predict the maintenance cost of a piece of software. But that's not a predictor of the quality! If you find that the maintenance cost is high, and the quality is also high, then you've just discovered that the product has had a large amount of development resources poured into it. And that is so. And it is increasing.

If someone wants to use this study to say that "Linux is likely to be buggy" then I'd say "OK, so show me the bugs". If they're using it to say "Linux kernel maintenance uses a lot of resources" then I'd say "Sure. Don't you wish you had such resources?".

Note that I'm not necessarily agreeing with the study. If they looked at the kernel core then sure, there's a lot of coupling. But that's a relatively small amount of code. If they were looking mainly at filesystem drivers and device drivers (the bulk of the kernel) then I'd say that the study is incorrect -- the interfaces into drivers is fairly lean, and is getting leaner.

Andrew then went on to read the paper in detail. His subsequent comments were rather different:

AAAARRRGGGGHHH! . . .The only thing they've done is look at the use of global variables and they've assumed that using a global variable is a "bad" coupling. And look at the naughty global variables which we've used:

jiffies: This is a variable which counts clock ticks. Of course it's global. Unless they know of a universe in which time advances at more than one speed at a time.

[Dr S: System time has to be global because time is a universal throughout the system.We don't usually worry about Einstein in software development :) ]

And they fail to note that if we did want to "modularize" jiffies, we'd make a change in a single file:

#define jiffies some_function_which_returns_jiffies()

Other examples such as system_utsname, init_task, panic_timeout, stop_a_enabled, xtime and `current' are all by definition singleton objects.

'current' is especially bogus -- this refers to the task structure for the currently-running task. It's not a global variable at all, really. If this is bad, then using the variable 'this' in C++ is also bad.

Geeze. Who reviewed this?

Theory vs Practice

Of course, one can engage in armchair debate endlessly; ultimately, what is needed is some empirical data against which a model or theory can be tested. Coupling, like cholesterol, comes in "good" and "bad" forms. The good form enables a system to work at peak performance, without introducing excessive maintenance costs. The bad form results in a system that is increasingly fragile and hard to scale. Which of these in practice has been uppermost in Linux kernel development?

This kernel mailing list thread from 2002 -- discussing a kernel of similar vintage to that covered by the study -- is of interest. Several people expressed a worry that the kernel would never effectively scale beyond 4 CPUs -- and coupling was one of the issues:

[2-CPU SMP] makes fine sense for any tightly coupled system, where the tight coupling is cost-efficient.

Three years later, have "long-term maintainability" issues in the Linux kernel held it back? Here's what Novell said last July [PDF] on the topic:

"More than 128 CPUs have been tested on available hardware, but theoretically, there is no limit on the number that will work."

This bumblebee continues to fly.


  


Coupling and the Maintainability of the Linux Kernel- by Dr Stupid | 195 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections, if any, here - please.
Authored by: ankylosaurus on Thursday, March 31 2005 @ 09:11 AM EST
Interesting stuff...

---
The Dinosaur with a Club at the End of its Tail

[ Reply to This | # ]

Off Topic Here, Please
Authored by: ankylosaurus on Thursday, March 31 2005 @ 09:14 AM EST
Please include clickable URL's:


<a href="http://www.example.com/"> text </a>

Remember to use HTML mode.

---
The Dinosaur with a Club at the End of its Tail

[ Reply to This | # ]

Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: Anonymous on Thursday, March 31 2005 @ 09:16 AM EST
I did some hacking on user-space networking software a couple of years ago and
had a look at Linux's (2.4) and NetBSDs (1.6) networking code.

I'd say it took about a quarter of the time to understand NetBSD's code compared
to Linux. So I understand completely if someone believes that Linux is hard to
maintain.

I run NetBSD on my firewall and Linux on my main worstation, so I'm happy with
both as a user. But as a developer I would never touch Linux if I could use
NetBSD instead.

Klas Adolfsson

[ Reply to This | # ]

Insufficiently studied quantitative analysis
Authored by: Anonymous on Thursday, March 31 2005 @ 09:23 AM EST
Studies of the flight of bumblebees is a pretty good analogue for studies of
complex software systems. The old statement that "the impossible
happens" was based on a fundamental lack of understanding about what really
happens: What bumblebees do is better described as "swimming" than as
"flying". I believe the researchers involved caught on to the real
dynamics of insect "flight" pretty quickly...

Many people use the word "monolithic" to describe the design of the
Linux kernel, as contrasted with the modularity of microkernels. In fact that
was the subject of a great little "discussion" between Linux and
Andrew Tanenbaum 12 years ago. But, as someone who works in that world all the
time (doing basic embedded Linux, including occasional driver work), I do not
really agree.

The "kernel" is not nearly as monolithic as it would seem at first
glance. The kernel comprises many subsystems, and while each of those
subsystems has plenty of coupling, there is surprisingly little systemic
coupling.

Finally, counting global variable usage in a software system is a nice
first-order approximation to coupling. It is not a perfect measure, any more
than any single trivial measurement technique can capture the reality of any
nontrivial system.

PJ, thanks again not only for helping the community with this website, but also
for "blogging" on topics that are not exactly-directly-law. This site
is a genuine community resource, and much appreciated.

[ Reply to This | # ]

Thanks Dr S n/t
Authored by: Anonymous on Thursday, March 31 2005 @ 09:56 AM EST
.

[ Reply to This | # ]

  • Thanks Dr S n/t - Authored by: Anonymous on Thursday, March 31 2005 @ 11:41 AM EST
Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: gbl on Thursday, March 31 2005 @ 09:57 AM EST
It's been a very long time since I cared about the details of the Linux kernel. I do however use Linux and so need a user interface. These days it seem that the default is Gnome. Unfortunately I see in the design of Gnome all the faults I previously saw and rejected in Windows. ie a mysterious monolith which only plays well with members of it's own gang.

One of the fundemental advantages of Unix is that each program does one thing and does it well. Today we see that advantage thrown away by OpenOffice, Gnome, Mozilla and a number of other huge projects that are hurtling down the wrong road.

Why are we re-implementing the mistakes of the past? To gain market share at the cost of what makes Linux better?

Have we no new ideas on how to design applications or the user interface?

---
If you love some code, set it free.

[ Reply to This | # ]

Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: lgrant on Thursday, March 31 2005 @ 10:00 AM EST
The coupling debate has been going on for a long time; in the '70's, I used to
read Glenford Meyers's excellent books on the subject. It is always a
tradeoff.

A module is most flexible if it doesn't have side effects outside the interface.
For example, suppose you have a module that formats an error message and prints
it on a printer. That is nice, but suppose you want it in a buffer, so you can
send it to someone. If the module insists on printing the message on a printer,
it won't do the job. Ideally, you would pass it something to tell it what to do
with the message.

Common coupling is potentially bad because of side effects. It is not
necessarily clear from the interface that when you call this module, it is going
to read or mess with something in the common area. Also, when you have stuff in
the common area being written by various modules, it can be hard to figure out
who changed something when it gets changed wrong, and if you are multi-tasking,
there are all kinds of serialization issues.

But look at the alternative, where you have a "pure" interface, where
there is no coupling, and everything that the module affects, or that affects
the module, comes through the interface. And suppose you have a series of
modules calling one another. If you decide that the lowest level module needs
to know what time it is, you have to add the clock as a parameter to it. But
then you have to add the clock to the parameter list of all the modules in the
chain, back up to the top, so that they can pass the clock. What was a simple
change suddenly affects a whole slew of modules. This is as much of a
maintenance nightmare as having too much common coupling.

In all the systems I have worked on in the last 30 years, both system and
application, they all start out with a common area for stuff everybody needs.
The good systems deal with serialization of non-read-only common variables early
on, though I've worked on several systems that didn't worry about serialization
until they started having timing problems and race conditions and such.

The operating system I work on mostly in my day job, IBM's MVS, has been around
for at least 35 years, and has an obscene amount of common coupling. It's a
pain sometimes, but it works, and I don't see it going away any time soon.

So I would not worry too much about the Linux kernel being unmaintainable.

Lynn Grant

[ Reply to This | # ]

Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: cf on Thursday, March 31 2005 @ 10:08 AM EST
This paper appears to be essentially a restatement of the old microkernel vs.
monolithic kernel debate. Those ensconsed in the academic realm tend to like
the elegance of the microkernel architecture; its well defined interfaces
between modules fits their worldview of form equals function, plus its easier to
teach.

Those that live in the real world and have to deal with messy concepts like
performance (this is quite useful in computers, no?) tend to design based on
"what really works" rather than according to somebody's idealized
notion of correct.

Plus Morton's comments regarding the use of global variables as the indicator of
module independence is quite telling. This really is a fairly unsophisticated
analysis.

[ Reply to This | # ]

Much Ado About Nothing, This
Authored by: Anonymous on Thursday, March 31 2005 @ 10:12 AM EST

The authors of the paper have lived in a hierarchical world, rather than in one where horizontal and parallel development has occurred. Certainly there are arguments for smaller kernels, even microkernels. The less there is inside a kernel, the tighter it is, and better coupled-- and tight coupling is preferred because it reduces the number of relationships and variables and possible states of the kernel. Reliability and discernibility are improved. Bigger isn't better.

But Linux kernel development has defied this with great success so far. There has to be a future point, however, where kernel development faces a re-write that additionally rids itself of legacy compatibility to shrink the kernel. It will have the Linux DNA, but must shed reams of code or become leaden, brittle, difficult or nearly impossible to maintain, and pocked with exceptions. This is what's happened to Windows-- a house of cards that's so difficult to rev that it takes billion dollar efforts. So, there is a kernel of truth in what's said in this synopsis. I hope kernel hackers aren't to vain to hear the message, even if the message is based on older code-- it's a significant one.

[ Reply to This | # ]

Old news...
Authored by: Anonymous on Thursday, March 31 2005 @ 10:13 AM EST
This is a case of trying to quantify, in some rudimentary way, something that
goes on all the time. Engineering design decisions get made, reversed, and
re-made, as the development and application of a design changes. The kernel
developers do this, and have concrete reasons for most of their decisions, I'm
sure, and yet, those concrete reasons are not absolute. You choose a path among
myriad possibilities when designing a concrete structure.

"jiffies: This is a variable which counts clock ticks. Of course it's
global. Unless they know of a universe in which time advances at more than one
speed at a time.

[Dr S: System time has to be global because time is a universal throughout the
system.We don't usually worry about Einstein in software development :) ]"

As far a Einstein is concerned, if you wanted to port Linux to a special-purpose
*asynchronous* processor, then relative time might be useful.

Geek Unorthodox

[ Reply to This | # ]

Evidence is very thin on the ground
Authored by: Anonymous on Thursday, March 31 2005 @ 10:42 AM EST
Both coupling and cohesion are beleived to be factors that effect the maintainability of software. However, to date the experimental evidence is very thin on the ground. In fact the experimental evidence for many of the claims made by software engineering academics is usually scant or non-existent.

Open source projects are providing some very useful data for academic researchers. However, many more data points will be needed before any statistical correlations can be reliably claimed.

A copy of the paper can be obtained her e

[ Reply to This | # ]

Paper can be found here.
Authored by: Anonymous on Thursday, March 31 2005 @ 10:57 AM EST
Full Paper can be found here.
Ful l Paper

[ Reply to This | # ]

Bah
Authored by: pmk on Thursday, March 31 2005 @ 11:07 AM EST
I've worked on several variants of UN*X kernels, including microkernel-based
implementations and my own monolithic kernel, and have recently ported Linux to
a new architecture (Cray X1). And I think that these "coupling"
metrics are useless crap.

Kernels are complicated pieces of software. They're especially hard to make
portable to wildly different processor and system architectures. But monolithic
kernels are not needlessly complicated; if you know what a kernel has to do, and
have the right perspective, the code is straightforward. Linux is actually
pretty elegant inside, and fun to port.

Perhaps some of the confusion stems from thinking of a monolithic kernel as a
"program". Apart from the boot phase and the occasional daemon, it's
actually much more of a big shared library used by all processes, which run in
both user and kernel modes. This library needs to manage lots of common
resources and do so efficiently. It's not an easy problem; but microkernel
implementations have to solve it too, and the extra interfaces detract from
clarity rather than contribute to it.

Just MHO.

[ Reply to This | # ]

Not a programmer...
Authored by: Latesigner on Thursday, March 31 2005 @ 11:14 AM EST
but I do take note of political implications.
I have the definite feeling that we've just headed off a FUD attack.

[ Reply to This | # ]

  • Couple of quips.. - Authored by: Anonymous on Thursday, March 31 2005 @ 12:19 PM EST
Coupling widely misunderstood.
Authored by: emmenjay on Thursday, March 31 2005 @ 11:32 AM EST
Coupling is a moderately esoteric thing and it is pretty hard to nail down a
good definition. Some of Dr S's examples are helpful, but I don't think they go
far enough.

As a programmer/engineer for over 15 years, let me express a few of my
thoughts.

Let's say that I have a 100 line C program and I want to make a change to some
data object. Maybe change it from a 32 bit int to 64 bit or change the units it
uses or such.

I can carefully inspect my hundred lines of code and find any code that uses the
data - and fix it.

Now let's take the same idea to a 10,000 line program. I don't know how many
LOC in the Linux kernel, but it is probably at least 10K. I cannot reasonably
inspect 10,000 lines of code and hope to find every use of the data. That means
that any change to the data is likely to break something else. Possibly in
subtle ways that are hard to find.

Now engineers have long ago spotted this problem. The way it is generally dealt
with is with some set of rules about what parts of the program can access what
data. We divide the program into modules, where a module consists of a
collection of data and functions. In a true object oriented design, we don't
let any module access another module's data directly. The module provides
functions to get and set the data.

e.g. (in C++)

class CSomething {
private:
int data;
public:
int GetData();
void SetData(int new_value);
};

Here we have a class with some data, and functions to access the data.

This produces zero coupling. We can change the data any way we like. We can
add new functions to do different things to the data. As long as
GetData/SetData still behave the same, we run little risk of breaking anything.
This is known as "encapsulation".

So why doesn't every program do that? The main reason is performance. Calling
extra functions uses extra CPU cycles. For your average application, that is no
excuse. CPUs are fast and robustness is generally worth a few cycles.

In a few, specialised, situations, you find that every CPU cycle counts and
encapsulation is too much overhead. Many of those specialised situations occur
when doing kernel programming.

That is not the only reason. Coupling is not well understood, and in the early
days of Unix it was not understood at all. Programmers who's background is in
Unix/C will spmetimes write code that allows too much coupling, simply from not
knowing better.

So what does it mean for Linux? Two things.

Firstly, coupling is not a death sentence. I don't really know if the Kernel
has too much coupling, but I wouldn't be surprised if it has. That *doesn't*
mean that is about to self-destruct. It is just something that the developers
need to keep in mind and take care with.

Secondly, kernel developers can make a conscious decision to root out
unnecessary coupling. Dispite what some other posters have said, global
variables are pretty much always bad. Sometimes, for performance reasons we
have to live with them. However where that is not the case we sould get rid of
them.

Somebody gave the example of system time being global. Why not make it static
(only visible in one file) and write Get/Set functions. That way, if you ever
need to change the format (32bit-->64bit, higher resolution for faster
clocks) that can be encapsulated and the rest of the program is protected.

So the bottom line: ignore the FUD, but take risks on board and work through
them. :-)

P.S. Somebody asked about Windows and coupling - Windows is unspeakably bad.
That's why every bugfix seems to break something and why a minor bug can make
the whole system vulnerable.

[ Reply to This | # ]

Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: Scott_Lazar on Thursday, March 31 2005 @ 11:35 AM EST
My thanks to Dr. S, Andrew Morton, and PJ for this article. You made facets of
the arcane world of kernel development far more understandable with this
explanation.

---
Scott
-------------------------
LINUX - VISIBLY superior!
-------------------------
All rights reserved. My comments are for use on Groklaw only.

[ Reply to This | # ]

Relativistic CPUs
Authored by: Anonymous on Thursday, March 31 2005 @ 11:44 AM EST
Einstein doesn't apply here. Even if the CPU is moving at some relativistic
velocity, Einstein doesn't apply unless one part of the kernel is moving at some
relativistically significant velocity with respect to some other part.
Otherwise, all parts of the OS experience the same time. (Synchronising with
the time experienced by an observer who is moving with respect to the CPU/OS -
well, that's an application problem, not an OS issue ;-)

So even Einstein and the theory of relativity don't drive you to need jiffies to
be anything other than global.

(You might have to keep more than one time if the OS had, say, two CPUs, and one
CPU was moving at 80% of the speed of light with respect to the second CPU, and
you were trying to have one OS image on the two CPUs. But if you're trying to
do something like that, you probably have worse problems than the system time -
things like, say, communication lag between the CPUs, for instance.)

And this isn't even O/T, because the article mentioned it!

MSS

[ Reply to This | # ]

Suck it and see!
Authored by: cybervegan on Thursday, March 31 2005 @ 12:24 PM EST
The best way to evaluate how good or bad the Linux kernel is, is to test how
durable and effective it is in common day-to-day use.

We don't see problems with stability.

We don't see snowball patches appearing.

We don't see thousands of malware programs eating through linuxspace.

If there were such incidents, instead of the hypothetical *possibility* of them,
then the anti-linux press would be shouting them from the rooftops. But they're
not - they have to make do with inflammatory stories based on dubious research,
funded by a particularly large company with an even larger vested interest in
the "failure" of linux.

Talk about the proverbial little Dutch boy plugging the hole in the dyke with
his finger! For the vested interests, it's really a case of (to quote Led
Zeppelin) "When the levee breaks, got no place to stay".

And you can bet if the levee does break, they'll try to paint us as the bad
guys!

It has to be said, though, Linux, just like any other large, complex piece of
software, has it's flaws and weaknesses, too - it's made by humans, who are by
our very nature, fallible. I don't see any of these flaws holding *me* back,
and every week, more and more big, grown-up companies and organisations are
saying they don't either.

There will always be Linux security fixes and debates about how Linux is
developed, but at the end of the day, forget the statistics: look at what's
happening in the real world: Linux continues to gain ground in all areas, and
just continues to get better. Just as the established leader is beginning to
show obvious signs of structural fatigue.

Poetic justice, if you ask me. We will continue to use Linux, because we know
what is best for us. Others are intrigued by our strange obsession, and are
beginning to get inquisitive; as they ask more questions, they begin to see why
we have made such a choice, and begin to ponder if they should, too. Some of
them do, and more every day. THAT speaks volumes.

regards,
-cybervegan

---
Software source code is a bit like underwear - you only want to show it off in
public if it's clean and tidy. Refusal could be due to embarrassment or shame...

[ Reply to This | # ]

Coupling and the Maintainability of the Linux Kernel- by Dr Stupid
Authored by: Anonymous on Thursday, March 31 2005 @ 12:30 PM EST
Though the article has the mentioned flaws the Linux
kernel has some fundamental design errors. Also the
development models are many times quite sick. If compared
to simpler (easier to maintain, simpler to understand,
easier to keep secure) micro-kernels and some really
secure and maintainable OSes and noticing a few tiny
flaws:

- Linux kernel keeps device drivers and all kinds of
unnecessary stuff running in kernel. It gives slightly
(~5% at the moment afaik) better performance in overall
but creates horrible security problems. The drivers and
such can't be governed for security well unless if they
are moved to user-land..

- Linux kernel developers are fundamentalist religious
about forcing stuff to be Open. In such they are against
ABIs and that makes 3rd party devices drivers hell. They
might break at every tiny release (for instance 2.6.11
breaked VMWARE's modules) and at least on 2.6 tree that
happens a lot. That's _bad_ for hardware support and even
drives away some companies because it looks it's too
bothersome to support Linux at all. And guess what? It IS
horrible unless you go open source. Why the duck should
everyone want that?! I couldn't myself care less, I just
want my stuff to work. Thanks a lot, jerks.

- Even widely wanted things like fbsplash (vendors won't
go without it and neither do at least I) (and device
drivers etc.. LOTS of stuff) are being kept out of the
official tree.. Nice trying to maintain a professional
grade distro when half of the kernel related features keep
breaking and you got to always wait for the features be
fixed again before being able to upgrade at all.

- Linux kernel was never designed to be secure. It was
designed quite much everything else and the "security
features" were glued on top later. For instance SELinux
and LSM was allowed only if it stands quietly in the
corner. Well, they do, they do.. But SELinux is slow (if
compared to for instance r(s)bac implementations), has
only tiny amount of the hooks it would require to bring
real security. Furthermore LSM is able to do only a few
things - not for instance buffer overflow protection - and
it's (as a general policy) the only place where security
features are allowed to be implemented in official tree.
LSM also still even today exports the symbols out to
everyone making it a distasterous risk.

- Linux supports too many arches, all kinds of mysterious
crap that no one uses. If it was programmed maintainable
(higher level abstractions and stuff) it would be aok. But
now the mainline development lags a bit because for
instance some ancient crap like MCA stuff is still being
maintained. Who cares? They could keep using the old still
working versions, why waste time with them.. The resources
should be used "a bit better".

- How can be something well maintainable if it is poorly
documented? It takes ages to get the new features really
documented and though Documentation/ has some great stuff
there is lots of complete trash (aged, etc) too - and a
lot of important stuff is missing.

- Why 9/10 of the security related fixes are being done in
complete dark? There is even some lying around, sadly. (A
few developers claiming there is no problem and then not
even looking at the code.. Or then fixing things silently.
You know, LKML is the place on the Internet where
arrogance flows like oxygen and if you got The Status the
rest are automatically wrong.) The #1 place to find 0-day
remotely exploitable kernel bugs is the kernel.org
changelogs. Just look at the diff with a bit sense and
voila - you got the tools to own 99% of the Linux servers
on the Internet. I bet not many sysadmins update pretty
much daily their kernels.. It's a complete wonder to me
why the kids haven't realized this and exploited...
Perhaps they just are too stupid - which is nice.

Nah. Just couple _tiny_ examples of what really is wrong
in there. A few of the details were a bit "thrown" in but
I won't write a complete book now into this little silly
text box. You know.. Some people can think outside the box
and really surprise with magnificent stuff. Some people
then again can't. They have their heads up to their
*cough* and play around hyping and acting pathetic.

(I use Linux all the time. There are lots of great sides
into it. I would like however the bad things to be fixed
as well.)

[ Reply to This | # ]

Risks in backward compatiblity?
Authored by: Anonymous on Thursday, March 31 2005 @ 01:28 PM EST

I'm wondering if it was decided that the risks entailed in maintaining backward compatibility was decided to be too great, and that explains why we are now in shared-library-hell, as newer versions of libraries don't seem to substitute. How many times have I tried to upgrade the OS version, only to find out all my old utilities either have to be rebuilt or I have to find every version of every library ever made and get them installed (which is what I usually do about the problem as it's usually easier). I've been upgrading periodically since I first installed Linux at home in about 1991, and you ought to see the nightmare in /lib. An upgrade for me usually consists of a new install in a new root partition, and a script I've been evolving that applies all my configuration options, then mounting all the non-root partitions in place and copying in old libraries as I find utilities that don't work because they're not in the new release. While it seems to show the kernel to be pretty compatible, the same seems much less true of the shared libraries.

The shared-library an example of coupling as well, is it not? An API doesn't help much if it's constantly evolving and doesn't bring the past forward with it. Are these things designed with so little foresight that every rev level generally breaks the old programs? Is the point of a shared library to reduce the in memory space of running programs (which it doesn't, if each program is running it's own version of it), or to make upgrading the libraries separately from the applications easier (which it clearly doesn't, or the programs wouldn't need the old ones)? I guess it's neither, in which case I'd like to know just what the point of shared libraries are...

[ Reply to This | # ]

Coupling defined
Authored by: overshoot on Thursday, March 31 2005 @ 02:35 PM EST
For those who aren't current with terms in software engineering, coupling is a metric for how much a piece of software depends on knowledge about another. It's a metric in that there are degrees of coupling:
  • Data coupling - Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are shared (e.g. passing an integer to a function which computes a square root).
  • Stamp coupling (Data-structured coupling) - Stamp coupling is when modules share a composite data structure, each module not knowing which part of the data structure will be used by the other (e.g. passing a student record to a function which calculates the student's GPA).
  • Control coupling - Control coupling is one module controlling the logic of another, by passing it information on what to do (e.g. passing a what-to-do flag).
  • Common coupling - Common coupling is when two modules share the same global data (e.g. a global variable).
  • Content coupling - Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).

The coupling discussed here appears to mainly be common coupling. One thing not adequately discussed is whether the "common variables" in question are WORM (Write Once, Read Mostly). If exactly one module is allowed to write to a variable, it's generally not a problem to let others access it as (effectively) read-only.

Classic examples of this are the system variables in /proc -- all sorts of processes can read them, but only their "owners" can write to them. Not materially different from having an "access method" which returns their values, such as /bin/date

[ Reply to This | # ]

It's All Relative
Authored by: sproggit on Thursday, March 31 2005 @ 02:48 PM EST
This is an interesting submission [as are some of the feedback items] but I'll
add to the mix with my limited observations of the Windows world. My experience
of developing for and working with Windows ranges from NT 3.51 to Win2000, so
that's my context. [I'm now a dedicated Linux user, btw].

Back in the days of NT 3.51, the Video Driver sub-system was user-space code and
not treated as part of the core OS. The same was true for many device drivers.

However, with the arrival of Windows NT 4.0, Microsoft moved their video
subsystem into the kernel space [not ring 0, but out of the user space] and
cited performance improvements as the driver at the time. They certainly got a
speed increase - and have worked at it since. *However*, the point behind
mentioning this is to observe that whilst the Development Community for Linux is
working [as Andrew Morton et al have shown] furiously and fastidiously to remove
weaknesses from the architecture of Linux, Microsoft are cheerfully galloping in
the opposite direction.

My next example concerns other device drivers. Microsoft now recommend that
their hardware partners participate in a Code-Signing process that uses
public-key cryptography techniques to digitally sign the code included in driver
modules. What this does, in effect, is ensure that any time you try and install
an unsigned [ie suspect] Driver into Windows 2000 or later OS, you get a pop-up
window that warns you the code is not trusted. Why? What's the point? Simply
that Microsoft moved all the device driver code into the kernel space [out of
the user space where Digital Equipment's Architects had placed it back in the
days of Windows NT 3.1]. They did it for performance reasons - exactly the same
as those quoted by Andrew Morton in his response as published by PJ.

I've been able to quote just two examples here because I'm not sufficiently
familiar with the latest MS design practices. However, these are relevant and
valid comparisons in as much as what we witness here is best described as a case
of "the pot calling the kettle black" - ie supporters or sectors of
the Old World Coding Model [proprietary software] trying to scare up some FUD
relating to the FOSS Community.

I loved Andrew Morton's comment about how the proprietary world would love to
have the Development resources available to FOSS - but it's more even than
that.

Think about it.

If you were running Windows and a piece of software crashed on you, all you
would get would be some crummy error message and a hex reference [or the typical
BSoD]. With luck, that might be useful to the vendor. If you were running linux,
the chances are that a crash handler will kick in [well, OK, if you are using
GUIs like KDE] and capture the details of the fault. But more than that. You can
go and look at the code. You can contact the developers directly. You can
[abilities notwithstanding] perform sufficient analysis yourself to narrow down
and help eliminate the glitch.

There's an old saying, something to the effect of "The true measure of a
cake is in the eating..." which says in effect, that with many things, it's
the end result that counts. So how do we measure end results in this case? Here
are some possible ways :-

1. # bugs per 1,000 lines of code reported for kernel + GUI [ie equivalent of
Windows]. Most stats I've seen indicate GNU/Linux is streets ahead. [It's worth
mentioning here that much of this is due to RMS and the work of the FSF and the
GNU guys. Their utilities and wrappers are seriously solid code!]

2. # active developers working in improvement/maintenance. Not exactly a fair
comparison, because this does not lead directly to better code - only better
programmers can do that. However, even if you only included the very best 1% of
Linux software maintainers, you'd be talking about more than Microsoft's entire
employee base, for example...

3. # of active beta/GA testers. No contest. The appetite for testing FOSS Code
on the web is voracious. Nothing comes close to SourceForge, and that is just
one of several very large developer communities on the web.

4. Personal experience. The essence of the article seems to suggest that, in
coding terms, writing coupled code is a "silly thing". Therefore it
suggests that Linux is not good because, under the covers, it does "silly
things". Well, there might be some merit in the "silly thing"
argument.

But...

With carefully version-numbered shared object libraries, and the inherent
ability to install multiple different versions of the same package on the same
host, does Linux suffer from "DLL Hell?" No.

With a selection of truly excellent browsers, does Linux embedd browser
technology in it's kernel to out-code legal rulings and stick up 2 fingers at
the US legal system and thus break all sorts of software design practices in the
process? No.

With an open and meritocratic development model, does Linux jealously guard it's
code base, thus preventing talented developers from contributing improvements
from the benefit of all [or, for that matter, allow a company to hire crap
programmers and push out sub-standard code]? No.

Are vulnerabilities within the kernel frantically hushed-up for weeks or months
on end, with users left hanging in the hope that someone at Microsoft might get
around to fixing the bug one day soon? No. [Typically reported Linux
vulnerabilities are fixed in a matter of hours, a day or 2 at most. I don't know
of any closed-source vendor that can claim to match that record so
consistently].


Let's be clear. Linux is by no means a perfect or flawless OS. It doesn't
pretend to be. What it does claim, however, is to be open, transparent and
honest about the way that it works, is developed and maintained. It also claims
to give everyone who is able and willing an equal chance to contribute and
improvement or request. The development and maintenance systems are ruthlessly
meritocratic in their operation - and that advances and enhances the code in a
manner that's far better than any company I've ever seen.

To repeat an earlier theme. It's the results that count. 'nuff said.

[ Reply to This | # ]

Bumblebees and helicopters
Authored by: AJWM on Thursday, March 31 2005 @ 05:07 PM EST
As the linked article points out, that myth got started because of a quick back-of-the-envelope calculation that treated bumblebees as fixed-wing aircraft. If you analyze a helicopter the same way, helicopters can't fly either.

What the calculations really mean is that a bumblebee can't glide. Which it can't. Stop the beating wing of a bumblebee, or the rotating wing of a helicopter, and both drop like rocks.

[ Reply to This | # ]

More interested in improved kernel performance metrics
Authored by: Anonymous on Thursday, March 31 2005 @ 08:51 PM EST

The article of a few days ago and the LKML only seems to mention database
metrics. There are many other metrics that are of importance other than
database (predominately I/O) based metrics.

The article essentially said that the 2.6.x kernel was up to 25% slower than
2.4. This is where real work needs to be done.

As far as coupling, I am sure that the kernel developers will find a way to
"route around" any problems.

[ Reply to This | # ]

Steering Analogy
Authored by: mrcreosote on Thursday, March 31 2005 @ 09:25 PM EST
Perhaps a better analogy would be 'fly-by-wire' as implemeneted in most modern
military and large passenger aircraft. Early aircraft used cables to directly
actuate the control surfaces. This gave way to hydraulics, but the hydraulic
systems were still actuated by direct input from the control column. However,
nowadays, the control column simply feeds input to a computer, which then
translates this into the most appropriate output to move the control surfaces.
The main reason this is done in modern military aircraft is they are designed to
be inherently unstable (for manouvreability) and consequently cannot be flown
'manually' by a human pilot. In commercial aircraft, fly-by-wire allows for the
system overriding certain inputs from the controls that would put the aircraft
into danger.

The F-16 was one of the first fly-by-wire fighters, which allowed the joystick
to be relocated to the pilot's right hand side, and also allowed the pilot's
seat to be reclined about 30 degrees, the better to withstand increased
g-forces.

Large ships are also now 'steer-by-wire' with the wheel a replica of a
traditional wheel, but about 5-10cm in diameter.

---
----------
mrcreosote

[ Reply to This | # ]

  • Steering Analogy - Authored by: Anonymous on Friday, April 01 2005 @ 05:18 AM EST
Scalability and comparisons (very geekish)
Authored by: elderlycynic on Friday, April 01 2005 @ 04:19 AM EST
Andrew Morton and Dr Stupid are mistaken in one respect;
there is no need to have a single cycle counter or timer,
and it is a major obstacle to scalability. SGI and Sun
know that sort of thing very well because they have had to
strip many such things out of their kernels. I know a fair
amount about time synchronisation, but it is REALLY not
appropriate for Groklaw.

Suffice it to say that I don't think that Linux is much
more coupled than most other operating systems, based on my
fairly wide-ranging and in-depth experience. Yes, this is
a major problem and, no, Linux does not have it under
control. But I can witness that few other vendors (if any)
have it under control, either. Microsoft certainly doesn't.

[ Reply to This | # ]

Relativistic Linux
Authored by: Anonymous on Saturday, April 02 2005 @ 11:49 PM EST
Mr. Morton says "jiffies: This is a variable which counts clock ticks. Of
course it's global. Unless they know of a universe in which time advances at
more than one speed at a time."

I believe that Dr. Einstein demonstrated quite decisively that our universe is
exactly such a place.

Doesn't general relativity say that time within black holes moves more slowly
than it does in free space. And doesn't special relativity state that time flows
more slowly for objects zipping along near the speed of light?

Obviously, this bodes ill for Linux. I seriously doubt its viability will extend
much past the heat-death of the universe. (Unless sufficient dark matter exists
for the "big crunch" scenario, and I don't think Linux will be viable
much beyond that, either.)

I WISH TODAY WASN'T THE 2ND OF APRIL!

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )