Comment by microcolonel | Hacker News Reader

Comment by microcolonel | Hacker News Reader

Parent Full thread

> — System-wide UI consistency, especially in the fine details

> — Singular UI/UX vision eliminates points of confusion and everything-is-a-compromise choices for third party developers

I mean, first-party GNOME applications are as consistent as first-party Apple macOS applications; and third-party macOS applications are as highly customized as third-party applications one might run on GNOME. Not sure what you base your experience on but this is not really any more of an issue for those looking for consistency over all else.

> — Properly accessible by non-experts, even when things turn to shit

I'd like an example, not really sure what you're talking about here. In my experience, when things go wrong on macOS, you're prettymuch SOL until the broken feature is either fixed, reimplemented, or removed in a subsequent major release of the operating system. In my experience, Apple doesn't respond to bug reports any more than other desktop OS vendors, including open source ones.

> — Nominally "perfect" hardware support

The graphics drivers on macOS are very poor. Apple's decision to neglect and then subsequently abandon OpenGL is pure laziness, and their implementation was already bad when they were still maintaining it. Furthermore, hardware compatibility with random gizmos on macOS leaves a lot to be desired in comparison to Linux, in my experience, though I guess your mileage may vary.

> — Robust colorimetry

colord works just fine for me, no amount of software is going to profile your monitors for you though.

> — Millisecond audio latency

I'm pretty sure CoreAudio frames are not less than 44 samples.

What I will give Apple credit for is a great set of graphics manipulation libraries which make it simple to use high quality scaling and manipulation algorithms, and making sure it's a conscious choice to use cheaper, faster ones, and their implementation of seamless suspend-to-disk with full disk encryption is admirable (though honestly, dispensable at the end of the day). Their shaping and font rendering libraries are almost as good as Harfbuzz and FreeType 2 (though I think they've just started using FreeType at least on some platforms). Accessibility features are also pretty good, and depending on what disability you have, it's a tossup between GNOME and macOS.

All those points are fine, but they're all yes-buts.

— I mean, first-party GNOME applications are as consistent as

Straight-up disagree. It all depends what your threshold of UI/UX consistency is. Unfortunately most open source enthusiasts have a low threshold. It is difficult to convey the importance of a thousand subtle details, each one impossibly trivial, but the sum total moves mountains.

— I'd like an example, not really sure what you're talking about here.

An example: If my aging father's Mac turns to shit, he can hold down R, boot up the computer from the recovery disk and restore from a Time Machine backup that he himself set up with no assistance required from anyone.

— The graphics drivers on macOS are very poor.

That's really a marginal opinion. Maybe if you're an OpenGL developer. Apple provides an excellent framework (Metal) which works brilliantly. Yes it would be great if Apple delivered first-class support for Vulkan, but complaining about OpenGL is last decade's problem.

— colord works just fine for me

It's increasingly robust at handling the basics, yes.

> That's really a marginal opinion. Maybe if you're an OpenGL developer. Apple provides an excellent framework (Metal) which works brilliantly. Yes it would be great if Apple delivered first-class support for Vulkan, but complaining about OpenGL is last decade's problem.

The Metal drivers are more stable, but the shader compilers generate slow code, just like the old Apple OpenGL drivers (the ones they wrote for the Intel GPUs). OpenGL issues are not "last decade's problem", I have on several occasions needed to write workarounds in WebGL shaders to prevent the NVIDIA drivers from crashing the whole windowing system (and every application with it) on macOS. On the same hardware, the drivers on Linux are faster, more stable, and more featureful and also include implementations of Vulkan.

> An example: If my aging father's Mac turns to shit, he can hold down R, boot up the computer from the recovery disk and restore from a Time Machine backup that he himself set up with no assistance required from anyone.

That's not a macOS feature though, that's an Apple PC firmware feature. I'll grant that AFAIK no vendor who ships a Linux distribution by default has a durable recovery partition, but there's nothing about macOS itself which makes that easier.

