> I always wonder why people bother with providing source under a source available license. [..] There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
There's nothing any UniversalBlue image tweaks that you couldn't tweak yourself. It's just adding/removing packages, adding/removing drivers, a few configuration scripts, and a bunch of tweaks to fix well-known gaming-related issues.
But the point is that, if you want to game on Linux, you probably want to perform exactly or almost exactly the same tweaks that Bazzite already does. So why bother doing them yourself?
It's not even a linux-from-scratch situation where you'd do it for the sake of learning. Googling "my controller doesn't work right", finding some discussion threads, and copy-pasting a bunch of fixes isn't particularly interesting.
Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.
Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?
Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.
(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)
It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version?
Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.
One quick improvement would be to style the number boxes to include decimal separators. For a few answers I was squinting to check if I had typed six or seven zeroes, for example.
Austria has 9 million people. Scaled up in proportion to US population, that's the equivalent of ~940 academics. Still not huge, but a somewhat bigger drop.
What if the bank abstained from evaluating your own stuff, and instead provided you with whatever they consider a 'good' device? Like a powered-up version of the TOTP hardware tokens they used to provide 15 years ago.
Instead of negotiating over what you do with your own devices, when you open a bank account they loan you a small, cheap, ultra-locked-down phone-like device that only runs the bank app and biometric verification. You may still use a web interface for online banking if you want a bigger screen and keyboard, but regardless all transactions need a confirmation through the bank's device.
This way you're free to do whatever you want with your hardware (including even not having one!), without requiring every bank to support every possible platform under the sun.
Umberto Eco once jokingly lamented the deprecation of the Index, writing that it was a "very handy canon of books one ought to read to call oneself an educated person".
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
reply