Hacker News Reader

As a long time (10+ years) Linux and macOS user, I accept most of the things you say, and macOS is an extremely time efficient platform to do work.

However, the lack of unifying vision is not an Achilles heel of the open source community. It's the essence of it. I like how any two installations of two distributions are never the same, and this broad ecosystem just works, tumbles, fights and creates new stuff.

I've created a compression algorithm [0] for my graduation project. It was a novel approach, but performed worse due to some technical reasons. One of my professors asked why I didn't compare it to a similar algorithm instead of plain old Zip. I said that our algorithm is never tried before, and it's pretty novel, so we had no equal to compare.

Then, one of my other professors replied to other professor asking the question. "There's no need to find an equal to compare. They did something new and untried. This is research".

Equally, Darling doesn't need to surpass macOS to be useful, because "this is research" too. Maybe they will learn something useful from this endeavor and incorporate it into Linux or their future development career.

This Katamari Damacy nature of GNU, Linux and free software community makes it so powerful and unique. Let Microsoft, Apple and Google have a top-down approach and others play as they feel and everyone improves the world as they wish.

[0]: https://www.academia.edu/20575315/Lossless_Text_Compression_...

I don't disagree with anything you've said, and I don't think that my post—if read in full—disagrees with it either.

The lack of unifying vision in open source can be both an Achilles heel and its most valuable asset.

The lack of a community-led ethos in macOS can be be both its Achilles heel and its most valuable asset.

Honestly, I missed your last footnote only. Possibly I got distracted by something. My fault.

When read in full, we're on the same page. OTOH, I also didn't disagree with you on anything it seems. So, the two comments can be nicely summed up as a look to same lawn from a opposing vantage points, since I use Linux more often than macOS (albeit I have a MacBook Pro that I use pretty regularly).

If my tone sounds a bit harsh, sorry for that. English is not my mother tongue. Also, if you can tell me where it's rude(ish), I can work on it.

— Internationalization

— Accessibility (deaf, blind etc)

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

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

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

> Nominally "perfect" hardware support

With the decline of Apple hardware, this is less true, and modern Linux hardware support is, at worst, no worse than what other OSes provide, in my experience.

> Navigable by non-experts, even when things turn to shit

I think the "Closed Box Philosophy" of Apple either defines or disproves this: Non-experts can't be tripped up by having to fix things... because nobody outside of Apple can fix things, eh? Can't screw up something you're not allowed to do.

> The achilles heel of the open source community stems from the lack of a unifying vision and a top-down approach.

This means that I can keep running Window Maker and nobody can take it away from me. In a broader sense, I'm not afraid to upgrade for fear of losing some part of my workflow due to a high-level decision taking an option away from me. I can use Emacs even if everyone else around me is using Vim, I can use qutebrowser even if nobody knows what the fuck a "Cute Browser" even is, I can write in Ruby even if the Current Dogma is JavaScript.

> With the decline of Apple hardware, this is less true, and modern Linux hardware support is, at worst, no worse than what other OSes provide, in my experience.

I will still take a perceived regression in hardware from Apple over anything else on the market today. They are that far ahead. Still the best touchpad and connectivity support which are the two most important factors in my book. Also still the most aesthetically pleasing and known brand of laptop in the world. The latter point is not so important in my book, but I do believe it helps contribute to the resale value of the Mac, which again is class leading in terms of mass produced laptops.

This is entirely subjective. Aesthetically pleasing and "well known" may be factors for you in a purchase decision, but I personally prefer more open hardware and choice in my purchases so that I can fine tune each component and not be at least a year behind when it comes to modern hardware when making a purchase to get better performance than what Mac will offer for a fraction of the cost.

Also, if you care a lot about looks then I'd recommend checking out Razer, or aluminum chassis notebooks:

https://www.reinisfischer.com/top-20-aluminium-chassis-noteb...

The butterfly switch Macbook Pro keyboards prove it isn't just a perceived regression.

I get the appeal of the Apple Universe: It Just Works, everything is crafted, etc. The problem with that idea is that it's been eroded from two directions: Apple's own incompetence at making hardware and software which Just Works, and everyone else catching up to Apple at lower price points and, as I said before, while offering more meaningful choice than Apple has since the days of the Apple II.

I remember when I needed ndiswrapper to use WiFi on a laptop under Linux. I remember when I needed a bizarre Frankenstein pseudo-FTP setup to access NTFS partitions on Linux. I remember when USB didn't exist and you needed device drivers for every single thing. Those days are gone. Macs not having to deal with those things is no longer a competitive advantage.

