This is the first I’ve heard something like that about Iceland; but I do know a little bit about Icelandic personal ID numbers.
This is the first I’ve heard something like that about Iceland; but I do know a little bit about Icelandic personal ID numbers.
Yeah, it’s essentially a weathervane or thermometer. You can indicate the state of a country by it.
At this point the US has joined the ranks of, well, grim theocracies. Not that the people at the top in the US worship anything but Mammon.
>What is C++? A miserable huge pile of "should"s
I had to figure out how to do the factory reset at the gym after I got the blue triangle of death when leaving work. Oddly enough it synced the gym plan I wanted and leaving it connected to the phone didn’t seem to produce any other ill effects, but I stayed away from anything using GPS.
But yeah, the general advice for Garmins just now seems to be “just don’t” and hope it doesn’t triangle itself until the fix is out
They’re stuck in a reboot loop, but not bricked. A factory reset works (but the problem may reappear on update).
Yeah, while -e
has a lot of limitations, it shouldn’t be thrown out with the bathwater. The unofficial strict mode can still de-weird bash to an extent, and I’d rather drop bash altogether when they’re insufficient, rather than try increasingly hard to work around bash’s weirdness. (I.e. I’d throw out the bathwater, baby and the family that spawned it at that point.)
Yeah, there’s also a subtle difference between ${1:-}
and ${1-}
: The first substitutes if 1
is unset or ""
; the second only if 1
is unset. So possibly ${foo-}
is actually the better to use for a lot of stuff, if the empty string is a valid value. There’s a lot to bash parameter expansion, and it’s all punctuation, which ups the line noise-iness of your scripts.
I don’t find it particularly legible or memorable; plus I’m generally not a fan of the variable amount of numbered arguments rather than being able to specify argument numbers and names like we are in practically every other programming language still in common use.
Yeah, another way to do it is
#!/bin/bash
set -euo pipefail
if [[ $# -lt 1 ]]
then
echo "Usage: $0 argument1" >&2
exit 1
fi
i.e. just count arguments. Related, fish
has kind of the orthogonal situation here, where you can name arguments in a better way, but there’s no set -u
function foo --argument-names bar
...
end
in the end my conclusion is that argument handling in shells is generally bad. Add in historic workarounds like if [ "x" = "x$1" ]
and it’s clear shells have always been Shortcut City
Side note: One point I have to award to Perl for using eq/lt/gt/etc
for string comparisons and ==/</>
for numeric comparisons. In shells it’s reversed for some reason? The absolute state of things when I can point to Perl as an example of something that did it better
#!/bin/bash
set -euo pipefail
if [[ -z "${1:-}" ]]
then
echo "we need an argument!" >&2
exit 1
fi
There’s also no uppercase d in systemd
, the word is entirely lowercase (but I’ll still write it with an uppercase s at the start of sentences).
Yeah, the manpages for systemd are large but also informative. Most of us only use a small subset of the features—much like we never explored everything possible with separate init programs.
Having used Linux on the desktop for some two decades and worked as a Linux sysadmin for a good while I don’t miss the init scripts. My impression is more that a certain cohort wants to pretend that service management is easy by ignoring large amounts of it. It’s easy to write a bad init script that breaks when you really need it, or be out of your depth with more complex cases.
Not to mention the whole conformity by convention thing. Systemd unit files are descriptive and predictable by their nature. So-called init scripts didn’t really have to be scripts, they just usually were, and their arguments and output and behaviour was also unenforced—there’s nothing really stopping you from writing a compiled program that self-daemonizes and place the binary with the init scripts rather than in /bin. Ultimately people who make programs also have to be good at writing init programs with that setup.
So we’d have people doing dumb shit themselves and getting angry at others doing dumb shit. PHP was also pretty popular and full of dumb shit. Lots of “worse is better” to go around.
Ultimately it’s more of the stuff covered in Bryan Cantrill’s Platform as a reflection of values. Some of us value predictability and correctness, others feel it’s a straitjacket. There’s no way of pleasing everyone with the same platform.
And currently the people who want to distribute their own riced-out init programs in bash, perl, php, node.js and so on are SOL. (They can still use them on their own machines.)
Ah, so we didn’t have to wait until 2038.
And very old. Part of the sales pitch for the COmmon Business-Protected Language was that anyone could learn to code in almost plain English.
Also, the stuff they wind up making is the kind of stuff that people with no coding experience make. Cooking up an ugly website with terrible performance and security isn’t much harder than making an ugly presentation with lots of WordArt. But it never was, either.
Between COBOL and LLM-enhanced “low code” we had other stuff, like that infamous product from MS that produced terrible HTML. At this point I can’t even recall what it was called. The SharePoint editor maybe?
Yeah, I switched to deezer then, haven’t had any trouble with it.
Batteries seem to work fine in rural Norway. If you live somewhere warmer and/or with a bigger population or population density than Norway, you should be fine.
Yeah, that’s the correctness focus. Some people dislike it as a straitjacket, some even take it as a personal insult because they see it as a skill issue. They, the good devs, shouldn’t be held back like that (spoiler: they aren’t as good as they think they are).
Personally I like that aspect of Rust, but I also write Python with a typechecker and a loong list of enabled lints in ruff
. I can get the happy path done without it, but having just the happy path often isn’t good enough.
Enforced correctness helps a lot with confidence for those of us who know we sometimes make bad assumptions or forget some nuance or detail. But it will be absolutely infuriating for people who can’t stand being told they made an error, even one of omission.
Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with “I’m tired of paying for an ABI stability I’m not using” it’s not so clear it would really be a boon to Rust.
That said no_std
appears to be what people go to for the lean Rust.
And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It’s part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it.
The serious answer here likely has several components:
$NEWTHING
, they’re likely to get … grumpy. Both they and the government may be correct here, even if they’re at odds—they have different scopes and concerns.Socks were invented to be used in sandals, it’s the one true way!
(Typed wearing big woolen socks in birkenstocks)
One rather obvious reason is that society has a lot of greybeards in general. The baby boomer generation was named that for a reason, and people have been living longer on average. Lots of countries are struggling with the demographic effects. There’s no reason to expect that tech or something even more specific like FOSS would be exempt.
Another aspect here is that FOSS is still kind of new in society. There’s just more people who have had the chance to age into FOSS greybeards than when those greybeards were young. (And they were thus likely to a lesser degree blocked by entrenched greybeards when they were getting started.)