ziotom78's comments

Thank you! I regularly use Reveal.js to create interactive slide decks for my classes, and your project will be a great tool to have!

Correct, but I would add: Julia is better than Python+NumPy/SciPy when you need extreme speed in custom logic that can’t be easily vectorized. As Julia is JIT-compiled, if your code calls most of the functions just once it won’t provide a big advantage, as the time spent compiling functions can be significant (e.g., if you use some library heavily based on macros).

To produce plots out of data files, Python and R are probably the best solutions.

It will surely be worse, at least at the beginning. But there is a significant chance that with time they will improve it, and one can hope that one year after the first release the product will actually be better than Teams, given that the developers will improve it based on their own experience.

A few weeks ago I decided to test C++ modules, but I had a hard time to figure out how to make them accepted by CMake. After a few days of struggle with `set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444")` (it was so hard to find the right UUID that worked with my version) and errors on `import std;`, I decided to give XMake a chance.

It took just a couple of minutes to have a working example that fully supported C++ modules and `import std`:

    set_languages("c++23")

    add_rules("mode.debug", "mode.release")

    target("mytest")
        set_kind("static")
        add_files("src/*.cpp")
        add_files("src/*.cppm", {public = true})
        set_policy("build.c++.modules", true)

It’s fantastic they were able to find these issues!

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.

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/

[2] https://github.com/simonschoelly/KittyTerminalImages.jl

[3] https://github.com/hzeller/timg

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

[4] https://en.wikipedia.org/wiki/Vajont_Dam

[5] https://en.wikipedia.org/wiki/M%C3%B6hne_Reservoir

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!