Two ways:

1. Say you want to rename the files Sevilla_big{number}.jpg to Sevilla_small{number}.jpg:

in bash, using the extglob option:

 shopt -s extglob
for f in pics/**/Sevilla_big*.jpg
do 
     mv "${f}" "${f/big/small/}"
done

(If you want to type it in a single line, you need to add semicolons as separators.)

The ‘"’ are only needed if file names contain whitespaces.

2. Using find:

   find . -name ‘Sevilla.*big.jpg’ > t

   now, you edit the file named “t” with Emacs or vim so that you duplicate the file names, modify them as you want, and copy them using the copy-rectangle command right to the collumn with the original names. (Vim also offers this functionality, it is super useful to learn!) Delete any names of files you don’t want to change. save the result to t.

Then, in bash:

 <t while read a b; do mv $a $b; done

Alternatively, you could also insert the mv command as a first collumn in t, save t and do:

source t

This variant wouldn’t work with spaces in filenames.

3. Bonus option:

Use the mmv command

I tried similar things on Debian and the usual problem seems to be that session management under Wayland is a mess.

That is simply not true.

Yeah that is correct.

I was thinking in Safe Rust alone, and actually forgot about Unsafe Rust.

Because I have so far almost never used Unsafe Rust, except for C library bindings.

See this explanation, this is why.

I don’t know how those bugs get there in the first place.

Easy to explain.

Visualizing program code as cables, this is how a shiny new program would look:

And this how, for example in a commercial environment, or if the programmers are not absolute masters, such a program will look after 15 years of bug fixing, feature requests, urgent changes, deadlines, and unfinished restructurings:

The thing is that especially C code contains tons of implicit invariants which you simply cannot maintain in such code.

And don’t forgot that the picture above shows perhaps 500 cables, but a codebase can easily contain 50000 lines of code…

So it was a linker issue?

No, that would have resulted in a linker error, not random undefined behaviour

But industry is still working with a fifty year old language written for systems where 32 kilobytes were a lot of memory.

Especially for embedded and DSP stuff there are so many architectures that aren’t even supported by the Rust compiler. And on those systems 32 kiB of RAM is sometimes a lot of memory.

These niches still exist but they get rapidly smaller every year. Because:

• Cheap hardware gets more powerful
• Demands rise… even some electric toothbrushes are networked now
• Rust support for embedded devices is rapidly expanding

Plus:

• In some domains, security is becoming a real issue

if you’re writing in raw C++ you’re doing it wrong.

So, C++ is the new Python?

Newsflash: all the things do not need to be multithreaded, there’s an awful lot of code that’s just peachy in a single threaded implementation, thank you very much, and multithreading it is just inviting trouble for no significant gains.

I am waiting for your single-threaded fork of the Linux kernel.

What part of Rust is fun?

C is fun to me because the syntax is easy to understand and straight to the point.

You probably had never the pleasure to search for bugs caused by C Undefined Behaviour in multithreaded code.

When I was writing my diploma thesis, I was writing multi-threaded code for an embedded DSP system. Results were wrong all the time. I tracked it down to atan2() giving wrong results. I searched for about six weeks how to fix that and it disappeared when I changed the position of the program’s data segment.

(If the concept of Undefined Behaviour is new to you, I can recommend the web pages of Jens Regehr).

The above debugging experience was 25 years ago. We have better languages now. Rust has no Undefined Behaviour. That means you can track any bug (except compiler bugs) deterministically down to where the actual logic of the code, and the model of it which was in your head depart. This is great.

Rust is fun because you can compile a complex program and it runs.

But industry is still working with a fifty year old language written for systems where 32 kilobytes were a lot of memory. At work, I am still searching for bugs in multi-threaded C code with manual memory management (the previous developer didn’t think this needs locks), and I have to explain to the CTO that no, wo won’t have a release this fall, while the company literally drowns in technical debt.

Attacking the messenger because you don’t have any good argument against the message?

This is the Linux kernel project, one of the technically most conservative projects in the FLOSS community.

