c0l0

You are right, this change makes the drop-in snippet more robust: If one issues `set -u` before trying or deciding whether to redefine `:` (which would also be the effect of invoking the interpreter with the `-u` option), the variant presented in the article breaks. If the shall-we-redefine-: check has already been performed before `-u` is in effect, the alternative implementation of `:` itself will work fine.

It's kinda unfortunate this slipped through, because before I tried to "formalize" this little trick in the article yesterday, I definitely remember having used variants that guarded against this little nasty trap you now independently rediscovered ;)

Would you mind me updating the article accordingly, and crediting your HN account name/profile in the changelog?

Thanks a lot for your rigorous reading and very constructive feedback! :)

Interesting find! Apparently, also in POSIX sh programming, all problems can be overcome by introducing another layer of indirection ;)

Would it be OK for you if I added that information/workaround to the article (crediting you, of course)?

Hey, thanks for taking the time to read and commenting! :)

Problem #1 (at least for the "advanced" part of the article's suggestion) is unfixable unless you boil the ocean and change the POSIX spec. I tried to make that clear in the prose, but might have failed at it. It's also the reason why I chose the title to refer to `bash` scripts in particular.

Problem #2 becomes less relevant once you realize that problem #1 completely overshadows it. And in `zsh`, where you can also redefine `:` to invoke a custom function, tests via `[[` also work just like they do in bash.

These days, we are lucky(?) enough to have ẞ (LATIN CAPITAL LETTER SHARP S) to avoid that particular conundrum ;)

No, but there will be fines ("Verwaltungsstrafen", which can be converted to "Ersatzfreiheitsstrafen" - jail time - if you are unable or unwilling to pay).

For k8s, look into https://github.com/kelseyhightower/kubernetes-the-hard-way - I did it using GCP, which would expose you to a little bit of that, too.

Imagine how much CO2 we could NOT emit into the atmosphere if we just yanked all the superfluous, useless and demonstrably harmful workloads from all the clouds and computers on this planet (instead, or in addition). No training your neural net for thousands of accumulated [CG]PU-years to make racial profiling, droning could-be-"combatants", or targeted advertising more effective. No high speed trading any more for ad real estate on the web, stocks, or natural resources.

I so, so wish that in many cases, people would perceive the actual value of simply NOT doing certain things. But we're spiraling into a lethal wet-bulb future on the back of so, so many things we not only could perfectly well do without, but that actually could never, in no conceivable scenario, have a net-positive effect on society in any way. What a darned pity.

I am afraid it does not matter any more, at least not for practical software freedom.

Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset.

It's an awful situation for people who would rather install software provided by a third party onto their hardware (due to not trusting the device manufacturer enough to only include software in their best interest, which is a very reasonable stance in my book), but I don't think there's a way out any more.

We had great wuzzler culture there (with a former semi-pro on the tech team back then), which eventually prompted me to ask them to introduce that "requirement"/nice-to-have to the job ads. Nice to see they still list it! ;)

I used to work there as Senior Sysadmin for several years. My pay was competitive with most offerings the Austrian IT market can be brought to bear.

They did not change names; LibreELEC was forked from OpenELEC over internal disputes in 2016 or so. Both projects live on independently.

My RPi 3B+ turned out to be fast enough to decode most any 1080p H.265 content in unaccelerated software on LE 9.2 without problems. Sure, at high bitrates you'll see more than 300% CPU consumed - but that's when having four cores in that tiny thing actually pays off for real :)

So I've been writing shell scripts for about two decades, about 75% of that time professionally. Parsing the unstructured, text-based output of utilities is not the problem for anyone who's had maybe a few weeks of training. Most `... | grep ... | cut ... | sed ... | awk ...`-abominations the post laments can be replaced by a single informed call to `awk`, making everything a lot more elegant and concise.

Having JSON as an intermediate representation to work on instead is not going to save anyone - what we'd really need is for all tool versions/variants output on all platforms (all GNU/Linux distros, all the BSDs, all embedded Linux variants, all commercial UNICES, etc.) to be the same, all the time. That's not going to happen, so shell scripting is going to stay messy.

Also, for my INTERACTIVE shell, anyone can try to pry free-form, text-based and semi-structured output from my cold, dead hands. JSON or YAML output might be an acceptable compromise between being easy to parse and bearable for human consumption, but for my daily work, I would rather have my tools make it easy for me, the human part in the whole equation, and not some parsing logic that might not even (need to) exist. Shell scripting provides most of its value from the fact that since I'm in its repl-of-sorts all the time, I can translate that familiarity to scripts and executables effortlessly, and I would not want that going away. But I am rather certain it would, if we had JSON (or another form of more structured data interchange syntax) adopted as the "universal" interface between UNIX tools.

Sure, on paper, that will always be possible - just not in the age of signed kernel images that are cryptographically verified by your immutable bootloader.

FWIW (and iirc), with programs using recent-ish glibc, you will never see a call to open() in the wild unless the program takes special care to bypass the implicit libc wrapper. glibc will transparently convert these calls to openat() under its own hood. I do notice that this probably doesn't do you any good on FreeBSD, though :)

