«

CBFalconer said:

> Barry Schwarz wrote:

<snip>

>>
>> The fact that a particular call to malloc fails does not mean the
>> application is out of memory. It only means that the requested
>> amount of contiguous memory is not available.
>
> In addition, malloc and friends have no idea what earlier
> assignments are being used for. There is no reason the program
> cannot react to the error by releasing stored items until this
> malloc actually succeeds. As long as success can be thus attained,
> there is no reason for the program to fail.

Unless of course some brain-damaged library designer has arranged that
malloc never, ever returns NULL, so that even properly-written
applications can't tell whether a request succeeded or not. If ever there
was a decision that favoured the mediocre over the competent, that's the
one.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In alt.lang.asm ray <> wrote in part:
> On Fri, 16 Nov 2007 18:15:41 -0800, nbaker2328 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 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.
>
> The main problem with your argument being, of course, that Vista
> which was delayed several times and had features thrown out so that
> it could finally come to market, seems to have even more problems.

This is a valid high-level argument: success is much more than
avoiding failure. Even glaring failures can be immaterial.

However, I am reading in ALA where details are very relevant so
I feel compelled to offer some of the many:


1) A Linux distro is _not_ the kernel. distros come and go,
the kernel is eternal

2) Much greater code review has been done for OpenBSD. It has
not lead to run-away success outside of its' domain.

3) Using a desktop/user distro for a "critical support system"
is unlikely to be successful except for "non-traditional"
definitions of "critical"

4) audio might be one of those defininitions

5) not understanding VM_overcommit and the OOM killer certainly
is "non-traditional" wrt "critical".

6) If Nathan or J-G dislike certainly library coding, they are
completely free to change it, forking the project. This is one
of the great strengths of the GPL and Linux. Whining is very
poor form and a waste of effort. Projects propagate based on
user judgement. Not critics and whiners.


-- Robert

Rod Pemberton wrote:
> "Dan Espen" <> wrote in message
> news:...
>> writes:
>>
>
> Sigh, had to go to Google to read the other six posts that didn't propagate
> well...
>
>>> 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".
>>>
>
> 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.

This has been the situation for the last twenty years. Linux and GNU
were born into and grew up in exactly this environment. If they die now,
it won't be for this reason.

Microsoft certainly has good people working for it. But they are very
closely constrained by the requirement to keep re-selling what is
broadly the same software, and even more so by the importance of
maintaining the near-monopoly. What innovation does occur is almost
entirely aimed at keeping and improving the incompatibility between
Windows and the rest of the IT world, and to some extent even with
earlier Microsoft software. GNU-Linux has no need or use for planned
obsolescence.

One particularly crippling constraint is that much-loved marketing word
'integration'. This means linking together relatively unrelated programs
so tightly that connection with non-Microsoft software is difficult or
impossible. This is the exact opposite of what is probably the single
strongest programming imperative, to isolate sub-programs as much as
possible and to use only well-defined interfaces between them.

A simple example: the Windows Small Business Server contains a POP3
downloader which drops mail straight into Exchange mailboxes, because it
can, and because the suits can then use the 'i' word. The competitive
POP3 download products all deliver to localhost:25 by SMTP, keeping the
interface clean and simple. The result is that the competitors can
utilise a number of Exchange features which the built-in POP3 connector
bypasses. While Microsoft is not a company to be underestimated, it
should not be overestimated either.

On Sun, 18 Nov 2007 10:11:12 +1000, Fredderic
<my-name-> wrote:

>On Sat, 17 Nov 2007 06:02:02 -0800 (PST),
>Evenbit <> wrote:
>
>> On Nov 16, 11:00 pm, Keith Kanios <ke...@kanios.net> wrote:
>> <<snipped>>
>>> I don't see how "straw man" applies here. I am simply commenting
>>> from the appreciation of being a system-level programmer.
>> 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.
>
>That's odd... I was under the impression we had this thing called
>paging, on modern operating systems. This has two effects; one,
>applications are actually allocated memory in complete pages, and
>secondly, those pages can reside anywhere in physical ram, and they'll
>still appear contiguous to the application.

It is true that a contiguous block of virtual memory need not be
located in a contiguous block of real memory. It is also irrelevant
to the point being made.

Once a virtual address has been allocated it cannot be reused until
it is freed. If multiple allocation requests for 65K blocks have
returned virtual addresses of 0x10000, 0x20000, and 0x30000 and I free
the middle one, a request for 130K will not fit at 0x20000. But a
request for 10K will. Virtual memory is subject to the same
fragmentation problems as real memory.

>
>The only time this might be an issue, is with DMA, where a component
>external to the processor (and hence without the benefit of the kernels
>page tables) needs to access data across two or more pages.

The real memory address are not the issue.

>
>Mind you, I'm not a systems level programmer either...
>
>
>>> 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.
>> 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??
>
>You, mate, are an ass. Every time I have run out of memory on a
>Windoze system, the entire system crashed. My wife who still uses

Before, you were merely technically incorrect. Now you are no longer
worth reading.

<snip>


Remove del for email

