5,575 karma · joined March 14, 2011
The Gigazone™, MN | Philadelphia, PA
Emailers, you can call me "swilson" at my work domain.
“Results are compared to previous-generation Mac mini systems with Apple M4, 10-core CPU, 10-core GPU, 32GB of unified memory, and 2TB SSD.”
You could get rid of a huge portion of the go standard library and have a massive ecosystem of leftpads, but the fact that `go build` can easily be run in off-line mode and doesn't execute any code other than the go toolchain itself, means you have a fundamentally more trustworthy ecosystem overall.
Rust, on the other hand, might keep you from a subset of buffer overruns, but it will gladly run obfuscated, untrusted code in your name when you wouldn't otherwise expect it to.
As an industry, we need to somehow stop making this mistake.
Charity scams are nothing new.
What is wrong with you?
There’s a massive difference.
Why force git to be a build tool?
Just document how to execute the scripts/checks that will be used by ci. Provide a simple script in the repo that folks can intentionally execute.
Expect to see heavy lobbying from the music and video industry to create some kind of "Know your Customer" regime internet service providers in order to create such a liability.
I wouldn't call this a slam dunk for privacy or liberty, given what it is going to force the various actors to do in response.
For now, though, let the file sharing flow!
At the end of the day though, 501(c)(3) status is a purely US concept, doesn't apply to international organizations internationally, and doesn't necessarily mean that you "can't" do what anyone is discussing here. It just means that folks gonna have to pay taxes and "donations" can't be written off on the taxes of donors.
Perhaps, at the end of the day, not pursuing tax-exemption/charity status is a more honest approach. It certainly doesn't precluding doing any of what has been discussed, it just changes the financial efficiency.
OSS isn't commercial, per se.
Universities "ship" plenty of "products":
I see this more as a way to answer the question of things like the maintainers of OpenSSL or sudo. One approach is to fund the "project" and let it deal with all of these questions. Another approach would be to fund the people themselves. So, have a faculty of expert software maintainers, vetted by the governance structure of the OSE. Within that faculty, you could have "adjuncts" and "residents" who have a time-bound grant and set of obligations. If they are successful and their work continues to be relevant, they could eventually apply for one of a defined set of "tenured" positions. Those positions would guarantee them independence and a stable source of income in order to continue their role as a maintainer.
The goal of this "faculty" would be sustainable OSS maintenance (which involves both leadership and contribution), rather than publishing research and teaching classes. So, similar overall structure and approach, but differing goals.