These days, Macs are only really special in that they tie you to the Apple universe. I'm not interested in being tied to a corporation like that.

> 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

There are consistent themes across both GTK+ and Qt. Pretty much all my apps share a similar theme and UI. There are Mac Apps as well that deviate from whatever "standardization" you're referring to.

> Navigable by non-experts, even when things turn to shit

It is no longer 2004. A lot of Mac users are also more than capable of running a few shell commands when needed. There are tons of web UIs and graphical apps to manage a Linux OS, from hardware, users, configuration, etc. However, a properly configured Linux OS won't need a lot of interaction on the frontend.

> Nominally "perfect" hardware support

Linux has way better hardware support than Mac. I'm not sure what you're referring to here.

> Robust colorimetry

Agreed, this is one area that needs some improvement, but last I checked it is pretty well supported:

https://wiki.archlinux.org/index.php/ICC_profiles

> Millisecond audio latency

Already exist:

https://wiki.archlinux.org/index.php/Professional_audio

> There are consistent themes across both GTK+ and Qt.

And then you open an app that’s neither GTK+ nor Qt, and you’re back to square one.

Besides, there’s more to UI than “theme”. I have ^w mapped to delete word on OS X. One line in one config file. It works universally in every text box on the system.

I tried setting that up in Linux. Eventually got it working through some gnome setting or some such. In some apps. Firefox didn’t respect it and wanted its own setting iirc. Then it would forget it every few months and trying to delete a word while I was typing would unconditionally close the browser. Fucking ridiculous stuff like that abounded. Life’s too short.

> Pretty much all my apps share a similar theme and UI. There are Mac Apps as well that deviate from whatever "standardization" you're referring to.

A few (very few anymore, in my experience) might deviate in terms of widget styling. Essentially none ignore system wide keybindings, or fail to integrate with system wide services, etc. In terms of inconsistency it’s night and day vs what I’ve had to put up with from Linux desktops.

> And then you open an app that’s neither GTK+ nor Qt, and you’re back to square one.

The same is true on every OS, if you open a java app on macos it's not going to look right, do you blame apple for that or the developers of the app?

> In some apps. Firefox didn’t respect it and wanted its own setting iirc.

Will firefox respect it on macos? It's not a good example anyway because firefox is not native, firefox is the electron of the 00's. Even when firefox tries to emulate the native theme it screws up, I had to turn off my dark theme just to get text areas with visible text.

All are exceptions that prove the rule.

> The same is true on every OS, if you open a java app on macos it's not going to look right, do you blame apple for that or the developers of the app?

I’d blame the app, because in the case of OS X there is a single consistent set of UI components that effectively everything uses, and being gratuitously incompatible is on the app.

In the case of Linux there is only a hodge-podge bazaar of gratuitously incompatible UI kits that every third app disagrees on which to use, so it’s hard to blame any single dev for the universally frustrating shitshow that results.

As an aside, the only java app I’ve interacted with in years (seriously, how often do these even come up any more?), IntelliJ, actually sunk the effort into looking and feeling right. Like I said, it’s night and day on this stuff versus what I experience in Linux on the regular.

> Will firefox respect it on macos?

Yes.

> It's not a good example anyway because firefox is not native, firefox is the electron of the 00's

Electron apps also get this 100% right on OS X.

There are really mostly 2. Gtk and QT and themed with similar themes they aren't different enough to be too meaningful.

Jetbrains had over a quarter of a million paying users in 2017. I'm not sure how much the average paying user spends but presumably they make somewhere between 37M and 125M gross. More money means more polish. Logically we need to invest in what is important to us.

The majority of users use virtually no hotkeys. A truly shocking portion don't even know how to copy and paste with their keyboard. Weep when you watch people who don't even know how shift keys work and hit caps lock letter caps lock.

I don't honestly believe that the inconsistency in colors or gui elements that exist on a typical linux system are a meaningful barrier to anyone.

A typical desktop ships with mostly qt or mostly gtk apps that share the same look and feel + a browser that looks and works like the user is used to working across platforms.

In a sense the browser is actually the single most important app for the majority of users and its more useful for it to be consistent with expectations than consistent with the desktop.

I think power users are more apt to be put off by small differences in much used keybindings but they are the minority.

While consistency may seem like an impossible task there are really 4 really big camps. Chrome Firefox gnome kde.

This seems like a small enough group that getting everyone to agree on a common way to communicate to all the desired way to define keybindings ought to be tractable.

I think this is a worthwhile endeavor we ought to persue.