Linux's approaching Achilles' heal - Debian

This is a discussion on Linux's approaching Achilles' heal - Debian ; 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: Linux's approaching Achilles' heal

  1. Re: Linux's approaching Achilles' heal

    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


  2. Re: Linux's approaching Achilles' heal

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


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

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

  3. Re: Linux's approaching Achilles' heal

    On Nov 19, 3:34 pm, Evenbit wrote:
    > On Nov 18, 12:46 am, Keith Kanios wrote:
    >
    >
    >
    > > Ah... theory. Leaves a nice warm feeling, doesn't it?

    >
    > ... and leads to my trade-mark trait of "going off half-****ed!"


    There's nothing to prove around here, only knowledge to gain and
    eventually give back.

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


    There you go

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2