jbrnh

That sounds horrible. This is a central part of Gimp interface. Would it not make sense to fork into a different toolkit focused on complex applications?

Electricity can still be more efficient for many of these with heat pumps, like indoor heating and steam production. The gap is smaller then for working engines of cause.

And Germany right now have battery storage equivalent of fully powering Germany for about 30 minute sand raising up every month, which is quite wild.. https://battery-charts.de/ With those feeding on negative-priced electricity, intermittent sources will only get more economical to the detriment of gas and nuclear.

How is seasonal storage relevant here? This is the usual few-hours-fluctuations, I assume? (can't read the article)

They are working on that https://battery-charts.de/

Word and Excel seems to change behavior on every release. I don't think it's something Gimp should try to chase. Gimp has save: "Save native gimp file" and export "Export an image file". It's a bit confusing to me why people find this confusing.

'Opening a JPEG' is creating a new image and importing the JPEG to it. ctrl-e on first use will establish the export setting. It's two clicks if you really want to overwrite the original. I think it would be very easy to accidentally and destructively overwrite the original image file if it was different, when ctrl-e is in muscle memory.

There was the GIMP Coffee stain filter (though it looks like it is not included in Gimp 3). https://docs.gimp.org/2.10/en/script-fu-coffee-stain.html

It's a blog. It references an interview. The post is also four month old. "In the Pipeline" is generally a fantastic resource on the pharma industry and chemistry news.

I would say it might, with the 'zi' variant (cd with interactive selection (using fzf)).

Yea, can we get one of a CT scanner?

This is why the trial was stopped due to efficacy.

I'm not sure I see the problem: 'Export', and 'Export as' works as 'Save' and 'Save as'. This i like 'Export to PDF' in a word processor. If you never save in GIMP, I suppose you don't use layers?

Why is shift-ctrl-E for 'export' difficult?

"The Firecracker Boys: H-Bombs, Inupiat Eskimos, and the Roots of the Environmental Movement" by Dan O'Neill is highly recommended.

Perhaps because of https://blogs.sciencemag.org/pipeline/archives/2021/04/28/ru...

Not quite the same, but "Life on the Infinite Farm" https://www.math.brown.edu/reschwar/farm.pdf

Yes, and it almost killed the company. I read an article a while back how they had no accounting from the designers to production, and literately had 8 different chef minifigs (also, making star wars sets helped them out as well)

My dad complained about modern specialized lego bricks 30 years ago. I got some of his old bricks from the 50's. They got some weird shapes too. Nothing changed.

yes, it's great!

It doesn't have alt<char> to enter normal commands from insert mode (double the number of lines).

It doesn't have (Vim 8) terminal mode.

A similar concept, it seems, Andrew Chaikin's "A Man on the Moon" is a fantastic read.

I think it is a commonly held view that HC Andersen conceived of TLM after his unreciprocated love interest in his (male) friend. https://www.huffpost.com/entry/hans-christian-andersen_n_563...

fzf never struck me as the slightest bit slow. What am I doing wrong? You can configure it with an external previewer that can of cause be arbitrarily slow or bloated but you can hardly fault fzf for that.

Or use 'shuf' for passwords:

shuf -r -e --random-source=/dev/urandom {a..z} {0..9} {A..Z} | paste -d "" -s | fold -w 25

I used to run a couple of hundred servers and workstations with SLES and openSUSE with btrfs for /. Just SUSE's vanilla supported setup, and user data on smb/nfs filers. I tended to forget that btrfs was even involved. I can't remember a single time btrfs gave us any trouble. But snapper snapshots saved a customers ass on one or two occasions.. That was several yeas ago. I also imagine that btrfs has only improved since then.

env and sh are both POSIX but AFAIK the path is not specified for either of them. If POSIX has an opinion on how you should start a script I would be happy for a link?

Bash in RHEL is in /usr/bin and /bin as /bin in symlinked to /usr/bin. I think it is equally unlikely that RHEL (Debian, SLES..) will will move either /bin/bash or /usr/bin/env as it would break a million scripts out there.

If we should migrate to FreeBSD while, for some reason, reusing linux oriented bash scripts, changing the path to /usr/local/bin/ would be the least of my headaches.

I agree that 'env' can make good sense if you don't know who/where/when your script is used. For internal projects, I don't really see the advantage.

But if I write the script for a bunch of RHEL servers then OS X and brew are irrelevant, and the full path is better (IMHO). It's the 'always use env..' I object to.

I don't quite get the recommendation to always use env bash over #!/bin/bash? If I use the full path, it is to get just that - the system's Bash. If it is missing or overruled in $PATH then I most likely don't want the script to run in the first place.