Barry Schwarz wrote:
>
> On Sun, 18 Nov 2007 10:11:12 +1000, Fredderic
> <my-name-> wrote:
>
> >On Sat, 17 Nov 2007 06:02:02 -0800 (PST),
> >Evenbit <> wrote:
> >
> >> On Nov 16, 11:00 pm, Keith Kanios <ke...@kanios.net> wrote:
> >> <<snipped>>
> >>> I don't see how "straw man" applies here. I am simply commenting
> >>> from the appreciation of being a system-level programmer.
> >> 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.
> >
> >That's odd... I was under the impression we had this thing called
> >paging, on modern operating systems. This has two effects; one,
> >applications are actually allocated memory in complete pages, and
> >secondly, those pages can reside anywhere in physical ram,
> >and they'll
> >still appear contiguous to the application.
>
> It is true that a contiguous block of virtual memory need not be
> located in a contiguous block of real memory. It is also irrelevant
> to the point being made.

It's completely irrelevant to the point being made.

--
pete

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


FUD... FUD... Go away... Come again... Some other day.

If it smells like a troll, looks like a troll and writes like a troll...

IT MUST BE A TROLL.








--

Jerry McBride ()

On Sun, 18 Nov 2007 15:56:34 +0000, Robert Redelmeier wrote:

> In alt.lang.asm ray <> wrote in part:
>> On Fri, 16 Nov 2007 18:15:41 -0800, nbaker2328 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 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.
>>
>> The main problem with your argument being, of course, that Vista
>> which was delayed several times and had features thrown out so that
>> it could finally come to market, seems to have even more problems.
>
> This is a valid high-level argument: success is much more than
> avoiding failure. Even glaring failures can be immaterial.
>
> However, I am reading in ALA where details are very relevant so
> I feel compelled to offer some of the many:
>
>
> 1) A Linux distro is _not_ the kernel. distros come and go,
> the kernel is eternal
>
> 2) Much greater code review has been done for OpenBSD. It has
> not lead to run-away success outside of its' domain.
>
> 3) Using a desktop/user distro for a "critical support system"
> is unlikely to be successful except for "non-traditional"
> definitions of "critical"

Would a real time monitoring system in a major DOD test and evaluation
environment qualify? I think so. And the ones I was familiar with before I
retired three years ago relied on Unix and Linux.


>
> 4) audio might be one of those defininitions
>
> 5) not understanding VM_overcommit and the OOM killer certainly
> is "non-traditional" wrt "critical".
>
> 6) If Nathan or J-G dislike certainly library coding, they are
> completely free to change it, forking the project. This is one
> of the great strengths of the GPL and Linux. Whining is very
> poor form and a waste of effort. Projects propagate based on
> user judgement. Not critics and whiners.
>
>
> -- Robert

In alt.lang.asm ray <> wrote in part:
> On Sun, 18 Nov 2007 15:56:34 +0000, Robert Redelmeier wrote:
>> 3) Using a desktop/user distro for a "critical support system"
>> is unlikely to be successful except for "non-traditional"
>> definitions of "critical"
>
> Would a real time monitoring system in a major DOD test and evaluation
> environment qualify? I think so. And the ones I was familiar with
> before I retired three years ago relied on Unix and Linux.

Certainly it would qualify as "critical". And I don't doubt
Unix and other Linux-like systems could pass.

All I'm trying to say is that I doubt an out-of-the-box,
install everything _user_ distro like Ubuntu would pass. Just
think of all the kernel modules. Redhat, Debian, Slackware or
even a correctly stripped Ubuntu would be necessary, preferably
with a kernel customized for the hardware. No X-server, XDM or
other eye candy will necessarily be reliable on all hardware.

-- Robert

On Nov 18, 12:46 am, Keith Kanios <ke...@kanios.net> wrote:
>
> Ah... theory. Leaves a nice warm feeling, doesn't it?

.... and leads to my trade-mark trait of "going off half-cocked!"

>
> Three potential solutions to fix your unsound comments.
>
> 1) Re-read those books.
> 2) Get more modern/informative books.
> 3) Try a little practical implementation so you can see why it is so
> foolish to back such inconsistent theories or potential
> misunderstandings.

Luckily, just re-reading them was enough to convince me of my error.
My confusion was due to putting too much emphasis on the fact that
blocks always contain pages that are assigned to contiguous regions of
a process' address space. It is true that it is possible to fragment
(make a mess of) the process' address space, but this should only
happen due to extremely bad code or via intentional effort on the part
of the programmer. Even then, I suspect that any "fragmentation wall"
is purely theoretical because your process would be stopped long
before it could be hit.

Also, if you write an application that is extremely memory-hungry, you
need to scrap everything and go back to the flow-charts for an
entirely different design.

Nathan.

"Richard Heathfield" <> wrote in message
>
>> Barry Schwarz wrote:
>
> <snip>
>
>>>
>>> The fact that a particular call to malloc fails does not mean the
>>> application is out of memory. It only means that the requested
>>> amount of contiguous memory is not available.
>>
>> In addition, malloc and friends have no idea what earlier
>> assignments are being used for. There is no reason the program
>> cannot react to the error by releasing stored items until this
>> malloc actually succeeds. As long as success can be thus attained,
>> there is no reason for the program to fail.
>
> Unless of course some brain-damaged library designer has arranged that
> malloc never, ever returns NULL, so that even properly-written
> applications can't tell whether a request succeeded or not. If ever there
> was a decision that favoured the mediocre over the competent, that's the
> one.
>
That's me.
Check out xmalloc(), a malloc that never returnsNULL, on my website.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm