51–60 of 151 posts
So is the moral of the story is to build an entire OS like erlang's actor model? Doesn't that work by using lightweight threads and messaging passing between them. The supervisor gives each thread a certain amount of time to run and then puts the current thread on the back burner while the next thread runs for it's allotted time. I remember hearing it in an erlang talk by Joe Armstrong on Youtube. I can't remember wh…
I agree with the main gist of the article and a lot of the points, but disagree on a few specifics. 1) mlock isn’t meant to be called on all your memory, just something that needs it to operate correctly. The situation the author described where the system comes to a halt as memory contents are paged in and out of memory/disk is (subjectively) worse when the only option is for the OOM killer to begin reaping processe…
This one's interesting since your outcome often depends on what hardware you have. On systems with slow IO, i.e. a slow HDD, it's possible for swapping to make a system entirely unusable for minutes, whereas if swap is disabled the OOM killer is able to kick in and solve the issue in less than a minute. That's the difference between being able to keep most of your work open and none of your work open (because the alternative is being forced to reboot).
Earlier quoted context omitted.
Can you be more specific about what was “solved” in the 90s? The platforms upon which apps are run now and the technologies as well as the expected capabilities of those apps have drastically changed. Not all UI development has changed just for being shiny. I see little reason why building a UI today cannot be a superset of what was solved in the 90s so I’m curious to know what that solved subset looks like to you
There were all kinds of standards, guidelines that made people recognize what the program is doing and how to operate it. Nowadays, UIs are mostly defective, trying its best to hinder effective usage and hide/strip functionality. There are of course progress too, but something was lost that make applications today much less intuitive and hard/tough to use.
Some platforms publish a list of recommended guidelines which are effectively a standard. For example here's one from Apple about when and how to use charts in an application: https://developer.apple.com/design/human-interface-guideline...
I believe it's pretty easy to resolve -- declare one thread as "UI Thread", and forbid doing any IO on it. Android (and I believe iOS does too) enforce that. It's up to the developer to show a meaningful message/animation if an IO operation takes noticeable time.
This is absolutely not true. Android simply detects that there has been no progress on the UI thread "for a few seconds" before force-closing the app [1]. By this time, the interaction has been janky/frozen for WAY too long. If you have seen bad iOS scrolling and lock-ups, you know this as well.
I have worked on mobile software for these apps that have billions of users. When I pointed out how much stuff ran on the UI thread, there was a collective "this is just the way it is" response and life went on.
It's super-depressing.
-----
[1] "Performing long operations in the UI thread, such as network access or database queries, blocks the whole UI. When the thread is blocked, no events can be dispatched, including drawing events.
From the user's perspective, the application appears to hang. Even worse, if the UI thread is blocked for more than a few seconds, the user is presented with the "application not responding" (ANR) dialog."
https://developer.android.com/guide/components/processes-and...
Earlier quoted context omitted.
You are replying out of context: if your file is on a network drive it doesn't matter if you have shiny UI, or text based terminal, you gonna wait for the round trip with your UI being unresponsive
That doesn't follow. Your UI can be responsive while the round trip happens. The application won't literally stop working 100%.
Earlier quoted context omitted.
UI was pretty much solved in the 90's including the problem of instant feedback. Then abandoned for shiny stuff. Personally I set up i3 to open most windows asynchronously, so my flow isn't interrupted. It's great, but takes a bit getting used to windows not randomly stealing focus. It's not for everyone though.
Can you be more specific about what was “solved” in the 90s? The platforms upon which apps are run now and the technologies as well as the expected capabilities of those apps have drastically changed. Not all UI development has changed just for being shiny. I see little reason why building a UI today cannot be a superset of what was solved in the 90s so I’m curious to know what that solved subset looks like to you
This was broken with Ribbon and the hamburger menus that every application seems to have switched to for no other reason it seems than to copy Chrome.
To be fair Ribbon is somewhat useable again, but the in the first version I have no idea how people were supposed to find the open and save functions :-)
Other problems:
Tooltips are gone. Yes, I can see they are hard to get right on mobile, but why remove them on desktop while at the same time when the help files and the menus were removed?
The result is even power users like me have to hunt through internet forums to figure out how to use simple features.
Back in the nineties I could also insert a hyphen-if-needed (I have no idea what it is called but the idea is that in languages like Norwegian and German were we create new words by smashing other words together it makes sense to put in invisible hyphens that activates whenever the word processor needs to break the word and disappears when the word is on the start or in the middle of a line and doesn't have to be split.)
Back in the nineties I was a kid on a farm. Today I am a 40+ year-old consultant who knows all these things used to be possible but the old shortcuts are gone and I cannot even figure out if it these features exist anymore as documentation is gone, tooltips are gone and what documentation exist is autotranslated to something so ridiculously bad that I can hardly belive it. (In one recent example I found Microsoft had consistently translated the word for "sharing" (sharing a link) with the word for "stock" (the ones you trade).
Earlier quoted context omitted.
Someone has not told Microsoft | It is not as simple as that. On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive. This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching it…
> Someone has not told Microsoft More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perf…
no, they just don't care.
Earlier quoted context omitted.
Strangely enough, I had the same experience with diablo 4 until I turned down some of the graphics settings. I'm not sure if it was some DLSS / frame generation thing or what, but the game felt sloppy to me. Especially in comparison to something like diablo 2 which feels razor sharp. I wish modern game developers & graphics pipelines would spend more effort optimizing input latency. I'll stop noticing the graphics 2…
> But if the input is laggy, I'll feel that the entire time I'm playing. You've already bought the game at this point so most devs don't care.
An insane amount of money and effort that goes into most AAA games. It seems like a stretch to accuse the industry of not caring about the quality of the games they make.
Edit: I was completely wrong, but the article is very interesting.
Earlier quoted context omitted.
Metal Slug on the PS4 was jarringly unresponsive compared to my expectations, though I'm not sure I've played it on an arcade machine in 20 years so maybe it's my memory or physiology at least partly to blame.
If I recall correctly, the PS4 controller has a disgusting amount of input delay. I noticed this most strongly on the FFX Remaster where you need to hit timer events before the arrow enters the shaded box. It doubly screws you in the chocobo racing section because the controls assume no delay, meaning you can’t respond to hazards in time and constantly overcorrect movement.
The obvious fix for laggy input is to apply the same processing to local input, but I've not heard of anyone doing this.
(I think this technique is known as netcode.)