Linux's approaching Achilles' heel
This thread belongs to

2007-11-16 12:15 GMT   |   #1
Like a run-away freighttrain, the Open Source Community's "standard
practice" (_faux peer review_ plus shoddy coding standards and casual
dismissal of bug reports pointing out critical flaws
) is exactly the mind-set that will bring Linux tumbling down the hill
into the valley of the forgotten, non-important OSs that "could have

It is easy to understand that, given the pressure to maintain a
'presence' in the month headlines and the desire to outperform the
competition in the number of 'features', some amount of short-cuts
will be taken and code audits being skipped so that the next 'distro
release' can announce a new fancy gizmo under its wing. *Some* degree
of this behavior is to be expected in an environment where any "Joe
Six-pack" can start a project and have his code used by and
encorporated into other software down the stream. However, I am quite
shocked that the practice is tolerated to the point that it leads to
extremely unstable critical support systems as detailed in the
following forum threads.

2007-11-16 12:57 GMT   |   #2
I wouldn't call audio a *critical* system. If you read the response to
the half-witted comment, you will see why such non-critical systems
would be sacrificed in favor of more critical systems. If you are in a
out-of-memory situation, you will be across the board. In those
situations, you do the very same thing the human body does...
sacrifice appendages first and keep warm blood pumping to the vital
organs above all else.

A better solution to such a problem would be in fronting an effort/
campaign to reduce the amount of bloat and unnecessary memory usage.
2007-11-16 13:34 GMT   |   #3
Oh come-on, Keith, you know better than to use the same pithy staw-man
that the PulseAudio retard used. We are talking about application
layers that deal primarily with multi-media data... this means the
'desired memory allotment' may run into the tens to the hundreds of
Gigs... so "across the board" is an extremely weak claim since it is
very unlikely for an other application requirement (and this goes for
the other apps currently running) to be anywhere near this size.

Reducing the amount of bloat and unnecessary memory usage
can only be successful if it were "drilled into their heads" at
the start of the Freshman programming course and consistantly
continued throughout the CompSci regimen.

2007-11-16 14:00 GMT   |   #4
I don't see how "straw man" applies here. I am simply commenting from
the appreciation of being a system-level programmer.

If one process is hogging all of the physical and swap memory, other
processes are being deprived of that memory. Ask Windows users how
appreciative it would be to lose one application's worth the data
instead of losing all of your data due to the entire system becoming

If the problem is actually with running out of process (virtual)
memory, then I can think of more graceful ways to handle such out-of-
memory situations.

.... instead of Java, C# and garbage collection wiping incompetent
asses? It would be appreciated, but highly unrealistic when software
is market driven. Quality is no longer a factor, it is just reduced
down to time and price.
2007-11-16 14:06 GMT   |   #5
Well, my friend Dan, I really do wish your assumption were correct.
It would be extremely nice (and helpful) if an application would
report an "error condition" before terminating. It would also, by
extension, be extremely nice (and helpful) if a support library would
report said error to the calling application so that the application
developer might have the opportunity to respond in a graceful manner
to environmental conditions. Non-returning function calls certainly
are a bane during debugging sessions.

I am also thinking of the Windows users who are new to Linux. When
programs like Firefox consistantly and suddenly "disappears" on them
(the way it does for me) without reporting the "why", they are going
to migrate back to their Microsoft products. At the very least, they
get the dreaded "Blue Screen of Death" which is a tonne more useful
information than something which terminates your application at will.
Now do you see the danger of PulseAudio and other shoddy libraries???

2007-11-16 21:24 GMT   |   #6
Ah, my friend Nathan, I'm afraid it is you that is the idiot.
I assume these malloc wrappers print a message and then abort.
Do you have any idea what else they can do?

Do you really think a program can carry on and do anything reasonable
when it runs out of memory?

Don't you think it might require something for the program to continue
on? Like maybe memory?

Never the less, most of the software I write is middleware and
it does try to return error indications to the caller on out
of memory. I sometimes see dumps produced by
programs using my middleware as they try to report back to the user
that something went wrong.

If you think you are so smart, find out what the real power of open
source is. Find a better way and submit a patch.

