Comment by dionidium
3 years ago
I would pay twice the going rate for a Macbook that ran a version of OSX that always immediately responded to my commands. When I hit Cmd-Q I want the app to close. Not when it's ready. Not after showing a dialog. Not after asking me if I'm sure. Not after cleaning up. Not after preparing to close. Not after doing some background processing.
Just close. I want to issue a command and I want it carried out immediately.
If the software can't do that gracefully, then it's bad software.
Same problem in Windows.
Also, there is no reason for the operating system UI to ever be stuck. If the program fails to redraw, show it blank, but don't prevent me from moving/sizing it. Even if the CPU is at 100%, I want my commands to get 1st priority. Too many times I had to spam Ctrl+alt+del just waiting for something to respond.
Or a computer you can actually power off.
Used to be: You throw a physical switch on the computer, it interrupts the power circuit from the power supply, and the computer went off instantly.
Today: You have to do it in some software menu, but invoking this, you're not even powering it off. You're requesting your computer to "pretty please, with sugar on top, turn off my computer when you're not too busy." Then the OS goes and does god knows what, maybe it decides to flush some caches, maybe it decides to do an entire operating system update, who knows--you're not the driver, you're just along for the ride.
Even the physical power button on the computer doesn't break a circuit anymore. It... you guessed it... sends a software signal begging the almighty operating system to please shut down.
And when you point this stuff out, all the excuses start coming out: "Bbbbut the OS has to flush its caches! Bbbbut the filesystem needs to write things to disk that are in-flight! Bbbbut applications need to gracefully shut down and free their memory (which is about to have the power cut). Bbbbbut there may be a critical background task still running that needs to...." I don't fucking care! I didn't command my computer to do any of these things.
It's gotten to the point where if you want to shut your computer down instantly, you need to pull the power plug or remove the battery. I expect we software engineers will fix that one some time soon, too.
> Today: You have to do it in some software menu, but invoking this, you're not even powering it off. You're requesting your computer to "pretty please, with sugar on top, turn off my computer when you're not too busy."
This captures my sentiment towards current trends in technology so aptly. I went to turn off a Windows machine the other day and the only options required allowing an update to be performed. There was no way to shut down or restart without allowing an upgrade. Fortunately I could bypass via the command line but this level of mediation is unwanted and abhorrent.
Most computers have an in-hardware function to cut power if you hold the power button down.
4 replies →
ACPI was introduced in Windows 98, so when you say “today” you actually mean “the past 25 years”. In fact it probably took longer staring at the “windows is shutting down, do not unplug your PC” screen than it takes today.
Oh, how I miss physical switches. It's not so much the lack of control, but why, oh why, does every action have to lag so horrendously?
On my pc motherboard (and all the ones I've had forever) if you hold the power button in for like 4 seconds it does a hard-power cut.
Just don't complain the next time you start it up that disk files you were writing to when the power failed are corrupted.
6 replies →
Software capable of doing some of the tasks people want done is sufficiently complex that it allows you to issue multiple commands for which immediate action would be contradictory. Telling the application to save state but then also respond to a quit command "immediately" would be one trivial example. Tell an application to quit right after you launched any operation that requires on-disk state to be modified would be the more general case. The software is not bad, it's just got enough power to allow you to make your intent ambiguous.
You can make the app window disappear while keeping the disk saving thread. It is perfectly doable.
Sure, but is that actually "quitting" ? Depends on what the user actually expects "quit" to do.
Also, you're assuming that there is a thread that saves state to disk. There may be (and if the state save is a significant operation, there probably should be). But that's far from always the case.
3 replies →
A "you have spent 3 hours working on this document without saving, are you sure you want to close?" windows used to be a good thing.
Nowadays the software should just auto-save it for you. But not all software is that well written, and the OS can't tell it apart.
So why is the OS supplementing functionality
I think there are legitimate use cases for delayed close. Especially in gaming. Some games play in ironman mode where closing the game could provide a cheat. To avoid this they need to be able to save on exit. Likewise, if the game is in the process of saving an override close could corrupt a save file which is unlikely to be a wanted behaviour for the user. Unfortunately, many companies abuse this feature and give pop-up dialogs akin to "Are you sure you want to close us?". I think the OS is in a difficult place with finding a balance as the feature itself is necessary for some developers.
Majority of the games out there always have warning before the title menu and continuing the game, the warning is always this "If you see this icon, please do not try to quit or shut down the game while it is saving". If they have that warning, then it should respect the user's command. I had a few games that locked out Alt-F4, refusing to listen to that command. The only way I can quit is through their menu then go to the main menu, then go to the title menu to confirm the quit. And the game have the gall to ask "Are you sure you want to quit?". Then what is the point of having that exit game option there if they are making us to through the hassle to quit the game.
Thankfully for SuperF4, it will force exit the game or any app that I have it focused on. I had one game that outright shamed me for doing that and I never went back to that game again. Sorry, I don't have time for games that chose to lock out the exit and three-finger salute command. SuperF4 is the boss now and there nothing that those games can do.
In another HN thread just the other day (paraphrasing, but the tone is accurate): "macOS is shit because cmd+Q kills my programs and it's too easy to hit accidentally while trying to strike cmd+A"
> In another HN thread just the other day (paraphrasing, but the tone is accurate): "macOS is shit because cmd+Q kills my programs and it's too easy to hit accidentally while trying to strike cmd+A"
On the other hand, macOS is wonderful because, if you don't want ⌘Q to do that, then you can re-bind the Quit command, and programs respect that. (I don't remember if programs have to opt-in to respecting it, or if the OS enforces it.) I know that various flavours of Linux can do this easily too, but I think that Windows doesn't have a native such feature.
I don't think programs have to opt in. You can remap it the same as every other menu command. Every AppKit app gets that menu entry by default.
The fact that remapping commands requires an exact, case sensitive match of the localized menu item label you have to type in by hand (and cannot copy to your clipboard) though...
It's hard to please everyone, and data-loss is kind of a trump concern, but actually macOS does because it has this feature. The keyboard shortcut is cmd+option+shift+escape but you can probably remap that.
I force quit apps all the time, sometimes even because I want them to restore their exact state. In a lot of apps, the macOS state restoration works great, possibly better than actually quitting them.
> If the software can't do that gracefully, then it's bad software.
What I want is that the software itself doesn't even get a chance to interfere with demands like ⌘Q. There's no reason Chrome should get to decide that it doesn't close until I hold ⌘Q; that way lies all sorts of dark patterns. (Adobe's attempt to seize control of basic OS functions is my bugbear here.)
I don't mind the OS having a system-wide setting whereby I can decide how much I want it to protect me from the consequences of my actions, but that should be a decision between me and the OS, enforced by the OS, not something I have to negotiate individually with every app.
(Same with the menu bar. I choose what goes in the menu bar, and macOS should enforce that choice, not tell me that the software has decided what goes there and I have to lump it.)
That’s a very hard constraint for a non real-time system to guarantee. It’s not necessarily a bad thing that your OS has a flexible scheduler. I think you’d find running a real-time OS as your daily development machine would have some of its own quirks you would find distasteful.
It doesn't have to be a truly real-time system. The difference here is more philosophical than technical. If the software were designed to make my demands a priority, then it could do a much better job responding to them, but nobody working on the software is thinking that way.
BeOS managed it, and Haiku continues to manage.
This is why I love Debian linux. It’s not nearly as polished as MacOS but dammit it’s quick and does what I tell it to do.
i think the reason a lot of software works that way is that most software does not carry out tasks asynchronously and even does blocking or time consuming stuff from the foreground or GUI thread instead of handing it off to a background thread. the reason for that is that doing anything async makes software exponentially more complex to engineer… so hence we have lots of apps that cannot just be stopped easily.
kill -9