Hacker News Reader

Comment by spudlyo | Hacker News Reader

I'm done with macOS, I've migrated to Linux for my general purpose computing. With every new release of macOS, Gatekeeper is becoming harder and harder to bypass, increasing Apple's control over what software can be run on macOS, forcing apps to be signed with an Apple Developer ID. While I'm happy they are taking security seriously, I'm seriously creeped out that macOS sends hashes of every executable I run to their cloud. It's starting to feel like a broader move away from the openness of personal computing and towards a more controlled, appliance-like software experience.

When Sequoia eliminated the ability to override Gatekeeper by control-clicking, it became clear to me that Apple is now employing a frog boiling strategy towards their ultimate goal -- more control of the software you can run on their hardware.

View on HN

My group makes a custom executable to reflash a hardware device we produce. We build it for Linux and Darwin.

Trying to get the program to work with our Mac users has become harder and harder. These are all internal developers.

Enabling developer mode and allowing Terminal execution isn't enough. Disabling the quarantine bit works - sometimes - but now we're getting automated nastygrams from corporate IT threatening to kick the laptops off the network. I'm exhausted. The emergency workaround, which I tell nobody about, is way less secure than if they just let us run our own software on our own computer.

I understand that you're doing it on principle, but for a software development team, 99$/year is a really minuscule price to pay to be able to build / notarise / distribute software.

Developers pay exorbitant amount of money for much lesser value, and the idea of putting your teammates at risk to stick it to apple is kind of sad bordering with negligence from a business POV.

Adding signing as a requirement can easily make what was once a very simple distribution mechanism into something much more complex - now you need manage signing certificates and keys to be able to build your thing.

The cost is far far higher than the price.

But it doesn't in practice.

I develop and distribute few free apps for macOS, and building / notarising is never a problem.