Greg is evil, don’t mind MIT code in the kernel and it was the main proponent of AI in the maintenance process.

That’s a mouthful, can you expand with facts?

don’t mind MIT code in the kernel

Last time I checked, the kernel used GPLv2? Could it be you misunderstand something about cross-using code with different licenses ?

No, that is settled and it is also a successful, gradual evolution. It just makes sense to start using Rust for drivers and at the periphery of the kernel, and use it in core subsystems perhaps later.

Any successful change in such a large project will be evolutionary. And also, for gaining security benefits, it makes sense to use Rust in new drivers, new modules, perhaps network stacks, and later file systems - but these roll much more slowly.

There is nothing wrong with that it’s just a little overused

That’s one of the problems of companies devaluing and abusing language so much that words are in danger to lose any meaning. It is a difference however whether Torvalds uses such a word, or a corporation advertising bullshit. It is really clear that corporations want to replace software developers.

e> Linux users: switch from Windows to Linux to avoid ai slop

Linus, an out of touch idiot: Actually vibe coded slop in the OS is good!

I don’t like LLMs for a number of reasons - the theft, the environmental impact, the deceptive marketing - and also because I am really pissed about the abysmal quality which my AI-pilled coworker produces.

But in difference to Windows and most commercial software, the Linux kernel project has high quality standards, and I have some faith they’ll keep them.

Also, the cited mail discussion is not about AI generating unreviewed code - which I still see as very questionable - but about checking code for bugs and deficiencies. Given the amount of CVEs found by LLMs, I see no way around that for important infrastrcture projects like the kernel.

Many people are not amused by the hype - me neither. But AI could unexpectedly help open source in a few ways:

• it will become clearer that quality matters. We alrrady see that with Windows - Linux is getting many new users.
• We might see a trend to source code rewriting and re-use instead of using libraries. Libraries are pervasively used now, and that has drawbacks like bloat and dependency hell.
• Copyright is rapidly losing importance. This is really bad for artists and book authors. But for most (not all) programmers not, since copyright in software was mostly a tool to protect profits of corporations. Software development at its core is a service.
• Issues of autonomy and control are becoming more important than ever. The kernel is a pragmatic project, but it being free to use and modify is absolutely central - that’s why it uses the GPL - and we are also seeing every day that Stallman was and is right more than anybody would desire.

Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has “over 5,000 developers” but “about 150 core maintainers that review the majority of the code,” a skew that drives his priorities. “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers,” he said, suggesting Rust’s ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: “If it builds as a reviewer, I know it’s OK. I can look at the logic.”

That’s a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.

Honestly, those who reinstall constantly feel like people that don’t take care of their stuff as they should. There’s no need to reinstall.

I’d take that with a pinch of salt. Over years, systems can get quite crufty and by my own experience, things like GNOME can break from upgrades even under Debian. A reinstall can tidy things up.

KDE has a history of doing that. Plasma widgets are a gaping security hole.

OMG, did they copy Microsoft’s “Active Desktop”? Sounds like this exactly.

Guix provides security patches. You can also define your own derived packages and patch them. Or fork the distro and build it with a different kernel and base packages, like the nonguix fork does. Or add an own patched OpenSSL library.

But what such approaches come down to in practice is that maintaining a forked distribution is a lot of work. For most people, the sane approach is to build on an existing distro.

It is not an easy problem. For example, the buildroot distro which is popular for embedded devices, AFAIK has only one release every six months.

By the way, secure open trust systems are hard. Around 2000, there was a FOSS web site called kuro5hin.org, a slashdot-sryle discussion board, which experimented with trust networks. As far as I remember, they did not find a good solution.

Wikipedia or stack overflow has the same issues.

I think a kind of real-life-based(!), signature-based web of trust like the GnuPG web of trust (but ideally with more user-friendly software…) could be part of the solution

It’s the derivates leeching the arch aur infrastructure and preinstalling aur helpers suggesting it’s safe to use as is.

So, Arch users do not depend on AUR? If so, that’s easy to fix. Just delete any mention of AUR from the Arch wiki.