7 ms·

> — System-wide UI consistency, especially in the fine details > — Singular UI/UX vision eliminates points of confusion and everything-is-a-compromise choices

> — 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.

sjwright 8y ago
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.
- microcolonel 8y ago
  > 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.
  - sjwright 8y ago
    > 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.
    - michaelmrose 8y ago
      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.
setpatchaddress 8y ago
CoreAudio round trip latency can be under 5ms.
- sjwright 8y ago
  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.
  - mmjaa 8y ago
    Ubuntu Studio just works.
- jancsika 8y ago
  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.
  - SargeZT 8y ago
    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.
- mmjaa 8y ago
  My Linux DAW regularly trumps that.
Symbiote 8y ago
> 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-guidelines/macos/ https://developer.apple.com/design/human-interface-guideline... https://hig.kde.org/ https://hig.kde.org/ https://developer.gnome.org/hig/stable/ 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.
snvzz 8y ago
>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.
- microcolonel 8y ago
  > 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.
  - snvzz 8y ago
    >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.

sjwright 8y ago

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.

microcolonel 8y ago
> 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.
- sjwright 8y ago
  > 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.
  - michaelmrose 8y ago
    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.

setpatchaddress 8y ago

CoreAudio round trip latency can be under 5ms.

sjwright 8y ago
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.
- mmjaa 8y ago
  Ubuntu Studio just works.
jancsika 8y ago
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.
- SargeZT 8y ago
  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.
mmjaa 8y ago
My Linux DAW regularly trumps that.

Symbiote 8y ago

> 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-guidelines/macos/ https://developer.apple.com/design/human-interface-guideline... https://hig.kde.org/ https://hig.kde.org/ https://developer.gnome.org/hig/stable/ 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.

snvzz 8y ago

>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.

microcolonel 8y ago
> 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.
- snvzz 8y ago
  >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.