Hacker News Reader

Comment by madez | Hacker News Reader

> 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.

View on HN

> 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-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 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++?

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?

> 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.

> 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!

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

There's also another split, honestly. Anyone can make an Apt package, but getting your apt package into Debian is another story. There's friction in both sides. Most of them are related to (very sensible when talking about C) distro policies. It's as much cultural as it is technical.

Someday I might write some of this up, but honestly, I deeply appreciate the work that the humans who build OS packages do, and don't really want to add more friction to the pile, or appear to be denigrating their work. It's more likely to just be an "argue on the internet" situation than actually cause any change that'd be helpful.

To be clear, again, this stuff already works. It's about the difference between "easy" and "possible".

> Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications.

One thing that might help people see this distinction better is if Cargo offered better post-build hooks to allow community-driven add-ons that handle packaging for the various system package managers. If a Rust developer could run cargo dist-package (or whatever it's called) and have it build a deb/rpm/pkg/msi, it'd be really easy to use cargo for the development phase and the other package managers for the distribution phase. As it is, if I want to run someone else's Rust software, I'm basically using cargo install to pull from crates and build locally.

You don't need hooks to do that today; name an executable `cargo-dist-package`, put it in your $PATH, and `cargo dist-package` Just Works. Well, you still have to implement it, but the workflow is there. Have it invoke `cargo build` and you're good to go.

We've been wary to add more hooks because then you can start to emulate a system package manager with them.

It's not just triggers, though having the post-build equivalent of build.rs would be a nice feature that doesn't really change the nature of cargo in any way. It would be quite useful for doing post-build logic...for example, when building a Neon module for Node, the dylib is that cargo compiles doesn't have the .node extension that Node wants it to have. It'd be a lot simpler (and more portable) to just put that rename into a post-build.rs rather than having to do it after every build or, as I do now, using a justfile to run both commands.

But 'hooks' also means making cargo more extensible. IIRC, cargo will error out if it finds a key in Cargo.toml that it doesn't recognize. It would be nice to be able to store configurations for extensions to the cargo build lifecycle in that file as well. Cargo could just ignore them. Also, it'd be nice to have a crate to read and safely write from/to Cargo.toml to make it easy for extension executables like you mentioned to use information about the build.

Just being able to pass through to an executable in $PATH isn't really enabling much and, aside from that, cargo seems pretty hostile towards implementing features that the team doesn't believe in. I guess what I'm advocating for is providing generic extension points in Cargo and then sitting back to watch what the community comes up with. My experience with the Rust community is that there are a lot of exceptionally smart developers who love the language and the tooling and I think we'd get a lot of exciting and creative features if the main team were removed from the critical path. A more organic approach to evolving the way we build Rust code might come up with something better and can serve as free user research for what should be included in the official cargo tool and become the officially-recommended best practice.

I hear you. I'm of two minds about this.

> I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself.

I haven't heard the phrase, "free software misses the point", before, and a quick web search turns up too many links to stallman's "why open source misses the point" article. Could you elaborate a little or link somewhere that does?

Thank you!

I actually have to thank you, deeply and truly, because in trying to respond to you, it clarifies a bunch of things for me. I've re-written this comment three times. Thanks.

I made that phrase up. But I'm sympathetic to the essay, and I think maybe I was subconsciously referring to it.

Okay so, my issue with free software is similar to my issue with liberalism. I mean that in a philosophical, historical sense, not a "the Democrats" sense.

Liberalism (and much thought from the Enlightenment) is focused on freedom with regards to exchange. The Four Freedoms are focused on "I have this artifact, what can I do with it in relation to others." Marxism, which I am more sympathetic to, instead focuses on production over exchange. That is, the issue is not in individuals exchanging things, but how those things are produced in the first place. So in some sense, it's pre-occupied with the wrong thing.

Let's make this more concrete. You know the concept of "source dumps"? Let's say that I'm MegaEvil Inc. I can create some software, and once a year, release a new version. I also give you a copy of the source code, licensed under the GPL. There's no mailing list, no way to send patches, no governance. Just a copy of the source, once a year. This is 100% Free Software, but I'd argue that it misses the point. It's still better than being proprietary! But it doesn't let me, as the user, exercise any control over how the software is made. Yes, I could create a fork, but what happens when one year, there's an extensive internal re-write? At some point, a fork is a completely separate project, and we're back to step 1.

That is, the question I'm interested in is, who has the power to affect the development of the software? Free Software has nothing to say about this. But that's the real step forward. Being at the complete whim of upstream isn't that different from being at the whim of a proprietary vendor.

Given that I've literally just thought of this, this might be a bit rambly, a bit too deep, and a bit under-developed. But there you go. :)

I'd say its pretty well written, and the disclaimer on a public forum goes without saying.

I suppose I could sum it up as: "GPL doesn't include anything about the infrastructure of the software." The lack of an infrastructure for developers to hook into, could be GPL in literal word (or law), but not GPL in spirit (or morals). Likewise, and to add to your example, client-server architecture such as cloud computing might be GPL compatible in literal word, but not in spirit.

>I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself.

Can I suggest a compromise with the belief that "Stallman is almost always right," because no human being with an extremist ideology is ever always right. A philosophy can be useful, even beneficial, but still be flawed.

I don't believe in the argument to moderation.

> A philosophy can be useful, even beneficial, but still be flawed.

I agree wholeheartedly.

Within this context, "Stallman is always right" applies to Stallman_with_FSF_hat_ie._FSF.org not Stallman_and_his_side_interests_on_Stallman.org.

Yes, thank you. I find many of Stallman’s personal views reprehensible, I’m purely talking about FSF stuff.

Reply on news.ycombinator.com