5 ms·

The main advantage of Linux over other systems is that its available from source and thus can be patched and recompiled easily. Here we see someone using LD_PRE

The main advantage of Linux over other systems is that its available from source and thus can be patched and recompiled easily. Here we see someone using LD_PRELOAD to patch the behavior of a binary, because they rely on distributions pre-compiled packages without means to change the source code themselves. This sort of negates that advantage, right?

nightfly 3y ago
Having an additional way to effect changes in behavior without recompiling an application hardly negates the benefit you described. They don't say the _cant_ or _couldn't_ change the source themselves either. And what you described is hardly the main advantage of Linux, FreeBSD enables that _much_ easier.
yrro 3y ago
I don't think openssh upstream would accept a patch that makes ssh interpret ipv4 addresses as anything other than ipv4 addresses, and who wants to carry such a patch downstream forever?
- blueflow 3y ago
  You don't need to merge upstream! Its your source, your build, your rules.
  - yrro 3y ago
    And if you're happy to take on that work (and the associated risk) forever, go for it. For others, hacks like tnat64 work fine. They also work for lots of programs, where patching each one individually to somehow detect that it's behind NAT64 and behave differently is a lot of work!
  - londons_explore 3y ago
    Maintaining your own patchset for your personal use is usually not a good use of your time and expertise. Every time someone runs a linter over upstream, you're going to have to remake that patch. Sure, it's only 20 mins... But that multiplied by every bit of software you patch and every release, and you quickly realise that a huge chunk of your life was wasted doing what is effectively busywork. Instead, contribute your time and efforts back to upstream, and now your efforts can help millions of people not just one. If others do the same, you'll see far more improvements to the software you use than you alone could ever write and maintain.
    - blueflow 3y ago
      You don't have to, its your own fork.
      - londons_explore 3y ago
        But you might want to integrate security patches... And one day you're going to need to make changes to support non-ancient glibc versions etc. Even staying still in the world of software involves some level of effort.
    - KirillPanov 3y ago
      The "upstream or nothing" attitude is an attempt to erase any difference between free software and "visible source". Offering changes back to upstream is always encouraged, but whether or not it is accepted is largely irrelevant to the patch author.
      - londons_explore 3y ago
        I just don't think it's a good use of OP's time - effectively developing and maintaining software for 1 user. One main benefit of software/computers/the internet is that work done by one person can benefit millions - thats what sets us apart from cavemen who had to do everything for themselves, and got a worse quality of life as a result.
        KirillPanov 3y ago
        > software for 1 user. This bogus assumption is the whole problem with the "upstream or nothing" attitude. You're letting a single project -- and usually a single individual -- be the gatekeeper between you and the entire remainder of humanity. That is stupid.
depr 3y ago
Isn't having the source available only the advantage it has over Windows? For most people the advantage is probably, as 'bcantrill once said, that they can Google their stacktraces.
charcircuit 3y ago
This way works with any binary. Your idea of patching the source would have to be done to every single program that uses the network that you want to work like this. Really this should just be a part of the OS though.
dspillett 3y ago
This method could apply to other tools with the same IPv4/IPv6 behaviour, without further modification. Changing the behaviour in the utility directly would only fix it for that one utility meaning that to fix another you need to do the same work again. It is perhaps also safer than modifying such a core component as SSH: if you introduce a bug the trick can be easily disabled until fixed, if you accidentally break SSH you might cause yourself significantly more hassle. > This sort of negates that advantage LD_PRELOAD trickery doesn't negate the advantage of having full source access, patching SSH would also have been a perfectly valid option, but is perhaps a better tool for this particular job. For another use of the trick see https://github.com/mariusae/trickle https://github.com/mariusae/trickle (the project looks stale, though that may be because it is properly done and there have been no security/other bugs to fix in recent history) which slips its own functions in the call chain to apply user controlled (rather than firewall/routing level) throughput shaping to utilities that don't offer it out of the box.
andylynch 3y ago
Plenty of people aren’t that concerned about building stuff from source, even when they are running on Linux. Often, proprietary third-party code doesn’t have source available at all.
userbinator 3y ago
Try actually recompiling something nontrivial but open-source, and getting the exact binary you already have, the one which you know works but just needs the one modification you want. You'll quickly discover that "open source" doesn't make everything easier.

