gsliepen

Even weirder: when the router forwards the packet from the host to the Internet, it already sees both the source IPv6 and MAC address, so it could store them.

Maybe there are some weird situations where a host that just got its own IP address starts proxying for a third node that wants return packets to asymmetrically bypass the host?

I think the solution is to really give the user control over when something is pasted and into which application. So if you press ctrl-V, it shouldn't pass that on to an application that then gets to poll the clipboard, instead the OS or window manager should send the contents of the clipboard to the application the moment ctrl-V is hit.

> Intent matters a great deal,

The road to hell is paved with good intentions.

For FPGAs in general: When latency is important. Even a $1 MCU has a huge amount of compute power nowadays, and they can simulate many things, but if you need to deterministically react within 1 microsecond to what happens on a pin, and your MCU doesn't already have a hardware peripheral that does exactly what you want, you're probably going to need an FPGA.

Some recent advances, like the Raspberry Pi Pico's PIO units, have made it possible to do things that MCU's couldn't do before, like emulating a ROM chip. But there are limits to what the PIOs can do.

If it comes to pure computation and not latency, you need some very specific use case before an FPGA becomes better than a regular CPU. Most likely when it involves massive parallelism and custom caches and interconnects. Although nowadays NPUs are starting to fill that niche.

For tiny boards in particular: getting experience and having fun.

The Swedes managed it.

> Everything being static inline makes it hostile to these older systems which have limited RAM.

Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.

> execute instructions faster (via -O3)

One problem with -O3 is that it disregards any effects of the cache (and yes, ESP32s have a bit of cache memory). I recommend using -Os as the default optimization level, as it often has the same or almost the same performance benefits as -O3. Less cache pressure is beneficial, especially for bigger applications, and the smaller code size is of course nice on embedded systems that have limited amounts of flash storage. If you know some specific functions or source files are performance sensitive, you can use pragmas to change optimization for those:

    #pragma GCC optimize("O3")

See https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-.... Clang has a similar pragma, see https://clang.llvm.org/docs/LanguageExtensions.html#extensio....

We'll see how much people like it once the cheap subscriptions end and the actual cost of LLMs (+ profit margin) is asked of them. Although I'm suspecting that eventually, machines that are good enough to run reasonably useful models will become cheap enought that most developers will have those, but that might be some years from now.

Debian is run by volunteers, and I think Debian Developers would not like it if they would have to pay to work on it, thus there will be some aversion to (at least frontier) LLMs.

> Notable are the endorsements, which are balanced over all three options, perhaps indicating only 1/3 are supportive of a more permissive position.

That's not the case. First, you can't really extrapolate from endorsers to all of the Debian Developers. Second, endorsers might not have looked at the other proposals at all, and the fact that they only endorsed one option doesn't mean they don't support the others. And you can also endorse an option if you believe it is a valid, useful proposal to add to the GR, even if you don't agree with it personally.

