yrlf

yrlf, 14 days ago

@BrodieOnLinux I don't quite like his language there, but he does have a point that in a codebase with such a large amount of bit tricks and deliberately wrapping things it's hard to get the ergonomics of wrapping vs non-wrapping arithmetic right.

His unhinged mails are always slightly hilarious to read though.

yrlf, 14 days ago

@ljrk @BrodieOnLinux after reading through the thread in more detail a bit after posting my toot, I absolutely agree with you:

u32_wrap is a really concise type and doesn't make the ergonomics bad. I initially thought of the early days of rust wrapping arithmetic with a.wrapping_add(b) which is just painful, but this is absolutely not what this is, you are right.

1/2

yrlf, 14 days ago

@ljrk @BrodieOnLinux

I think that actually doing the conversion is probably quite a herculean task, since the kernel is HUGE. But once that conversion is done, the "extra maintainer work" that Linux is worried about is probably either zero or negative, since reviewing patches with/without wrapping arithmetic probably becomes easier, and you will see the warning anyway if you forget to add the u32_wrap the first time around.

2/2

yrlf, 14 days ago

@buonhobo @ljrk @BrodieOnLinux I read that differently:

I read it as he's gonna focus on the implicit conversion first, but not that he's necessarily gonna abandon other things altogether, but that's just my interpretation.

yrlf, 14 days ago

@buonhobo @ljrk @BrodieOnLinux There seems to be a tone of "I think this is important, but if you're not gonna take it like this I'll see if I can find a way to iteratively get things like this into the kernel"

yrlf, 1 month ago

@b0rk interesting! Apparently for branches git allowed it at some earlier version, but tags named HEAD still seem to be allowed.

I dug in that repo a bit, and it seems it had that warning for a different reason:

for some reason git internally found both HEAD and refs/heads/HEAD, even though .git/refs/heads/HEAD does not exist. I haven't figured out why that was yet, and a clone of that repo didn't have the issue.

(checked by adding a debug print to the expand_refs() function in refs.c)

yrlf, 20 days ago

@drewdevault Which STL are you using for C++ in userspace?

yrlf, 1 month ago

@TechConnectify how often do fridges need to defrost?

If it's more than a day between defrost cycles, why can't an actual "smart" fridge time those to be when you're unlikely to have JUST put new stuff in? Say, at night?

yrlf, 1 month ago

@davx5app cool update! Nice to see it much better looking :)

I have one minor visual bug report though: The "Ignore alerts embedded in the calendar" text is covered by the enable switch on my device.

Otherwise great!

yrlf, 1 month ago

@drewdevault how exactly does async I/O differ from I/O multiplexing in your understanding?

I/O multiplexing is IIUC having a single thread of execution and using poll() / epoll() / select() / ... to periodically check which I/O is ready and then handling that (either directly or via callbacks). Most nontrivial programs that do that do it via callbacks and an event loop.

1/2

@miki

yrlf, 1 month ago

@cuddle @drewdevault @miki

Even in Async I/O you don't have infinite work to do. At some point you will run out of useful work to do while waiting and you will need to block on I/O (otherwise you will needlessly spin the CPU)

With I/O multiplexing it's the same: you will repeatedly call poll() / epoll() / select() on your file descriptors, and as long as you still have useful work to do while waiting you can pass the timeout as 0 and it will not block if no fd is ready at this point.

1/2

yrlf, 1 month ago

@cuddle @drewdevault @miki

On POSIX/Linux, AFAIK the only "real" low-level async I/O API that exists is IO uring (you put work in the ring and it completes at some point in the future). All other APIs are basically variations on the I/O multiplexing model (poll() / epoll() / select()).

There is O_NONBLOCK, but all that does IIUC (correct me if I'm wrong) is to make sure that I/O calls return EAGAIN when too much work is posted at once to do it without blocking, and you need to poll() it again

yrlf, 1 month ago

@cuddle @drewdevault @miki

Disclaimer: I'm mostly extrapolating from code I've read, articles I've read, a few personal projects that attempt to not needlessly block, and a few experiments with the various APIs.

It might very well be that my understanding of this is incomplete, lacking, or wrong. If anyone here has more experience, feel free to correct me as I'd like to know more about this as well.

yrlf, 1 month ago

@jacqueline the crazy/sad thing is that this exact toot is an eerily good description for a few other discords I've seen in the past.

yrlf, 2 months ago

@b0rk is this "HEAD detached at" vs "HEAD detached from" thing explicit state that git keeps, or is this dynamically discovered from repository state?

e.g.: if you checkout some commit abc123 and detach your HEAD, then create a commit or two, git will say "detached from abc123". Will it still say that if the repo changes under your feet to have those commits (or some of them) be in the history of a new branch without changing HEAD?

yrlf, 6 months ago

@notjustbikes @WaterSword The de-facto way to do quote toots in Mastodon at the moment seems to be to just make a new toot with a link to the quoted one.

Many clients have explicit support for that, but I do agree that the situation is suboptimal.

yrlf, 6 months ago

@b0rk For me the cost of rebases is the fact that you basically have to have two completely separate mental models of what a 'commit' is.

Normally, git treats commits as the state of the repository and its whole history at some point, while with rebase and cherry-pick and the like, git treats commits and branches as basically a set of patches. (1/2)

yrlf, 6 months ago

@b0rk This patch-based model allows you to very easily rework and combine commits in a feature branch (especially with interactive rebasing!) to create a nice and easily reviewable history, which is great, but comes at the cost of making it hella easy to shoot yourself in the foot by failing to correctly merge, re-merge, split, or combine commits.

2/2

yrlf, 6 months ago

@b0rk As for bad experiences I've had with it: Especially in my early days with git, I've often had weird situations where I left an unfinished rebase with something like 'git reset --hard' and forgot to actually abort the rebase, making some things behave weirdly until I noticed a while later

yrlf, 7 months ago

@publicvoit https://suche.machs-auf.at/search?q=Linux