4 ms·

My usual comment shilling for xmake in any build system conversation, that's how much I like it : https://xmake.io/#/ https://xmake.io/#/

sebtron 3y ago
Unrelated, but why do so many modern tools tell you to curl | sh to install them? It feels so wrong to run random code from the web. Surely "get the files from here and run install.sh" is not a hard instruction to follow for a developer, right?
- jcelerier 3y ago
  ... What's the actual difference between these two cases in terms of security ? Downloading install.sh from Firefox won't be magically safer than downloading it from curl and I'm not going to read 2k lines of shell script every time I install a new version of cmake on a new machine
  - sebtron 3y ago
    What's an install script doing in 2k lines? If it is a reasonable size, I would definitely skim through it to check that it does not mess up with my environment. Or at least that it is not an obviously malicious script.
    - acdha 3y ago
      Okay, so what happens next? It downloads and installs something which you almost certainly aren’t auditing before you install it. If you don’t trust their installer, you shouldn’t trust their code. The reason why a vocal subcommunity gets hung up on “curl | sh” is that they aren’t comfortable accepting the degree of trust which they’re placing in so many third parties but haven’t fully accepted the implications. Saying “download the file and open it manually” is basically the same as the TSA making you throw out a water bottle – it feels like diligence even though it’s pointless. This is why most security people are focused on things like pervasive sandboxing to contain the damage when someone makes a mistake, code-signing and revocation, and trusted third-party providers (e.g. a Linux distribution or App Store) which are more trustworthy and can possibly do things like audit every binary they ship.
- eddd-ddde 3y ago
  Honestly, there's no difference in practice. You can always just curl, inspect the script, shell it. Personally I always use AUR wrappers since I hate having programs installed outside of packages.
- cassepipe 3y ago
  There are other installation methods : https://xmake.io/#/guide/installation?id=macos https://xmake.io/#/guide/installation?id=macos It's in the official Fedora and Arch repos and there is ppa for Ubuntu
mronetwo 3y ago
Why? What's so special about it?
- cassepipe 3y ago
  1. No DSL, it's lua 2. No build/meta-build system separation 3. It's ninja-like fast 4. Package management and plenty of perks
mdaniel 3y ago
it took some digging to find "does xmake use xmake" since it's down in the src folder but here's a concrete example https://github.com/xmake-io/xmake/blob/v2.8.9/core/xmake.lua https://github.com/xmake-io/xmake/blob/v2.8.9/core/xmake.lua and https://github.com/xmake-io/xmake/blob/v2.8.9/core/src/xmake/xmake.lua https://github.com/xmake-io/xmake/blob/v2.8.9/core/src/xmake... but I couldn't decipher what the matching .sh files do, if anything

sebtron 3y ago

Unrelated, but why do so many modern tools tell you to curl | sh to install them? It feels so wrong to run random code from the web. Surely "get the files from here and run install.sh" is not a hard instruction to follow for a developer, right?

jcelerier 3y ago
... What's the actual difference between these two cases in terms of security ? Downloading install.sh from Firefox won't be magically safer than downloading it from curl and I'm not going to read 2k lines of shell script every time I install a new version of cmake on a new machine
- sebtron 3y ago
  What's an install script doing in 2k lines? If it is a reasonable size, I would definitely skim through it to check that it does not mess up with my environment. Or at least that it is not an obviously malicious script.
  - acdha 3y ago
    Okay, so what happens next? It downloads and installs something which you almost certainly aren’t auditing before you install it. If you don’t trust their installer, you shouldn’t trust their code. The reason why a vocal subcommunity gets hung up on “curl | sh” is that they aren’t comfortable accepting the degree of trust which they’re placing in so many third parties but haven’t fully accepted the implications. Saying “download the file and open it manually” is basically the same as the TSA making you throw out a water bottle – it feels like diligence even though it’s pointless. This is why most security people are focused on things like pervasive sandboxing to contain the damage when someone makes a mistake, code-signing and revocation, and trusted third-party providers (e.g. a Linux distribution or App Store) which are more trustworthy and can possibly do things like audit every binary they ship.
eddd-ddde 3y ago
Honestly, there's no difference in practice. You can always just curl, inspect the script, shell it. Personally I always use AUR wrappers since I hate having programs installed outside of packages.
cassepipe 3y ago
There are other installation methods : https://xmake.io/#/guide/installation?id=macos https://xmake.io/#/guide/installation?id=macos It's in the official Fedora and Arch repos and there is ppa for Ubuntu

mronetwo 3y ago

Why? What's so special about it?

cassepipe 3y ago
1. No DSL, it's lua 2. No build/meta-build system separation 3. It's ninja-like fast 4. Package management and plenty of perks

mdaniel 3y ago

it took some digging to find "does xmake use xmake" since it's down in the src folder but here's a concrete example https://github.com/xmake-io/xmake/blob/v2.8.9/core/xmake.lua https://github.com/xmake-io/xmake/blob/v2.8.9/core/xmake.lua and https://github.com/xmake-io/xmake/blob/v2.8.9/core/src/xmake/xmake.lua https://github.com/xmake-io/xmake/blob/v2.8.9/core/src/xmake... but I couldn't decipher what the matching .sh files do, if anything