> That's not a macOS feature though, that's an Apple PC firmware feature.

That you see a distinction here is telling. The end user doesn't see the distinction.

As for all of your complaints about the OpenGL drivers, that's an issue for developers, not end users. Yes, maybe there might be more 3D apps and faster 3D apps if the video driver situation was better, but also maybe not? Either way, this is all irrelevant because the fundamental argument here is the impetus for end users to remain on a platform. Just because you can possibly eek out an extra 20% performance in your Linux app on the same hardware isn't going to shift people.

-------------------

On a side note, could the people who are down-voting microcolonel please stop? This is a discussion of ideas, and his/her ideas are being expressed with valid form and structure.

Basically the point is that either distro or hardware providers can already offer easy to use backup functionality.

For example Linux mint comes with time shift. I honestly haven't paid much attention to what people do provide as I've mostly historically used rsync or more recently zfs send/syncoid.

> As for all of your complaints about the OpenGL drivers, that's an issue for developers, not end users.

I shipped an application with WebGL under the impression that it would not need to be custom tested on a decade's worth of MacBooks Pro, but received a report later that a user had lost data because the graphics driver restarted the windowing system when he opened my webpage.

If an honest, non-malicious webpage can cause your windowing system to restart, that is an end-user problem. Even Apple themselves don't bother to test their official websites on more than one generation of Mac, why should everyone who uses this now half-decade-old web API have to buy $10,000+ worth of equipment, some of it with old versions of the OS, because they can't trust the vendor of the hardware to maintain the drivers?

And this is on top of the fact that, generally speaking, on a given piece of hardware, the application will run dramatically more slowly on macOS than on Windows or Linux.

> That you see a distinction here is telling. The end user doesn't see the distinction.

I tend to agree, but in this case there's an important distinction for us to make, even if the end users are generally unaware. In the case of recovering intentional backups on a fully-functioning computer, Apple has done a good job of making that straightforward on their laptops, if you attribute that to "macOS", then you miss the point that a) any vendor could offer the same thing, even if they don't, and it has nothing to do with macOS and b) improving "Linux" won't make a recovery partition suddenly appear on your computer. Furthermore, Apple's advantage here only applies to functioning computers. Apple makes it extremely difficult to recover data from damaged devices, and in the case of the iPhone, they literally censor any mention of it being possible from the forums, and lie straight to the faces of their customers. When something gets a little bit wet, Apple will tell you that you should have bought iCloud, and that your data are gone forever.

Woah there buddy.

— Apple makes it extremely easy for anyone to start backing up their computer in a way that covers an array of scenarios from accidental or malicious deletions to full-on disaster recovery.

— It has everything to do with MacOS because the creation of backups happens within a MacOS environment and the restoring of backups happens within a MacOS environment. The only "firmware" aspect is the (relatively) simple boot-time keyboard triggers.

— Apple's solution to damaged devices is having a comprehensive backup strategy. If your plan is to recover data from a damaged device, you've failed before you begin. Apple doesn't offer first-party data recovery services, but there are plenty of third party services to handle disaster recovery situations. To the extent that they make it difficult for you to recover data from a damaged device, it's because they do robust on-disk encryption.

— Yes, any vendor "could" offer the same thing. That's exactly the point. They could. Most don't. That's the point.

> If your plan is to recover data from a damaged device, you've failed before you begin.

Apple says this is the case, but it's not actually the case. Repairing a device is how you recover data from it. I know it's preferable that people make an effort to protect their data, but in the real world, approximately zero people back up anything.

What I mean is that you've failed in principle. You shouldn't ever risk being in a position where access to your data may become contingent upon the skills of a repairer wielding a soldering iron. If maintaining comprehensive backups isn't boneheadedly simple and robust, your vendor is selling junk.

But as a practical matter I don't disagree. If you failed to maintain comprehensive backups (or you have suffered a rare double-disaster) then it's great that these hardware repair experts exist.

