Fundraising campaign for Slackware 15.0
 

Dear Slackers,

What do you think about a fundraising campaign for Slackware 15.0?
Is anybody aware of a tool (or a website) for such a campaign?

IMHO
Donators should have an opportunity to select their most wanted feature.
Mine would be: Reproduceable builds

Regards

Please do not collect money on my behalf without my approval. Thanks.

that is an ideology that takes away the freedom of the developer.

Since you asked, "Uggghhh...".

Unless announced, initiated and controlled by Patrick Volkerding, I would personally consider it just another internet scam.

Patrick will let us know when he decides to change the way we support his work. Apparently, he wants to provide some available options and not others, for his own reasons - let's respect that and go with what he provides.

Remember, Slackware is Patrick Volkerding's baby, not a child raised in a dememnted... err... democratic village. That is what makes it special - including the business model... respect it.


It would be very difficult to improve on Slackbuild scripts! How is that not reproducible?

Thank you! I respect Patrick. He will let us know how he wants to receive support for his work. I will continue to make donations to his paypal account.

This exists already, donate to PV's paypal account, or mail him a check. Support fellow users here on LQ in the Slackware sub forum. Participate in ##slackware irc, run -current and help squash bugs etc... All of those things will help to ensure a healthy future for Slackware.

Because its not a .deb or .rpm ... :doh::banghead: LOL

I know there are some people in software development that need, or think they need the very latest in just about everything. I know there are lots more that are just in the habit of a nearly constant upgrade cycle. Just FTR, while I do look forward to Slackware 15, I'm in no rush. There is nothing pressing that I want to do that I cannot do myself as I need it. The payoff of a new full release is that it all works smoothly together and has a consistency among many making any problems and solutions easy to explain and resolve. In that regard I think it is one of the reasons Slackware is not like all those "committee" releases, it has a singular vision but one meant to allow maximum flexibility. It is a very noble and difficult pursuit and I afford Patrick all the time he ever may need to "prepare the feast". My patience, and his, have always paid off. Slackware is simply elegant and the best there is IMHO. It is worth waiting for. I doubt Carrots nor Whips will make it happen any sooner.

Ah, but you can get that for no money now! (Which doesn't mean that you can't throw some ducats Mr. Volkerding's way.) The wonderful people in this thread are doing that to scratch their own itches.

I don't like Patreon et al, but why not set up a Patreon?
After all, PayPal is kinda shitty, too.

Let's be inventive!

Everybody asks for money to implement features...

How about a fundraising campaign for Slackware to NOT adopt certain features?

For example, I think will be worth to see the big-mouths around here who yell against systemd, how much money will they willing to put where their big mouth is.

How about we leave Patrick alone to do his job and donate meanwhile to the PayPal link he provided?

I agree Patrick is the man and has the final say on how/if he would like donations. Still I think Screamer’s intentions were admirable. I don’t know if it’s a good idea to use donations to influence Slackware’s make up. But again that would be Patrick’s call.

To me such fundraising campaigns (for/against a feature) seem like hand-twisting. I naively think that donations should simply help Slackware, not influence its path of development.

PP: I do not mean to sound harsh to anyone, I am sure you guys had good intentions :)

This is very right, I have seen really terrible features proposed and not rejected for other projects because they were submitted as a paid bounty.

Thanks for your reply.

I believe, good work deserves good money.
In my opinion, Slackware is the best Linux distribution out there.

Of course, it's up to you.


1st execution:
2nd execution:
The checksums of the created binary packages differ.

The reason for "reproducible builds" is to establish trust in open source.

How can you easily verify that a provided binary package was created by compiling the given source code?


I already donated to his paypal account.

And yes, I'm willing to pay for certain features - maybe somebody else too.

I had a look at https://wiki.debian.org/ReproducibleBuilds.

Even with a huge infrastructure and a lot of work they are not yet there.

Maybe I'm pessimistic, but I don't see that easily feasible in Slackware, if at all.

It could be done, but IMHO it is not worth that much trouble to soothe people who are paranoid that my binaries are backdoored. Plus, I don't like the way the requirements for a reproducible build change the timestamps on files to make sure that nothing is different from one build to the next. I find the timestamps to be useful information about when binaries were compiled and when documentation was last updated.

Maybe that money could be better used to fund a fork instead of hand-twisting - paid for features aren't going to be universally trusted. After all, one person's really cool improvement is another's motivation to download and install a BSD.

By examining the checksums of the contents of the package. The builder would have to provide a signed copy of the checksum listing for each package. For Slackware to provide such, a copy MANIFEST.bz2 that was signed by Mr. Volkerding's private key that also contained the sha1 or better hash of each file as well as the current information that's in there should suffice.

That assumes that any compiler or linker used assembles the final file(s) in the exact same fashion; if those tools cannot make that guarantee, then you fall back on trust, which is a human concept.

The slackware-from-scratch project allows you to build your own packages, assuming that you trust your own environment.

Frankly, that's what worries me the most and I do not see/have a solution based on the off-the-shelf consumer-grade technology, other than independent isolated secure environments comparing the results, thus, perfect reproducible builds should be achieved first.

