Sjonny's comments

There are loads of .BAK files as well, and diffing them with the actual file gives you some insight on what they were working on. (Like pre and post Counterstrike addon).

> 5.0 came out late during development of the chip, which turned out to be mostly compliant, with the exception of some blending modes such as additive blending which Jensen Huang later claimed was due to Microsoft not giving them the specification in time.

Not sure if this is the same thing I had, but on my Riva128 the alpha blending wasn't properly implemented. I distinctly recall playing Unreal Tournament and when I fired the rocket launcher there were big black squared with a smoke texture on them slowly rotating :D couldn't see where I was shooting :D

COLORTERM is also a very weird thing. Most of the time I don't need it to be defined, but when using a screen session it suddenly looks very crappy when COLORTERM is set to truecolor. Removing the env var makes it look all normal again.

I recently got a popup in youtube to unlink the accounts, so already on their way.

There is no alternative. Either the information is required and useful and should be shown always, or it has no value and you can just leave it out.

Tooltips are the worst kind of information providers in a website. First of all you don't know they're there, you actively need to search with your mouse cursor and wait to see something lights up. And then you can only read it, no way to copy/paste information out of it. Often they also cover up other information when they do popup, and most of the time the extra information they do provide is useless.

Tooltips should be removed entirely instead of fixing 22 year old bugs.

you can run windirstat (or similar tool) on a checkout to get an idea

> The law is temporary

I'm not so sure about this. In the article he states:

> Once it became clear the intended law would likely pass parliament

and in the dutch version it sounds even worse to me:

> Na het verschijnen van het advies van de Raad van State is mij duidelijk geworden dat de verruiming van de bevoegdheden en de verschuiving van het toezicht niet meer ongedaan zullen worden gemaakt.

I can't really tell for sure if he thinks this law is here to stay, but me being a pessimist when it comes down to government, I think there is nothing temporary about this.

you're right .. it's the quote, not the comic.

I love this comic from him: https://i.imgur.com/CFq57ny.jpg

HN was down?

cool, I never knew! Somehow the game I thought it would add a feature is still lacking it. For some reason rumble on my xbox joystick with Enter the Gungeon never worked. I thought it was because of an old SDL version, because experimentation showed that. But by using the SDL_DYNAMIC_API env and loading my system SDL the game still not added rumble to my joystick. Ohwell.

It's not the system that is not supporting udev, it's the choice of the game developers how they compiled SDL .. without dependencies, and so without udev.

Upstream fixes are nice, but since the game statically links SDL you can't put in a newer version of libSDL.so in the game path and have it patched like that. Are there other ways of patching statically linked binaries with updated functions?

I've been wondering.. is it possible to write something to override the statically linked functions? In this case, most (if not all) functions have an SDL_ prefix. Would it be possible to LD_PRELOAD a library that loads a shared version of SDL and goes over all the function pointers to move them point them to a new location? Is there a tool for this?

Code is for humans, not for computers.

Choose:

  AddElement(object, true, false);
  AddElement(object, true, true);
  AddElement(object, false, false);
  AddElement(object, false, true);

or

  AddElement(object, visible::on, deletable::off);
  AddElement(object, visible::on, deletable::on);
  AddElement(object, visible::off, deletable::off);
  AddElement(object, visible::off, deletable::on);

The latter is more readable, you can spot bugs easier, you don't need to remember which parameter was for visibility, and which was for indicating deletable. And it doesn't take much more to write this than a confusing boolean. It doesn't scale.

Except this isn't an issue that should be solved at the IDE level. Not everybody is using the same IDE and has all the same features, or even the same options enabled in an IDE.

The solution provided in the article is the way to go.

This is neat. What I'm missing though is a static link to a particular card which I can then share with others.

I don't think things like this happen deliberately. To trigger this, you need to have a custom module without that specified indicator, and then you need to boot your previous kernel and notice that the module wasn't loaded. That are a lot of steps to get there which most people won't do.

Maybe kernel developers would get in this situation, but even then they'd probably had their system setup better for their situation (and maybe gone through that same process and thought it was part of the setup steps).

It's about this module: https://github.com/a1wong/it87

There is an old version of it in the kernel, which doesn't support newer released versions of that chip. I remember reading somewhere that the maintainer was being swamped with requests to make support for those chips too, but didn't get any help for it and it became a toxic environment to work on. So he dropped it.