> I mean, first-party GNOME applications are as consistent as first-party Apple macOS applications

That's true in the basic sense, and my impression is that KDE is better than Gnome, but Mac OS is ahead of both in the overall consistency of interaction with the application.

All three platforms have a set of human interface guidelines:

https://developer.apple.com/design/human-interface-guideline...

https://hig.kde.org/

https://developer.gnome.org/hig/stable/

I use KDE, and the core applications are equal with Mac OS for consistency of interaction. The difference is the niche applications, where I think a Mac OS developer puts a bit more effort into following the guidelines, whereas the KDE developer adds an additional feature or customization.

CoreAudio round trip latency can be under 5ms.

And maybe you can get something comparable on Linux. Maybe? Do I have to think about which distro I use? Do I have to think about which audio hardware I use? Do I have to think about which audio apps I use?

On Mac, you get that insane latency without having to put a moment's thought into any part of your architecture. I get that insane latency even if I never bothered to learn why latency matters.

"Just works" is more than ease of use. It's productivity. It shows respect to your mental load and mental priorities. And it is worth money to anyone whose time is valuable.

Ubuntu Studio just works.

I bet somebody has a Gnu/Linux rig using ALSA with well below 5ms round-trip latency, too.

The plus to CoreAudio is that any system it runs on has probably been designed so that a non-technical user can get something like the low-latency you're describing by default. The minus is that hardware probably costs at least $800, and CoreAudio doesn't support things like the RPI.

The plus to ALSA is that it runs on things like RPI, with the minus that non-technical users probably won't get round-trip latency below 5 ms without paying someone Mac-level money for hardware designed especially for Linux audio.

Yeah, 5ms isn't that tough to achieve. You need decent hardware for sure, but hell, you can get PulseAudio of all things to under 10ms.

My Linux DAW regularly trumps that.

It's easy to get latency this low with ALSA+JACK.

Edit: and it's possible to go much lower, for example look at the linux-based Bela: https://bela.io/about#why-latency-matters

>I'm pretty sure CoreAudio frames are not less than 44 samples.

CoreAudio is actually pretty good.

Without the linux-rt patchset, jack pipelines do overrun even when running jack at 10ms. Linux has quite the latency spikes.

It's possible to demonstrate this fairly quickly by running cyclictest from rt-tests.

> CoreAudio is actually pretty good.

I wasn't arguing that, I was saying that "millisecond latency" involves frames smaller than (samplerate / 1000) samples, completely ignoring overhead.

> Without the linux-rt patchset, jack pipelines do overrun even when running jack at 10ms. Linux has quite the latency spikes.

Are we talking about sub-10ms latency? Sure, that's a different matter, and Linux's default schedulers could stand to improve support for mixed-realtime.

>Are we talking about sub-10ms latency?

Yes. Even for the audio case, having to run jack at 10ms is already a lot, particularly since Linux is not the only source of latency.

>Sure, that's a different matter, and Linux's default schedulers could stand to improve support for mixed-realtime.

Even SCHED_FIFO (where preemption is immediate, and cpu isn't released until the high priority program yields it itself) suffers from latency spikes; it is not a scheduler issue but an overall Linux design issue.

cyclictest from rt-tests will easily highlight that. Try leaving cyclictest --smp -p98 -m on the background. After a while, you'll notice the entirely unacceptable max latency readings. All the test does is set an alarm so that the task becomes runnable (which means it should run immediately due to SCHED_FIFO) and check the difference between the alarm and the current time.

Mainline kernel is effectively unusable for anything that requires low latencies such as audio work, as it spends too much time running non-preemptable code in supervisor mode. Linux-rt improves this situation radically, but the monolithic design simply isn't suitable for this; microkernel multiserver systems are a much better fit.

Incidentally, refer to seL4 for a system that has a guarantee in the form of a formal proof of worst case execution time.

Reply on news.ycombinator.com