But most importantly, when Debian votes, you don't vote for a single option, instead you rank the choices, and apart from the given options, another option "further discussion" is always added to the list of choices. It's likely that many who rank the most permissive option first will rank the lesser permissive option second, above "further discussion", or they could even give options the same rank (if they really don't think one is better than the other).

If you do a rebase -i because you want to squash or fix some commits, then there's git commit --squash and git commit --fixup commands which will mark commits as intending to squash or fixup another commit, and then you can use git rebase --autosquash <base> to automatically do what you want in one go. Of course, often you forget to use the --squash/--fixup options or you can't be bothered to lookup the hash of the commit you want to fix, so you'll end up using git rebase -i anyway.

I actually tried doing it as a Vulkan compute shader, continuously simulating 128 strings (all possible MIDI notes). It didn't work very well. While the latency was tolerable, it was slower than doing the same on the CPU (although this was with an integrated GPU, not a dedicated card).

The simplest form of string synthesis is perhaps the Karplus-Strong algorithm (https://en.wikipedia.org/wiki/Karplus%E2%80%93Strong_string_...). Instead of simulating the motion of all parts of the string for each timestep, it simplifies it to a perfect transmission of motion, except at the end of the string where some function will be applied that captures the losses from the motion, typically by performing a simple low-pass filter. Computationally it is very efficient: just a few FMA operations per sample. The drawback is that you need a buffer to store the state of the string, which can be quite large (especially for low frequencies which correspond to long strings), and you need to read and write to different parts of this buffer. Thus, if you are simulating multiple strings, it's more likely that memory bandwidth will be the bottleneck instead of raw compute power.

> However, I have to wonder about the cost of these projects.

A very good way to deal with this is to recognize that all infrastructure needs maintenance and periodic replacement. Once it is time to replace a road, that is when you change it to include bike paths, bus lanes and so on.

You need some foresight, planning, make new road designs part of law, and political will. Some countries have made this work very well.

Nice, although if you already are running your own DHCP and web server, it's very easy to add a TFTP server and configure everything to serve whatever you want. So it does feel a bit like reinventing the wheel to me.

A PXE boot server has many uses. The project already mentions using it for tools like GParted, Memtest86+ and so on. Booting live OS or OS installers via netboot.xyz is also great. But you can automate things even further; at a previous job (~18 years ago) I used PXE to serve a debian installer image with a preseed file to add user accounts with SSH keys, apt install all the dependencies, and install local binaries to get machines up and running useful stuff without needing to do any manual configuration. Nowadays you'd probably just have it do a minimal install + add just an SSH key, and then let another tool like Ansible take over the rest of the provisioning.

It's definitely possible, but I agree with many other commenters it probably will not happen.

I wrote an encrypted mesh networking library that runs on normal operating systems. A customer asked me if I could make it run on an ESP32 with 520 kiB of RAM. At first this seemed impossible, but it turned out that it was, and not even that hard. While the original library was not memory hungry at all for a desktop CPU, it still wasted space on unnecessarily large buffers. Cutting those out made the library run on an ESP32 while leaving plenty of room for an application.

Also, my first PC was a 200 MHz single-core 32-bit AMD k6 with 32 MiB of RAM. This ran a graphical OS with browsers, word processors, 3D games and so on. Nowadays you can get a CPU with more than that amount of RAM as just built-in cache.

So a good place to start optimizing code would be to actually get a "severely resource constrained" computer and start making your code work on it.

Ok, but that would just be your own website having a single point of failure, not that Let's Encrypt is a single point of failure. Otherwise you could call every certificate authority a single point of failure.

No, it's not. You can always switch to a different SSL provider. There are other free ones (as mentioned in other comments).

However, thinking about how to make your own setup more robust without having to manually change configuration when one SSL provider stops working is a good exercise. I wonder if you can just get your server's private key signed by multiple SSL providers, and serve multiple certificates to clients, and whether all browsers handle that correctly.

Very nice. I wonder if implementing a one-instruction set computer (for example something that implements Adrian Cable's subleq VM, see https://www.ioccc.org/2025/cable/) would be educational and whether it can make the design of a computer from discrete logic chips simpler or more complex. Though it would very likely not be as efficient.

Nice! What surprised my about the IOCCC submission though was how fast it ran. Sure, subleq can at least do some useful arithmetic in one instructions, but it still requires a lot of instructions to do an integer multiplication, let alone a floating point operation. But DOOM was actually playable with a decent FPS.

Seems like this does the reverse of the C64 demo "A Mind Is Born" (https://linusakesson.net/scene/a-mind-is-born/): that one is making music first, and simultaneously interprets it as graphics. Of course that C64 demo is huge compared to this x86 one :)

There was a wild range in capabilities in the various BASIC implementations of that time. I grew up with an Amstrad CPC6128, it came with Locomotive BASIC (https://en.wikipedia.org/wiki/Locomotive_BASIC), which was very capable: at one point I had written a multiplayer game with background music in it, without needing a single PEEK, POKE or CALL. The few times I saw Commodore BASIC programs it was littered with those three.

I'm happy that my bank (still) allows me to have both a stand-alone reader and a mobile app to authenticate. Because if you lose your authentication device, a lot of things suddenly get a lot harder.

I also tried to use an old phone as a backup device. However, most authentication apps only allow it to be installed on a single device.

And even if you avoid external libraries, you still need to interact with the kernel to do I/O, and that involves system calls that are also non-portable.

I would use RFC2822 as the underlying format to store any kind of message (pull request, review comment, issue etc.), and of course when displaying messages use CommonMark to style them. Any metadata goes into headers, and Message-ID/In-Reply-To/References headers can be used to link them all together. Using this well defined format you can then decide how to best store and transport all the messages, maybe in a git repo as well, use email, or whatever else works.

I personally think Gerrit works much better than whatever GitHub et al. have for code reviews. As for CI, I would try to keep that out of it as much as possible; just hooks to start a pipeline and to display the result and decide whether to allow a merge or not.

Rust's FromStr only deals with parsing a single object. However, ideally std::scan() would be an exact counterpart of std::print() and would be able to parse multiple objects. I totally agree that the C way of passing references to already existing variables is not great. Ideally you return a tuple of objects, but then it becomes very annoying to specify the types. Maybe something like this?

    auto [value, text, goose] = std::scan<int, std::string, Goose>(input, "{} {} {}");

A halfway solution would be to have the hypothetical std::scan() take references to std::optional<>s or std::expected<>s:

    std::optional<int> value;
    std::optional<std::string> text;
    std::optional<Goose> goose;
    /* auto result = */ std::scan(input, "{} {} {}", value, text, goose);

The latter would be type safe, close to how scanf() works, but less satisfying from a functional programming standpoint.

Orthogonal to that, adding support for scanning a Goose would be just like how you add a formatter for it, and would be quite similar to a Rust trait. One could imagine having to define something like this:

    template<>
    struct std::scanner<Goose> {
        constexpr auto parse(std::format_parse_context& ctx) {…}
        auto scan(std::format_context& ctx) const -> std::optional<Goose> {…}
    };

The C example could have implemented a lot of validation just by checking the return value of sscanf():

    if (sscanf(user_input, "%4u-%2u-%2u", &year, &month, &day) != 3) {
        // return an error
    }

This still does not catch trailing garbage, but you could check for that as well:

    if (sscanf(user_input, "%4u-%2u-%2u%c", &year, &month, &day, &dummy) != 3) {
        // return an error
    }

The result would be 4 if there was at least one trailing character. Too bad there is still no std::scan() companion to C++23's std::print().

Yes, but this project doesn't do anything analog to begin with. It could just have several S/PDIF and I2S inputs, and convert that to USB. You probably don't want any processing then, and just pass the digital inputs straight to USB. The limit of how many channels you could simultaneously process would then be the USB bandwidth.

I wonder if you could have it play the music as well by the right timing of flipping, just like how the Floppotron works.

The SourceHut UI looks weird compared to commercial offerings, but every time I use it I am pleasantly surprised how fast it is and how little clutter there is.

I worked on an open source application, and some people wanted to use parts of it as a library in their commercial applications. So I started a consultancy due to that demand. I still had a regular job at the same time though, so there was never a need to gather enough clients to make a living out of the consultancy job.

Things I learned:

- Get an accountant ASAP, even if the income is small. Just the peace of mind that my taxes were being filed correctly was worth the cost.

- You don't need a perfect solution from the start, you are working with your client towards something they can use.

- You need to stay on top of things and communicate regularly, even if your client doesn't.

- Almost all clients wanted me to either come work for them or sell all (rights of) my work to them. This is understandable from their side, but if you want to stay independent you need to set some boundaries.