But lose the arrogant attitude.
2007-11-16 21:51 GMT   |   #7
Although I strongly believe there are reasons to support the claim that
Linux is or will be "tumbling down the hill into the valley of the
forgotten, non-important OSs that 'could have been'," I don't believe the
issue is the mindset of Linux coders, their standards, their failure to fix
bugs, or even other issues such as reversion of prior bug fixes or
filesystem problems...

The real primary issue is money. Can Linux survive long term against a
company with billions in financial and physical capital, licensed and
proprietary software patents, driven programmers who are _paid_ to program
for a living, and an endless supply of software drivers written for their
OS's API by hardware manufacturers. Secondary issues include software
development time for new PC hardware or circuitry and the far above average
intellect of "their" large paid programmer base versus the average IQ,
skill, and time constraints of many unpaid "Joe Six-pack" 's. I see Linux
running into a wall due to the rapid continuous changes and advances in PC
circuitry unless a huge infusion of cash is found. A for profit Linux OS
corporation needs to be formed. Getting Apple to dump OS X for paid copies
of Linux would be a good start. If Linux can't compete with OS X for
profit, I really don't see a long term PC future. Perhaps one might as well
dump Linux now and embrace OS X...

Personally, I also think some long term design changes are needed. I'd
recommend a adopting a syscall only based version of Linux as it's primary
form, like UML. If only a syscall interface had to be written to bootstrap
Linux, cross-compiling to other platforms would be faster and easier.
Unfortunately, even with a UML version available, Linux's syscall interface
has bloated from 40 implemented functions in v0.01 to 290 in v2.16.17. The
number of syscalls needs to be drastically reduced or the syscall interface
needs to be built entirely on a small set of functions. I'd also recommend
using some other highly popular interface that allows development of almost
OS applications, say the SDL library, instead of the current syscall
interface. If SDL, this would allow numerous OS-like applications such as
DOSBox, Scummvm, etc. to run as the "higher level" OS. Writing the low
level OS portions are a pain. Nobody really wants to do that. It's already
been done fairly well for Linux. Much of the low level parts of Linux have
been extracted from Linux for the LinuxBIOS' FILO project anyway. Allowing
different top-ends to the OS would encourage much more upper level OS
development and adaptation. This adaptability might be a good long term
advantage against a corporate competitor that has become stagnant.

2007-11-16 22:17 GMT   |   #8
Evenbit seem to have missed the point.
When an application is out of memory, almost anything you try to do to
report an error is going to fail.

It takes memory to invoke a function.

Firefox disappearing, likely has nothing to do with his issue.

Install the Firefox bug reporting tool and a Firefox failure will
invoke a dialog that sends a bug report back to the developers.

I don't see any danger about PulseAudio.
It's an audio application.
It will stop and I'll look for the problem.
2007-11-16 23:35 GMT   |   #9
Audio is certainly a critical system for those users who are not
blessed with the normal human attribute of being 'sighted'. Blind
people do not depend on either screen graphics or text from a video
monitor -- they are able to use a PC solely via the audio feedback.
Why should library developers be granted exclusive permission to
determine which systems are *critical* and which are not? Shouldn't
these decision be left for the application programmer to decide?

2007-11-17 00:02 GMT   |   #10
It is obvious that if you are indeed a "system-level programmer" who
is worth his salt, then you would have _some_ understanding about
modern memory management issues (it is clear from your responses that
you do not). When we issue a call to an OS asking for a chunck of
memory, the OS responds by looking for an area of _contiguous_ free
memory space of the size that we request. So, you see, it is
perfectly possible that an attempt to allocate 50Gigs will fail, while
subsequent calls to the same OS function asking for 10 instances of
10Gigs each will succeed.

Wouldn't the better choice be to not lose ANY data??? Why do Linux
developers consistantly shoot for standards that are _below_ that of
Windows developers? Why should end-users tolerate a less-stable
experience -- especially when Linux-fans consistantly "bill" Linux as
the better(TM) product??

"If the problem is actually with running out of process (virtual)
memory, then I can think of more graceful ways to handle such out-of-
memory situations.

This is indeed the issue at hand -- being "more graceful" than killing
the calling application and preventing any error reports from being

"... instead of Java, C# and garbage collection wiping incompetent
asses? It would be appreciated, but highly unrealistic when software
is market driven. Quality is no longer a factor, it is just reduced
down to time and price.

This is the very mind-set and attitude which will get Linux labelled a
"has been" in the OS history books.


1 2nextlast