@alcinnz This _really_ resonated for me: “Software must be made understandable. The essence of FOSS for me can be reduced to one fundamental computing right: the right to refuse to run, on my machines, code that I do not have the option to understand. That is it.”. Thanks for sharing :)

@brad @alcinnz also this:

"I'm not fundamentally opposed to closed source software, so as long as it runs on someone else's computer."

@Coffee @brad I'm starting to think I should reread that again...

I've said similar in the past...

@brad @alcinnz
Exactly!! But there are a lot of NERDs - though indispensable for the developmetn of FOSSes - who have serious problems to communicate with non-NERDs.

@alcinnz I think the problem is everyone’s used to “distros.” Nobody touches actual source code anymore. Most Linux users are as closed source as Microsoft, and the only difference is they downloaded their binary packages from their distro, who pinkie-sweared that it was compiled from this source code over here that no one looks at or uses anymore.

And that allows awful incomprehensible, sabatoged design in projects like Firefox or Chromium, and nobody even knows about it, because they never had to compile anything themselves.

@cy In the case of Chromium or Firefox I think there's another issue, which goes beyond "distros" (though I do like the idea of source distros which compiles the code on *your* computer)...

But then you're talking to someone who tried to study that code and got driven mad enough to try and reimplement it in interesting new ways...

@alcinnz

In the case of Chromium or Firefox I think there’s another issue, which goes beyond “distros”

Awful incomprehensible, sabatoged design?

I do like the idea of source distros which compiles the code on your computer

It’s a good way to find out which software has been made f-ing impossible to compile, at least.

@cy Awful incomprehensible, sabatoged design not so much of those projects themselves, but of the main protocols our society currently uses to communicate! We're being expected to run code this convoluted!

With webdevelopers celebrating every new JavaScript API, blissfully ignorant of the cost.

WebKit at least remains *somewhat* comprehensible despite what it's implementing...

@cy @alcinnz yeah i dont consider gecko or webkit/webengine/blink and any of their derivitave works to be truly foss in spirit. one of those things i talk about enough to the point where i should write a blog post about it

@cy @alcinnz
> I do like the idea of source distros which compiles the code on your computer

That is not very effective. wiki.debian.org/ReproducibleBu is more ambitious and far reaching.

@federico3 @alcinnz @cy Source distros that *allow* you to compile the code on your computer, but also allow you to download binaries from a cache, *and validate that that cache contains accurate and reproducible output*, is a great compromise.

Talking about Guix and Nix here, of course.

@clacke @federico3 @alcinnz Honestly I like APT better than Nix. apt and rpm have “src” packages for each package, which can in theory all be compiled. But those packages are not distributed as one big monolithic git repo of all packages. So they’re a lot easier to uh… download, on a per-package basis. Can be a real issue if you have my stupid craptop with its 80GB hard disk, or bandwidth constraints such that downloading 20 gigabytes is infeasible.

@cy @clacke @alcinnz @federico3 nixpkgs is ~1.5 GB. It does not contain all the sources for the packages like in debian's repos, just hashes of them.

@fgaz @alcinnz @clacke @federico3 Oh, sorry I didn’t realize. Is that amount including all the change history?

@cy
Yes, I think so.

By the way, using nix you can get the source of a package (for example, emacs) by doing

nix-build '<nixpkgs>' -A emacs.src
@alcinnz @clacke @federico3 @fgaz

@cy @alcinnz @clacke @federico3 yes, without the history it's like 1/10th of that

@federico3 @alcinnz

https://wiki.debian.org/ReproducibleBuilds is more ambitious and far reaching.

That depends. Making compilation reproducible requires that you discard certain optimizations and security features. It’s possible you could take a reproducible build and further optimize it for each computer, but good luck making that less expensive than just recompiling the source. If your computer has a common architecture and you don’t need optimization, then reproducible builds are okay.

Reproducible builds eliminate anyone who can check the source but can’t figure out how to compile it, but that should be a pretty small intersection except for source code deliberately made impossible to compile. Only other problem is if you use someone else’s build, and that someone decides to start “supporting” systemd for instance, you don’t really have much of a choice about it.

Anyway, I think they’re a grey area. Possible to verify but only for people who can compile them. Allows for impossible to compile source to sneak under the radar, and harder to customize for your needs. But not terrible.

@cy not everything needs to be a reproducible build. only the security hot path needs to be.

@federico3 @alcinnz

@icedquinn @alcinnz @federico3 Or you could just use open source in everything, and not risk someone taking the heightened privileges you thought were no big deal and finding a way to escalate them.

@cy @alcinnz @federico3 reproducible builds are about combatting thompson's "trusting trust" attack.

