Live data from Hacker News

Why iOS 13 and Catalina Are So Buggy

tidbits.com

211–220 of 368 posts

Re: Why iOS 13 and Catalina Are So Buggy

#211
post #162
post #104

I have a slightly different take on this. I think every company should dedicate a certain percentage of their revenue to handling bug reports from users. Yes, many bug reports will be bogus, but many will be pure gold (I speak from experience). Yes, it involves a lot of manual work. But it is so incredibly worth it — you get to catch the odd bugs that you will never catch with automated or in-house testing. In contra…

You are writing this based on gut feeling, big companies simply can't go over every bug report- it's not scalable. I used to work on a product at a big company, we took users input very seriously, not only from bug reports but also by analyzing telemetrics data and simple users "star" feedback. At the end of the day it's simply impossible to both fix everything and still go forward when the product is big and complex…

> To this day the product has terrible reputation as buggy and unfriendly.

In what way is that an argument against paying attention to bug reports? Are you saying that the continuing existence of this product means it does not matter? Arguably that strategy will work, up to the point when something better comes along, and by then you will be too deep in bugs to pivot.

Re: Why iOS 13 and Catalina Are So Buggy

#212
post #161

Earlier quoted context omitted.

I've used Windows on and off since 3.11, and have used 98, xp, 7 and 10 a lot. As much fun as it is to hate on Windows, if I'm honest with myself 10 has been the most stable experience I've had with Windows, with the possible exception of 3.11 (though that was a long time ago).

This seems pretty far removed from most other people's experiences.

Win 10 is fine for me.

Re: Why iOS 13 and Catalina Are So Buggy

#213
post #104

I have a slightly different take on this. I think every company should dedicate a certain percentage of their revenue to handling bug reports from users. Yes, many bug reports will be bogus, but many will be pure gold (I speak from experience). Yes, it involves a lot of manual work. But it is so incredibly worth it — you get to catch the odd bugs that you will never catch with automated or in-house testing. In contra…

> If Apple also spent 10% of its revenue on processing bug reports and fixing bugs Just to be clear, you're suggesting they dedicate $25B/year to bug fixing? Seems high, given their total R&D budget for 2018 was only ~56% of that. https://www.macrumors.com/2018/11/05/apple-2018-form-10-k-hi...

Sure, why not? It's not like they're doing anything else with the money. It doesn't have to be only software fixes either. There's plenty of hardware issues like the keyboard.

The spending doesn't have to be instant either. Just start increasing the spending and measure user satisfaction and bug report counts. Once you've arrived deep into diminishing returns you can stop increasing the spending.

Re: Why iOS 13 and Catalina Are So Buggy

#214
post #104

I have a slightly different take on this. I think every company should dedicate a certain percentage of their revenue to handling bug reports from users. Yes, many bug reports will be bogus, but many will be pure gold (I speak from experience). Yes, it involves a lot of manual work. But it is so incredibly worth it — you get to catch the odd bugs that you will never catch with automated or in-house testing. In contra…

> If Apple also spent 10% of its revenue on processing bug reports and fixing bugs Just to be clear, you're suggesting they dedicate $25B/year to bug fixing? Seems high, given their total R&D budget for 2018 was only ~56% of that. https://www.macrumors.com/2018/11/05/apple-2018-form-10-k-hi...

The number doesn't matter. It's the precedent being set that Apple takes bug reports, and investigations into them, seriously through a percentage of revenue. It could be 10% of something more in-line with Mac OS X - like 10% of revenue from OS X app store sales. Either way the point is that Apple should be concerned about quality of software far more than it is. I submitted a bug to Apple about how the Apple login page was rejecting requests from browser headers from Linux machines. Apple rejected the ticket as a problem on my end even though I gave them clear instructions on how to repro. I did the same on Twitter - even linking them to a Browserling instance showing them, again, exactly how to repro. I gave up talking to the wall. Apple didn't care until it got mainstream press. That's a horrible user experience and frustrating that you need to traverse multiple avenues and hope your issue bubbles up to a consensus of users to get the appropriate attention. How many bugs like that go unaddressed even though someone has spent the time and effort documenting and submitting it? Sure, wrangling that isn't easy - but Apple has the resources to do it.

Re: Why iOS 13 and Catalina Are So Buggy

#215
post #161

Earlier quoted context omitted.

Did they not use 2000? Or XP? Or even 7 for that matter?

I've used Windows on and off since 3.11, and have used 98, xp, 7 and 10 a lot. As much fun as it is to hate on Windows, if I'm honest with myself 10 has been the most stable experience I've had with Windows, with the possible exception of 3.11 (though that was a long time ago).

