Dynamic linking with LD_PRELOAD - get it compiled - Linux

This is a discussion on Dynamic linking with LD_PRELOAD - get it compiled - Linux ; On Mar 12, 1:26 pm, Johannes Bauer wrote: > > The best place to stop this chain is at the very first link. You > > should need a damn good reason to do it wrong, not a good reason ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 62

Thread: Dynamic linking with LD_PRELOAD - get it compiled

  1. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 12, 1:26 pm, Johannes Bauer wrote:

    > > The best place to stop this chain is at the very first link. You
    > > should need a damn good reason to do it wrong, not a good reason to do
    > > it right.


    > So essentialy what you're saying is that I should respond with "My code
    > is poorly written, I'm not giving it out" rather then "My code is poorly
    > written, do whatever you want with it" (as I did)?


    No, please read what I wrote again. What I'm saying is that it was no
    easier to write your code poorly, and your justification (that nobody
    else would ever use the code with different libraries) turned out to
    be bogus.

    > I think when it is explicitly stated that the code is of poor quality,
    > full of ridiculous hacks and induces undefined behavior as of the
    > C-standard - what else would anyone expect who tried to use it other
    > than the code breaking? And why do you blame me for this?


    Because you chose to write code of poor quality and full of ridiculous
    hacks, and you did so knowing that this was exactly what you were
    doing.

    > Actually I do not think anyone seriously wants to use the code - maybe
    > take a peek, that's it. With the discussion here, all warnings are
    > pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
    > guess he knows what he's doing).


    I hope not. But there's a lesson here -- code has a way of outliving
    its expected life and decisions to do things in a dirty way have a way
    of coming back and biting someone. So don't do that unless you have a
    really good reason and always be suspicious when you find yourself
    thinking "nobody else will ever use this for anything else".

    Tell me, did you wrap your code with appropriate 'ifdef's and
    '#warning's? How much longer would that have taken?

    DS

  2. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz schrieb:
    > On Mar 12, 1:26 pm, Johannes Bauer wrote:
    >
    >>> The best place to stop this chain is at the very first link. You
    >>> should need a damn good reason to do it wrong, not a good reason to do
    >>> it right.

    >
    >> So essentialy what you're saying is that I should respond with "My code
    >> is poorly written, I'm not giving it out" rather then "My code is poorly
    >> written, do whatever you want with it" (as I did)?

    >
    > No, please read what I wrote again. What I'm saying is that it was no
    > easier to write your code poorly, and your justification (that nobody
    > else would ever use the code with different libraries) turned out to
    > be bogus.


    You make me sound like a liar, which I find kind of unfair. I did, in
    fact, not know that anyone would have any interest in the code. My
    assumtions turned out to be incorrect - but it's not like I knew that in
    advance.

    >> I think when it is explicitly stated that the code is of poor quality,
    >> full of ridiculous hacks and induces undefined behavior as of the
    >> C-standard - what else would anyone expect who tried to use it other
    >> than the code breaking? And why do you blame me for this?

    >
    > Because you chose to write code of poor quality and full of ridiculous
    > hacks, and you did so knowing that this was exactly what you were
    > doing.


    Yes, because it saved me an - warning, wild guess here - appriximate
    300-500 lines of code in the generator which it would have taken if I
    wanted to support all kinds of (pointer) types. It was a lot easier that
    way.

    >> Actually I do not think anyone seriously wants to use the code - maybe
    >> take a peek, that's it. With the discussion here, all warnings are
    >> pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
    >> guess he knows what he's doing).

    >
    > I hope not. But there's a lesson here -- code has a way of outliving
    > its expected life and decisions to do things in a dirty way have a way
    > of coming back and biting someone. So don't do that unless you have a
    > really good reason and always be suspicious when you find yourself
    > thinking "nobody else will ever use this for anything else".


    And they should come back and bite everyone who uses them! They
    absolutely should. Because the one thing we both seem to agree on is
    that the generated code is crap. Whoever uses crap gets UB. Period.

    > Tell me, did you wrap your code with appropriate 'ifdef's and
    > '#warning's? How much longer would that have taken?


    It actually emits a warning for each generated #define which replaces a
    prototype. Do you want me to send you the source? ;-)

    Regards,
    Johannes

    --
    "PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  3. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 12, 3:13 pm, Johannes Bauer wrote:

    > > No, please read what I wrote again. What I'm saying is that it was no
    > > easier to write your code poorly, and your justification (that nobody
    > > else would ever use the code with different libraries) turned out to
    > > be bogus.


    > You make me sound like a liar, which I find kind of unfair. I did, in
    > fact, not know that anyone would have any interest in the code. My
    > assumtions turned out to be incorrect - but it's not like I knew that in
    > advance.


    Right, just like the people who wrote code with Y2K bugs didn't know
    in advance that their code would still be in use 30 years later. Every
    link in the chain has a justification, but the end result is disaster.
    So you have to stop the chain at the first link.

    > > Tell me, did you wrap your code with appropriate 'ifdef's and
    > > '#warning's? How much longer would that have taken?


    > It actually emits a warning for each generated #define which replaces a
    > prototype. Do you want me to send you the source? ;-)


    No, let's stop it from spreading any further.

    The point is not the particular thing you did in this particular case.
    The point is that any time you find yourself thinking "this code will
    never be used for anything other than precisely what I'm using it for
    now", you're as likely to be wrong as right. And the next person will
    find it "happens to work for me" and so on and so on.

    At least try to document your assumptions when and where you make
    them. Try to use appropriate 'ifdef's and '#warning's and whatever
    else it takes.

    DS

  4. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Wed, 12 Mar 2008 15:53:41 +0100 Johannes Bauer wrote:
    | phil-news-nospam@ipal.net schrieb:
    |
    |> OK, so that works. It's a hack. What I'm curious about is why you could
    |> not just define select to match the library declaration? Are you trying
    |> to make this an intercept function that just passes on the arguments AND
    |> can work no matter which way the function is declared/defined by libc?
    |
    | Exactly. It's a code generator which just passes on pointers in the
    | gerneated code. It links together with user code which has knowledge
    | about the pointers (so it casts appropriately).
    |
    | I've not thought about licensing the code itself, but if you want to see
    | it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
    | generates C code (that builds a shared lib which can be used to
    | LD_PRELOAD and reverse engineer certain other libraries/programs). Is
    | your mail valid? I'd send it to you then.

    I'd rather you not email any code. If you want to make it public, put it
    online somewhere and tell us where. If you don't, I'd rather not have it.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-12-2022@ipal.net |
    |------------------------------------/-------------------------------------|

  5. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Wed, 12 Mar 2008 12:18:28 -0700 (PDT) David Schwartz wrote:
    | On Mar 12, 12:06 pm, Johannes Bauer wrote:
    |
    |> Nope, you're wrong. I never ever intended to give the app away in the
    |> first place - if someone asks, however, that's fine with me.
    |
    | You never intended to, but code has a way of being used outside the
    | designer's intentions.

    Lots of code gets used way beyond the intentions. Look at XML for example.
    It was intended as a _document_ format. It's being used to store config
    data and other non-document things. People are doing that because it has
    parsers already built, ready to use. They don't want to write parsers for
    what might otherwise be a more optimal format for what they are doing.

    Just because code has a _narrow_ use doesn't mean someone else won't find
    a reasonable use for it ... or merely be inspired by it.


    | The first thought is, "it's only ever going to be used on this
    | platform with this compiler, so there's no reason to make it
    | portable". The next thought is, "hey, maybe it works on this other
    | platform". Then, "hey, it seems to work, so let's use it". The next
    | thing you know, it breaks.

    And you want to protect people that are so stupid that they mis-port code,
    by saying no one else should benefit by this narrow purpose code?


    | The best place to stop this chain is at the very first link. You
    | should need a damn good reason to do it wrong, not a good reason to do
    | it right.

    OTOH, maybe someone will look at that code, say "I can do better", and
    write it all over from scratch to do the same thing, only better. I seem
    to remember some Swedish speaking Finnish college student having that
    attitude many years ago.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-12-2023@ipal.net |
    |------------------------------------/-------------------------------------|

  6. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Wed, 12 Mar 2008 15:45:48 -0700 (PDT) David Schwartz wrote:
    | On Mar 12, 3:13 pm, Johannes Bauer wrote:
    |
    |> > No, please read what I wrote again. What I'm saying is that it was no
    |> > easier to write your code poorly, and your justification (that nobody
    |> > else would ever use the code with different libraries) turned out to
    |> > be bogus.
    |
    |> You make me sound like a liar, which I find kind of unfair. I did, in
    |> fact, not know that anyone would have any interest in the code. My
    |> assumtions turned out to be incorrect - but it's not like I knew that in
    |> advance.
    |
    | Right, just like the people who wrote code with Y2K bugs didn't know
    | in advance that their code would still be in use 30 years later. Every
    | link in the chain has a justification, but the end result is disaster.
    | So you have to stop the chain at the first link.

    Ironically, over 90% of the code that failed Y2K where I was consulting
    at the time specifically to rapidly deal with Y2K issues, had been written
    within the prior 3 years.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-12-2031@ipal.net |
    |------------------------------------/-------------------------------------|

  7. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:

    > | The best place to stop this chain is at the very first link. You
    > | should need a damn good reason to do it wrong, not a good reason to do
    > | it right.


    > OTOH, maybe someone will look at that code, say "I can do better", and
    > write it all over from scratch to do the same thing, only better. I seem
    > to remember some Swedish speaking Finnish college student having that
    > attitude many years ago.


    You can almost always do it better from scratch if you get to start
    out learning what goes wrong and what goes right when you try to do it
    the way you thought was best. On the flip side, if you try to do it a
    way that you know is wrong, you learn very little when it doesn't work
    the way people hope.

    A good programming adage is "do it once and throw it away". The second
    time, you will be able to design it knowing the real strengths and
    weaknesses of your first design.

    The best code I've ever written has been at least the third of fourth
    time I've tried to do something. Sometimes the re-writes are in-place,
    sometimes they're total. It depends how wrong I got it the N-1th time.

    But none of that will happen if you start out knowingly doing it
    wrong.

    DS

  8. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz writes:
    > On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
    >> | The best place to stop this chain is at the very first link. You
    >> | should need a damn good reason to do it wrong, not a good reason to do
    >> | it right.

    >
    >> OTOH, maybe someone will look at that code, say "I can do better", and
    >> write it all over from scratch to do the same thing, only better. I seem
    >> to remember some Swedish speaking Finnish college student having that
    >> attitude many years ago.

    >
    > You can almost always do it better from scratch if you get to start
    > out learning what goes wrong and what goes right when you try to do it
    > the way you thought was best. On the flip side, if you try to do it a
    > way that you know is wrong, you learn very little when it doesn't work
    > the way people hope.
    >
    > A good programming adage is "do it once and throw it away". The second
    > time, you will be able to design it knowing the real strengths and
    > weaknesses of your first design.


    .... which will lead to gathering actual experience with the real
    'strengths and weaknesses' of the 'first improved design' ...


  9. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Wed, 12 Mar 2008 23:14:59 -0700 (PDT) David Schwartz wrote:
    | On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
    |
    |> | The best place to stop this chain is at the very first link. You
    |> | should need a damn good reason to do it wrong, not a good reason to do
    |> | it right.
    |
    |> OTOH, maybe someone will look at that code, say "I can do better", and
    |> write it all over from scratch to do the same thing, only better. I seem
    |> to remember some Swedish speaking Finnish college student having that
    |> attitude many years ago.
    |
    | You can almost always do it better from scratch if you get to start
    | out learning what goes wrong and what goes right when you try to do it
    | the way you thought was best. On the flip side, if you try to do it a
    | way that you know is wrong, you learn very little when it doesn't work
    | the way people hope.

    I'm not talking about that. I'm talking about inspiration not in how to
    do it, but in what to do. Someone will look at the bad code and see that
    it clearly is done in a bad way, and decide to do it from scratch. But
    they didn't get the idea to do it at all until the see that someone has
    already written the code.


    | A good programming adage is "do it once and throw it away". The second
    | time, you will be able to design it knowing the real strengths and
    | weaknesses of your first design.

    I agree with this. But sometimes that "second time" is someone else.


    | The best code I've ever written has been at least the third of fourth
    | time I've tried to do something. Sometimes the re-writes are in-place,
    | sometimes they're total. It depends how wrong I got it the N-1th time.

    That's happened to me more than once.


    | But none of that will happen if you start out knowingly doing it
    | wrong.

    Not necessarily. I call it "prototyping". I see no reason not to let it
    loose, as as long as you don't make any claims that it is believed to be
    done right.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-13-0758@ipal.net |
    |------------------------------------/-------------------------------------|

  10. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > On Mar 12, 3:13 pm, Johannes Bauer wrote:
    >
    >> > No, please read what I wrote again. What I'm saying is that it was no
    >> > easier to write your code poorly, and your justification (that nobody
    >> > else would ever use the code with different libraries) turned out to
    >> > be bogus.

    >
    >> You make me sound like a liar, which I find kind of unfair. I did, in
    >> fact, not know that anyone would have any interest in the code. My
    >> assumtions turned out to be incorrect - but it's not like I knew that in
    >> advance.

    >
    > Right, just like the people who wrote code with Y2K bugs didn't know
    > in advance that their code would still be in use 30 years later. Every
    > link in the chain has a justification, but the end result is disaster.
    > So you have to stop the chain at the first link.


    Were you doing programming then? I was. When you have a machine with
    perhaps 256KB of memory and 16 or so 100MB disks you store data as
    efficiently as possible.

    BTW, what exactly is your problem? Do you always need to get the last
    word? The OP has a solution to _his_ problem, that it doesn't fit
    _your_ ideas of perfection is of no matter. If he makes his code
    available, with no warranty of course, for other people who may find
    it useful it is certainly all the better.

    Jerry

  11. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 13, 1:31 pm, Jerry Peters wrote:

    > Were you doing programming then? I was. When you have a machine with
    > perhaps 256KB of memory and 16 or so 100MB disks you store data as
    > efficiently as possible.


    Right, but that mentality doesn't work any more. In the vast majority
    of programming applications, maintainability, understandability, and
    reusability are much more important than squeezing out a few bytes.

    > BTW, what exactly is your problem? Do you always need to get the last
    > word?


    I don't always need to get the last word, but if I disagree with
    someone and they raise new points, I will usually respond to them. If
    I think there's a valuable lesson that might be missed, I'll usually
    point it out.

    > The OP has a solution to _his_ problem, that it doesn't fit
    > _your_ ideas of perfection is of no matter.


    It may not matter to the OP, but that's not how the give and take of
    USENET works. It's not "you help me with this, and I'll help somebody
    else". It's "you help me with this, and everybody will learn from it,
    adding to the storehouse of knowledge we all have".

    That's why when someone posts a very specific question about a very
    specific one-in-a-million case, it's important that somebody somewhere
    point out that this not the typical case and that following the
    solutions in that thread will probably be wrong if you're not the
    poster.

    This preserves the usefulness of past USENET posts.

    > If he makes his code
    > available, with no warranty of course, for other people who may find
    > it useful it is certainly all the better.


    Maybe, maybe not. If it serves as an example or subsequently breaks in
    production use in subtle and horrible ways, it is not all the better.
    If people see this post and assume that's how things are typically
    done, it is not all the better.

    We need to lose the mentality from the 60s through the 90s that
    performance and space efficiency are priority one. For the bulk of
    code written today, correctness, understandability and maintainability
    are extremely important. They should never be sacrificed for
    performance or alleged convenience when there is no good reason to do
    so.

    When they are sacrificed for good reason, it is important that it be
    understood that these are things we do when we have good reason.

    DS

  12. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > We need to lose the mentality from the 60s through the 90s that
    > performance and space efficiency are priority one. For the bulk of
    > code written today, correctness, understandability and maintainability
    > are extremely important. They should never be sacrificed for
    > performance or alleged convenience when there is no good reason to do
    > so.


    I am horrified by this prose. This is the reason why most software today
    (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
    more and more powerful machines to get reasonable performance. All
    developers should be trained to get performance out of their code.



    --

    Michel TALON


  13. Re: Dynamic linking with LD_PRELOAD - get it compiled

    talon@lpthe.jussieu.fr (Michel Talon) writes:
    > David Schwartz wrote:
    >> We need to lose the mentality from the 60s through the 90s that
    >> performance and space efficiency are priority one. For the bulk of
    >> code written today, correctness, understandability and maintainability
    >> are extremely important. They should never be sacrificed for
    >> performance or alleged convenience when there is no good reason to do
    >> so.

    >
    > I am horrified by this prose. This is the reason why most software today
    > (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
    > more and more powerful machines to get reasonable performance.


    This isn't exactly true. I mainly develop targetting an 'embedded'
    ARM9-based system with a 200Mhz-CPU, no possibility for any paging
    and 64M of RAM. While this would have been a top-of-line desktop some
    dozen years ago, it is really 'limited' hardware nowadays. The base
    operating system image has a (compressed) size of (presently) 2052K
    (the uncompressed FS tree is 6M). The 'largest' application running on
    these device has (on my development board) presently a RSS of 1020K,
    mainly, because it needs to link against most of the Kerberos 5
    libraries. All others are significantly smaller. Nothing running on
    such a device has been 'heavily' optimized for either speed or space
    efficiency. The most advanced thing I have done in this respect was to
    rewrite the top-level AES- and MD5 interfacing code to avoid redundant
    memory copies, of which there were plenty, and obviously useless
    computations (like using cipertext stealing instead of padding
    cleartext to the AES blocksize when encrypting IP datagrams to support
    VPN functionality).

    I am generally very much in favor of prefering simple, structured code
    at the expense of both performance and speed except in situations
    where there is a real need to do otherwise. Because I like to 'waste'
    computer ressources in order to make code more accessible to humans,
    I avoid obvious 'waste for no particular reason', to ensure that I
    preferably never get into the situation where I have to contort the
    code in order to make it faster or smaller. So far, this has proven to
    be completely sufficient.

  14. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 14, 2:01 am, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
    > David Schwartz wrote:
    > > We need to lose the mentality from the 60s through the 90s that
    > > performance and space efficiency are priority one. For the bulk of
    > > code written today, correctness, understandability and maintainability
    > > are extremely important. They should never be sacrificed for
    > > performance or alleged convenience when there is no good reason to do
    > > so.


    > I am horrified by this prose. This is the reason why most software today
    > (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
    > more and more powerful machines to get reasonable performance.


    Nope, that's a myth. Reusable code is efficient.

    > All
    > developers should be trained to get performance out of their code.


    Absolutely, by creating reusable code.

    You could never have a product like OpenOffice if every element had to
    be generated from scratch just for OpenOffice. And you could never
    implement everything OpenOffice has to do efficiently if you had to do
    it just for OpenOffice. But someone has written an efficient XML
    parser. And someone has written an efficient text renderer. And with
    those pieces, you can produce an efficient complete product with
    reasonable effort.

    If a bug is found in the XML parser, and you used that XML parser, you
    just upgrade it to the version with the bug fix.

    Sure, you could write your own XML parser that had just the features
    you needed. But it will probably perform worse, because you don't need
    enough XML features to justify optimizing it. And it sure as hell
    won't be maintained, because you don't particularly care about XML
    parsing.

    It used to be that you had no choice. A general-purpose whatever would
    be too bulky and slow to be an option. But now you have a choice.
    Ironically, performance will typically be better, because more effort
    can go into optimizing each component if it's reusable.

    DS

  15. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz writes:
    > On Mar 14, 2:01 am, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
    >> David Schwartz wrote:
    >> > We need to lose the mentality from the 60s through the 90s that
    >> > performance and space efficiency are priority one. For the bulk of
    >> > code written today, correctness, understandability and maintainability
    >> > are extremely important. They should never be sacrificed for
    >> > performance or alleged convenience when there is no good reason to do
    >> > so.

    >
    >> I am horrified by this prose. This is the reason why most software today
    >> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
    >> more and more powerful machines to get reasonable performance.

    >
    > Nope, that's a myth. Reusable code is efficient.


    'Reusable code' is 'efficient' for people paying for software
    development, provided they are not using it themselves. If they do,
    any preceived benefit will be eaten over time.

    >> All developers should be trained to get performance out of their
    >> code.

    >
    > Absolutely, by creating reusable code.
    >
    > You could never have a product like OpenOffice if every element had to
    > be generated from scratch just for OpenOffice.


    Funnily enough, the people who wrote the original StarWriter did just
    that. They even coded a signifcant part of it in assembly, because
    this means it ran well (extremly well, actually) on then-current PC
    hardware.

    [...]

    > But someone has written an efficient XML parser.


    Considering that 'parsing XML' necessitates dealing with more than
    enough overhead to make anything 'slow', optimizing the hell out of an
    XML-parser to make it 'faster' is a stupid waste of time: Just not
    using XML would increase the 'performance' of the thing using it and
    decrease the time needed to develop it more.

    But the crucial point is, of course, that _somebody else has written
    an XML parser_ and that 'mere users', if only because of lack of
    alternatives, are willing to accept that their 3.x Ghz-PCs with 4G of
    RAM enable them to at least not spend more time waiting for the
    computer than they already did wait for a 4.77Mhz-machine with 640M of
    RAM twenty years ago. 'Fortunately', the waste of electricity and the
    corresponding, ever incresing heap of toxic rubbish does not yet have
    to be paid by the people causing it, so, their particular method of
    socializing cost to increase private gain still works.

    [...]

    > If a bug is found in the XML parser, and you used that XML
    > parser, you just upgrade it to the version with the bug fix.


    It's more likely that 'you' just add some code to workaround this
    particular issue in the 'frontend-code', because 'the bug in
    the XML parser' will never be fixed, either, because the people who
    wrote don't care or consider it to actually be a feature, or because
    nobody feels comfortable touching this particular piece of code, given
    that this could break one of the other 567 workarounds for bugs and
    quirks in it nobody understand entirely anymore, too.

    There is method to this madness, and the method cause each
    'sufficiently complicated' program to exhibit a tumor-like growth over
    time.

    > Sure, you could write your own XML parser that had just the features
    > you needed. But it will probably perform worse, because you don't need
    > enough XML features to justify optimizing it.


    Simpler, and especially, less code, will usually perform better than
    more complicated or more code.

    [...]

    > Ironically, performance will typically be better, because more effort
    > can go into optimizing each component if it's reusable.


    If there is a need to even think about 'optimizing components', that's
    usually a sign that the baby already drowned. Computers are fast
    enough nowadays that simple code will almost always perform 'well
    enough'. What remains to be done would be to convince the clever
    people spending enormous amounts of time trying to fix their design
    errors by means of 'hyper-clever optimimzations' to go looking for
    another playing field. Maybe complicated crossword puzzles coud be
    one. This would help to increase both the actual performance and
    reliablity of software quite a bit, because suddenly, the time to
    develop it sensibly would be there because the need to 'clever around'
    350 KLoC of inerithed deficiencies would be gone.



  16. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 14, 7:11 pm, David Schwartz wrote:
    > [a lot of stuff]


    David, while everything you say about reusability and proper software
    design is true and valid, unless you actually cite the specific source
    for this "all software must be properly designed, modular, reusable,
    and portable" that you seemed to have made up, your entire original
    attack on poor Mr. Bauer completely falls apart.

    Can you fill us all in on where that rule is? Is that part of a
    standard or something? This may be hard to believe, but Johannes
    Bauer's kludgey application is not the only one of it's kind out
    there. In fact, there may be hundreds of thousands, even millions, of
    programs that people have written that don't get the International
    Organization of Perfectly Designed Application's 100% Seal of Quality
    Approval. Millions! How can you sleep at night, knowing that somewhere
    there is a program that compiles on somebody's computer, but not on
    yours? How can you sleep at night, knowing that somewhere there is an
    application with source code that can't be infinitely copied, pasted,
    expanded, and reused? How do you feel knowing that your kids may be
    using computers with poorly designed applications on them?? Your own
    children, for God's sake! Using improperly designed applications! What
    is this world coming to?

    > It used to be that you had no choice. A general-purpose whatever would
    > be too bulky and slow to be an option. But now you have a choice.


    Precisely. The last sentence hits the nail on the head.

    Jason

  17. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Sat, 15 Mar 2008 15:11:04 -0700 (PDT) jason.cipriani@gmail.com wrote:

    | David, while everything you say about reusability and proper software
    | design is true and valid, unless you actually cite the specific source
    | for this "all software must be properly designed, modular, reusable,
    | and portable" that you seemed to have made up, your entire original
    | attack on poor Mr. Bauer completely falls apart.

    It's actually a rather common principle. OTOH, I think that principle
    is overused and too often misapplied ... especially the reusable part.
    I separate a lot of the software I write into library functions and main
    programs. The library functions are intended to be reusable. The main
    programs are not.

    When writing a new program, I try to understand how widely it could be
    used for its purpose. But I won't consider making it usable for purposes
    I cannot imagine.


    | Can you fill us all in on where that rule is? Is that part of a
    | standard or something? This may be hard to believe, but Johannes
    | Bauer's kludgey application is not the only one of it's kind out
    | there. In fact, there may be hundreds of thousands, even millions, of
    | programs that people have written that don't get the International
    | Organization of Perfectly Designed Application's 100% Seal of Quality
    | Approval. Millions! How can you sleep at night, knowing that somewhere
    | there is a program that compiles on somebody's computer, but not on
    | yours? How can you sleep at night, knowing that somewhere there is an
    | application with source code that can't be infinitely copied, pasted,
    | expanded, and reused? How do you feel knowing that your kids may be
    | using computers with poorly designed applications on them?? Your own
    | children, for God's sake! Using improperly designed applications! What
    | is this world coming to?

    Whenever I need to write something that is very machine specific to one
    single machine, I have no qualms about doing that. I have done it many
    times. And there are plenty of examples around of programs and functions
    that are very machine specific. And device drivers are, too, but that is
    an obvious special case.


    |> It used to be that you had no choice. A general-purpose whatever would
    |> be too bulky and slow to be an option. But now you have a choice.
    |
    | Precisely. The last sentence hits the nail on the head.

    You mean we should still have a choice between a highly optimized machine
    specific program and a (relatively) slow and bulky (but comfortably fast
    on today's machines) portable version, where one can run 20 of the former
    or 3 of the latter at the same time on a given modern machine?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-17-0826@ipal.net |
    |------------------------------------/-------------------------------------|

  18. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 9:33 am, phil-news-nos...@ipal.net wrote:
    > [snip a lot of reasonable stuff that I agree with]


    > |> It used to be that you had no choice. A general-purpose whatever would
    > |> be too bulky and slow to be an option. But now you have a choice.
    > |
    > | Precisely. The last sentence hits the nail on the head.
    >
    > You mean we should still have a choice between a highly optimized machine
    > specific program and a (relatively) slow and bulky (but comfortably fast
    > on today's machines) portable version, where one can run 20 of the former
    > or 3 of the latter at the same time on a given modern machine?


    That's probably not what I meant, as it doesn't make sense in the
    context of what I said. More likely, I meant that a programmer still
    has a choice between a portable, reusable application (which doesn't
    necessarily have to be slow and bulky, even relatively), and a non-
    portable, not-so-reusable application that he puts together quickly
    and gets the job done. I should have been less vague.

    My major point is that it's unreasonable to claim that all
    applications should consist of portable and reusable code. Another
    point I am making is that it is equally unreasonable to criticize
    (even mildly) an application that does not consist of portable/
    reusable code and that also makes no claims otherwise (of course, if
    somebody claims to have written a "cross-platform food processing
    library" but it only chops carrots on Windows, you're definitely
    justified in smacking them around a bit).

    Jason

  19. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mon, 17 Mar 2008 09:33:26 -0700 (PDT) jason.cipriani@gmail.com wrote:

    | My major point is that it's unreasonable to claim that all
    | applications should consist of portable and reusable code. Another
    | point I am making is that it is equally unreasonable to criticize
    | (even mildly) an application that does not consist of portable/
    | reusable code and that also makes no claims otherwise (of course, if
    | somebody claims to have written a "cross-platform food processing
    | library" but it only chops carrots on Windows, you're definitely
    | justified in smacking them around a bit).

    Windows? Isn't that for letting cherry pies cool down?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-17-1503@ipal.net |
    |------------------------------------/-------------------------------------|

  20. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
    wrote:

    > My major point is that it's unreasonable to claim that all
    > applications should consist of portable and reusable code.


    Well, since nobody claimed that, ...

    > Another
    > point I am making is that it is equally unreasonable to criticize
    > (even mildly) an application that does not consist of portable/
    > reusable code and that also makes no claims otherwise


    Why not? What if the code would have been more robust, easier to
    understand, portable, and reusable with even less effort than it took
    to make it non-portable and not reusable? Would you still argue that
    it's unreasonable to criticize it just because it doesn't claim to be
    portable or reusable?

    > (of course, if
    > somebody claims to have written a "cross-platform food processing
    > library" but it only chops carrots on Windows, you're definitely
    > justified in smacking them around a bit).


    Bad design and bad code is still bad even if nobody claims it's good.
    In many cases, it's actually harder to write the non-portable, non-
    reusable code than it would have been to do it right.

    A good example would be writing your own XML library because you "only
    need a few simple capabilities". Not only is this likely to be more
    work than using one that's already made, but it will likely mishandle
    a large number of corner cases that maintained XML libraries work hard
    to get right.

    It's likely not even faster in execution. And if it is, that doesn't
    matter anyway since the assumption was that this was a limited-purpose
    program. And, of course, that would be premature optimization.

    It might take up less memory, but who cares? And in many cases, it
    actually won't.

    DS

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast