LWN: Comments on "Debian, Rust, and librsvg"

Debian, Rust, and librsvg

immibis — Tue, 23 Feb 2021 16:11:10 +0000

The point isn't to make backdoors visible, so I don't see the relevance? The point is to support more CPU architectures.

The point of Rust isn't "security" as in "making backdoors visible" either, if that's where the confusion is coming from. The point of Rust is "security" as in "writing fewer exploitable bugs"

Debian, Rust, and librsvg

tschwinge — Thu, 29 Nov 2018 22:13:09 +0000

Adding a LLVM IR front end to GCC is precisely what I suggested in <https://users.rust-lang.org/t/rust-front-end-to-gcc/11601/12>. Alas, I still lack a big enough chunk of time to dedicate to that. :-/

Debian, Rust, and librsvg

ewen — Fri, 23 Nov 2018 10:03:17 +0000

Maybe https://www.owlfolio.org/research/bootstrapping-trust-in-... which speculates using FORTH as part of this bootstrap? Or https://github.com/oriansj/stage0 which mentions FORTH but ultimately takes a different route via assembly and C.

If you’re thinking of another one and do find the link I’d be curious to read about their approach.

Ewen

Debian, Rust, and librsvg

joncb — Tue, 20 Nov 2018 22:17:36 +0000

> What dependency hell was that?

Bear in mind that this was a long time ago but my memory is that i was trying to get a somewhat more recent version of Mysql as the stable version was really quite old. Investigating why showed that the problem was that Mysql had a hard dependency on perl which had a dependency loop that prevented it updating. (i'm eliding a lot of details because i just don't remember them... i vaguely recall the kernel was involved somewhere too) Ultimately my options were :-
* Build and maintain my own installation of Mysql (Ugh... no)
* Move to unstable (Production... no)
* Live with the ancient version (This is what i ended up doing)

Honestly i probably should have culled that part of the comment because it serves no purpose really. I don't hold a grudge against Debian, i just found other distributions that (irrespective of that issue) suited me more. Shortly after that incident someone introduced me to Gentoo and, for me, the rest was history. I've not felt a need to go back although these days i use Arch, CoreOS and Alpine more often than Gentoo.

Debian, Rust, and librsvg

rodgerd — Tue, 20 Nov 2018 22:07:54 +0000

Pretty much.

