Live data from Hacker News

macOS Sonoma Boot Failures

github.com

191–200 of 290 posts

Re: macOS Sonoma Boot Failures

#191
post #184

Earlier quoted context omitted.

Documented by whom? Are you going to show a marcan post to them and claim it’s an Apple issue?

Marcan's post contains apple ticket numbers... presumably you show them those.

Apple store employees probably may not have access to bug reports that their engineers would be able to access?

Re: macOS Sonoma Boot Failures

#192
post #166

Earlier quoted context omitted.

> Text-only BIOS setup was the norm for a long time I've had a GUI BIOS setup on almost every PC I've owned since the first 486 I built back in 1993.

The GUI was rendered in text mode. It's called a TUI (Text-based User Interface)

TIL, I thought TUI meant Terminal UI

Re: macOS Sonoma Boot Failures

#193

Earlier quoted context omitted.

Text-only BIOS setup was the norm for a long time before the stupidly bloated EFI graphical stuff became common. Even then, there were the better full-featured TUIs: https://upload.wikimedia.org/wikipedia/commons/0/05/Award_BI... https://liveusb.files.wordpress.com/2010/05/awardbios-firstb... And the simplified crap with tabs that often came with prebuilt PCs but later seems to have spread to others too: https://cdn.…

To my horror, I recently had to visit the UEFI firmware setup of a Lenovo tablet.... That was touch enabled.

Most gaming laptops' UEFI screens are so "gamer" it's cringe. Dell XPS series have UEFI GUIs that are quite neat and absolutely an improvement over the text screens.

Re: macOS Sonoma Boot Failures

#194

Earlier quoted context omitted.

The messiness of resolutions during boot always annoyed me on PCs. It was understandable back in the days of BIOS, but ith the advent of UEFI it seems like it should be possible to run EFI config screens and the like at monitor native rez (or at minimum, native aspect ratio) but I’ve never seen this… it’s always 1024x768 or somesuch stretched to fit a 16:9 monitor which looks awful.

EFI config screens should be text mode only, full-stop. So they can easily be used over serial console redirection. Ran into one recently that was high-rez graphical. It needed a USB mouse to change critical settings because the tab order for the onscreen widgets didn't work. Anyone responsible for creating graphical EFI config screens should stop writing software for the good of humanity.

Upside though? I was helping a more software-oriented buddy get a PC build up and running that'd been half-finished by some kid he paid to put it together. The GUI on the EFI config was so intense, it was slowing down and completely locking up.

Got into the temps, realized that the CPU fan had been plugged into an AUX fan header instead of the CPU header.

Fan was spinning, wouldn't have thought to check if the EFI wasn't crashing.

I'm completely joking of course. I completely agree with you, I miss text-only mode. The modern Dell one stinks, the Asus one stinks...I have no data, but I'd be shocked if Gigabyte or ASRock were any good... :(

Re: macOS Sonoma Boot Failures

#195
post #38
post #5

See also his twitter for some speculation as to how on earth simply changing refresh rate would cause boot corruption: https://social.treehouse.systems/@marcan/111329614147717090 >Why? I can tell you why: because Apple hates display modeset flicker, and switching modes between ProMotion on/off causes a modeset flicker, so of course they made it so that is stored in nvram somewhere and applied when the screen is turne…

Interesting. I wonder why anyone would turn ProMotion off considering that 120Hz massively improves responsiveness. I've only encountered one app that doesn't work with variable refresh rate and that's Genshin on Windows. Even that's probably not an issue with newer monitors that can handle VRR down to 60Hz without my monitor's frame-doubling flicker as it keeps switching been 60Hz and 120Hz

I turned it off. The primary reason is that I use ctrl+arrow keys to move between workspaces frequently.

These might seem unrelated, but:

* There's a `defaults set` setting that allows you to speed up the transition animation length from 1 second to 0.5 second, which is huge because that transition is extremely poorly implemented (it leaves the windows on the workspace that you're leaving activated until the transition is complete, so you start typing and it's on the other screen you can't even see any more) and VERY SLOW

* That setting only works if the refresh rate is 60Hz, and it completely fails to do anything if ProMotion is on, because for some reason the animation length isn't programmed to handle the different refresh rates.

So having ProMotion off relieves frustration.

Re: macOS Sonoma Boot Failures

#196

Earlier quoted context omitted.

Well the CSS transition wouldn't run at 60 fps, it would run at 120 fps, no? An animation that looks slick at 120 fps might look too fast/slow/complex/whatever on a common 60 hz screen. So if I was still doing this sort of development, I'd prefer to be working on a 60 hz monitor.

Aren't CSS animations capped at 60, same as requestAnimationFrame? I've been advocating (and using) high refresh displays for over two decades and I find your reasoning preposterous. Downgrading to crappy 60 Hz monitor for nothing.

CSS transitions and animations seem to be declared using expressions that are continuous over time so it would make sense that they are just quantized down to whatever refresh rate the system supports.

Re: macOS Sonoma Boot Failures

#197
post #193

Earlier quoted context omitted.

To my horror, I recently had to visit the UEFI firmware setup of a Lenovo tablet.... That was touch enabled.

Most gaming laptops' UEFI screens are so "gamer" it's cringe. Dell XPS series have UEFI GUIs that are quite neat and absolutely an improvement over the text screens.

I'm also partial to the Surface devices'. MS put a surprising amount of effort into making them look Windows-y.

Re: macOS Sonoma Boot Failures

#198

Earlier quoted context omitted.

Well the CSS transition wouldn't run at 60 fps, it would run at 120 fps, no? An animation that looks slick at 120 fps might look too fast/slow/complex/whatever on a common 60 hz screen. So if I was still doing this sort of development, I'd prefer to be working on a 60 hz monitor.

Aren't CSS animations capped at 60, same as requestAnimationFrame? I've been advocating (and using) high refresh displays for over two decades and I find your reasoning preposterous. Downgrading to crappy 60 Hz monitor for nothing.

I am pretty sure they are synchronized to refresh rate (at least on windows).

I made a small experiment about raf https://codepen.io/mmis1000/pen/qBxqgLr and it always looks uniform regardless I am on a 60, 120, 160 fps screen. (It would blink crazily if you put it in the middle of two screen with different refresh rate, because it can't be in two refresh rate at same time)

Erit: okay, it looks non uniform only in safari. Clap, clap, clap, Apple…

Re: macOS Sonoma Boot Failures

#200
post #38
post #5

See also his twitter for some speculation as to how on earth simply changing refresh rate would cause boot corruption: https://social.treehouse.systems/@marcan/111329614147717090 >Why? I can tell you why: because Apple hates display modeset flicker, and switching modes between ProMotion on/off causes a modeset flicker, so of course they made it so that is stored in nvram somewhere and applied when the screen is turne…

Interesting. I wonder why anyone would turn ProMotion off considering that 120Hz massively improves responsiveness. I've only encountered one app that doesn't work with variable refresh rate and that's Genshin on Windows. Even that's probably not an issue with newer monitors that can handle VRR down to 60Hz without my monitor's frame-doubling flicker as it keeps switching been 60Hz and 120Hz

Surely I'm not the only one that simply cannot perceive any difference between 60Hz and 120Hz?
Post reply on HN