onlydnaq

Something about that headline really irks me. I think GitHub is an amazing place for people to share code, I also think it’s really nice of them to do this.

But the maintainers aren’t “their” maintainers. They are maintainers using GitHub for their projects.

Probably just me overreacting, just thought I’d mention it.

Without having looked into it too deeply I feel that they are somewhat “cheating” by using a superserver to launch a new process for each connection, thus letting the OS handle the dynamic allocation needed for each connection.

Still pretty impressive project. Would be fun to take a deeper look at it at some point.

A CPU can halt as a power saving measure, and still respond to interrupts.

I have one of the full size Ploopy trackballs, and it feels really good in the hand. It is 3D-printed, and it shows, but the texture of it feels pretty nice when using it.

I struggled a bit with accuracy at first, but now I’ve lowered the DPI to around 500 and it’s become much more usable for me since.

It's worth to know that the watch also tracks HRV whenever you use the Breathe app, so if you want to get consistent HRV readings the easiest way is to use Breathe once a day (for example right when you wake up).

That was their April fools joke though.

> Could I have done all that in a single shell, then had it automatically cleaned up when I was done?

Yes, that is a pretty standard workflow for most nix users. You either set up a shell.nix for your project with all of its dependencies, or if you need a certain tool once you just write for example: ‘nix shell -p iotop’ to enter a shell where iotop is in the path.

Why would anyone use rdrand directly? Seems like user space applications should use getrandom() or /dev/urandom and the kernel should use rdrand as a complementary random number source in its random number generator.

No user space program should need to use rdrand directly at all.

That’s exactly what I meant as well. SQL may be the implementation, but if so with a well designed exposed schema, not with the application internals.

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly.

A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. Inserting multiple objects in the same transaction?, already implemented. Updating several fields at the same time as well? Getting only the entities you are interested in together with their subentities?, well that’s what a relational database does.

As I said, I’m not a web developer, and I haven’t touched on use cases where a lot of different things need to happen on server operations, but all the examples in the article would be easily solvable with SQL.