And, like it or not (and I don't, particularly), LLVM is becoming the compiler of choice for more and more software.

Debian, Rust, and librsvg

roc — Tue, 20 Nov 2018 18:43:02 +0000

If Debian strongly values both "one source tree per package" and "support practically-unused architectures no matter what the cost", then I guess Debian should maintain the LLVM branch to make that possible.

What is *not* reasonable is for the vanishingly small number of people who care about these niche architectures to push the costs of supporting those architectures onto others.

Debian, Rust, and librsvg

farnz — Tue, 20 Nov 2018 12:22:43 +0000

From my PoV (having written production code in all the languages I'm mentioning), D is a competitor to C++11 - it's a major advance on C++03, and competitive with C++11. The trouble is that where C++ has continued to evolve in the form of C++14 and C++17, D seems to have become stuck; it's neither improving at the rate C++ is, nor is it exploring areas of the programming language design space that C++ does not.

Rust is advancing where D has not (indeed, some of the production D code I've worked on in the past has been rewritten in Rust) because the use of affine types moves an interesting set of bugs from runtime to compile time; it thus doesn't matter that C++20 will be a better C++ than Rust, because Rust isn't aiming to be a better C++; in contrast, D was a better C++03, comparable to C++11, and has fallen back since then into a niche where it's not as good as C++ for systems programming (the GC is effectively compulsory), not as good for quick hacks as Go or Python, and has the same division of bugs into runtime versus compile time as C++ (unlike Rust).

Debian, Rust, and librsvg

moltonel — Tue, 20 Nov 2018 12:09:31 +0000

Sorry if my comment sounded mean or hurt anybody, I try to be considerate but something always slips by. However, this is indeed what it *looks like* to me. A subjective, biased observation sure, but an honest one. Maybe "hopeless" would have been better than "desperate" ? In the sense that it's IMHO unlikely to change the trend, not in the sense that the D community is giving up.

I actually really liked D when I first encountered it. I did tutorials and wrote toy programs, talked to my peers about D, kept an eye on development... And then nothing, it never picked up as I hoped it would. Use of D is still very annecdotal. It seems to me that the window of opportunity for D has closed. I'd be happy to be proved wrong.

Debian, Rust, and librsvg

nix — Tue, 20 Nov 2018 11:57:39 +0000

Yes, but you don't have to do it when they come out: you can do it when you run into something that needs the latest version, and build the intermediate versions only for the sake of building the next in the chain (and then throw them away again). No need to ship, validate etc every version in turn.

Debian, Rust, and librsvg

renox — Tue, 20 Nov 2018 09:15:24 +0000

> D has been struggling to gain popularity for 16 years, and *its gcc frontend looks like a desperate attempt to buck the trend*

You'd better be careful about what you write, this part of your comment is both very mean and very stupid..
It's very likely that D's gcc frontend exist because there are some people who like D and who like gcc also so they/he wanted to integrate D's frontend into gcc, nothing "desperate" about this.

Debian, Rust, and librsvg

Jonno — Tue, 20 Nov 2018 09:01:01 +0000

> So one’s expected to port Every. Single. Ever. Released. version of rust to a new CPU architecture, when one comes along, in order to get it bootstrapped?

Of course not, rust support cross-compilation perfectly well!

Sure, that means that if you want to re-verify the chain of trust from scratch you are going to need two computers (one of each arch), but that is a comparatively minor inconvenience...

Debian, Rust, and librsvg

mirabilos — Tue, 20 Nov 2018 06:02:31 +0000

This just causes more fragmentation. It’s also hard to get those separate branches packaged. We, in Debian, really want to have *one* source tree for a package, that is used on all architectures. (Reminds me to kick that one maintainer whose packages regularily FTBFS on some architectures because some of the patch files are applied only conditionally…)

Debian, Rust, and librsvg

mirabilos — Tue, 20 Nov 2018 05:57:28 +0000

And, more importantly than “from decades ago”, is “simple enough to port quickly to new architectures”.

Debian, Rust, and librsvg

mirabilos — Tue, 20 Nov 2018 05:56:04 +0000

So one’s expected to port Every. Single. Ever. Released. version of rust to a new CPU architecture, when one comes along, in order to get it bootstrapped?

That sounds ridiculous.

Debian, Rust, and librsvg

roc — Mon, 19 Nov 2018 21:27:05 +0000

What about those of us who aren't "professional, enterprise shops" and just want to make software available in a way that every Linux user, even Fedora users, can easily consume? And though this approach creates a pile of ongoing work for the software vendor, it also brings back the issue of whether you trust the application vendor to choose good versions of dependent libraries and keep them up to date.

The Rust approach --- modern dependency management with a global library repository and static linking --- is far more appealing to developers than "set up your own package repository for every distro your users care about".

At some point it may be worth extending crates.io with labels for trusted library versions. Even then it will still be a far more efficient and practical system for managing dependencies than anything C/C++ have to offer.

Debian, Rust, and librsvg

moltonel — Mon, 19 Nov 2018 20:56:20 +0000

> How is it bullshit? Multiple languages do that. Go, D, Java, Pascal, C/C++, Python, Fortran and so on all have multiple implementations and have standardized their language. But, of course, all these languages designers are wrong and only the Rust way is the proper way to do it.

I know you were relying to an aggressive comment, but please don't spread the idea that the Rust community doesn't want independent implementations or claims that the current Rust way is the only proper one. There's a difference between saying "it would never get as good as the main implementation / it's not worth the effort right now / for the portability usecase it'd be better to port llvm" (which all seem true to me) and refusing an alternate implementation when it comes up (which I would find silly). If anything, mrustc is a counter-example (though it's not clear whether the intended usecase is portability, or trusting trust, of standardisation or...).

All the languages you mention arrived at multiple implems via different routes. C/C++/Fortran/pascal are (were) simple enough that writing a compiler is (was) easy, they were often a new platform's first language, and they got half a century (!) to get there. Java alternate implems endured legal hurdles despite the original implementor's "write one run anywhere" hype. Python implems constantly lag behind the mainline, and many were abandoned because of this. D has been struggling to gain popularity for 16 years, and its gcc frontend looks like a desperate attempt to buck the trend. Go has a huge corporation developing and lobbying it, which can easily absorb the cost of a gcc frontend (plus, like D, Go has been designed to be easy to implement).

It seems likely that Rust too will get good alternate implementation(s) someday, from mrustc or somewhere else. But these things take a lot of time (unless you're a huge corporation and are happy to cut corners in your language). And for now, it's just not a priority for Rust. The Rust community is very good at focusing on short- and long-term targets. Its RFC process is really good, and it is better defined than many "standardized" languages. When the pace of new features has slowed down and it is time for an alternate implem, it'll happen. We might have a few more years debating whether "the year of the need for an alternate rust implem" has arrived or not ;)

Debian, Rust, and librsvg

jccleaver — Mon, 19 Nov 2018 18:46:15 +0000

> Unlike vendoring, you need an extra server-side repository that has to be replicated *per distro* and probably per major version. This has to be built, tested and maintained as all distros evolve. No thanks.

That's... not very difficult. Plenty of vendors do exactly that, for any repos that they support. Yes, this is why Fedora's 6 month releases aren't supported, but if you're a professional, enterprise shop the ability to do this against stable targets is pretty trivial. If you're building one or more RPMs already for your own software, separating bundled libraries into their own RPMs too is not difficult, and is certainly a good practice.

Debian, Rust, and librsvg

jccleaver — Mon, 19 Nov 2018 18:32:16 +0000

> It's been roughly 15 years since I stopped using Debian because of a dependency hell worse than i'd ever experienced on windows

What dependency hell was that? As long as you're using a repo-based dependency resolver and aren't trying to install things from different major releases of the OS (without recompiling) you really shouldn't be running into that. yum and apt-get and the like have been around for... well, I guess about 15 years now.

Have you been back recently? We're a long way from manually searching for .deb's or browsing rpmfind.net

Debian, Rust, and librsvg

jccleaver — Mon, 19 Nov 2018 18:28:13 +0000

> > This is the biggest BS i've read all day.
> How is it bullshit? Multiple languages do that. Go, D, Java, Pascal, C/C++, Python, Fortran and so on all have multiple implementations and have standardized their language. But, of course, all these languages designers are wrong and only the Rust way is the proper way to do it.

Interestingly, even perl has gone this route. The perl5 binary remains the language specification for perl v5, but perl6 has an independent specification and has actually had several different implementations over the years.

Debian, Rust, and librsvg

epa — Mon, 19 Nov 2018 15:39:20 +0000

I was kind of assuming you'd build your binary per distro and version anyway. But if you have the same binary over multiple versions of the same distro, or over multiple distros, then you could have the same repository for them too. (Though the distros make this needlessly hard by using different names for the same packages, so a package listing dependencies for Fedora often won't work on SuSE, even if the binary itself would.)

I mentioned this way because I think it's what Adobe did for packaging acroread. Though it seems they have now given up on Linux altogether.

Debian, Rust, and librsvg

mstone_ — Mon, 19 Nov 2018 14:58:20 +0000

systemd is not what killed kfreebsd.

Debian, Rust, and librsvg

dgm — Mon, 19 Nov 2018 14:15:58 +0000

> My understanding is that both Rust and Cargo only require the previous stable version at most, and should never have dependency loops between their latest versions.

Doesn't that imply that you (potentially) have to build each and every version in succession to get the latest one?

Debian, Rust, and librsvg

peter-b — Mon, 19 Nov 2018 12:07:07 +0000

> I think the good solution is to make more (all) arch support rust

I agree. Who is going to do the work?

Debian, Rust, and librsvg

nix — Sun, 18 Nov 2018 23:51:08 +0000

The OS critical components are not likely to depend on any particularly recent Rust compiler version. The latest released Firefox is happy with Rust 1.28, which is two releases old now. So you only need to upgrade Rust occasionally, in bursts, when its deps require it. (Note that it is only recently that FF came to depend on anything so recent: only one release ago it depended on 1.24.)

Debian, Rust, and librsvg

mjg59 — Sun, 18 Nov 2018 23:13:17 +0000

I know how to add a package to Debian. I'm asking how to add a package to the current stable version of Debian in a way that ensures that it receives security updates. The backports process doesn't ensure this, and also restricts updates to versions that are available in testing - ie, if a dependency in unstable is blocked from testing for any reason, I'm not able to update the version in backports. Worse, backports policy is to only permit packages if there's established demand for them - if I have a new package, it's hard to demonstrate that.

Debian, Rust, and librsvg

Yui — Sun, 18 Nov 2018 22:09:01 +0000

Also if you are going to publish libraries in a vendor repository then make sure that they do not conflict with libraries in distro repositories. This means you need to use a different name for them and install them in a different path.

Debian, Rust, and librsvg

Yui — Sun, 18 Nov 2018 22:06:00 +0000

Vendor specific repositories should never be preferred over the distro repositories for security and compatibility reasons. Sure it gives you greater flexibility to publish new versions but if your software is either that unstable or has that much of its important functionality implemented that it would be necessary then then maybe there are more important things to do than worry about the delivery.

Debian, Rust, and librsvg

roc — Sun, 18 Nov 2018 21:22:57 +0000

Also, this can't solve the problem for applications that want to deploy on platforms where there isn't library package management, whereas vendoring does solve that.

Debian, Rust, and librsvg

roc — Sun, 18 Nov 2018 21:22:08 +0000

That has all the disadvantages of vendoring the library, as far as I can tell, and some additional disadvantages.

Like vendoring, you have to do a bunch of ongoing work to import the libraries and track their evolution.

Unlike vendoring, you need an extra server-side repository that has to be replicated *per distro* and probably per major version. This has to be built, tested and maintained as all distros evolve. No thanks.

Debian, Rust, and librsvg

roc — Sun, 18 Nov 2018 21:13:53 +0000

Where are the maintainers going to come from for all these application packages and the libraries they depend on that aren't already packaged, for each distribution? There isn't infinite volunteer bandwidth to package for every single project that any user might ever want to install. If the application developer(s) themselves have to be the packager for each distribution, then you've made "get your application in the distribution repositories" much more work than any other option for dependency management. You've also put trust decisions in the hands of the very people you didn't trust in the first place.

An application might not be packageable for policy reasons, because the distro isn't accepting new packages or the application is closed-source.

For platforms that don't have library package management (i.e. everything except Linux distros), "get your application in the distribution repositories" doesn't help at all with library dependency management, so developers need a separate solution for Windows/Mac/iOS/Android (usually "vendor the libraries"). Once you've vendored the libraries you may as well use them on all platforms.

Compared to the problems of C/C++ dependency management, fixing whatever security issues cargo has is easy.

Debian, Rust, and librsvg

epa — Sun, 18 Nov 2018 20:24:48 +0000

There is a fourth option — package the dependency yourself as an rpm, deb, or whatever, and publish it alongside your application in a small repository you maintain. So rather than telling users ‘download this file and install it with rpm’ you ask them to add your package repository to their system (also telling them your GPG key signature, should they want to check that) and then they use ‘dnf’, ‘apt’, ‘yum’ and so on to install the application, with dependencies pulled down as needed.

This also has the advantage that you can publish new versions in your repository, and provided they are correctly signed, the system’s normal package management tools will prompt to install the upgrade.

Debian, Rust, and librsvg

hsivonen — Sun, 18 Nov 2018 17:53:44 +0000

> No one is saying that a distro should ban a specific programming language.

For all practical purposes, the OP is complaining about an upstream package adopting a particular programming language (and the new version getting imported into Debian) despite it being supported on all Debian "release" platforms.

> especially if those dependencies are only available for a very limited number of architectures.

"very limited number of architectures" is not a fair characterization of the situation. Upstream lists Rust ports for 20 different architecture targets for glibc Linux. Even if you remove targets that are ISA supersets of other targets (i.e. collapse various 32-bit ARM flavors, collapse 32-bit x86 with and without SSE2) but still count 32-bit and 64-bit flavors separately, the count is still around 16, give or take one, depending on what exactly you consider a superset.

Just because a specific ISA that the OP cares about isn't supported does not mean that Rust isn't "portable" or is only available to a "very limited number of architectures".

Debian, Rust, and librsvg

mpr22 — Sun, 18 Nov 2018 16:31:23 +0000

It seems to me that the point Matthew seems to be making has eluded you.

Debian stretch is the current Debian stable.

New packages are basically never accepted into Debian stable. (It is possible to imagine some exotic scenarios where they might be, but I imagine them being along the lines of "upstream for package Q currently in Debian stable has fixed a critical security vulnerability by a method involving the use of package P not currently available in stable and the Debian maintainers of Q do not have the labour resource available to develop their own fix".)

If you care enough to ensure that your program will work with 2- to 4-year-old versions of its dynamic library dependencies so that you don't have to drag in eleventy-one updated library versions that might actually break a stable system because the SONAME has been bumped, then once you've got it into unstable you can get it into the -backports repo for stable or possibly even oldstable - but that's officially not part of Debian.

Debian, Rust, and librsvg

Yui — Sun, 18 Nov 2018 15:00:02 +0000

Why wouldn't it be?

Debian, Rust, and librsvg

Yui — Sun, 18 Nov 2018 14:59:27 +0000

https://www.debian.org/doc/manuals/maint-guide/index.en.html

This is probably a reasonable starting point.

Debian, Rust, and librsvg

Yui — Sun, 18 Nov 2018 14:57:52 +0000

>If you position distros as application distribution channels from the developer perspective

It's the best application distribution channel from both developer and user perspective. There isn't a more secure or convenient way of installing software.

>why should it be OK for a distro to block Rust?

No one is saying that a distro should ban a specific programming language. It would be beneficial for all if such system level components didn't add new dependencies, especially if those dependencies are only available for a very limited number of architectures.

Debian, Rust, and librsvg

mjg59 — Sun, 18 Nov 2018 10:51:45 +0000

How do I get my application in the repositories for Debian Stretch?

Debian, Rust, and librsvg

hsivonen — Sun, 18 Nov 2018 10:33:06 +0000

As the post you are replying to points out, GCC has intentionally been designed, for licensing strategy reasons, not to support some technically reasonable things. Adding a GCC capability to ingest LLVM IR would circumvent the licensing strategy, so it's unlikely that such a capability would be accepted in the upstream GCC unless the licensing strategy is first revised. (The existence of LLMV pretty much foils strategy's fundamental assumption in the context of ISAs that are still in chip production.)

Debian, Rust, and librsvg

roblucid — Sun, 18 Nov 2018 10:27:16 +0000

I have built GCC in past without GCC.
A phase of the compiler build, created a GCC subset, that could then bootstrap the full compiler.
If you didn't have a C working on target, then cross compiling was another possibility. GCC was used on Sun h/w to build code for telephone exchanges for example, unsuitable to run a compiler natively.

Debian, Rust, and librsvg

roc — Sun, 18 Nov 2018 10:19:41 +0000

Surely you can see why that is no "solution" at all for most projects.