Yeah, there should be a clear separation between scripts, which should have a shebang, and interactive use.
If a script starts acting oddly after someone does a chsh, then that script is broken. Hopefully people don’t actually distribute broken script files that have some implicit dependency on an unspecified interpreter in this day and age.
That’s interesting I hadn’t thought about the JSON angle! Do you mean that you can actually use
jqon regular command outputs likels -l?
No, you need to be using a tool which has json output as an option. These are becoming more common, but I think still rare among the GNU coreutils. ls output especially is unparseable, as in, there are tons of resources telling people not to do it because it’s pretty much guaranteed to break.
I’ve been using fish (with starship for prompt) for like a year I think, after having had a self-built zsh setup for … I don’t know how long.
I’m capable of using awk but in a very simple way; I generally prefer being able to use jq. IMO both awk and perl are sort of remnants of the age before JSON became the standard text-based structured data format. We used to have to write a lot of dinky little regex-based parsers in Perl to extract data. These days we likely get JSON and can operate on actual data structures.
I tried nu very briefly but I’m just too used to POSIX-ish shells to bother switching to another model. For scripting I’ll use with set -eou pipefail but very quickly switch to Python if it looks like it’s going to have any sort of serious logic.
My impression is that there’s likely more of us that’d like a less wibbly-wobbly, better shell language for scripting purposes, but that efforts into designing such a language very quickly goes in the direction of nu and oil and whatnot.
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?
No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.
systemd is pretty great. I tend to start long-running processes as user services, and I’ve even taken to starting some apps that give an old laptop trouble with systemd-run and a slice with some memory restrictions. Easy peasy, works great, all declarative, no wibbly-wobbly shell scripts involved.
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.
But what did you learn? What are we supposed to learn? Did you get any context, like how he actually went to anger management therapy later?
Or is this just guffawing and gawping at an old angry email from a tech celebrity?
This mail is 13 years old, and doesn’t seem relevant for anything? This post seems like a lazy attempt at shit-stirring.
Yeah, JSON is essentially a side effect of having JavaScript already. It makes sense that it shows up a lot of places, especially web. But just like with JS, it’s not really good, just ubiquitous.
A wave with an infinitely long period isn’t really recognizable as a wave. It’d just be interpreted as a flat line anywhere in the universe. And as mentioned, the energy of light is tied to its frequency: E = hf. (Or with hbar • omega, but that’s just multiplied with and divided by 2π, so, the same thing.)
So an infinitely long wave would have f=0 and thus no energy.
The highest frequency you’d get would be 1/planck-time, so the energy would be the Planck constant divided by Planck time, which would be roughly 12.3 GJ. That’s a lot of energy for just one photon, but if it’s just the one, likely not world-ending.
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.
I’ve very barely dipped my toes in dbus before, and the option to have something else is on its face attractive (not a fan of XML and the late 90s/early aughties style of oop), but JSON for a system interface?
I mean, Kubernetes shows that yaml can work, but in this day and age I’d expect several options for serialisation, and for the default to be binary, not strings.
String serialisations are primarily for humans IMO, either as readers or writers. As writers we want something with comments (and preferably no “find the missing }” game), so for that most of us would prefer something like TOML if the data is simple enough, and actually Yaml for complexity at the level of Kubernetes—JSON manages to be even more of a PITA at that level.
But machine-to-machine? Protobuf, cap’n’proto, postcard, even CBOR should all be alternatives to examine
It’s even a tape archiving tool. Just pretty much nobody uses it in the original way any more.
Very much one of those “if it ain’t broke, don’t replace it” tools.