nightfly 3y ago

Having an additional way to effect changes in behavior without recompiling an application hardly negates the benefit you described. They don't say the _cant_ or _couldn't_ change the source themselves either. And what you described is hardly the main advantage of Linux, FreeBSD enables that _much_ easier.

yrro 3y ago

I don't think openssh upstream would accept a patch that makes ssh interpret ipv4 addresses as anything other than ipv4 addresses, and who wants to carry such a patch downstream forever?

blueflow 3y ago
You don't need to merge upstream! Its your source, your build, your rules.
- yrro 3y ago
  And if you're happy to take on that work (and the associated risk) forever, go for it. For others, hacks like tnat64 work fine. They also work for lots of programs, where patching each one individually to somehow detect that it's behind NAT64 and behave differently is a lot of work!
- londons_explore 3y ago
  Maintaining your own patchset for your personal use is usually not a good use of your time and expertise. Every time someone runs a linter over upstream, you're going to have to remake that patch. Sure, it's only 20 mins... But that multiplied by every bit of software you patch and every release, and you quickly realise that a huge chunk of your life was wasted doing what is effectively busywork. Instead, contribute your time and efforts back to upstream, and now your efforts can help millions of people not just one. If others do the same, you'll see far more improvements to the software you use than you alone could ever write and maintain.
  - blueflow 3y ago
    You don't have to, its your own fork.
    - londons_explore 3y ago
      But you might want to integrate security patches... And one day you're going to need to make changes to support non-ancient glibc versions etc. Even staying still in the world of software involves some level of effort.
  - KirillPanov 3y ago
    The "upstream or nothing" attitude is an attempt to erase any difference between free software and "visible source". Offering changes back to upstream is always encouraged, but whether or not it is accepted is largely irrelevant to the patch author.
    - londons_explore 3y ago
      I just don't think it's a good use of OP's time - effectively developing and maintaining software for 1 user. One main benefit of software/computers/the internet is that work done by one person can benefit millions - thats what sets us apart from cavemen who had to do everything for themselves, and got a worse quality of life as a result.
      - KirillPanov 3y ago
        > software for 1 user. This bogus assumption is the whole problem with the "upstream or nothing" attitude. You're letting a single project -- and usually a single individual -- be the gatekeeper between you and the entire remainder of humanity. That is stupid.

depr 3y ago

Isn't having the source available only the advantage it has over Windows? For most people the advantage is probably, as 'bcantrill once said, that they can Google their stacktraces.

charcircuit 3y ago

This way works with any binary. Your idea of patching the source would have to be done to every single program that uses the network that you want to work like this. Really this should just be a part of the OS though.

dspillett 3y ago

This method could apply to other tools with the same IPv4/IPv6 behaviour, without further modification. Changing the behaviour in the utility directly would only fix it for that one utility meaning that to fix another you need to do the same work again. It is perhaps also safer than modifying such a core component as SSH: if you introduce a bug the trick can be easily disabled until fixed, if you accidentally break SSH you might cause yourself significantly more hassle. > This sort of negates that advantage LD_PRELOAD trickery doesn't negate the advantage of having full source access, patching SSH would also have been a perfectly valid option, but is perhaps a better tool for this particular job. For another use of the trick see https://github.com/mariusae/trickle https://github.com/mariusae/trickle (the project looks stale, though that may be because it is properly done and there have been no security/other bugs to fix in recent history) which slips its own functions in the call chain to apply user controlled (rather than firewall/routing level) throughput shaping to utilities that don't offer it out of the box.

andylynch 3y ago

Plenty of people aren’t that concerned about building stuff from source, even when they are running on Linux. Often, proprietary third-party code doesn’t have source available at all.

userbinator 3y ago

Try actually recompiling something nontrivial but open-source, and getting the exact binary you already have, the one which you know works but just needs the one modification you want. You'll quickly discover that "open source" doesn't make everything easier.