You can stop output on a terminal (emulator) by exercising flow control. If you get overwhelmed by `tail` (or a similar tool's) output, hit ^S. If you are ready to resume, strike ^Q.

Given that the actual reviewers of scientific works aren't paid, I'd say that the publishers like Springer and Elsevier came up with a pretty good system (first and foremost good for themselves, though) to do just that. ;)

FTR, directed at those who valiantly continue to self-host mail/SMTP: Greylisting is not sound any more in this day and age, because the largest mail services will rarely, if ever, use the same MTA instance to retry delivery upon a soft bounce.

The good news is that if you have postfix, using postscreen with an informed choice of blocklists is enough to deal with 99%+ of inbound spam. You can strap in rspamd or spamassassin/amavis behind that, but it's mostly not needed.

The inbound-mail-problems are largely solved, but surefire delivery to other parties is a matter of IPaddr/domain reputation, properly implementing relevant standards, and luck.

If you're interested in learning more about (including, but not limited to, self-hosting) email, the #email channel on the libera.chat IRC network is a great resource to ask questions.

Could it? Yes.

Will it? Maybe.

Would I count on it in all cases? No.

Also, I find it preposterous to rely on a second automated system to cancel out the mistakes the first one made.

What a cool project! If only I actually needed a doorbell... ;)

I would however LOVE to have a blueprint for a DIY "smart" door lock (like https://nuki.io/, but with FOSS firm- and software) available, yet a recent web search for such a thing did not yield results. If I did overlook something, please let me know!

/tmp/. has the sticky bit set (+1000), so renaming any files in there is not allowed for anyone but that particular inode's owner user (or UID 0, of course). If your socket directory with important UNIX domain socket inodes isn't similarly protected, that's a problem.

That's just like, your opinion, man. The tens of thousands of users that migrated to other networks feel differently about the matter.

I have several networking devices around the country with OpenWrt on them (for example, at my mom's house). They serve different needs, with different selections of packages installed, and are not of the same hardware, so keeping them up to date proved a hassle eventually. I chose to wrap some primitive Python around OpenWrt's excellent ImageBuilder that helps me keep a declarative build configuration around in an INI-style file, and (most of the time, when point releases are released) only dial up a single version number variable to rebuild all images in parallel. The flashing afterwards I haven't automated, but that might be too much of a footgun anyway.

If you feel like taking a look, here's the source: https://johannes.truschnigg.info/code/openwrt_autobuild/

---

While I was responsible for running the internal CAs at $prevjob, I wanted to give (human) users a convenient and secure means to generate and submit CSRs. I implemented a browser-based CSR generator based on the great work if https://pkijs.org - a demo variant of this internal portal is online at https://johannes.truschnigg.info/csr/ and might actually be of use to someone else :)

---

Several years ago also at $prevjob, I was looking for a reliable way to do PostgreSQL WAL archiving without the clunky shellscripts floating around in documentation and on Wikis, and implemented a little C program to do that job. While today you're probably using something like wal-g or other advanced tools that consume the WAL for replication and DR purposes, you may still want to have a program that does one thing, and one thing well, and that is making sure WAL segments get copied from location A to location B, without much overhead, period.

That would be it: https://johannes.truschnigg.info/code/pg_archive_wal_segment...

Just a few weeks ago, I fixed a problem in an internal tool (that still also runs on an ancient Solaris 10 box) by switching from `awk` to `gawk`, since the former would briefly whine on stderr and quit whenever a line in its input would contain too many fields. A recent change had managed to break that undocumented barrier.

In this case there's at least no silent breakage involved, but the badly written shell script that called it did not bother to check for that condition, and a fair number of heads were scratched for a while as a consequence.

While I find this post and the ideas presented very interesting on the technical level, work in that direction ("remote attestation", making devices "tamper-proof") tends to give me a dystopian vibe - foreshadowing a world where there's no hardware left you can hack, build and flash your own firmware onto: Complete tivoization, to re-use lingo from when the GPLv3 was drafted. With that, really neutering all the benefits Free Software provides.

What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?

I don't see that (some communities opting for libera.chat, some for OFTC) as a problem, though. Recent events show that some amount of IRC network diversity can only be a good thing.

Template rendering performance has always been one of my gripes with ansible. Have you ever taken up the challenge to debug/profile it, and get to the bottom of that seemingly obscene slowness? (It's one of those things I always plan to finally do whenever it affects me, but tend to forget or "postpone" as soon as I move beyond that one particularly slow task...)

This right here.

For programs that do not require access to an X11 display, you could also work around the problem of not really trusting the code to not do anything that isn't in your best interest by using `sudo` (or `su` or `setpriv` or ...) to change to an unprivileged account.

Or by having the (non-script) executable file have the SUID bit set, and owned by an unprivileged account on the system.

> 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates)

Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key.

With the CA system in place, you "just" need to get another CA to sign for the identity you would like to spoof. Not saying it's easy, but for the proverbial "nation state"-level attacker (maybe with their own CA root already in your trust store :)), it's certainly easier to do that than to break RSA or EC.

But you don't get to have that! You get the "insane" syntax oh bash, encapsulated in a ridiculously verbose and frankly quite unintuitive JavaScript contraption that seems to provide little, if any, benefit.

Also, Shell scripting is mostly about correctly and safely interacting with other CLI-based tools - which this new thing wrapping a shell (and badly at that, see other comments in this thread) won't help you get right, either.