Remix.run Logo
goodmythical 6 hours ago

I mean, that's not at all the case.

As a trivial application of the spec, consider that there are time-limitted trials of software. Once it's run for 30m, it'll never run again without significant intervention.

If you're the kind of person that's willing to go out of your way to invalidate the control spec rather than just abide by your own time control rules, you've got a more significant problem than you're willing to admit.

We don't need software that prevents running for 31 minutes in every 24 hour period, we need humans who are both willing and able to manage their time.

I mean, can you imagine being the kind of person that blames a piece of software for one's inability to stop using said software. Like it's somehow tiktok or youtube or android or linux or who the fuck ever's fault that you can't stop doomscrolling or gaming or gambling or whatever.

As a matter of fact, every software already supports what you're asking for. Run a script that monitors focus time and kills after a certain period if you're really so unable to simply close the software based on your own paradigm. Leave the script running and have it issue kills for the entire duration of your specification. [use=focustime/24h; while use>30m/24h, kill proc.exe].

There are already existing implementations of this that, for instance, limit a user acct to a certain amount of time per period. Imagine a library that only allows 30m/account. I just got out of an environment that only allows accts to access for a maxiumum of 15m with one sign on with a 15m cooldown. If you used it for 3 minutes and signed out, you'd have to get back in line for 15m. If you demanded using it as much as possible you would use it for 15 and wait for 15.