Distribution usually isn’t considered a strong point for Python, though.
For other languages that build a static executable, the more expected method of distribution would be some automated workflow that builds artifacts for various os/architecture-triplets, that you can then just download off the project page.
Isn’t that just nitpicking?
No, because the definitions are phrased very differently. Software doesn’t have to be copyleft to be considered FOSS either, as is the case with tons of BSD and MIT and whatnot code that’s used in proprietary programs—all they have to do is make it clear that they’re using their software (and even that’s not a given).
Even with copyleft licenses like the GPL, as long as they never distribute their software to anyone they don’t have to offer them the source code either, as with so many backends. The AGPL gives consumers of distributed systems some more rights.
Free software is mostly about providing you rights when you encounter the source code, meaning that you’re allowed to modify it and share it. This is as opposed to stuff like “source available” licenses that permit you to read the source code, but not modify or share it.
Such a license would neither be regarded as free software nor open source.
Some other alternative could be making GPL-3.0-or-later + a Contributor License Agreement a more common option, so that it is possible to tell companies that if they want to use the library in some closed-source application, they need to work out a license deal.
CLAs are frequently involved in turning software proprietary though, so it isn’t exactly held in the highest esteem in the FOSS community.
And without a CLA you essentially get the Linux kernel situation, which will be stuck on GPL2 forever, since they can’t reasonably get everyone to agree to switch to GPL3, especially since some copyright holders are not just unwilling, but unreachable or dead (and in several jurisdictions copyright lasts for decades after death).
Personally I suspect public funding, similar to science, education and libraries, is a more likely option, though that’ll be an uphill political struggle a lot of places.
Yep. I wonder if that CRA compliance stuff won’t change that. Industries with strict demands on safety should be putting in work and resources to ensure that those demands are actually met, but how the CRA deals with FOSS took a bit of work to not be a complete disaster, and I can’t imagine it’s easy for FOSS projects to work out the details there.
As in:
In the case where they don’t want to pitch in, well, something cURL-equivalent but known CRA-compliant won’t just fall off the back of a wagon, which means the companies that need compliance have a problem.
Then again, apparently the HPE Nonstop ecosystem has git available on their platform all through the spare-time efforts of all of one dude, which absolutely shows that critical systems are willing to rely on precarious software, so I’m not gonna hold my breath.
Yeah, it’s once again a case of a central piece of software in a very precarious situation, and businesses that aren’t … quite mindful of the fact that they’re making demands from someone they’re not paying.
Why is this linking to what appears to be another link aggregator, rather than what appears to be the original blog post?
Well, bash should show up quickly enough. But yeah.
I’m also no longer much of a bash guy. Back when I was my scripts were a lot simpler, and broke in weird ways a lot more. And every time I picked up a new defensive habit, my bash became a little bit uglier, and I thought to myself “maybe I should just do this in Python”.
But this script would be a lot longer in Python.
IME I’ll rather find some openapi docs for Google than their actual product docs. As in, I’ll start out trying to read their kubernetes docs, then shortly after it’s “fuck it, I’m going to docs.rs/k8s-openapi”.
My actual worst case are Elastic’s docs, though. Somehow they have plenty of stuff in there, just never the stuff I’m trying to figure out.
For those who want to give it a go:
#!/bin/bash
set -euo pipefail
while read -rd ":" path
do
for bin in "$path"/*
do
# don't error out if there's no manpage
set +e
man "$(basename "$bin")"
set -e
done
done < <(printf '%s%s' "$PATH" ":")
when you get sick of it, hit ^Z (ctrl-z) and go kill %1. Then you get to start all over from the start next time!
Bonus points for starting a tracker so you can count how long it takes to go from “eugh, what’s with that overwrought and excessively defensive bash script” to “fuck, now I’m doing it too”
Humans also frequently need to try a wrong approach first to get the idea of a better approach, no matter if we’re rested or not. Which is why it’s important to be able to throw away prototypes rather than push an “it seemed like a good idea at the time” to prod.
But having a good sleep, walk in a park, shower, etc lets us think better than if we’re just banging our heads in the same corner all day long. Breaks are important. General health, too.
We could probably stand to have some organisation standards in repo roots, but I tend to agree that dotfiles aren’t the way to go there. The project root is similar to ~/.config and the like: When you’re there you should not be subjected to further hidden levels. Those config files are a significant part of the project.
State files however, like all the stuff in .git, lockfiles and the like are generally¹ fine to hide away. Those are side effects of running other tools, not ordinary editable configuration. Same goes for cache—and both cache and runtime files should likely go in the ordinary XDG dirs rather than be something every project has to set up a gitignore for.
If anything I’m more frustrated with the C projects that just plop every source file in the root directory.
¹ Just don’t make it too easy to sneak unexpected crap in there. We don’t need to make the next Jia Tan’s job easier.
There’s wasm if you need to target browsers.
We’ve also recently introduced Coding Challenges to our site! These new challenges represent a new, fun way for developers to level up by tackling captivating puzzles and earning recognition for your skills and creativity. It’s a rewarding way to practice and expand your knowledge with the Stack Overflow community in a space that celebrates diverse and unique approaches.
aka
>pls provide training material for the LLMs for free :pray:
lol. lmao, even
Yeah, and Android has had some 16 years of “optimize later”. I have some very very limited experience with writing mobile apps and while I found it to be a PITA, there is clearly a lot of thought given to how to not eat all the battery and die in the ecosystem there. I would expect that kind of work to also be done at the JVM level.
If Windows Mobile had succeeded, C# likely would’ve been lower as well, just because there’d be more incentive to make a battery charge last longer.
Is there a lot of computation-intensive code being written in pure Python? My impression was that the numpy/pandas/polars etc kind of stuff was powered by languages like fortran, rust and c++.
And it powers a lot of phones. People generally don’t like it when their phone needs to charge all the freaking time.
And battery costs, including charging time, for a lot of devices. Users generally aren’t happy with devices that run out of juice all the time.
As if anyone cared if they had to wait a total of 3 seconds in a workday.
That depends on when it appears. Some tasks kind of have to feel instantaneous, and there might be a pretty slim margin between okay and frustrating.
But yeah, that’s the kind of savings that mostly matter on the scale of regional or national grid planning.
Most engineers already write bloated, abstracted, glacial code that burns CPU cycles like a California wildfire. Clean code? Ha! You’re writing for other programmers’ academic circlejerk, not the hardware.
It’s interesting that everybody else preaches ‘Write for the human first, for the machine second’.
Yeah, the author seems to lean too hard into the “programming is electronics” model, where the opposing end is “programming is math and formal logic”; most of us take some mixed view. And most of us have higher correctness requirements than what a reasonable effort in memory unsafe languages like C and C++ gives us, so we trade away some machine efficiency. In the authors parlance, most of us aren’t interested in the demoscene circlejerk; we need to make tradeoffs between maintainability and everything else. Write-once code isn’t good enough.
There have been attempts at establishing a third pole of “promptgramming is natural language” or whatever ever since COBOL promised programming in plain English, but the ambiguity of natural language when used to encode a business logic machine means that a “sufficiently advanced compiler” will have to be extremely advanced, on the order of including the manager and the entire engineering methodology.
I’ve been using neovim for years (and the vim family for decades), and I guess with LSP it’s pretty much an IDE these days.
Yeah, I’m used to having my config in
git. Buuuut I guess non-devs aren’t really used to that workflow.