3 ms·

Former 1990s pizza delivery driver here. I used paper maps extensively. He's right. He's right that speed matters. It matters when you are driving in traffi

Former 1990s pizza delivery driver here. I used paper maps extensively. He's right. He's right that speed matters. It matters when you are driving in traffic and you need to know where to take that left turn. I don't use Google Maps or any map app when I'm driving because it's too damn dangerous. Much better to take a screenshot of the map beforehand because jpgs don't take 45 seconds to load. Sure, you can pull over and wait a minute for the map to load (and sometimes I do this), but with a paper map you can just fold it so that the area you are driving in appears and with a glance you can see where that turn is. Load speed ~0.5 seconds. The issue, as far as I am concerned, is not with the UI of the apps, but with the OS. It strikes me as completely primitive that modern OS's (and I include browsers, because they are basically a one-abstraction-layer-higher OS) don't have a proper way of prioritizing the user's needs, instead leaving it to the applications. It's an abdication of responsibility IMHO. I'm sure there are challenges and reasons why it is that way. Maybe there are experimental OS's which do this properly or ways to tweak existing ones. I don't know enough about this. I'd be happy to learn more from those of you who do...

6510 6y ago
> don't have a proper way of prioritizing the user's needs To me that means it is no longer my/your computer. > Maybe there are experimental OS's which do this properly https://en.wikipedia.org/wiki/RTLinux https://en.wikipedia.org/wiki/RTLinux Funny: In JS I tried to find the maximum number of http requests a system could make. Async operations have unpredictable response time. Parsing the payload when it is returned was not an option since you end up with more parse jobs than the system can deal with at that moment which freezes the UI. (Earlier requests may arrive late, later requests might arrive soon.) So I ended up de-async-ing the tasks an doing them with setInterval (which requires checking the time or it will cluster up the parse tasks again) and tuning down the number of requests if there are many unfinished parse jobs. Now, if the user clicks something everything waits except dumping the responses into an array. Previously I couldn't lower the number of requests far enough to completely avoid UI freezes. They only got less frequent. With everything synced properly I can push the rate of the requests 20 times higher without freezes than async with 1 freeze per minute.

6510 6y ago

> don't have a proper way of prioritizing the user's needs To me that means it is no longer my/your computer. > Maybe there are experimental OS's which do this properly https://en.wikipedia.org/wiki/RTLinux https://en.wikipedia.org/wiki/RTLinux Funny: In JS I tried to find the maximum number of http requests a system could make. Async operations have unpredictable response time. Parsing the payload when it is returned was not an option since you end up with more parse jobs than the system can deal with at that moment which freezes the UI. (Earlier requests may arrive late, later requests might arrive soon.) So I ended up de-async-ing the tasks an doing them with setInterval (which requires checking the time or it will cluster up the parse tasks again) and tuning down the number of requests if there are many unfinished parse jobs. Now, if the user clicks something everything waits except dumping the responses into an array. Previously I couldn't lower the number of requests far enough to completely avoid UI freezes. They only got less frequent. With everything synced properly I can push the rate of the requests 20 times higher without freezes than async with 1 freeze per minute.