- A few months have passed and I might not remember everything correctly, but there was a series of problems:
- I use several symbols as Greek letters (α, β, γ…) and mathematical operators (×, −, ·, ∂…), and after much digging I found that the only way I could make keyd work with them was to choose a US keyboard layout. So, I had to write a configuration file for keyd to remap not only the special characters listed above, but every character of the Italian keyboard (è, é, ò, à, ù…). This extensive remapping required then an exception for Espanso to prevent `keyd` from intercepting its virtual keyboard output.
- However, this forced US-layout setup created a conflict with VirtualBox that I was unable to solve. When I installed Windows and selected the Italian layout inside the VM, the guest OS received the raw key codes corresponding to a US physical keyboard (due to the keyd remapping layer). Since the guest OS expected Italian key codes, all the standard Italian keys (like è, à, ò) stopped working correctly. Without keyd enabled, the standard Italian layout worked perfectly in the VM.
- The attempts to create application-specific exceptions (e.g., to disable keyd for the VM window) using tools like keyd-application-mapper did not function correctly in my KDE environment because of known issues in these tools.
- Finally, introducing new hardware like my Corsair keyboard added another layer of complexity, as its Linux driver (ckb-next) was incompatible with the active keyd remapping layer. This was the point when I decided to revert to X11.
I should definitely collect all these details and write a blog post about it…
- Xdotool and Xmodmap are the two main reasons why, after a few months running Wayland+keyd+dotool I went back to X11. I found really hard to have the following things working at once:
- Italian layout for my keyboard with heavily-customized AltGr keys for mathematical notation (in X11 it's just a matter of having a Xmodmap file)
- Using Espanso for many common shortcuts like :date: (current YYYY-MM-DD date) and :pidigits:
- A reasonable way to run Windows in a VM while using an Italian layout for my keyboard
- The possibility to use automation scripts using something as close as possible to xdotool
- Sometimes I use my home keyboard, sometimes I use my work keyboard, and sometimes I use my laptop keyboard. I expect the system to work in the same way regardless of my input device
It's not that Wayland prevents one from doing all this stuff, but the available solutions were fragile and complicated and took me so long before figuring solutions that only worked partially... For instance, to make keyd work as expected, I was forced to set up my Italian keyboard as an English keyboard and then remap all the keys manually... And every time I plugged a new keyboard, I had to tell keyd to enable my customizations on it, because telling it to use the layout with any keyboard conflicted with VirtualBox.
I understand that X11 is too complicated to be maintained, but from an user's perspective, so far I am far more efficient in X11.
- As others have commented, this trick alone cannot ensure truly "reproducible" builds.
We used the same trick (git hash + git diff to monitor uncommitted changes) in a Python simulation framework we are developing for the JAXA/EU space mission "LiteBIRD." [1]
[1] https://iopscience.iop.org/article/10.1088/1475-7516/2025/11...
- I believe they are really referring to the default mode used by GCC when no standard is explicitly stated.
The email mentions that the last time they changed it was 5 years ago in GCC 11, and the link <https://gcc.gnu.org/projects/cxx-status.html#cxx17> indeed says
> C++17 mode is the default since GCC 11; it can be explicitly selected with the -std=c++17 command-line flag, or -std=gnu++17 to enable GNU extensions as well.
which does not imply a change in an obscure feature (bootstrapping) that would only affect a few users.
- Thanks for the link, I was not aware of this story.
- Absolutely, the shortcut help is so useful!
I believe that Nano and Pico copied it from Wordstar.
- I run Kitty and use this feature regularly. Most of the time, I rely on it within Yazi [1], a TUI file manager, but I can also display plots within the Julia REPL, thanks to the KittyTerminalImages.jl package [2]. It's even more crucial when I'm navigating a remote directory and need to check an image file, as I usually have timg [3] installed on those servers. Once you discover how valuable this is, it becomes a permanent part of your workflow.
[1] https://yazi-rs.github.io/
- I was going to reply, but kakacik already said what I wanted.
- What strikes me is the fact that nuclear power has received an incredible amount of backslash after the Chernobyl incident (a few thousands deaths) and the Fukushima incident (one disputed death), but hydroelectric power is considered a "good" source of energy despite a few incredibly deadly incidents:
- Banquiao (China, 1975): between 26.000 and 240.000 [1]
- Derna (Lybia, 2023): between 6000 and 20.000 deaths [2]
- Machchu (India, 1979): 5000 deaths [3]
- Vajont (Italy, 1963): 2000 deaths [4]
- Möhne dam (Germany, 1943): 1500 deaths [5]
[1] https://en.wikipedia.org/wiki/1975_Banqiao_Dam_failure
[2] https://en.wikipedia.org/wiki/2023_Derna_dam_collapse
[3] https://en.wikipedia.org/wiki/Morvi_dam_failure
- That's a fair point. I think the author intended the post to be a treasure trove of ideas for your own scripts, not as something to blindly include in your daily workflow.
- It has been said that Italy is extremely vulnerable to fake news. I am not sure that we are more vulnerable than others, but it is a fact that local media provide news that is sloppy at best if not even willfully deceitful.
A couple of examples found in a book I read recently about the Fukushima incident:
- “Tokyo, a capital in agony. «We will never live here again.»”, from La Repubblica (March 20th, 2011) [1] The lead paragraph of the article reads, “Fear and nightmare of radiations: four million have already fled what was perceived as a model city”. At the time, Tokyo had 13 million people; a loss of 4 million would have meant a catastrophic collapse of the city and would have been recorded by the local media. None of this happened.
- “Fukushima, ten years after the tsunami and nuclear disaster. A return to normalcy amid abandoned lands and fears of radiation”, from Il Fatto Quotidiano (March 11th, 2021, ten years later) [2]. The lead paragraph says, “It was the worst nuclear disaster since the Chernobyl accident in 1986. Twenty thousand people died.” The number 20,000 refers to the victims of the tsunami, but there is only one (disputed) victim caused by the nuclear accident.
[1] https://www.repubblica.it/esteri/2011/03/20/news/tokyo_capit...
[2] https://www.ilfattoquotidiano.it/2021/03/11/fukushima-dieci-...
- Right, but I believe nobody can claim that Human error bugs go to zero for Rust code.
- I fully resonate with point #2. A few days ago, I was stuck trying to implement some feature in a C++ library, so I used ChatGPT for brainstorming.
ChatGPT proposed a few ideas, all apparently reasonable, and then it advocated for one that was presented unambiguously as the "best". After a few iterations, I realized that its solution would have required a class hierarchy where the base class contained a templated virtual function, which is not allowed in C++. I pointed this out to ChatGPT and asked it to rethink the solution; it then immediately advocated for the other approach it had initially suggested.
- Interesting! I wasn’t aware of pumped hydro. I checked one of the links in the thread, and it does look like a promising technology.
Has it been proven at the scale and reliability needed to balance a fully solar-dominated grid year-round?
- Nice, thanks!
- The course is meant to teach students how to write numerical code (integration, PDEs, Monte Carlo, …) rather than to teach OO design itself. C++ is the chosen vehicle, and the professor has a strong OOP background, so the course material ends up structured that way.
That’s why some of us wonder whether a lighter approach (lambdas, NumPy in Python, etc.) might let students focus more directly on the numerical methods without so much boilerplate.
- I’m a teaching assistant in a C++ course for second-year physics students. The goal is to teach numerical and data analysis, but the course is structured around a very object-oriented style. For example, every function is defined through inheritance:
If students want to integrate or find the roots of a function, they must first subclass it:class BaseFunction { public: BaseFunction(); virtual double Eval(double x) const = 0; };
Everything in the course (numerical integration, PDEs, Monte Carlo sampling, …) follows this pattern.class SinClass : public BaseFunction { private: double _omega, _phase; public: SinClass(double omega, double phase); double get_omega() const; double get_phase() const; void set_omega(double new_omega); void set_phase(double new_phase); double Eval(double x) const override { return sin(_omega * x + _phase); } };The professor is an excellent teacher and students love him. But other faculty worry that our students leave without any real exposure to Python, and that they keep reproducing this heavy OOP style even in situations where a simple lambda or a few lines of NumPy would be far more natural. (Lambdas are shown at the very end of the course, but mostly as a curiosity.)
That’s why I found the blog post so interesting: it shows how natural code can look in Python or Fortran. By contrast, our students’ code is weighed down by boilerplate. It makes me think that sometimes the real difficulty in teaching numerical analysis isn’t the language itself, or whether arrays start at 0 or 1, but the teaching approach that frames every problem through layers of abstraction.
That four new CVEs (two high-severity!) were found in a mature and well-tested library like png reminds me how non-trivial and unforgiving software engineering can be.
Security flaws are often just waiting behind the corner: this should be humbling lesson for all of us.