the threat model is that your copy of gcc (which you need a copy of gcc to get more copies of gcc) is compromised and puts backdoors in your code. thereby using open source does literally nothing, because the compiler is compromised to continue compromising itself in the binary as it processes the source.

it's about ensuring the open source you are using is actually the code you put in.

@icedquinn @alcinnz @federico3 Ah, yeah that “Thompson’s” fearmongering. Well if you even need to bother worrying about it, reproducible builds do not combat that at all, because if you can compare the hashes of your reproducible builds, then you can compare the hashes of your compilers to make sure they’re the same before building anything.

@cy @alcinnz @federico3 part of reproducible build infrastructure is indeed checking hashes of the shit that goes in to software?

@icedquinn @alcinnz @federico3 Reproducible builds are convenient, but they don’t defend against mystical computer conquering quines any more than checking your compiler’s hash.

@cy @alcinnz
> Making compilation reproducible requires that you discard certain optimizations and security features.

No. Reproducible builds are meant to be run across many architectures, platform and be cross-verified by multiple organizations (e.g. distros) in order to 99.9% of the use cases. The few users that have a real need to recompile few of their binaries locally are still free to do that. But they still benefit in terms of security, legal compliance, ease of maintenance...

@federico3 @alcinnz Uh… yes? I didn’t say the optimization was significant or needed by all, just that it exists. And reproducible builds do not increase security in the slightest at all even one tiny titch more than compiling their source. Ease of maintenance is great, until everyone starts using builds that are impossible to compile and telling you “what’s the problem? If you are such a scaredy pants just compile it!”

There are no legal threats to using source code in existence that do not also apply to reproducible builds.

@cy @alcinnz @federico3 If you can't figure out how to compile it, it's not reproducible. On the distros I'm aware of that work actively on reproducibility, all builds are trivial to run:

sudo apt-get build-dep $PACKAGE; apt-get -b source $PACKAGE

nix-build '<nixpkgs>' -A thePackage

guix build somethingsomething # it's been a while 😀

Nix and Guix will pull a binary by default, but you can just add a parameter saying you don't want that, and both have a parameter telling them to build locally *and* pull the binary and tell you if there's a diff. Currently something like 95% of packages build reproducibly, possibly more as I haven't checked in a few months.

@clacke @alcinnz @federico3 @cy
Reproducibility doesn't help much against Firefox's complexity.
Source: i just had to debug a crash in IceCat that caused my old browser profile to not load.
Also, IceCat routinely breaks on Guix and so do plenty of (/all?) other browser engines.

I'm pretty sure the package is reproducible, but understanding and modifying it is just so goddamn hard, and needlessly so. Like, all you need for reproducibility is to make your "build" function pure. But a pure function can still be arbitrarily complex and it can still be applied to arbitrarily complex data (here: source code).

@grainloom @alcinnz @federico3 @cy I think it's fair to say that if we accept the GPLv3's definition that source code is "the preferred form of the work for making modifications to it", above a certain complexity, intrinsic or incidental, it is unclear if there is any source code at all.

@clacke @alcinnz @federico3 @cy Well, it's still the preferred form, it just tries to do way too many things, so even the best and most preferred form is not very good.

@cy @alcinnz

and the only difference is they downloaded their binary packages from their distro

That’s a big difference! Distros have the user’s interests in mind and can –for example– patch out or refuse to package harmful code.

who pinkie-sweared that it was compiled from this source code over here

In many distros this is actually verifiable by the user. Packages aren’t some black box binary blob, but actual descriptions of how to build them in the context of that specific distro.

@alcinnz

@fgaz @alcinnz I don’t know anyone who uses the source packages for Firefox or Rust.

That’s a big difference! Distros have the user’s interests in mind and can –for example– patch out or refuse to package harmful code.

Just because someone puts on a hemp skirt and sings kumbaya doesn’t mean they have your interests in mind. Anyway multiple independent people can verify the source code to be harmful or not. Only the one who compiled it can verify a binary. “reproducible binaries” being a sort of grey area there.

@cy @alcinnz @fgaz but if you you don't trust on vendor, you can always go to another. At some point you have to trust someone, but if there are alternatives it's not as bad. Not perfect, but definitely not as bad as with propriety software.

The implicit argument that precompiled binaries are somehow just as bad as closed source software is a bit misleading in my opinion

@loke @alcinnz @fgaz Sorry, I didn’t mean to imply that precompiled binaries were as bad as closed source. A binary can (generally) only be verified by the vendor who compiles it, but it is at least possible to verify it, if you really do trust the vendor. Compilers of closed source software claim that it would be disastrous for them if you ever learned what their binary really does, and how could anyone trust a vendor claiming that?

