accelbred

Hyperfine is a really useful tool.

Weirdest thing I've used it for is comparing io throughput on various disks.

Nice! I was planning to try this at some point to bootstrap my environment, so nice to know its possible.

I work for the team that maintains coreMQTT (https://github.com/FreeRTOS/coreMQTT)

Its a C89 MQTT library intended for embedded devices.

MMUless embedded with FreeRTOS. For example, at one point, we did not want connecting over TCP to block our command handler, so created a task that waited for a notification, and connected on that task, and went back to waiting for another notification. Though we ended up combining some tasks' responsibilities to reduce the amount of total stack space we needed.

I have the opposite experience, working in embedded (C, not Rust...). Building a synchronous API on top of an async one is hell, and making a blocking API asynchronous is easy.

If you want blocking code to run asynchronously, just run it on another task. I can write an api that queues up the action for the other thread to take, and some functions to check current state. Its easy.

To build a blocking API on top of an async one, I now need a lot of cross thread synchronization. For example, nimBLE provides an async bluetooth interface, but I needed a sync one. I ended up having my API calls block waiting for a series of FreeRTOS task notifications from the code executing asynchronously in nimBLE's bluetooth task. This was a mess of thousands of lines of BLE handling code that involved messaging between the threads. Each error condition needed to be manually verified that it sends an error notification. If a later step does not execute, either through library bug or us missing an error condition, then we are deadlocked. If the main thread continues because we expect no more async work but one of the async functions are called, we will be accessing invalid memory, causing who knows what to happen, and maybe corrupting the other task's stack. If any notification sending point is missed in the code, we deadlock.

Not only prototypes but typedefs with function pointers as well.

I end up using a .S asm file with .incbin directives to embed files.

#embed would be much nicer

C++ can seamlessly include C89 headers.

The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++.

Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

Are strings used for timestamps? Those are usually why I'm sending 64-bit ints over IPC.

magit supports git-absorb out of the box if its installed; see the magit-commit-absorb command. I find it quite useful.

Thats not part of stock gnome. In stock gnome, that bar is only in the activities screen.

Gnome is the only out of the box desktop environment I like.

KDE, Cinnamon, XFCE, and others drove me to hacking together something with i3 or bspwm. At that point, I hadn't tried modern Gnome myself due to what others said about it, and having last used Gnome 2. I ended up using it at work though, and I shortly converted all of my machines over. Its been great.

I am glad that Gnome doesn't fall in line with other desktop environments; I don't like the others. Gnome breaking old conventions and making something new is what makes it good. I don't like KDE, and I don't want Gnome to copy it.

I also dont get the issue with the top bar. It wastes a lot less space than the taskbars in other desktop envionments. I also do want the time and wifi status somewhere, and Id rather not have some notch.

I also only use Gnome on desktops/laptops, but I find the settings menus nice to navigate and aethetically pleasing.

The author mentions dragging to top as awkward for maximizing but thats what I use on other DEs as well. And if I want to see a window behind the current one, I bring that window to front, not minimise the front window. Gnome's hot-corner to window selection screen is a huge usability improvement over minimizing a bunch of windows to get to the one I want.

You can use right mouse to resize if preferred; its an available setting.

I only really use the file manager for moving around files or unpacking zips. Most stuff I'll do from shell or Emacs. I haven't missed any features from the file manager, and I wouldn't want something with more complexity for my usecase. If I wanted a more powerful file manager, I'd install one.

A lot of customization is available through extensions, though I've ended up preferring the stock experience plus an exension that adds a button to keep laptop from going to sleep.

Another huge reason I would not use KDE is that its difficult to declaratively configure. The DE should not depend on persisted state. This is trivial on Gnome because everything is configured with dconf, and my declarative system configuration (using NixOS) has all my changed dconf settings. I only persist data and minimal state between reboots, and Gnome needs nothing persisted for me to always boot into my clean, configured as I want, Gnome DE.

Even most unsupported titles work. You can enable the setting to allow running unsupported games with proton as well. If a game doesnt work, you can refund it with "it doesnt run on Linux" as a reason. Of all the games Ive tried, only had to do that for three.

Kani will find 1023 unless you constrain the input. The link you posted is saying a property test is unlikely to find it but Kani will find it.

I signed up for Discord long before they required a phone number (my account still does not have one).

If I had not, then I would not sign up with a phone number to access some chatroom.

Why would Matrix be a non-starter?

I've recently switched from Discord to Matrix and its been a breath of fresh air.

Ollama has a opencl backend. I'm on Linux and clblast works great with AMD cards. As far as I remember opencl on Windows did not have that much issues, but its been a while.

I just use Tailscale to make it available on other machines. I use the interface through Emacs.

I'm using it on an AMD GPU with the clblast backend.

You can run it on a different machine. I've set up my desktop to host ollama, and use it from my laptop just fine.

I used Arch for years, and left it due to poor stability. Every time I would try to use an AUR app it would be broken and need re-installing. Sure the non-AUR stuff was mostly fine, but a lot of necessary applictions are in AUR, and AUR is touted as a major selling point of Arch. When there was an issue during a system update, recovering the system was a mess. I also cannot call it stable when you can't update one application without updating the rest of the system.

I switched to Gentoo and it fixed all the issues I was encountering with Arch, and was more stable. Now I'm on NixOS, which is far more stable than Arch or Gentoo were.

Now, that said, the way SteamOS uses it, I don't see any issues. With an immutable system, A/B updates, and tested images, the compatibility and update issues are solved. Using flatpak for user applications solves the rest of the noted issues. Would be ideal if I could install with Nix instead of Flatpak, but ran into some trouble there.

Looks cool!

If it gets support for ollama or the llama-cpp server, I'll give it a go.

On Gnome, you open the disk manager. You click format.

In fact a lot of things are easier. On windows, you need a third party tool to install an iso onto a disk. On Gnome, you open disk manager, right click disk, click restore from image.

Any exception thrown with -fno-exceptions results in std::terminate. The behavior of std::terminate is unspecified.

C89 is a requirement where I work still, so C89 libraries are useful here. We support vendor C toolchains that don't always have C99 features.

Magit is great. So not all have failed.

This is a bad take by the author; users wanting stability should be on the release branch, or pin commits on master. It should be expected that the development branch is used to develop in-progress features. Sometimes these take a while to hammer out. If you follow master, you will have frequent breaking changes and should be comfortable reverting to a previous commit when theres something breaking your workflow. Better yet, stay on a release.

That thread increases my trust in the Wayland developers significantly.

If you wan't volume manager features, you can put btrfs/bcachefs on top of LVM

Its pretty easy to statically link with musl on linux.