willx86

They changed their config to lua, so no more hyprland.conf good thing nix has rollbacks !

Maybe migrate sooner rather than later

Kinda like jackass, fascinating to watch but damn I do not want to do it

Try it out :)

uv init uv add XXX uv run main.py

( You can pin python versions and auto install them etc )

https://github.com/will-x86/nixos-dotfiles

( ./home/base/nixvim)

One small thing I have now got 30 more red dots as during my gym session I regulary change the music by opening my phone :)

They exist, e.g. https://www.coolspotgaming.co.uk/products/custom-game-boy-ad... ( I haven't used this service )

This seems like a good mid point between a $500 cartridge and having no friction between games

Are you not wasting 8 bits using a Qn.m of 8.8? If you values are only 0-1?

A bit like this? ( iocaine is newer)

Same with chips, efficiency, speed, etc all depend on good design, and cutting edge factors, if the main reason your chip isn't faster is because of the distance between your L1 cache and your core is far, then having a bigger node process but bigger chip won't make it quicker.

I've has more core dumps/seg faults than any other language I've ever used.

Skill issue? Yes, 100℅, it's definitely due to my lack of skill in the language

The only time I've ever made a rust program seg fault is when using nightly macros/"features" and being on stable, leading to rustc crashing with a nice error and then I change to nightly

and that was caught at compile time...

Skill is a huge factor in safety

"70% of vulns are..." Yes, production code written at huge companies by experts... If experts are making those mistakes, that says a lot about it IMO

That being said, I'm not a "one language for all", they have their place, embedded rust is hilarious as it's essentially a requirement to have unsafe blocks in your initialisation

Anyway rant over

An introduction into topics that are a bit deeper than typical are very interesting to me

It may not make me an expert in the topic reading this, but it at least gives me some new information and if I'd like to know more, I know what to look for.

Before this article if I wanted to know more my searches would be "How does Go memory management work"

Maybe I'm in a minority as this being not trivial information to me though

Short thing, when I built something similar using chromedp I had to scroll on some pages to properly render all of them, due to lazy rendering on some websites ( also some pages had infinite scroll so had to break after a certain amount scrolled)

Might be worth adding it as an option ( unless it is already)

Nice project

Using context here would be great so jobs can be cancelled instead of timeout