@alcinnz thank you for resurfacing this article. I've been looking for it for a long time.

@alcinnz IMHO this article draws all the wrong conclusions from this story.

Stuff like leafpad and event-stream are cultural and infrastructure problems, and demonstrate that big libraries with multiple independent maintainers are better than every rando and their sentient keyboard being allowed to upload packages to the newest CPAN out there.

Everybody's got the right to publish whatever, but package managers should keep the gates a bit.

@alcinnz We can't really avoid trusting authors and packagers. Any operating system that's useful is inevitably running millions of lines of code, and even govt orgs would have a hard time auditing stuff.

The simpler, understandable argument doesn't really hold water. There's inherent complexity to what we need from computers and while code can be made simpler, the task of deep auditing by users remains unachievable, and wasteful.

@alcinnz The essence of the problem the article talks about is who do we trust and how much.

When you're grabbing code from some random Github repo you read it. We've grown to expect more than that from tools like npm or pypa, but they are essentially the same and we should learn that.

People trust some little module published a few months ago as much as they trust boost or Django. We should learn that that's wrong and teach about this.

@alcinnz IDK how CS depts. &c do it but they should have one big course on the topic.

Teach FOSS (both use and maintenance). teach netiquette, teach why we should trust Debian more than Ubuntu, Ubuntu more than pypa, pypa more than npm, and npm more than (?).

@cadadr @alcinnz no please not another BA module.

I already take CS344 and that is aids. Learning about agile, no more soft science stuff - please.

@cadadr In my experience they totally ignore the question of what code's safe to reuse (which seems to be a massive oversight to me...), whilst Free Software has a warranted a couple days discussion from them.

@alcinnz Sad, when most programmers' job is to find best libraries---most (F)OSS---, customise, and add some epoxy.

@cadadr @alcinnz the problem with teaching this is that it's not science and not factual. So whose point of view do we choose for a curriculum? Just in your toot, for example, I find the notion of trusting Debian more than Ubuntu pretty puzzling. And I've been doing open source for about 15 years. I certainly don't want things like that to be taught as if it's something uncontroversial.

@isagalaev @alcinnz You'd rather teach the mechanics, students ofc could figure out who to trust for themselves. They'd know the history of FOSS and its tooling, and what methods are present, and how they differ.

A *lot* of scientific "facts" are pretty controversial in their own disciplines. If we only taught uncontested facts, you'd hardly make a semester out of it.

@cadadr @alcinnz tooling and history is very different from netiquette and trust which you were talking about. I have no problem with the former. My problem starts when FOSS people start subtly introducing ideology into technical topics.

@isagalaev @alcinnz It's true that netiquette and trust models exist in variety and are tied to certain ideologies.

They can be introduced just like tooling, in their variety, without preference. Teach why some people insist on 80 char lines, why some oppose, why the distinction exists, for example.

Endorsement of "ideology" may be minimised but eventually nothing is free of it. Even avoiding it itself is an ideology, and by adopting it you're transmitting it to your students.

@isagalaev @alcinnz Software development is a social endeavour, FOSS even more so.

Universities can teach young programmers the variety of methods, ideologies, stances, traditions that they'll inevitably encounter the minute they do _anything_ with software. The minute you step into this world, you're bombarded with all of it and apparently students are graduating with no preparation for it whatsoever.

@isagalaev @alcinnz But ultimately this is history of the field and the currents of the field.

They'll interact with other coders, in uni, at work, online. These will all have preferences. Our guys will have to make preferences.

And part of programmers job is to know how to make these preferences, professional, academic or hobbyist.

If a programmer doesn't know what's the difference between GPL'd software from GNU and stuff from a company under ISC, they are not well prepared to do their job.

@isagalaev @alcinnz AFAIU in the current shape of things they're having to learn it via trial and error.

But school is the perfect sandbox to learn about these issues.

@cadadr @isagalaev @alcinnz all bang on target. Re: teaching the choices that exist, it may not be just high-level choices. I guess there is barely a mention of modal vs non-modal editing in curricula; coupled with most Linux distro installs only having vi clones and not emacsen, it too amounts to hiding an important tool from potential programmers (whether to RSI the pinky finger or not!).

@cadadr @alcinnz now, all of this is decidedly different from what you proposed in the first toot I replied too :-) And all this is something people have been (deservedly) chastising academia about for years.

@isagalaev @alcinnz Frankly I don't see how they are different. That first toot contained just a random example off the top of my head. Just wanted to put it in more concrete shape so that it's shorter.

I disagree on the chastising bit. Attacking "academia" is a programmers' hobby. Outside of that industries are in a healthy (perhaps a bit too healthy, even) relationship with it, especially STEM. IDK tho, I'm not in CS/CE.

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).