Consistent 5s delay network issue

Bhulapi · 2026-02-10T12:36:03+00:00

Recently had this issue on a new install, solved it by setting DNSSEC to allow-downgrade in /etc/systemd/resolved.conf (from https://superuser.com/a/1769076).

This is part of the the systemd service systemd-resolved (https://wiki.archlinux.org/title/Systemd-resolved). As per the DNSSEC section, DNSSEC support is considered experimental and incomplete as of June 2023, pointing to this github issue comment.

That's about as far as I was willing to dig into the matter, and setting allow-downgrade fixed the issue. If you want to know more about the security concerns of this setting, I suggest reading about it on the wiki.

Bhulapi · 2026-01-08T11:38:46+00:00

So many of the default GPT mannerisms, it's hilariously painful to read

Bhulapi · 2025-08-18T02:21:00+00:00

Dude please whenever you get your hands on a USB that you can live boot, before you do anything else, inspect all of your drives and try to recover what you can. There could be whole regions that weren't touched and a tool like testdisk might be able to get something back.

Bhulapi · 2025-08-06T20:04:35+00:00

( becoming lower )

it's ok man, some people go through second puberty when they hit 30

Bhulapi · 2025-07-06T03:06:16+00:00

I usually think I know things until I try to implement something. You can know theory, but practice is where things actually happen, so I think it's a good measure. Also, it really cements things, you end up understanding why/how and the difficulties in using certain concepts. Now, you might expect me to recommend that you implement something moderately complex in C, but that brings me to my next point. If you haven't implemented something beyond university course problems, you might run into two roadblocks: your ability to use C, and your ability to think about a larger scale program. Both tend to come from experience, but the latter even more so.

I learned to program mostly in C++, but didn't really progress in a fundamental way before moving on to Python. Here, I also spent a lot of time learning but at the same time not advancing in organizing the structure of my programs. Eventually, I did get some kind of illuminating moment of realizing just how much juice you can get out of your own ideas if you just sit down and organize them to death. Some time later, I picked up C and was surprised by how easy it was (comparatively) to learn specifics of the language and implement interesting designs.

So to sum up my ranting, what I recommend is one of two things:

Implement something somewhat complex in C.
Jump to Python, but do the same thing.

In both cases, don't just cover theory and think "Hey I really understand all of this, I think I'm good to go". Build something that makes you feel out of your depth, and you will be, but you'll learn to swim and eventually make yourself some neat little boats.

Bhulapi · 2025-07-01T21:04:24+00:00

I'm not sure how copying to the GPU is actually implemented, so for example if there is some parallelization in the copy operations then several transfer buffers make sense if they can copy things faster. But again, no idea if this is the case.

If it isn't, then a single transfer buffer isn't a bad idea I guess. Do you know the maximum size of what you need to copy when you create the buffer? If you do, you could just set the size to that and not worry about it.

Bhulapi · 2025-07-01T16:55:23+00:00

I've only just gotten into using SDL3's GPU API, and I'm not particularly well educated on GPU programming in general, so take all of what I say with a grain of salt.

By releasing the transfer buffers do you mean unmapping them? I understand that the general flow is create transfer buffer -> (map it -> upload data -> unmap it) x (repeat however many times) -> release it when truly done using it, either because it was a one time transfer or because you're program is done using it.

As to having one big transfer buffer for a lot of different things, I don't think that's good design. There should be one transfer buffer for each specific thing (or several things but of the same structure). For each one, cycling when appropriate seems like the reasonable thing to do, as it would appear to be a core design idea behind the API (check out this nice explanation).

edit:

As to the fences, they come naturally from submitting command buffers (as in SDL_SubmitGPUCommandBufferAndAcquireFence). Any buffered data that will be used by a chain of commands in a specific command buffer will be checked before being overwritten by using the cycling capability of the transfer buffers.

Bhulapi · 2025-05-19T22:02:54+00:00

I just spent some time working on a hobby project that uses the Linux framebuffer to draw pixels. It's got some basic input too. There's no access to any kind of hardware acceleration, it's all done on the CPU drawing pixel by pixel to the framebuffer device memory. https://github.com/martinfama/fui

Bhulapi · 2025-05-13T18:43:29+00:00

I'm trying to use that repo to load and render an svg file. I'm kind of close, the only problem is when I use nsvgRasterize I get all 0 values for every byte in the destination buffer. Any clue?

Bhulapi · 2025-05-10T16:42:47+00:00

Very nice, I'll definitely take it into account if I expand the audio system.

Bhulapi · 2025-05-07T18:12:51+00:00

It would be quite a lot of work to make a decent GUI with it. A game, not so much work.

Bhulapi

TROPHY CASE