In that first one, the double pasted AI retort in the last comment is pretty wild. In both of these, look at the actual "files changed" tab for the wtf.
I recently reviewed a PR that I suspect is AI generated. It added a function that doesn't appear to be called from anywhere.
It's shit because AI is absolutely not on the level of a good developer yet. So it changes the expectation. If a PR is not AI generated then there is a reasonable expectation that a vaguely competent human has actually thought about it. If it's AI generated then the expectation is that they didn't really think about it at all and are just hoping the AI got it right (which it very often doesn't). It's rude because you're essentially pawning off work that the author should have done to the reviewer.
Obviously not everyone dumps raw AI generated code straight into a PR, so I don't have any problem with using AI in general. But if I can tell that your code is AI generated (as you easily can in the cases you linked), then you've definitely done it wrong.
On Linux, there's no need to use this. Modern Linux kernels implement getrandom() in the vDSO, which does similar buffering, and keeps those buffers safe in the event of forks or VM forks and kernel reseed events.
The readme says:
> Maintains all cryptographic security guarantees of crypto/rand
I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.
I didn't look, but I don't think of channels as a pub/sub mechanism. You can have a producer close() a channel to notify consumers of a value available somewhere else, or you can loop through a bunch of buffered channels and do nonblocking sends.
A different design, without channels, could improve on those.
I prefer to think of channels as a memory-sharing mechanism.
In most cases where you want to send data between concurrent goroutines, channels are a better primitive, as they allow the sender and receiver to safely and concurrently process data without needing explicit locks. (Internally, channels are protected with mutexes, but that's a single, battle-tested and likely bug-free implementation shared by all users of channels.)
The fact that channels also block on send/receive means and support buffering means that there's a lot more to them, but that's how you should think of them. The fact that channels look like a queue if you squint is a red herring that has caused many a junior developer to abuse them for that purpose, but they are a surprisingly poor fit for that. Even backpressure tends to be something you want to control manually (using intermediate buffers and so on), because channels can be fiendishly hard to debug once you chain more than a couple of them. Something forgets to close a close a channel, and your whole pipeline can stall. Channels are also slow, requiring mutex locking even in scenarios where data isn't in need of locking and could just be passed directly between functions.
Lots of libraries (such as Rill and go-stream) have sprung up that wrap channels to model data pipelines (especially with generics it's become easier to build generic operators like deduping, fan-out, buffering and so on), but I've found them to be a bad idea. Channels should remain a low-level primitive to build pipelines, but they're not what you should use as your main API surface.
> Channels should remain a low-level primitive to build pipelines, but they're not what you should use as your main API surface.
I remember hearing (not sure where) that this is a lesson that was learned early on in Go. Channels were the new hotness, so let's use them to do things that were not possible before. But it turned out that Go was better for doing what was already possible before, but more cleanly.
If you don't need "predictable randomness", like for repeatable statistical simulations, then absolutely, you should only use getrandom(). On recent Linux, this is implemented in the vDSO and is super fast. Few excuses now to use anything different.
The portable API is getentropy, which glibc provides as a simple wrapper around getrandom. getentropy was added to POSIX, and is also available on most modern unix systems, including FreeBSD, Illumos, NetBSD, macOS, OpenBSD, and Solaris.
arc4random has been provided by glibc 2.36 (2022), and is available on all the above-mentioned systems as well. If you don't want to make a syscall per request (outside Linux), just use arc4random; it'll be the fastest method available. musl libc lacks arc4random, unfortunately, but you can always ship a small wrapper.
Systems that support arc4random also support arc4random_uniform, which is a way to get an unbiased unsigned integer between 0 and N (up to 2^32-1). That's probably the most important reason to use the arc4random family.
vDSO getrandom has been in the kernel for what, two weeks? And it is only "super fast" compared to the unbelievably slow full syscall. Compared to PCG it is like watching rocks grow.
Careful with the "chacha csprng" when the seed from the seed() function appears to be 32 or 64 bits. That's not enough for the cs part. (Also the output stream appears to wrap after 2**32 blocks. Could make this larger.)
> By the end of the training, they learned to name an average of 7.08 pitches (ranging from 3 to 12) at an accuracy of 90% or above and within a response-time (RT) window of 1,305–2,028 ms.
That doesn't actually seem very promising, or at least useful at all. It still seems way less useful than my accurate and near instantaneous relative-pitch. What could I do as a musician with 2 seconds of latency to be wrong some amount of the time.
Yes, thank goodness relative pitch is trainable, because that’s all you need, almost all the time. This new ability would let you come in on the right pitch for your first note, which is a cool trick. But after that, relative is fine. Indeed, it would be awful if you heard everything absolute and had to translate to relative (I’m guessing you can do both at the same time, though).
Your relative pitch gets decent within a few weeks of practice (<10h).
Getting it always right takes longer, and so do "weird" intervals, but the basic intervals are not that hard. Also, basic knowledge of song structure, phrases, and chords helps with relative pitch, because it narrows down the set of choices in many circumstances.
After all, the most useful exercise of relative pitch is "what's that melody", not "what's that random interval".
As for precision of relative pitch: After a year of weekly training, most people are able to tune a guitar to within 2-3 cents. Which is, granted, a very specific form of relative pitch, but it shows you can get pretty good precision at that. It probably extends further. (IDK, I have seen no examples of people explicitly practicing microtonal relative pitch outside of "tune an instrument")
The WireGuard project is also in the same situation, due to Equinix Metal shutting down. If anybody would like to host us, please reach out to team at wireguard dot com. Thanks!
Saw that. Looks appealing, but I'm not particularly keen on, "We only require that you keep one sudo-enabled account on the system for us to use as needed for troubleshooting." [1] Do I want to give root access to the project's master git server to somebody I've never met, who is probably a good & nice person, but not really directly associated with the project? In general, I'm wary of places with relaxed enough informal policies that somebody could just walk over to a machine and fiddle with it. It's not that I actually intend to do some kind of top secret computing on Internet-facing machines like those, but I also don't want to have to be _as_ concerned about those edge cases when I'm deciding which things to run or host on it.
Thank you for wireguard - it's been a hugely impactful piece of software.
Do you think it would be helpful to outline what hardware resources you would need to successfully migrate the project and all the CI/CD computations to a new home? This would help people determine if they can help with hosting.
No, it's considerably more involved than that. For example, there's extensive CI: https://www.wireguard.com/build-status/ This thing builds a fresh kernel and boots it for every commit for a bunch of systems. And there's also a lot of long running fuzzing and SAT solving and all sorts of other heavy computation happening during different aspects of development. Development is a bit more than just pushing some code up to Github and hoping for the best.
https://github.com/WireGuard/wireguard-android/pull/82 https://github.com/WireGuard/wireguard-android/pull/80
In that first one, the double pasted AI retort in the last comment is pretty wild. In both of these, look at the actual "files changed" tab for the wtf.