I've used Windows since 3.11 as well and I still use Windows 7 and Windows 10 every day. The rate of significant issues has been higher with Windows 10 than with Windows 7. Although they're mostly related to the UWP parts. For example on Windows 10 the UWP UI stuff sometimes stops working so I can't even open the start menu. That has never happened to me on Windows 7, although it did happen on XP and earlier. To be clear, I'm talking about the start menu specifically not the whole explorer.exe freezing, which happens on every Windows including 10, but can be restarted without a whole PC reboot.

Re: Why iOS 13 and Catalina Are So Buggy

#216

Earlier quoted context omitted.

The macOS kernel (XNU) does not have any kind of containerisation support. I believe "Docker for Mac" is actually a Linux kernel running inside a hyperkit/xhyve VM, and uses Linux's container support. Apple hasn't put much public effort into making macOS work well inside a virtual machine. Recent versions in particular, where the window compositor uses Metal for drawing, don't run well. Apple hasn't opened the API fo…

> "Docker for Mac" is actually a Linux kernel running inside a hyperkit/xhyve VM, and uses Linux's container support. This is indeed correct. Your Docker VM lives at: /Users/$USERNAME/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw It would be very nice to be able to use libvirt from my Mac in the same way as my Linux workstation. Or be able to migrate VMs between the two. They're both using the same-ish C…

It would be very nice to be able to use libvirt from my Mac in the same way as my Linux workstation.

I believe libvirt as such is supposed to work on macOS. Furthermore, recent versions of Qemu apparently support using macOS's Hypervisor.framework. So it seems like this should be doable, although I've not had a chance to try it myself yet.

Re: Why iOS 13 and Catalina Are So Buggy

#217
One of the things that I heard about Windows 10 was that Microsoft switched from testing on real hardware to virtualized testing and relying on end-user crash reports. If Apple did something similar, that would explain why more nonfatal bugs make it through to final release.

Re: Why iOS 13 and Catalina Are So Buggy

#218
post #104

I have a slightly different take on this. I think every company should dedicate a certain percentage of their revenue to handling bug reports from users. Yes, many bug reports will be bogus, but many will be pure gold (I speak from experience). Yes, it involves a lot of manual work. But it is so incredibly worth it — you get to catch the odd bugs that you will never catch with automated or in-house testing. In contra…

> If Apple also spent 10% of its revenue on processing bug reports and fixing bugs Just to be clear, you're suggesting they dedicate $25B/year to bug fixing? Seems high, given their total R&D budget for 2018 was only ~56% of that. https://www.macrumors.com/2018/11/05/apple-2018-form-10-k-hi...

Yes bug fixing the frigging keyboard should take at least 1 Billion. At least they would have something that types properly

Re: Why iOS 13 and Catalina Are So Buggy

#219

Earlier quoted context omitted.

The macOS kernel (XNU) does not have any kind of containerisation support. I believe "Docker for Mac" is actually a Linux kernel running inside a hyperkit/xhyve VM, and uses Linux's container support. Apple hasn't put much public effort into making macOS work well inside a virtual machine. Recent versions in particular, where the window compositor uses Metal for drawing, don't run well. Apple hasn't opened the API fo…

> The tightening of code signing requirements [see the 'library-validation' flag] even locked out nvidia from providing their own GPU drivers from macOS 10.14 onwards. Library validation has nothing to do with drivers.

Library validation has nothing to do with drivers.

Depends on the type of driver. For GPU drivers, it is indeed a problem.

I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work:

- One or more kexts provide an IOFramebuffer implementation, plus an IOAccelerator object which listens for various types of user clients. The IOFB and IOAccel are typically clients of the GPU's IOPCIDevice object and handle its interrupts and memory.

- A variety of user space plugins (essentially dynamic libraries) are loaded into any process wishing to use GPU acceleration, with different plugins for Metal, OpenGL, and so on.

The kext communicates directly with the hardware and manages memory, but the user space plugin tends to deal with the higher level tasks such as generating command streams, compiling shaders, etc., and they talk to the kernel driver using the IOKit user client mechanism. The plugins also provide the back-end implementations for the app-facing APIs such as OpenGL, Metal, and OpenCL.

In recent macOS versions, WindowServer, the process responsible for drawing your macOS desktop, has had the library-validation codesigning flag enabled. This flag enforces that any code loaded into the process must be signed using a certificate from the same Developer Team ID as the main executable or Apple's own certificate. This means, no third-party plugins can be loaded.

This also means third-party GPU drivers can't work with most Apple apps and WindowServer itself, because they require aforementioned user space plugin.

For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled.

Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about.

Re: Why iOS 13 and Catalina Are So Buggy

#220
My number one iOS bug right now: "Hey Siri call Scott's conference line" That exact text shows up on the screen...and Siri says "Calling Don's conference line". Both are in my contacts list. I have not had this problem prior to this week so it's probably a backend issue.
Post reply on HN