Debugging CI pipelines is so annoying, why is there no better way than committing a bunch of dumb changes until it works?
Same person as @Gobbel2000@feddit.de, different instance.
Debugging CI pipelines is so annoying, why is there no better way than committing a bunch of dumb changes until it works?
Does USB not use interrupts?
Why not go with the base version then?
Snake case and kebab case mixed arbitrarily.
man -k
to the rescue: mbsrtowcs
, strxfrm
and wcstold
are C functions.
/boot/vmlinuz-linux
This statement is wrong.
The premise is already wrong. No orchestra can play Beethoven’s 9th symphony in 40 minutes, this piece is longer than an hour.
THE MORE YOU SAVE
Very experimental, not just with microtonality but making the singers do noises that few composers dared to put into their music.
I must say I like the idea of having changes to files be bound to just the current branch, not the entire worktree (section 6.4.2), but other than that the points that are brought up don’t really seem too compelling. It certainly didn’t convince me that git has an inherently flawed design. For example, eliminating the staging area is a tempting point for simplifying git, but the authors already admit that it has some legitimate use cases.
But of course it is always nice to see some experimentation done in this space. I think the main reason why git sometimes is confusing, is because distributed version control really is a complex task, and git already does a very good job at making it tractable.
Huh? Hexagonal Architecture?
Jon Gjengset on Youtube is doing live coding where he uses neovim quite well. And you’ll learn about Rust while you’re at it.
I (luckily) haven’t had much experience using autotools, but I do suppose it was no coincidence that the injection was initiated there. I really like the comparison that was made in the post of the Meson maintainer you linked:
Several “undefeatable” fortresses have been taken over by attackers entering via sewage pipes.
That P != NP.