You seem to be comparing a single dev sending apps to the world vs a corporate team pushing to employees (if I get parent's case right).

In most cases, just involving account management makes the corporate case 10x more of a PITA. Doing things in a corporate environment is a different game altogether.

In contrast to this point, as long as I use Xcode and do the same thing I've always done allowing it to manage provisioning and everything else, I don't have a problem. However, I want to use CI/CD. Have you seen what kind of access you have to give fastlane? It's pretty wild. And even after giving it the keys to the kingdom, it still didn't work. Integrating apple code signing with CI/CD is really hard, full of very strange error messages and incantations to make it "work".

I don't know about fastlane, since my CI/CD is just a shell script, and signing and notarising is as hard as (checking the script) running `codesign ...` followed by `notarytool submit ... --wait`

Yes, you need to put keys on the build server for the "Developer ID Application" (which is what you need to distribute apps outside of AppStore) signature to work.

You do not need to give any special access to anything else beyond that.

Anyway, it is indeed more difficult than cross-build for Darwin from linux and call it a day.

Code signing is absolutely disgusting practically and philosophically. It has very reasonable and good intent behind it, but the practical implementations cause great suffering and sadness both for developers (cert management, cost, tools) and end-users (freedom of computing).

It is ugly: https://hearsum.ca/posts/history-of-code-signing-at-mozilla/

Do you distribute OSS software which requires notarizing? If so, have you found a way to let the community build the software without a paid developer account? I would be very interested in a solution which allows OSS development, relying on protected APIs without requiring that anyone who builds the app to have a paid developer account.

I take it you feel the trade off for dev team inconvenience, vs end user security, is not worth it?

They're talking about internal software for internal users. It can be made insanely secure, but that surely isn't the primary concern in this case.

I'm just observing that the cost is a lot higher than $99/year.

I do this professionally, I maintain macOS CI workers for my employer. Apple doesn't make it easy.

The principle is what matters. The amount is not the issue. The issue is that there is a cost at all. "It's so cheap" is never an excuse for charging for something that should be free. In this case, running software you have no intent to charge for, on your computer. It's as if someone started charging $0.01/month for breathable air. "But $0.01 is trivial," would not excuse it.

The commenter I replied to employed by a business, develops software and distributes it within a team of engineers with Macs.

For your personal needs, you do not need to pay anything for building and using apps locally.

Untrue. There are specific APIs which require notarization , regardless of usage. Credential autofill is one such API.

It costs money, and isn't free, for a reason you're not acknowledging. I don't think it's a major profit center for Apple.

It's about setting a higher floor for malicious actors than "random botnet residential IP + a captcha solving service". It's about proving some semblance of identity through a card number and a transaction that goes through without a chargeback.

As the case upthread shows, there's plenty to dislike about a system that inhibits running code built for personal use. And it's obviously neither foolproof nor without collateral damage. Reasonable people can debate if it's worth it. But it still ought be acknowledged that the motivations are closer to the reason you have to identify yourself and pay a nominal fee to drive a vehicle on public roads.

> But it still ought be acknowledged that the motivations are closer to the reason

Since this isn't true, no acknowledgement required, it doesn't need to be a "major" profit center to magically become a benevolent feature

I don't buy it. Or rather, I am willing to believe that some team at Apple has convinced itself that this makes sense, but they're wrong.

In particular, the security boundaries are nonsensical. The whole model of "notarization" is that the developer of some software has convinced Apple that the software as a whole (not a specific running instance) is worthy of doing a specific thing to the system as a whole.

But this is almost useless. Should Facebook be allowed to do various things that can violate privacy and steal data? What if the app has a valid reason to sometimes do those things?

Or, more egregiously, consider something like VSCode. I run it, and the fancy Apple sandbox helpfully asks me if I want to grant access to "Documents." The answer is really "no! -- I want to grant access to the specific folders that I want this workspace to access", but MacOS isn't even close to being able to understand that. So instead, one needs to grant permission, at which point, the user is completely pwned, as VSCode is wildly insecure.

So no, I really don't believe that MacOS's security model makes its users meaningfully more secure. At best, the code signing scheme has some value for attribution after an attack occurs, but most attacks seem to involve stolen credentials, and I bet a bunch just hijack validly-notarized-but-insecure software a la the VSCode example.

Notarization is not a trusted system on macOS - or rather, notarized binaries still have a "this was downloaded from the internet" prompt, and the user is meant to make a decision on whether it is trustworthy.

Notarization does some minimal checks, but is mostly about attaching a real identity so that maliciousness has at least some real-world consequences. The most obvious being that you lose the ability to get more apps notarized.

Actually the cost is not the issue (you are paying for it one way or the other), the issue is the authorization to do such an action on your (supposedly) own hardware.

The tool is built deep in our CI/CD chain. The whole thing is a house of cards built on a massive pile of tinder next to an open drum of kerosene. You want me to integrate XCode into that?

Last time I tried setting up an Apple developer license inside a large corporation, one that they paid for and not tied to me or my credit card, it was also a nightmare.

And yes, it's also on principle.

Who said anything about Xcode? The codesign tool is part of macOS, not Xcode. The CLI tool for notarization is bundled with Xcode, but you don't have to use it; they have an official REST API that you can use directly.

Do you have any notes on how to run it inside a Gitlab pipeline via a Linux Docker instance? I'd love to learn how to do this, then.

Sure it's trivial, but it is tacit acceptance that you need permission to make a program on their platform. Permission that needs to be renewed year over year. Permission to earn a living on this platform.

Permission that can be revoked for any reason, including being compelled by someone with more power than Apple.

It is permission to _distribute to others_, you can build and run on your own computer without a problem.

Once signed, binary will work forever, you only need active subscription when you need to re-sign / re-notarise.

They can revoke a signature too.

If your signature is compromised and you start signing malware then yes. That's the whole purpose of it.

Do you have any evidence that it happened in any different circumstances at least once?

$99/year for one of the basic uses of a computer isn't okay.

Distributing software is not what I would call one of the basic uses of a computer.

There's extensive documentation. Examples:

https://developer.apple.com/documentation/security/code-sign...

https://developer.apple.com/documentation/security/notarizin...

There are dedicated sections of the developer web forums:

https://developer.apple.com/forums/topics/code-signing-topic

https://developer.apple.com/forums/topics/code-signing-topic...

...and there's an apple developer support person, Quinn, who appears to be heavily if not solely dedicated to helping developers do binary signing/notarization/stapling correctly.

They have written a slew of Tech Notes about signing and notarization. Main TN is at https://developer.apple.com/documentation/technotes/tn3125-i...

Quinn also has their email address in their sig so people can just reach out via email without even needing an Apple account, or if they prefer more confidentiality.

I mean, come on.

As someone who actually signs, notorizes and distributes desktop apps for macOS, I can safely say their documentation is less than ideal.

Maybe because I'm using Electron framework which makes things more complicated, but I don't really understand why there's is a difference between different types of certificates (Developer ID, Apple distribution, macOS distribution) and I had to guess which one to use everytime I set it up.

Also why is notorization a completely different process from code signing, and requires completely different set of credentials from it. Seems odd to me.

> Also why is notorization a completely different process from code signing

Because they do completely different things. Signing is a proof that you were the one to write and package that software; notarisation is an online security check for malware. If I recall, you still sign but do not notarise when distributing to the Mac App Store.

Ok, so the certificate used to sign the package is generated by Apple, why can't I just use that to prove my identity for notarization?

Or maybe simpler, why can't Apple just do code sign and notarization with one single cli call, with one set of credentials?

Google Play does this under the hook, I don't even think about it. iOS is similar, Transponder app does everything in one go.

A lot of developers (including myself) don’t want to notarize/sign their binaries that they want to run on their own machine(s).

OMG, this. I was working on a tool to help integrate password managers on macOS and I got completely blocked by the notarizing requirements. Some things literally cannot be built for macOS as open source software, now.

I don't really think saying documentation exists says much when Apple is notorious for having documentation that's either borderline or downright useless. It's generally the norm that some random blog post from a decade ago is more useful than their documentation, and I say this from firsthand experience.

Can you sign and notarize your own software made for internal use with your own infrastructure? If so, then this is a valid response. If not, then this is an irrelevant response because the issue is going through Apple, not the process being difficult or undocumented. If I own the device, then I should be free to decide what the sources of authority over it are.

Edit: I haven't tested it yet, but it does seem that you can sign an executable with your own certificate (self-signed or internal CA-issued) however you can't notarize it. Right now, notarization is only required for certain kinds of Apple-issued developer certificates, but that may change in the future.

Anecdotally, I was not able to find any way to notarize software for internal use, without paying for a $99 developer account. Though I would have been willing to pay, I know that others who might want to build the software wouldn’t, so I abandoned my project. I suppose I could have maintained it as open source with the developer account required to build, but it seemed disingenuous to me at the time.

> I mean, come on. Is that really necessary? Obviously there are enough people who did not know about, or find helpful, the resources you’re referring to, that we have people complaining on Hacker News. This isn’t exactly a novice’s forum. Perhaps the problem lies with visibility and accessibility of the support resources, rather than all of the people who have seen notarization as a hurdle to getting real work done.

btw, for those who don’t want to search, Quinn’s signature states:

“ Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

> emergency workaround

I once really urgently needed `nmap` to do some production debugging ASAP. Unfortunately, the security tools would flag this immediately on my machine, as I knew this from previous experiments. Solution - compile my own binary from sources, then quickly rename it. I assume that this "workaround" was totally fine for sec department. At least production got fixed and money kept flowing.

> At least production got fixed and money kept flowing.

You were denied the tools to get your job done. You've put yourself at risk by applying an unapproved workaround.

Never ever do this (unless you hold substantial shares). Let the company's bottom line take the fall. If that's the only thing they care about, that's your only way to make the problem visible.

Unfortunately the real world isn't black and white. Yes, according to the company policies, I should watch the world burn and do nothing, while looking at the company bleeding money due to customers SLA being broken. Of course, after submitting a ticket to get nmap approved, which takes days. Extra points if I'm on oncall, then racking that sweet incident money is great.

But the underlying SRE culture here is that, if you know what you are doing and have a functioning brain of a responsible person, you'd be forgiven a jump over the fence, if it means putting out a fire on the other side of it. We aren't kids.

There’s a middle ground. Get the appropriate stakeholders involved in the decision, including security. Let security be the ones to keep the system down, if it cones to that. Or, let the business operations folks make the decision to go over security’s head. Either way, this is not something an engineer tasked with fixing an outage should be making the decision on.

> this is not something an engineer tasked with fixing an outage should be making the decision on

I don’t get this at all.

I’d much prefer a team of highly empowered and highly responsible engineers than impotent engineers who need hand holding in case they make a mistake.

Well, good thing that wasn’t what I suggested.

Engineers _should_ have leeway in how they resolve issues. As I read, though, you have a company policy which explicitly disallows the action you needed to take to fix the problem (if I misread, my apologies). Getting the stakeholders involved is the responsible thing to do when policies need to be broken.

Ideally, the way this kind of situation gets handled should be documented as part of a break-glass policy, so there’s no ambiguity. If that’s not the case, though, the business should get to decide, alongside the policy maker (e.g.: security), whether that policy should be broken as part of an emergency fix, and how to remediate the policy drift after the crisis.

If you’re all tight enough that you’re allowed to make these kinds of decisions in the heat of the moment, that’s great, but it should be agreed upon, and documented, beforehand.

Well I found out the hard way that company culture or values can mean nothing if you don't CYA. Granted, the shop was small enough that our team was in charge of both the security policies and ops, but still, on one unfortunate occasion I've stepped outside my area of responsibility to "do what's right" and got punished. The next time I've been in a similar situation - well, I've walked away from the fire and grabbed the popcorn.

By the way, I'm still burnt out. This work is stressful. Don't let it take away what's already scarce for you.

xattr -cr <file> should clear the "download" extended attribute and make it as if the software was compiled on the machine itself, bypassing the ever-so-annoying Gatekeeper.

For binary patching: codesign --force --deep -s - <file> (no developer ID required, "ad-hoc signing" is just updating a few hashes here and there). Note that you should otherwise not use codesign as it is the job of the linker to do it.

Very aware of the attributes, unfortunately these machines are on a global corporate network so there are layers and layers of monitoring software to prevent internal and external attacks. Changing perm bits on an OSX executable is instantly noted and sent upwards as a possible security breach.

Last time we did this I had to spend a week explaining to management that Macs could actually run software other than PowerPoint and it was necessary for our job.

The local workaround that we use is to just spin up a Linux VM and program devices from there. The less legal workaround is using WebUSB and I'm afraid to even tell the necessary people how I did it, because it's sitting out on a public-facing server.

I migrated to Linux about a year ago too. Not the smoothest experience ever (looking at you, ath11k with device-specific quirks) but so far I am delighted. Finally, I don't have to fight my computer to do things I expect it to do.

Unfortunately, I still have to deal with macOS for work due to corporate policies.

The main problem I had with living in a Gnome desktop environment, is with the keyboard. I'm not willing to abandon my use of Emacs control+meta sequences for cursor and editing movements everywhere in the GUI. On macOS, this works because the command (super/Win on Linux/Windows) key is used for common shortcuts and the control key is free for editing shortcuts.

I spent a day or so hacking around with kanata[0], which is a kernel level keyboard remapping tool, that lets you define keyboard mapping layers in a similar way you might with QMK firmware. When I press the 'super/win/cmd' it activates a layer which maps certain sequences to their control equivalents, so I can create tabs, close windows, copy and paste (and many more) like my macOS muscle memory wants to do. Other super key sequences (like Super-L for lock desktop or Super-Tab for window cycling) are unchanged. Furthermore, when I hit the control or meta/alt/option key, it activates a layer where Emacs editing keys are emulated using the Gnome equivalents. For example, C-a and C-e are mapped to home/end, etc.

The only problem is, this is not the behavior I want in terminals or in GNU/Emacs itself. So I installed a Gnome shell extension[1] that exports information about the active window state to a DBUS endpoint. That let me write a small python daemon (managed by a systemd user service) which wakes up whenever the active window changes. Based on this info, I send a message to the TCP server that kanata (also managed by a systemd user service) provides for remote control to switch to the appropriate layer.

After doing this, and tweaking my Gnome setup for another day or so, I am just as comfortable on my Linux machine as I was on my Mac. My main applications are Emacs, Firefox, Mattermost, Slack, ChatGPT, Discord, Kitty, and Steam. My Linux box was previously my Windows gaming box (don't get me started about frog boiling on Windows) and I'm amazed that I can play all my favorite titles (Manor Lords, Hell Let Loose, Foundation, Arma Reforager) on Linux with Proton.

[0]: https://github.com/jtroo/kanata

[1]: https://github.com/hseliger/window-calls-extended

I'm convinced a DE that figures this shit out out of the box will explode in popularity. Super for the OS and DE shortcuts. Ctrl for the Terminal and readline cursor movements. It can't be impossible to bake these in as defaults.

Love this, and I'm in the same boat. Is your configuration of kanata public at all?

I know it's mostly muscle memory, but macOS shortcuts just seem sane and consistent and that has been one of the biggest frustrations when trying to switch. I found toshy[0] which does something similar - did you try that? The goal is purely macOS key remappings in Linux, so a much smaller scope than kanata.

[0]: https://toshy.app

I didn't try toshy, I had a bad experience when I tried kinto.sh a couple of years back, and I had a pretty clear idea of how I could get what I wanted out of a fully featured keyboard remapping tool under Linux. I initially started with Kmonad, but once I found Kanata, and realized that it had a TCP interface for programmatically changing layers, I quickly switched.

I have a Kinesis 360 keyboard, and my config[0] probably won't work for other keyboards, but it can give you a starting point for your own config.

[0]: https://gitlab.com/spudlyo/dotfiles/-/blob/master/kanata/.co...

The hashes are completely anonymized and not that intrusive. I'd rather they do it that way and have a global view of possible malware attacks than the complete free-for-all that other platforms "enjoy".

But here's my (unpopular) take as a GNOME user and using Fedora immutable distros + flatpaks -- I suspect Linux is going to go in a broadly similar direction. Maybe not soon (even flatpaks aren't universally acclaimed), but sometime.

"Immutable" distros? We used to live-boot those from optical media back in the day. Fedora is quite late to the game.

It doesn't matter whether it is anonymized. Apple has no business collecting information about what executables I am running on my own computer, or even whether I'm running executables at all. I don't care what their stated purpose is. I don't care what they want a "global view" of. It's my computer, not theirs.

I don't even mind that they've introduced a level on the totem pole that's above root. But on my computer, -I- should be the one at that level, not Apple.

> it's my computer, not theirs.

the issue seems to be that you still believe this?

to downvoters: you can think its not fair that apple effectively holds control of your device, true, but the only way you can change things is to not buy the products. If you buy it, you accept how it is. vote with your wallets, not in some internet forum

I think it depends on what distro you're talking about. Corporate distros like RHEL and SLES are absolutely going that way. It takes a lot of effort to backport fixes, and the money's not there in desktop Linux to make it worth their while if containerization is a viable alternative. Red Hat's gotten rid of a bunch of graphical applications for RHEL 10 and stated that users can get them from Flathub as an alternative. I believe there was some consternation when CentOS Stream 10 launched without even a packaged web browser and the advice was to install Firefox from Flathub (there's a lot of use cases where that breaks stuff), but it appears they've walked that back and started providing Firefox as a traditional package.

