cross-posted from: https://scribe.disroot.org/post/3795786

• The European Central Bank (ECB) is set to introduce what it calls a 'climate factor' when lending to banks against appropriate collateral in their short and long-term financing instruments.
• This climate factor could reduce the value assigned to the assets pledged as collateral, thus protecting the Eurosystem against a potential decline in collateral value in the event of climate-related shocks.
• The climate factor also raises the pressure on commercial banks to direct their funds towards 'greener' investments as the bloc seeks to reduce it carbon footprint.
• The new measure will apply to marketable assets issued by non-financial corporations, taking effect in the second half of 2026.

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

So the history part is fairly easy. There's only one major rule, and one minor clarification:

• You must never EVER destroy other peoples history. You must not rebase commits other people did.

[...]

If you are working with git together with other people, it's worth a read.

“Jujutsu (jj) is a version control system with a significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power (in fact, you could argue Jujutsu is more powerful). Stacked-diff workflows, seamless rebases, and ephemeral revisions are all natural with jj [...]”

Part 2 of the series is out and is here.

Well, I hope you don't have any important, sensitive personal information in the cloud?

Short answer is: yes, as soon as more than one OS mounts a file system in read-write mode.

The kernel of a modern OS (I am generously including Windows here) caches file system data structures in memory. When you hibernate the computer, the content of that memory is written into a large file because that speeds-up a later restart.

Now, if you boot up another OS, and modify these partitions (without mounting them read-only), you alter the file systems data structures. That happens already when you view folders because this modifies access times stored in the inodes.

When you now shut down the second OS, and resume the first OS, the restarted kernel will have and use cached file system metadata which id loaded from the image into the kernel, that does not match that of the files on disk. And this causes file system corruption by definition.

.... virtual machines where you only have to select which accompanying image of Arch / Tumbleweed / Ubuntu / Fedora you want to try.

In addition, the combination of a very stable base system (say, Debian or SuSE Leap) with a fast-moving, bleeading edge virtualized system (say, SuSE Tumbleweed, Arch or Guix) on top can be surprisingly useful. And because small virtual machines, when not running, are nothing else than files on your computer, you can have many versions of them, alter things, try stuff out, then delete it and go back to the tidy original state.

cross-posted from: https://lemmy.today/post/34561505

Cool even if you're not interested in learning Scheme. It has some neat features.

Code as data? 😵‍💫

Archive link: https://archive.ph/A7LI4

Marianne Belotti has worked at large institutions with modernizing decades-old code bases. She is author of the book "Kill it with Fire" [review].

From that book's author bio:

Marianne Bellotti has worked as a software engineer for over 15 years. She built data infrastructure for the United Nations to help humanitarian organizations share crisis data worldwide and tackled some of the oldest and most complicated computer systems in the world as part of United States Digital Service. At Auth0 she ran Platform Services, a portfolio that included shared services, untrusted code execution, and developer tools. Currently she runs Identity and Access Control at Rebellion Defense. She can be found on most social networks under the handle bellmar.

Say you are dual-booting Debian and Arch and want to upgrade Debian oldstable to Debian stable. But you want to keep the old installation available as a fall-back option. And you also want to re-use your configuration files and dot files, but in a way that incompatible changes to your dot files in the new Debian or Arch version do never break the old program versions.

How do you do that ?

(I describe my own approach in a comment below.)