Press review: 30.12.2023

by Patryk Kocielnik

HPC

The hardware / datacenter side of this [HPC] is equally fascinating.

I used to work in AWS, but on the software / services side of things. But now and then, we would crash some talks from the datacenter folks.

One key relevation for me was that increasing compute power in DCs is primarily a thermodynamics problem than actual computing. The nodes have become so dense that shipping power in and shipping heat out, with all kinds of redundancies is an extremely hard problem. And it's not like you can perform a software update if you've discovered some inefficiencies.

This was ~10 years ago, so probably some things have changed.

What blows me away is that Amazon, starting out as an internet bookstore is at the cutting edge of solving thermodynamics problems.

‒ https://news.ycombinator.com/item?id=38815334

Cyber Resilience Act

Very good explanation and very encouraging

The Debian statement appears to be based on an earlier version of the CRA.

It for example says “Knowing whether software is commercial or not isn’t feasible, neither in Debian nor in most free software projects”. Under the CRA there is no need to figure that out for Debian.

“Having to get legal advice before giving a gift to society will discourage many developers” - the final version of the CRA is clear that if you are giving a gift, the CRA does not apply to you anyhow. There is now a very clear statement on that (see above).

‒ https://news.ycombinator.com/item?id=38818734

Shells

Rule of thumb about shells:

  You'll never know for sure what shell is the default, so write your scripts to a minimum shell family, and encode the name of that shell family in the shebang.

The default shell, for either the entire system or an individual user, could be:

  - A Bourne shell
  - A C shell
  - A POSIX shell
  - A "modern" shell, like Bash, Zsh, Fish, Osh

Use the following shebangs to call the class of shell you expect. Start with /usr/bin/env to allow the system to locate the executable based on the current PATH environment variable rather than a fixed filesystem path.

  #!/usr/bin/env sh
  #              ^ should result in a Bourne-like shell, on modern systems, but could also be
  #                a POSIX shell (like Ash), which is not really backwards compatible

  #!/usr/bin/env csh
  #              ^ should result in a C shell

  #!/usr/bin/env bash
  #              ^ should result in a Bash shell, though the only version you should
  #                expect is version 3.2.57, the last GPLv2 version

  #!/usr/bin/env dash
  #              ^ you expect the system to have a specific shell. if your code depends
  #                on Dash features, do this. otherwise write your code using an earlier
  #                version of the original shell family, such as Bourne or POSIX.

‒ https://news.ycombinator.com/item?id=38814599

Vidir

This is probably what I use most often. Running vidir opens your $EDITOR or $VISUAL with files / directories of the specified directory (or the current directory) and allows you to edit them. If you change the name, it will rename it. If you delete a file row, the file gets deleted. To delete an entire directory with everything in it, delete its row and all sub entries.

vidir *.pdf

fd -t f | vidir -

What if you've made so many great changes that you want to just quit the editor without applying any of them? You just need to quit the editor with exit code 1. In Vim / Helix you do that with :cq. This by the way works in pretty much all cases where a command invokes your editor (e.g. when writing a commit message).

‒ https://jpospisil.com/2023/12/19/the-hidden-gems-of-moreutils