However, less corporate distros that mostly just ship built upstream software as-is since they don't have to support it for long periods (think Arch, Fedora, Void, etc) don't have that problem, so I expect we'll continue seeing them use traditional packages.

> I believe there was some consternation when CentOS Stream 10 launched without even a packaged web browser and the advice was to install Firefox from Flathub

Ubuntu does the exact same thing with their snap repository, the Firefox apt package from Ubuntu is fake. At least Flatpak is a community-led project unlike snap.

My advice is to add Mozilla's apt repo for Firefox by following the handy guide on their website. It's pretty short and easy (copy and paste).

My advice for web browsers is to use Flatpak.

You can limit the file system permissions of the app, like giving only access to downloads, so that if/when there’s a sandbox leak you’re fine. You can also disable various things, like webcam or mic, this way.

In addition, you can get perpetual updates to the latest version of your browser even on old, stable distros like Debian.

Running a new browser on an old distro would be a strong reason for me (if I somehow couldn't update the distro - but I can and I do.) Regarding security, the added work and complication outweighs the added security for me. I can't really disagree with having a different preference. More security on this wild internet is better, right?

IMO it's not much added work. In KDE you can navigate to settings and edit flatpak permissions, and flatpaks are available to download via discover. I haven't noticed any weirdness for firefox or chrome.

> I suspect Linux is going to go in a broadly similar direction.

Linux is pretty diverse, there are still distributions out there that haven't adopted systemd.

I understand and appreciate the sentiment, but I see the intent very differently. Apple is not employing a frog boiling strategy, but rather being responsive to an increasingly sophisticated adversary.

It’s like criticism of the quality of Google search dropping. It has absolutely tanked, but it’s not because the algorithm is worse, it’s because the internet has grown orders of magnitude and most of it uses the same hyper aggressive SEO optimisation, such that the signal to noise ratio is far worse than ever before.

> being responsive to an increasingly sophisticated adversary

"Those who refuse to give up essential Liberty to purchase temporary Safety deserve to have to deal with the GNOME desktop user experience."

I miss macOS sometimes.

It is because the algorithm is worse. So many garbage results are showing up which they continue to allow.

Kagi lets me completely block specific domains. If Google cared about quality they’d let you do the same.

You can also block specific subdomains, too. Useful when I want to be able to see finance.yahoo.com items in my search results, but nothing else from the yahoo.com domain.

That rationalization ignores a lot of confounding evidence, such as other search engines being able to deliver great results and adequately keep the SEO garbage out.

That’s kinda the SEO equivalent of security by obscurity though, right? SEO spam puts a lot less effort into optimizing for other search engines, whereas Google is dealing with being the primary target of every adversarial SEO spam site.

This is a great theory but it isn't the reason. Google management made a conscious decision about five years ago to prioritise profit over search quality.

We know this because the emails came out in discovery for one of the antitrust suits.

The biggest struggle is that the original Macintosh was so simple to manage. The original concept of system extensions to expand the capabilities and the file structure built on the hierarchy with the desktop as the top level was broken with the shift to Unix.

Suddenly the users file hierarchy started wherever the Home folder was located and it became an island of user controlled environment surrounded by complexity of computer operating systems.

The result I found overall well thought out but when the desktop became just a folder I felt the Mac moved from it’s simplicity embracing the complexity that was offered by windows.

Simplicity is fine for a hobby project. An operating system having zero concern for any kind of security is a non-starter today.

It's amazing the rose tinted glasses people have about the original Macintosh environment. It was insanely janky and (unless you were ruthlessly conservative) insanely unstable by today's standards. By version 10.5 (Leopard) the modern UNIX-based MacOS was unequivocally superior to Classic MacOS in every metric other than nostalgia.

I understand the trade offs and accept them. I was trying to point out where the split is and how it won't go back. I think the point of view expressed in your comment is s distorted as the ones your derding.

I also believe that the simplicity could have security as performant. The real advantage of the Unix layer is compatibility that the Macintosh was missing.

I sincerely tried to interpret what you meant here, but I failed. I understand the words, and the fragments of every sentence, but I wasn’t able to deduce the intent of your reply.

Are you trying to say that it’s possible for a system to be both simple and secure? Absolutely that’s the case, but with a trade-off — either it needs to restrict the user’s freedom, or be fully disconnected from the outside world.

I have pondering these ideas a long time and what is needed is an intense glossing over of all the details. The original Macintosh did exactly this and was called a toy and with 128k completely useless. Alternatively my unsophisticated Mom saw the Mac 128k demoed at the mall and went into a frenzy to get that tool. She wanted to publish documents.

The threats in the world are real and the internet doesn't help. I 100% agree that a network connection needs to be kept at a distance to make things simpler.

I think the power of language used to describe a system is where simplicity begins.

What I'm working on is creating a crisp line of delineation between "local" and "public" networks.

If by default after is on the "local" network auto-discovery is secure. If things are explicitly needed a user can publish them through physical manipulation to publish to the outside world.

The outside world can now be described using classic Users and Groups which is cultural easy to understand.

I'm trying to create an environment that focuses on making those 2 things plus a third element simple to understand and physically manipulatable.

The freedom I'm looking for is available on the "local" network. The "public" network is where our data is interchanged with the outside world based on our publishing. I don't expect people to interact with this layer much. I expect people to configure it for whatever institution/organization/government.

Most of the complexity I see in computing these days is market drive demand for eyeballs/clicks/...

Of course Google's algorithm is worse. Google prioritises showing you search results that make money for Google. Google has no incentive to show you anything else.

I can't believe I even have to say this out loud. Look up enshittification.

> Apple

Actively depleting the good-will they accumulated over the years definitely makes it worse. It's that harder to give the benefit of the doubt to a company also showing the middle finger to their Devs.

> Google

Giving priority to AdSense sites, fucking around with content lengths (famously penalising short stay sites), killing advanced search options. That's just thinking about it for 10s, but to me most of it is totally of Google's making.

As someone who runs a decent sized site with AdSense, I wish.

What used to be a powerful, user-respecting OS is increasingly starting to feel like an iOS cousin with training wheels

What OS are you talking about?

If Linux, you'll have to be more specific, because users don't use Linux. They use Android, Ubuntu, Gnome, pop!os, redhat etc.

They're clearly talking about macOS in that comment.

> Gatekeeper is becoming harder and harder to bypass

sudo spctl —-master-disable

Why remember all these little tricks Apple makes you do to use your own hardware?

stockholm syndrome

Yes because everything in Linux is completely intuitive and you never have to know anything obscure to use it to your liking…

The difference: in Linux it is a usability issue to be fixed, whereas on macOS it is a feature and explicit design goal to make it that way. In general, I have found that things which are difficult on Linux are so because the problem is difficult, not because the people who make my computer have paternalistic attitudes about my usage of it.

So it’s purely ideological without any real world difference?

Are most people better off with Apple defaults?

And it’s not because the problem is “difficult”. It’s because for 20 years it has been claimed that this will be the “year of Linux on the Desktop” and it’s never been good enough for most people.

That isn't the denotation of my post; I was not characterizing Linux as a whole, but only responding to your specific (unsound) analogy. It works better for me, for a number of reasons including that above. Perhaps it will work better for you, as well. :)

The second part of your post is incoherent to me, I can't tell what you're trying to say.

It’s perfectly fine. KDE and Gnome are both now more cohesive, more intuitive, and less buggy than either Windows or MacOS.

The problem with Linux is that, while it’s very good, it’s different.

Nobody actually cares how intuitive something is, at least not in absolute. People will still say Windows is intuitive. Pretty much nothing in Windows, from the registry to COM to IIS to setting/control panel/computer management, is intuitive. But they know how to use it and are used to that particular brand of buggy inconsistency.

Linux desktops have been high quality for a long time now. The reality is you, and others, measure quality as “how much is it like windows” or “how much of it is like macOS”. When that’s your metric, Linux will always come up short, just by definition.

If I pick up a Linux laptop right now, how well will it handle low latency audio? How well will it handle power management? My graphics hardware? Getting WiFi to work reliably is still an issue.

Can I get a high performance Linux laptop with good battery life, fast graphics, that runs cool and silent?

Yes, but be mindful of the hardware you're using

What's high performance for you?

I can certainly get a Framework (Fedora and Ubuntu officially supported), throw my prefered Bluefin-Framework image in and get working

Battery life around 7 hours is the average I see reported, Fast/Silent will depend on the model, but I don't see the issue really Upgradability and easeness of battery replacement are a plus

I just picked framework because they were first to come to mind, but I think Dell has a nice Linux story, Tuxedo also comes to mind

7 hours battery life is less than half of what I get on my MacBook Air. That wouldn’t last me on my ATL - HNL flight I took last year or my MCO - LHR 10 hour flight I’m taking this year.

These are the typical reviews I see around the Framework

https://community.frame.work/t/fw-16-review-the-good-the-bad...

Poor battery life, heavy, runs hot, poor build quality, bad speakers, and decent but not great graphics.

Yes, I just bought one a few months ago actually. A new lunar lake laptop. It gets 12 hours of battery life and has plenty performance for programming, plus 32 gigs of ram. It’s under 3 pounds and the screen is OLED.

And yes, everything works. On bleeding edge 2 month old hardware.

I even use thunderbolt 4 to connect my external displays and peripherals. Not only does it work, but it’s pleasant. KDE has a settings panel for thunderbolt. I can even change my monitor brightness in KDE settings. No OSD required!

But wait, there’s more! I’m running 2 1440p monitors at 240hz and the system never even hiccups.

But wait, there’s more more! The battery settings are really advanced so I can change the power profile, maximum charge, everything.

The only thing I’m unsure about in your comment is “low latency audio”. It seems low latency to me, but I’m not an audio engineer.

> Getting WiFi to work reliably is still an issue.

This should not be an issue. I have hardware that varies a lot and I literally buy random wifi dongles for $1, $4, $5, Amazon, AliExpress, etc. and they have all just worked on first plugin. I can easily take my phone and tether it to my PC using USB-C and it appears in my Gnome network list and just starts using it for Internet.

> how well will it handle low latency audio

Pretty well you can use OBS to verify this. There are plenty of settings if you want to tune that.

> My graphics hardware?

Just ignore Nvidia and move on. Sure they might figure it out one day, I gave up a decade ago and I use Intel integrated or AMD dedicated for GPUs. Nvidia does "work" for most purposes but it will cause you a headache eventually and those are not worth $400 to me.

> How well will it handle power management?

I enjoy the basic controls that Gnome provides that give me a simple way to basically say "go all out" or "save some battery" etc. There are finer grain controls available and I have used commands in the past to push crappy hardware to it's limits before I chucked it (old Intel iGPUs)

> Can I get a high performance Linux laptop with good battery life, fast graphics, that runs cool and silent?

You can get ones that are specifically marketed for this purpose. Tuxedo is one that specializes in this and obviously System76 also do. These have a higher price point than a regular Dell system, which IMO is the better option in some ways. Dell sells more systems and has more users and it will "just work". They sold Linux systems for years and still do I believe.

Regarding "running silent" this is a gripe I have, not that it runs loud but some laptops have custom RGB crap and sometimes in Linux I don't have access to the extra functionality to customize my lighting or manually set my fans to ramp up etc. There are projects that aim to do this, but I have not looked into them beyond the most basic `fancontrol` built in command.

> Are most people better off with Apple defaults?

I think once you expand the scope to "most people" it might become impossible to say what the correct answer for that large of a group is. In the past their value add might have been more compelling and their feature lock not as draconian. It appears some people think that has changed over time.

> In general, I have found that things which are difficult on Linux are so because the problem is difficult [...].

Hard disagree. Audio mixing is not difficult[1]. The Linux kernel guys were right - it does not belong in the kernel. The userspace story however, has been a complete shitshow for decades. I think Pipewire mostly fixed that? Not sure, sometimes I still have to log out and back in to fix audio.

The funniest part? It's been working in the BSDs all along. I recommend reading the source of sndiod[1].

[1]: <https://cvsweb.openbsd.org/src/usr.bin/sndiod/>

What's even worse? Probably systemd. I try not to hold a strong opinion - I tolerate it, the way I tolerate traffic when taking a walk. The technical issue however is several orders of magnitude simpler - again, the BSDs come to mind, but you can also write a complete PID1 program in about 20 lines of straightforward C[2]. I don't mind the commands being unfamiliar (they're already all different in almost every OS family); it's that the entire package is dreadfully large in scope, opaque, and I find it more difficult to interact with than anything else in this landscape.

[2]: <https://ewontfix.com/14/>

There are indeed always exceptions to generalizations, as you've pointed out. Though pulseaudio always trudged along fine for me (not like audio had always worked for me on other systems), and pipewire works perfectly.

I agree PulseAudio, Pipewire, ALSA, etc. are a pretty big shit show in Linux and have been for some time. From what I understand there are a few stories there with various levels of screw ups, but at no point was this situation the goal, and we are moving closer to an easy to use system that "just works" for these needs.

However, it's worth noting that audio experts doing high grade mixing in production are using these systems quite effectively and have been for a long time. It's similar to Blender in that regard with it always having the "guts" of doing great things, but only the experts that knew the correct spells to cast were able to use it effectively before the UI/UX was improved with 2.x and later I believe.

I work in live media production. I would never consider doing any mixing on Linux - just like I wouldn't consider putting Docker containers on a Mac to serve live HTTP traffic.

I never mentioned Linux. I'm curious why people want to pay for this component of their product from Apple.

Don't disable SIP, clear the downloaded/quarantine extended attribute instead. This clears all extended attributes: xattr -cr <file> and bypasses the obnoxious GK.

Frustrating thing is the earlier versions worked well, it protected you from accidental things but the way to force it was clear and obvious. Now bypass is obtuse and requires enough work arounds people advise just disabling it which is also bad to normalize.

I don’t know if it’s just me, but i want more Gatekeeper, not less - help me stay safer. Or is it a security theatre? Malware producers can sign things just fine?

An OS that won't let you do what you want to do is malware.

It is indeed starting to feel like that.

The more Gatekeeper, the more used people get to clicking OK without considering what it means. No amount of software can prevent the social engineering of an actual malware that tells the user to just click that OK button that they already have to do on a regular basis. Less is more here. It's why Windows tuned down their UAC after Vista.

> clicking OK without considering what it means.

Predefined value on current macOS's Gatekeeper is "move to Bin" instead of OK. Other option is Done - which cancels opening action. If you want to bypass that, you need to go to system settings > privacy & security and manually allow particular app there.

Who know what later updated will bring.

It is not a consent prompt. You get a choice on whether to trash the binary or quit.

To run a non-motorized app requires you to open a separate app, navigate to the security section and select that you want to authorize the app to run.

Apple does not have any desire to make distribution of non-notarized binaries commercially viable.

And we've seen this change across all browsers. There no longer is a "continue" prompt for TLS issues. The result is, way fewer maintained sites go months with an expired certificate.

Safe from what, exactly? Is this one of those state-actors-are-after-my-cat-photos delusions?

Reply on news.ycombinator.com