4 ms·

Note to 1-bit people: saying that "X is not a good thing in general", is not the same as saying that "X is a bad thing in general". All that's being said here i

• old-gregg 6y ago
  The "1-bit people" part made me laugh. Thanks ;)
  • Karsteski 6y ago
    I'm definitely stealing it
• AtlasBarfed 6y ago
  I think this is still the hallmark of API volatility. I personally think with the stalling of serial speed in CPUs, we will eventually have to optimize and stabilize interfaces. I think some of that will require stabilization of many APIs and libraries such that they don't change over the span of a decade. This era is basically unthinkable in the current age, but I think that is because we have been living in the "free lunch" era of faster better CPUs every year for too long. Much like all of the 20th century was an era of resource availability. The 21st will be an era of succeeding within resource constraints: with efficiency. Those libraries will be excellent candidates for shared libraries.
  • ece 6y ago
    As the reply to Linus's post points out, the increase in storage/network (~9MB vs 40+MB) can be multiples of the shared library cost, and memory cost can be multiples too if you're not calling the same binary over and over again like Clang. A middle ground could be distros can keep control over the version that's being statically linked at build time. It would do away with the dependency conflicts that happen now and result in a better user experience. The app/libraries can be updated as needed together. This is what's happening in a venv or container too, once you've built the venv or container it's effectively static. You do need to keep track of the library versions ultimately at build time. This effectively means handing things off to the build system, and distros like Nix have effectively wrapped build systems to some success I think.
    • jonringer117 6y ago
      Nix doesn't really "wrap" anything besides compilers, or when it's absolutely necessary for an application. And the wrapping is only done so that there's a way to shoehorn certain CFLAGS, some nix-specific behavior, and other configuration options which an upstream may not have a great way to configure. But for most mature build systems we largely just use the toolchain as-is. CMake, pkg-config, autotools, and other toolchains or technologies generally allow enough flexibility to enable non-FHS builds to be done in a consistent and easy manner. Actually, creating nix packages for upstreams which have good release management discipline is trivial once you're familiar with nix. What makes nix special is that you when you go to build the package, you reference the dependencies through their canonical name, but nix translates these dependencies to a unique paths which are hashed to capture all inputs (including configuration flags) used to create the dependency. So you can use multiple conflicting versions of a dependency in a package's dependency tree without issue. Dependencies can be shared if a dependency matches exactly, but can differ if needed. And that's something that FHS distros cannot do. Actually, since nix never makes any assumptions about what's installed on the system, you're free to use it on any distro. And it's hermetic, so the host system wouldn't be changed outside of the `/nix` directory. You can even use is it even on macOS, although it's not as well supported, but should work fine for common packages. > A middle ground could be distros can keep control over the version that's being statically linked at build time. Nixpkgs already does this, even if the dependency is dynamically linked. So there's no additional overhead with switching it out to the static variants; other than upstreams may not support that scenario as well as "traditional" dynamic linking.
• slver 6y ago
  "Note to the 1-bit people" is an odd redirect given Linus is known for his 1-bit opinions.
  • ric2b 5y ago
    I wouldn't say that, his opinions are more notorious for being... "strongly worded", not for being black or white.