Well, a difference that makes no difference is no difference (a phrase I've picked up somewhere in my worldly wanderings).

An example would be two files, one containing
the other containing
They both contain the same information and perform the same function (mainly leading the reader to think I'm an idiot), but they aren't exactly equal since the byte sequence of the text is different. This shows up as well in source code diff programs, where blocks of code move around in ways that don't mean squat to the compiler but the programmers end up examining the change in code reviews because a simple diff will tell you that it was deleted in one place and added in another.

So, in an ideal world, you wouldn't aim for "I can get a blob with the exact same checksum if I build it twice"; you'd aim for "I can get a blob that is functionally the same if I build it twice". That requires the thing doing the comparison to know what is semantically important to compare.

I think that's a toss-up in difficulty to hammering tools to generate the exact same output with the exact same file input independent of the hardware that is running the tool. Maybe not; maybe all the tools would have to do is ensure a stable processing order of the input files and that would be it.

But this is pretty off topic, so we should consider moving further discussion (after any rebuttals, since I'm not aiming to get the last word) to a new thread.

Reproducible for what purpose? As you said, there'd need to be an authoritative list of the "originals" so that you could compare whether what you'd reproduced was identical.
However, given that Slackware-current doesn't operate a snapshot model (you'd have to build your own, but for what purpose?), a package built even only days or weeks ago, would most likely not be the same due to evolving ecosystem in which it lives. If there was a snapshot model, one could (as is mentioned already) set up a chroot setup like Debian and Fedora do, and install the specific versions of packages; but then for what purpose? If you're maintaining a specific build for your own project, and have tested everything to the nth degree, then definitely you want to leave things as they are. For example, I used to work at a Digital Asset Management company that built image asset management software, which used ImageMagick among other things. A rebuild (Same version) of IM for a security fix ended up messing up the colours of the images so we had to revert it!
But if you're in that space, you're on your own anyway.

Having the same checksums doesn't make any sense to me - it's not important. The part that's interesting and important is that the package is linked to the same libraries each time, and has the same functionality as it did previously (unless it's configured not to, of course). That's a concern for the distributor where the package is being re-built at a later date, and built on on other architectures.

I think we should look at the coders and make sure that they can type out the same lines of code again, to make sure it was really they who did it!! ;-)

Perhaps reproducibility has more value in a low trust environment where reputation can't be relied upon -- such as a community distro where there are hundreds of maintainers, and a high degree of maintainer churn.

That's not a problem we have here. As long as the packages are signed by Pat in order to allow us to check that they were not meddled with in transit, we're golden.

That is one of the weirder* things I have heard lately. Bascially, you are proposing that Patrick blackmails his clients: "Give money or I'll put systemd in it". I sincerely hope it does not come to that.

*this as a very strong euphemism

@Richard Cranium
The source code (package) is usually signed, I wouldn't worry about that.
@drmozes
See above.
@GazL
It's not about reputation / human trust, but the pretty impossible to achieve security of the working environment.
A recent article about tech (blockchains) & trust:
https://www.schneier.com/blog/archiv...hain_and_.html

A SW building & distribution source (like in case of a distro), that servers many users is always a target worth taking into consideration for different interest groups with different (mainly lucrative on this level) scopes.
I'm not that much of an "absolutist" about computer security, but always (especially these days), start with the premise that I cannot trust the system(s) 100%. And I do have some knowledge&experience(I've seen enough, failed myself too on a few occasions) in the security field.
I mentioned the consumer-grade crap you can get off-the-shelf, that you cannot really secure and you can observe that the "big players" with their industrial-corporate level systems are increasingly making use of specialized security tech:
https://www.zdnet.com/article/google...rity-features/
https://www.sdxcentral.com/articles/...urity/2018/04/
https://www.cisco.com/c/dam/en_us/ab...-45-734230.pdf

And, I'd like to add, that the computer systems security(cybersecurity), while a big theme these days, mainly marketing, is not really offering you too much, nor anyone else cares about your broken systems, like insurance companies for instance:
https://www.schneier.com/blog/archiv...nsurance_.html
https://www.schneier.com/blog/archiv...urity_i_2.html
So you're pretty much left on your own...

heh...

Pity that you quoted that text. I have exactly one person on my blacklist here at LQ, just to be sure that I don't have to see blabber like that.

Sorry, that was not my intention. I quoted only for context and not to maximize exposure of nonsense in aforementioned thread :). Maybe you can make a feature request to Jeremy in the feedback forum to not show blacklisted members in quotes? Not sure if this can be easily coded, but it would make sense to extend the blacklist behaviour this way.

The fashion of reproducible builds gives me the bouts of paranoia and the creeps. It is that Charlie Brown character that carries a blanket around for comfort. It is a problem of what is supposed to be finite machine acting as a ouija board; wink wink Intel, at the most fundamental level.

This is a suggestion, hopefully it will spark some ideas in the right people. I do not have the time, and pretty sure not the skills for this. Maybe the idea will morph into something better. :-)

How about a USB key, but a unique system. Say 64 GB. One that is live, like Alien Bob' s LiveSlack. Just a vanilla full install of Slackware 15 with an encrypted root and encrypted persistent storage. Off the top of my head the encrypted persistence may have to be done when the user first boots into the Live. Another partition, FAT32 unencrypted with a mirror of Slackware 15 that is synced with mirrors when booted into the live mode.

A nice little case with Slackware artwork. Something that is collectable like CDs were, yet also practical and something people will use everyday. A little vain thing that will give people a little more incentive to financially help PV.

I forget to mention the normal tried and true install/rescue system would also be as it is now. Boot into a desktop you choose for live workstation mode. Then you have a live system, an install/rescue, and a portable mirror, all in one.

Just send money I think. No need to ask for permission.

Reproducible builds are an interesting idea, but it's way too "nichey" for Slackware IMHO. Biggest priority from the community should just be to ensure Pat receives sufficient donations to earn a decent living for the work he does and to keep the lights on.

It would be easy to prove that packages do not contain any backdoor.
Mainly, I'm thinking about repositories that provide binary packages.
For instance, SlackOnly provides binary packages built from SlackBuilds.org build scripts.

What do you think about the following approach?
In my opinion, you do not lose any information at all.