5 ms·

> You're welcome! And thanks for your posts too. Thanks :-) > And also regardless of personal feelings, many people in the Rust world seem to be very excited

by madez 9y ago

> You're welcome! And thanks for your posts too. Thanks :-) > And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly WebAssembly and JavaScript are used to create locked-in software to deliver uncopyable experiences, to ultimately exercise power over other people. Clearly, there will be people interested in this, because the power can be used to generate profit. Ethically, I think it must not be supported. It goes frontally against the idea and intent of free software. I think this problem is glaring, and I'm interested in your view about this very aspect. > How is Cargo and rustup better than Apt? I didn't mean to restrict this to Apt. Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems. Apt is not special in this regard, and was just used as an example.

steveklabnik 9y ago
> I'm interested in your view about this very aspect. I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself. With regards to WebAssembly, it's also complicated. You can argue that JavaScript is basically in the same place, and so for me, it's kind of a moot point. That is, there's no requirement for JavaScript to be free software today either. In practice, obfuscated/minified JS and WebAssembly are basically the same, with the exception that the tooling for de-{obfuscating,compiling} JS is currently more robust and mature since it's been around a lot longer. TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. > I didn't mean to restrict this to Apt Quite fair! And as I alluded to above, it's not just the thing that I posted. This is quite long but I have little time, so I'm gonna be brief. https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... basically is, IMO, the gold standard for talking about these things. However, I think the distinction of OS/system package manager vs Language package manager is important. Basically, Cargo and Apt (I'll follow your lead here with using Apt as a standin) have very different goals, and very different constants. This is because they're doing two very different jobs. Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications. With Cargo, we've very strongly stayed away from giving it any sort of "system package manager" features, because that's not what we're trying to do. However, at some point, a developer delivers an application to an end user, and so I agree strongly that Cargo should play well with Apt. It cannot, however, be replaced by Apt. To that end, I think tools like https://crates.io/crates/debcargo https://crates.io/crates/debcargo are the path forward, and in fact that tool is (in my understanding) being used by Debian to manage this bridge. I would love to have a simple Cargo command to generate a compatible system package for any of these systems. It's a long tail thing though, so it's gonna take some time. Anyway, yeah, that's the root of it. There's tons of other details too. Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time. > Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems What's the gold standard example for you, exempting C and C++?
- madez 9y ago
  I'll try to keep it brief this time. > TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. It's a step in the wrong direction. Working on WebAssembly is not as bad as it could be because there already is JavaScript, but instead of working on WebAssembly, I think we should bury JavaScript. > Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time. Fair enough. Looking forward to it. > What's the gold standard example for you, exempting C and C++? Maybe Python on Debian. But why shouldn't C be the benchmark? And why compare to another language instead of what's desireable?
  - steveklabnik 9y ago
    > Maybe Python on Debian. Cool, thanks. I'll look into it. I'm more familiar with Ruby and Debian which has a... storied history :) > But why shouldn't C be the benchmark? In some sense, it shouldn't, I'm in agreement that in some sense, we should talk about what's desireable. However, there's a reason that it's significant: apt is designed around C. Its compilation model, everything. So of course C works with apt very well; I'd hope so! But non-C languages have a much larger hurdle. In terms of Rust's integration into a system, it'd face challenges similar to non-C than to C.
    - madez 9y ago
      > apt is designed around C It would be nice to have a list of what each of Apt, Pacman and Portage needed to change to accommodate Rusts needs. Thanks for your comments!
      - burntsushi 9y ago
        Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10 https://github.com/BurntSushi/ripgrep/issues/10
      - steveklabnik 9y ago

by madez 9y ago

steveklabnik 9y ago

> I'm interested in your view about this very aspect. I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself. With regards to WebAssembly, it's also complicated. You can argue that JavaScript is basically in the same place, and so for me, it's kind of a moot point. That is, there's no requirement for JavaScript to be free software today either. In practice, obfuscated/minified JS and WebAssembly are basically the same, with the exception that the tooling for de-{obfuscating,compiling} JS is currently more robust and mature since it's been around a lot longer. TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. > I didn't mean to restrict this to Apt Quite fair! And as I alluded to above, it's not just the thing that I posted. This is quite long but I have little time, so I'm gonna be brief. https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... basically is, IMO, the gold standard for talking about these things. However, I think the distinction of OS/system package manager vs Language package manager is important. Basically, Cargo and Apt (I'll follow your lead here with using Apt as a standin) have very different goals, and very different constants. This is because they're doing two very different jobs. Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications. With Cargo, we've very strongly stayed away from giving it any sort of "system package manager" features, because that's not what we're trying to do. However, at some point, a developer delivers an application to an end user, and so I agree strongly that Cargo should play well with Apt. It cannot, however, be replaced by Apt. To that end, I think tools like https://crates.io/crates/debcargo https://crates.io/crates/debcargo are the path forward, and in fact that tool is (in my understanding) being used by Debian to manage this bridge. I would love to have a simple Cargo command to generate a compatible system package for any of these systems. It's a long tail thing though, so it's gonna take some time. Anyway, yeah, that's the root of it. There's tons of other details too. Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time. > Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems What's the gold standard example for you, exempting C and C++?

madez 9y ago
I'll try to keep it brief this time. > TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. It's a step in the wrong direction. Working on WebAssembly is not as bad as it could be because there already is JavaScript, but instead of working on WebAssembly, I think we should bury JavaScript. > Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time. Fair enough. Looking forward to it. > What's the gold standard example for you, exempting C and C++? Maybe Python on Debian. But why shouldn't C be the benchmark? And why compare to another language instead of what's desireable?
- steveklabnik 9y ago
  > Maybe Python on Debian. Cool, thanks. I'll look into it. I'm more familiar with Ruby and Debian which has a... storied history :) > But why shouldn't C be the benchmark? In some sense, it shouldn't, I'm in agreement that in some sense, we should talk about what's desireable. However, there's a reason that it's significant: apt is designed around C. Its compilation model, everything. So of course C works with apt very well; I'd hope so! But non-C languages have a much larger hurdle. In terms of Rust's integration into a system, it'd face challenges similar to non-C than to C.
  - madez 9y ago
    > apt is designed around C It would be nice to have a list of what each of Apt, Pacman and Portage needed to change to accommodate Rusts needs. Thanks for your comments!
    - burntsushi 9y ago
      Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10 https://github.com/BurntSushi/ripgrep/issues/10
    - steveklabnik 9y ago