Tachiyomi for manga reading

I use sync, but I think they still should be FOSS, or at least open source. Just because when anything gets left behind or never fixed, you can take it and patch it up yourself. That includes clients too, lots of good clients that get left behind because Dev stopped and whatever they were interfacing with changed.

Also not a researcher, but I also believe hallucinations are simply the artifact of being able generate responses that aren’t pure reproduction of training data. Aka, the generalization we want. The problem is we have something that generalize without the ability to judge what it thinks of.

It will in my opinion never go away, but I’m sure it can be improved significantly.

Doesn’t seem completely impossible with the estimated storage capacity, but like with all of these things, drastically changing the build up of concrete means changing the properties of the very thing used to hold your home together.

It might be cheap materials, but the effort involved also seem very high having to cut up after the hardening to create the super capacitors. Which again may affect structural integrity.

Imagine having set up keybind for our mouse, ND then the game updates and creates a new executable or two somewhere else, and no matter what you do, it never recognizes the game ever again. So no more keybind, and the only way to fix would be to set up a profile and disabled the auto switch running all other games and profiles you have…

That’s my experience with ghub, otherwise apart from clunky unintuitive ui, it at least worked.

(the game is rainbow six siege by the way, haven’t been able to use a profile in that game all year. Part of the blame is naturally that siege does things very shitty when you can include like 5 different executables that are run)

There is a small yes, but not for that big of a gap. There is some minimal advantage, which is if the framerate goes above that of a screen(even at 30 fps caps, you might hit 31 occasionally depending on how it’s limited), you get screen tearing. Screen tearing is where new and old frame overlap causing the image to tear. VSYNC and other tech avoids this, but comes at a cost of a small delay in framerate.

So the solution is simply to cap framerate either to a divisible part of the framerate, eg. 30 fps for 60 Hz screens, 60 fps for 120 Hz. You want divisible because if you create 35 fps, the frames will not be done at the same time as the screen is with showing a frame. Thus the need to have it semi matched up.

But this is a rather big loss for a good screen, so you’d like to just cap fps to a few frames below the screen Hz. Modern technologies deal with that by talking better with the screen, so the screen shows a frame until given a next one. GSYNC and FreeSync are the ones that allow variable framerate without needing to match screen Hz and FPS. (There are some limitations, particularly they can be limited to some framerate ranges iirc, and if you go above screen refresh rate you’ll still have either screen tearing or VSYNC kick in with that extra delay.)

They could make it paid only today, and it’d be instantly profitable. Most free users would transition to a free alternative, but the corporate world would easily pay for use. So would some power users. But I’m sure they are making good money with all the API use anyways, the free access is a cheap way to get mass testing and training data.