Prev: How to backup a PC with multiple OSs
Next: Linux long term survivability, was Re: Linux's approaching Achilles' heal
From: nbaker2328 on 16 Nov 2007 21:15
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 http://pulseaudio.org/ticket/158
) 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
been".

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.

http://ubuntuforums.org/showthread.php?t=612606
http://ubuntuforums.org/showthread.php?t=614962

Nathan.
From: Keith Kanios on 16 Nov 2007 21:57
On Nov 16, 8:15 pm, nbaker2...(a)charter.net wrote:
> 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 flawshttp://pulseaudio.org/ticket/158
> ) 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
> been".
>
> 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.
>
> http://ubuntuforums.org/showthread.php?t=612606http://ubuntuforums.org/showthread.php?t=614962
>
> Nathan.

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.
From: Dan Espen on 16 Nov 2007 22:24
nbaker2328(a)charter.net writes:

> 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 http://pulseaudio.org/ticket/158
> ) 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
> been".
>
> 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.
>
> http://ubuntuforums.org/showthread.php?t=612606
> http://ubuntuforums.org/showthread.php?t=614962
>
> Nathan.

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.
From: Evenbit on 16 Nov 2007 22:34
On Nov 16, 9:57 pm, Keith Kanios <ke...(a)kanios.net> wrote:
> On Nov 16, 8:15 pm, nbaker2...(a)charter.net wrote:
>
>
>
> > 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 flawshttp://pulseaudio.org/ticket/158
> > ) 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
> > been".
>
> > 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.
>
> >http://ubuntuforums.org/showthread.php?t=612606http://ubuntuforums.or...
>
> > Nathan.
>
> 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.

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.

>
> A better solution to such a problem would be in fronting an effort/
> campaign to reduce the amount of bloat and unnecessary memory usage.

This 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.

Nathan.
From: Keith Kanios on 16 Nov 2007 23:00
On Nov 16, 9:34 pm, Evenbit <nbaker2...(a)charter.net> wrote:
> On Nov 16, 9:57 pm, Keith Kanios <ke...(a)kanios.net> wrote:
>
>
>
> > On Nov 16, 8:15 pm, nbaker2...(a)charter.net wrote:
>
> > > 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 flawshttp://pulseaudio.org/ticket/158
> > > ) 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
> > > been".
>
> > > 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.
>
> > >http://ubuntuforums.org/showthread.php?t=612606http://ubuntuforums.or...
>
> > > Nathan.
>
> > 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.
>
> 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.
>

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
unresponsive.

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.

>
> > A better solution to such a problem would be in fronting an effort/
> > campaign to reduce the amount of bloat and unnecessary memory usage.
>
> This 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.
>
> Nathan.

.... 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.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: How to backup a PC with multiple OSs
Next: Linux long term survivability, was Re: Linux's approaching Achilles' heal