gsliepen

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, "{} {} {}");

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

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
    }

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

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.

That's an easy answer, but multi-process mutexes are supported on Linux (and perhaps other OSes as well), and it would be nice if this could also be safely handled by something like Surelock. If it would, then it couldn't rely on VM addresses to order locks.

What about mutexes living in shared memory, and each process having a different address mapping?

Something similar: https://www.youtube.com/watch?v=7t7_naYJnHo Source code can be found here: https://github.com/spookysys/attiny-synth

A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinventing the wheel, and each of them has to deal with all the quirks of the graphics drivers. I think this is a big problem with the architecture of Wayland. There really should be a standard library that all desktops use. Wlroots aims to be one, but I don't see Gnome and KDE moving to it anytime soon.

I did move from physics to becoming a SWE. I could put the knowledge I gained doing 3D rendering and GPU compute used for visualization and simulations in my academic jobs on my CV, and get a job as a SWE that way. Later I moved to another job where I could use my physics background to help develop a new sensor.

As for how to market yourself: first you should convert your academic CV to one that is suited for the type of companies you are applying for. Unless you wrote something that ended up in Nature or some other super high profile journal, companies typically don't care about your publications. What they do care about is things like: can you communicate well? How well can you organize things on your own? Do you handle stress well? You did a PhD, so the answer to those things is yes, you just need to write that in your CV in a way a company recruiter/interviewer understands, even if they themselves are not from academia. So you don't have two halves that belong to different resumes, you are just one person and you just translate your resume to the "language" that your prospective job provider speaks.

Finally, your list of skills does not need to be a perfect match for what a company is looking for. Of course, there needs to be some overlap, but as long as it means you can pick up new things quickly, it will be fine. That and being a good fit for the company's culture are the most important things.

I did not start out with a unicorn role, but in I found ways to apply my physics background in my current job.

I used GIMP before I ever used Photoshop. My experience was the opposite. I think that means the UIs are different, but there is no one that is objectively better, it's just a matter of what your expectations are, which are set by whatever you learned first.

As for CMYK support: why do designers even need to use this? Sure, not every RGB is the same, and it took some while before we even got sRGB as some standard, but the same goes for CMYK: every printer has its own profile. I had the displeasure of trying to get the CMYK profile of a "professional" printing company that only accepted files in CMYK, and they didn't even know which profile their printers used. Ideally you would send a RGB file including the display profile your screen uses, and then the printing facility converts that to whatever CMYK they need.

Of course there are also special colors or effects outside of RGB/CMYK that you might want to use when printing something, that's something else.

You are assuming division itself is an O(1) operation. However, it also scales with the size of the number. So more correct would be to say that this naive method is O(sqrt(N) log(N) log(log(N))).

If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. It just is the right solution for the job.

The three drawbacks of the original TCP algorithm were the window size (the maximum value is just too small for today's speeds), poor handling of missing packets (addressed by extensions such as selective-ACK), and the fact that it only manages one stream at a time, and some applications want multiple streams that don't block each other. You could use multiple TCP connections, but that adds its own overhead, so SCTP and QUIC were designed to address those issues.

The congestion control algorithm is not part of the on-the-wire protocol, it's just some code on each side of the connection that decides when to (re)send packets to make the best use of the available bandwidth. Anything that implements a reliable stream on top of datagrams needs to implement such an algorithm. The original ones (Reno, Vegas, etc) were very simple but already did a good job, although back then network equipment didn't have large buffers. A lot of research is going into making better algorithms that handle large buffers, large roundtrip times, varying bandwidth needs and also being fair when multiple connections share the same bandwidth.

They shouldn't; the whole point is that the IP header is enough to route packets between endpoints, and only the endpoints should care about any higher layer protocols. But unfortunately some routers do, and if you have NAT then the NAT device needs to examine the TCP or UDP header to know how to forward those packets.

Could be an interesting chip for a future Raspberry Pi model? With Radeon having nice open source drivers, it would be easy to run a vanilla Linux OS on it. The TDP looks compatible as well.

Predicting the future is very hard (think butterfly effects, Lyapunov exponents and so on). It's also easy to extrapolate what would happen if the current situation continues unchanged, but very hard to predict what will happen in the near future in response to the current situation. People are already reacting to changes in politics and climate, thereby softening the blow, and maybe in some cases averting it.

I'm hoping Charles Stross knows this, and you should take his predictions as "this is what would happen if we did absolutely nothing about it".

Nice. Note though that you don't necessarily have to limit everyone else to email; some messaging platforms allow one user to post something using a webpage for example, and cause that to send email to another user, and vice versa. One data point: GitHub's issue tracker can forward issues as email, and you can reply to those back via email, and your response will end up as a new comment on the issue.