The big issue which the author mentioned, where Macs now spew logs at a rate of thousands of messages per second is the real WTF. I don’t even have a problem with verbosity per se, the Mac logs are not only informing of events that have a severity level of debug (such as “Woke from sleep due to network” or info, such as “Display #1 was disconnected” - they’re brimming with literal errors. It’s as though a few years ago they decided to simply give up on having a stable OS which at least functioned correctly, even on a clean install at idle. The logs make clear that most components are full of uncaught exceptions that apparently they don’t even care about. It’s weird that they don’t think this will eventually destabilize the whole system.
With that level of neglect among Apples system developers, the logs may as well just be piped to /dev/null anyway, because ain’t nobody got time for digging through that volume of logs to troubleshoot anything. It’s a far cry from 10 years ago, when if you were having something wonky happening, you could go right to Console and find the whole story spelled out for you.
Developing on Android similarly drives me mad because of the volume of garbage spewed in Logcat. Yes, you can filter, buy if the problem is in an external component you might need to see the full log - and then it's wading through MBs of random errors, warnings, and other nonsense trying to figure out what the relevant log bits actually are.
They’ve always been this way. Eventually the OS will get noticeably shitty, then it will be embarrassing, then they’ll do a cleanup sprint and fix most of them.
When I worked at a (formerly state monopoly)telco around 2000 it would happen that an inspector would come in and look for any warning lights on equipment. If you were around you'd better know how to fix it right away.
These days that kind of attention to detail is long lost in the sea of competition and cost cutting. But issues tend to build up now and cause really expensive megaprojects to really fix them.
I could imagine software engineering followed a similar trajectory.
It used to be that even-numbered releases fixed bugs and stabilized the OS, with notable features coming in odd-numbered releases. Now they don’t care. Unifying iOS and macOS has become the goal, and probably some PMs are getting nice promotions thanks to that. The golden stability of macOS (a la Snow Leopard) is gone. Now I get random reboots every other week, so I keep a tight Time Machine schedule.
> It used to be that even-numbered releases fixed bugs and stabilized the OS, with notable features coming in odd-numbered releases.
That's a myth. The stability comes from minor bug fix updates, not from major updates. And the even-numbered Mac OS X 10.4 Tiger for example had huge new features, such as Spotlight, Dashboard, VoiceOver, etc. Mac OS X 10.2 Jaguar also had huge new features.
I stand corrected, and I’ll rephrase it as “it used to be that every now and then Apple released a version of macOS with notable fixes and small improvements.”
I’m not downplaying how much work is going into crazy features that millions probably like. But I make software, and I’m tired of how macOS is now marginally less annoying than trying to maintain an Arch Linux setup.
I went through a period of burnout at my work during Covid.
I was in Canada at the time though and our lockdowns lasted through almost 2 years though (unlike many places in the US that either did not do lockdowns at all, or did only for a very short period).
In any case during this time period of being stuck, isolated and inside most of the year I had little else to do but throw myself into my work. Today I have the same job and a much healthier balance but that’s mostly due to a really good manager that noticed and helped me out.
> Mac OS X had a yearly release cycle in the beginning if I remember correctly.
That's not correct. Here are the # of months since the previous Mac .0 release:
10.1.0 6
10.2.0 11
10.3.0 14
10.4.0 18
10.5.0 30 (delayed due to iPhone)
10.6.0 22
10.7.0 23
(Steve Jobs resigns)
10.8.0 12
10.9.0 15
10.10.0 12
10.11.0 11
10.12.0 12
10.13.0 12
10.14.0 12
10.15.0 12
This was a logical progression until 10.8. The fundamental software development principle is that immature software is easier to improve, because there's a lot of low-hanging fruit — glaring bugs and missing features — whereas mature software is harder to improve and easier to accidentally break. That's why major updates should come more slowly as the software matures over time.
It's no coincidence that Tiger and Snow Leopard are viewed as high points in Mac OS X quality and stability. It's not because of the .0 releases, which were very buggy like any .0 releases; it was because they ultimately became very stable after many many months of minor bug fix updates with no major updates (30 and 23 months respectively).
Also worth mentioning: major Mac OS X updates used to cost $129. Now they cost $0. You get what you pay for. Now users are pushed into updating whether they like it or not. You might wonder whether the principle starts to apply: if you're not the customer, you're the product. After all, Apple has been transitioning into a so-called "services" company. They'd rather sell yearly "subscriptions" (more accurately, rentals) than major OS updates.
> In my opinion, the drop in quality was probably at least also related to Steve Jobs‘ death.
This may be true, but note that the change in OS release schedule coincides with the death of Jobs. Mac OS X 10.8 was the first post-Jobs release and also the start of the annual schedule.
Thanks for the details. Just to be clear, I‘m certainly not in favor of the yearly release cycle. Or rather, I‘m not in favor of any primarily calendar driven release cycle.
FWIW, the update from (checks notes for the naming) Ventura to Sonoma is pretty much just a bugfix release, there were almost no noteworthy new features.
There's no such thing as a major bugfix release. Every major update introduces more bugs than it fixes, and Sonoma is no exception to that hard rule. Which bugs were fixed? I've personally filed multiple new bugs against Sonoma.
I wrote about this in my previous comment: "It's not because of the .0 releases, which were very buggy like any .0 releases"
I have been at a company that transitioned from normal release cycles to arbitrary yearly release cycles. Every year became a literal race to fix issues, improve existing features, and add new features. It was a gigantic mess. The yearly release cycle only really gives a few months to do all of that, because the other months are doing integrations, testing, and bug fixes to get the release out the door.
I can certainly see that if the emphasis on new features greatly outweighs that of bug fixes and improvements, then you can extend the implementation months for larger features because you can just bleed the bug fixes and improvements into next year's release. But then that year's feature set takes precedence and dept accumulation occurs.
My own experience with macOS is that it stopped "just working" a decade ago Apple stopped caring about it and poured everything into iOS. And then this is exacerbated by today's mode of operating by just treating features like they're free and frequent release cycles.
It's not the release cycle per say, but the need to pack new features in each cycle for marketing and sales.
A regular release cycle that focuses on security, stability and incremental improvements, is fine as long as there isn't a need to constantly push new features in.
In my experience engineering teams usually always want to fix issues like this. However, this typically come down to something leading to either pressure to ship features relenting and engineering being allowed to clean up debt or awareness of quality issues increasing. Seems like burnout would be a factor if Apple tried to fix it but failed or took forever.
Oddly, being paid more and being safer while others get worse can actually contribute to burnout. Comraderie and morale matter.
Burnout is more about a disconnect and dysregulation between workload/emotional regulation/stress/morale than it is about any one of those factors.
As anyone who has burnt out at a super boring job, or a pointless but high stress job can attest.
A high stress, high risk, job that matters, keeps someone interested, and someone can take breaks from is much less of a burnout risk than one that someone can’t see matters , or they don’t grow in, regardless of the stress level or ability to take breaks from.
Thank you for the reminder. This random developer (not from Apple) does feel some exhaustion, but I have it lucky compared to some other folk and should be grateful for that. Hoping those other folk who have it worse will have some relief too...
The log censorship _has_ to be because sketchy / malicious apps are reading private data from the log. And it seems pretty obvious that the greater good is achieved by blocking that personal data.
As a user, I certainly wish there was a logging level / filter / setting of “things that are broken that you can do something about”, along with the ability to dig into the underlying trace data that helps you better understand details about the problem. But I think it’s pretty clear to everyone that’s not the user that Apple is solving for. Even if you did have a clear bug & root cause, good luck getting it acknowledged & fixed through their public-facing bug tracker.
These profiles are provided by Apple for the explicit use of debugging... what makes you think bad faith actors wouldn't take advantage of harvesting such juicy data? Especially at the verbose rate macOS provides...
(1) Very few Mac users have installed the private log debugging profile.
(2) The number of Mac users who have both installed the private log debugging profile and also installed malware without knowing it is vanishingly small.
(3) People mostly use the profile temporarily and then uninstall it, so even in the vanishingly small number of cases, the window of opportunity is a lot smaller.
It would be a lot of effort for no return. Bad faith actors are looking for easy, plentiful targets. Expert users who comb the logs are the opposite of that.
In fact, it's a great deal of effort to find useful information in the logs even for good faith actors looking at their own machines, because of the loquaciousness of the OS.
How exactly is a bad faith actor going to spearfish [people who have temporarily installed the Apple private logging profile]? And why? What exactly do people like Howard, the article author, and me have in our private debugging logs that's interesting, useful, and worth spearfishing specifically people like us?
Keep in mind, crucially, that the aerospace employees were publicly known via LinkedIn to be aerospace employees. How is it publicly known who has temporarily installed the Apple private logging profile? Who besides the article author would even announce that publicly? Also, the value of hacking an aerospace company is known.
You can come up with any conspiracy theory you like, but the level of plausibility in this case is nonexistent.
Have you ever looked into the average email inbox? 99% of bad actors are simply casting a net as wide as they can to find the most gullible people.
Targeted, specialized attacks are rare.
But people basing their routines around the assumption that it won't happen to them, is why some notable attacks have succeeded.
Obviously you need to base your practises around your own risk profile and their will be a point of limited likelihood of useful return on effort that will be different for different people/organisations, but some should be paranoid enough to worry about that other 1% of attempts.
Under the section heading "Privacy", the author wrote: "Censorship to maintain privacy is an important feature in the Unified log, and is responsible for so many of its entries being peppered with <private> instead of revealing potentially sensitive data."
So yes, this is privacy-related.
> Just enable more verbose logging to see all your personal details in said logs again.
From the article:
"Apple has now decided that some log content is too private to reveal even when privacy has been removed. I came across this recently..."
"Of course, it may be possible to turn this additional privacy off, but the documentation leads us once again to a guessing game."
This is overly general: whether or not secrets should be in diagnostic information depends on what you’re trying to diagnose. I’ve written PAM modules, for example, and logging TOTP secrets and passwords was absolutely essential for development purposes, even if I eventually deleted the relevant code for production.
But you shouldn't! Could you log your DB creds to your error logs for debugging? Sure! But they shouldn't go there! If you need to check them, use the mechanism for accessing creds.
I have to think that if you want this level of insight and control over your system, you're going to be less frustrated by not using MacOS at all and switching to Linux or a BSD.
Macs are appliances, like a fridge. When your fridge breaks, you don't look at the logs and try to diagnose it yourself, you take it to a repair shop. Apple has been pretty clear they really don't want you poking around on their systems.
I know about this. Unfortunately it is in no way sufficient.
I want it to stop dropping these _anywhere_, and I'd be more than happy to give up thumbnail functionality for this. However, afaik the "easiest" way to do this is apparently to bind a hook to listen to all file system writes by everything and then sweep up the junk whenever it is detected...
That's definitely an aspect that got worse during these 20 years though, and Apple has no incentives to reverse the trend. If anything, there C* suite explicitly advocates for a more iOS like model all across the board.
Parent's comparison point was linux, but I'd argue current macos isn't that far from current windows.
Seriously - this dichotomy is absurd. My workplace has been RHEL for 20 years and has quietly side stepped all of this nonsense. Yes, even after the acquisition.
The way I use my laptop (plugged and always attached to a monitor, keyboard and external mouse), a desktop would be the most appropriate choice. And no, I don't want to work at coffee shop and a smaller, lighter, cheaper laptop could do if I wanted to be mobile around the house (WFH).
We run Dell Latitude, Precision, and sometimes XPS (though I hate those). Pretty much no issues. Dell would rather us run Ubuntu it seems, but it's close enough that RHEL tends to work fine.
No they just check the "water damage" sensors regardless of the problem and then tell you the price of changing the bottom bit, the top bit, and the price of a new machine, which are conveniently all the same price.
[edit]
Aha, touched a predictably sore Apple spot there I see.
> When your fridge breaks, you don't look at the logs and try to diagnose it yourself, you take it to a repair shop.
I for one welcome the ability to troubleshoot and fix the devices I’m using. Unless it’s still in warranty (but maybe even then) I do want to look at logs or diagnose the problems. Order the replacement part online and have it running again. There’s no reason I must rely on someone else to do something I could and should be able to do myself.
This is hilarious. The idea that the typical IT admin wishes that Linda in Marketing would use Linux is so divorced from reality.
IT just wants a fleet of systems that are easy to automatically deploy, patch, and restrict dangerous actions on. The easier they are for the lowest common denominator employee to use, the fewer tickets get opened.
The idea that your IT team will ever waste their time crawling through your local system logs is unrealistic.
I’m not saying the log shouldn’t be there or shouldn’t function properly, I just think that macOS being commercial and popular makes it very easy to administer compared to a Linux desktop. You just buy off the shelf products like Jamf and click a few buttons and that’s about it, voila, you have a managed fleet.
The architectural elegance of the system is secondary to the amount of labor cost it saves.
You can even order a computer directly from Apple shipped to your employee’s house and have it zero touch provisioned. I’d love to see a Linux laptop with that capability (really, I would love to see it).
I worked as a CPE before moving onto SRE and this is spot on. Jamf and others like Kandji are excellent tools for deploying, configuring, and erasing the device at scale and same thing for InTune for windows.
There’s no equivalent for Linuxes other than agent based CMs like Puppet or Chef and those tools don’t deliver the same features as the tools that are offered for windows and macOS.
Not sure why you are downvoted, because this is spot on. You can tell many people on HN nave never worked in an enterprise environment. As a developer I would love to have a Linux laptop, but a Mac is as close as I can get. Companies do not have the resources or wherewithal to manage and secure 3 or more disparate desktop platforms.
Macs are some of the easiest things to administer because of the rock solid MDM, nuke and block, lost item mitigation (as soon as declared lost, can wipe remotely, and even sometimes track via geolocation for filing police reports and for insurance claims). The pervasiveness and userfriendliness of filevault makes it so much easier than trying to enforce luks on linux.
If you do encounter an OS level issue that can't be solved by first or 2nd tier local support, wiping from internet recovery is the next step, followed by sending it back to Apple (if you are within applecare) for direct replacement.
The Apple Business team is incredible, and is much better than regular genius bar service at the apple store.
They are pricy on the whole, but it's worth it if you have a need for macs in your environment.
> Macs are some of the easiest things to administer because of the rock solid MDM, nuke and block, lost item mitigation (as soon as declared lost, can wipe remotely, and even sometimes track via geolocation for filing police reports and for insurance claims).
All these things you mention are not “administration” in a “manage systems that end-users use”, they are “manage devices” activities. Macs have the literal worst business/enterprise administration administration/manageability experience. At previous $client, they had in excess of 30k desktops, and in excess of 50k total endpoints.
They spawned a new opco, and that new opco wanted all macs. 12 months along, that was all thrown out because of the ongoing challenges of securing, managing, and administering the devices, and supporting the userbase. It wasn’t even a TCO thing (that was also wild, about 4x over a “regular” workplace, that being either Win10 or a supported Linux build), it was a “we never want to see Mac’s in the entire global organisation ever again.
Macs have their place. There are plenty of environments where they can function adequately. Medium and Large Enterprise isn’t amongst those, and that is 100% due to the dire administration experience.
> 12 months along, that was all thrown out because of the ongoing challenges of securing, managing, and administering the devices, and supporting the userbase.
But did the admin team know about the macOS environment? We’re a Mac only environment in my company and the management AND securing of all the devices is trivial (can be done easily by one person for more than 100 devices with time to spare, and it’s scalable).
But of course if the team is used to other OSes, they won’t know the tools and will find it difficult to manage Macs.
Windows's fleet management features are far better than Mac and Linux. Centralized user management, patching, policies, and application deployment all built into the OS "just works" for IT in the same way Macs "just work" for users. It's not something that can be seen as easily from a user perspective though. I've been... frustradedly enjoying watching the IT department from the company that acquired us attempt to recreate Active Directory in aggregate with a bunch of third party tools on our Macs. An example: last week I had a meeting with IT because one of their tools wasn't collecting logs or whatever. Turns out the tool didn't have the full disk access permission turned on. No good enterprise management solution should allow the endpoint to override settings from corporate, and especially it should have a way to change every setting on the device remotely. Windows has that built in to Pro and Enterprise editions, Linux has enough server management tools that you can sorta build one yourself, Macs like to think the company's laptops belong to the users.
I'm glad Apple's pushing back on the abilities of corporations to install rootkits and other spyware on their employee's laptops. One would think that, after things like the Solarwinds hack, IT departments would be more skeptical of making a big single point of failure for security issues: I don't think the purported DLP and other justifications for this software are really adequate.
Well, I don't think employees should be bringing their own laptops to work anyway. It's extremely borderline with phones IMO and they have facilities like work profiles for handling that specifically. But the business should be able to do whatever it thinks necessary with the business's laptops it issues to employees. Sometimes it's even required to legally.
I’m not talking about personal devices, I think the typically IT policies at large corporations cause more problems than they solve and I think Apple making certain things impossible is a great idea to help push back on these policies: for example, IT should not need on-demand screen recording or key logging access and, especially, should not be able to put such software on an employee’s work laptop without explicit consent on the part of the employee.
Yes. It doesn't surprise me that some organizations want to spy on their users, but I'm thankful Apple is making it harder for them to do so without making it transparent to the end users what's going on.
I'm sorry, my last comment was unnecessarily snarky. I was coming back to delete it and write a more respectful one but you had already replied.
BLUF: For reasons of security and compliance, licensing, and low levels of computer skills among users, privacy-invading enterprise management tools give IT departments the best and most efficient way to accomplish their goals. IMO if you don't want work looking at personal stuff, then don't do personal stuff on work devices.
In short, this discussion highlights the difference between computer power users (developers in particular) and IT. If you're a dev, you're likely highly motivated to get work done, practice security best practices, and keep your system in a well-running configuration. The average employee (which does include many devs) is not like that. When you think of the things you might want privacy for on your work device, it's probably going to be things like checking the news, listening to music, maybe putting YouTube on in the background. Innocent stuff that a micromanager might not like but is probably better for employee mental health anyway. When IT thinks of what an average user would want privacy for, their experience tells them that it's Facebook, porn, and shady gambling sites that say "you've won $1 million just click notmalware.exe to claim it!!!".
I and most IT departments wouldn't mind if everyone used their work computers for only the former non-work activities. I'd bet that the vast, vast majority of IT guys think that "boss constantly monitors your screen" software is creepy and unethical. 99% of users don't get their computers infected trying to download more RAM because Excel is slow because they have a dozen workbooks open. But there's one user that does, it's hard to identify who it is in advance, and once it happens once management wants it to never happen again.
As far as immediate screen recording or key logging, I can tell you from personal experience that some people cannot do anything outside of their established workflow. That includes clicking the link in the email I sent them, clicking the "download support tool" button, clicking the downloaded file, and clicking "allow access". Walking someone through that series of steps over the phone during COVID was about half an hour of wasted time for both me and them. The next time they needed support though, I could just hop on via the support tool immediately. (Just for clarification, the tool was approved and licensed for us to use; it wasn't just Teamviewer I got the user to install. For administrative reasons though, many of the systems that were our responsibility were not installed by us.)
The creepy micromanaging screen logging stuff that runs constantly is not good. Those capabilities are good and useful in many circumstances, but in the type of stuff I think you're thinking about I agree it's horribly unethical. To be frank, I don't think that OS permissions preventing that from working is the right line of defense against that though. If it gets to the point where management thinks that's even an appropriate solution then management has clearly lost the plot and OS permissions won't help.
Automatically installing software is also difficult. What should IT do if, for example, Docker Desktop changes their licensing terms and now we need to move everyone to Rancher Desktop? What if networking wants to move everyone from some horrible IPSec VPN installed in 2013 to a new and modern Wireguard-based client? What if the helpdesk is inundated with tickets asking how to install the new version of Acrobat since the corporate newsletter announced we now had it? Just install it individually for user after user after user, or install it for everyone at once and be done with it? (Acrobat was the worst. IIRC I had to install three different versions over the course of a year once, and one of those versions required that you completely remove every trace of the old version first or else the new version would fail silently when you tried to start it. And of course Adobe's uninstaller wasn't comprehensive enough. I remember a ~2 week period where three quarters of my tickets were manually removing the old version of Acrobat and installing the new one.)
You said installing software should require the user's explicit consent. Linda in HR is probably going to dismiss the popup asking to install the new VPN because she doesn't know what it means. It's bad enough already with updates. If you don't have automatic silent background installs, that means that the day after the old VPN stops working, Linda and a dozen other people are going to submit tickets saying they can't access the network anymore. You won't have problems: you know what a VPN is, you read the emails from IT detailing that they're upgrading, you know that the new version will be faster. Not everybody is as good with computers as that. Automatically installing new software often means avoiding a bunch of tickets allowing helpdesk to work on actually meaningful things.
Those privacy-invasive tools are critical to IT getting their work done. Now, I absolutely get why people have bad attitudes towards IT. IT is often unfairly biased against users. After all, the only users they interact with most of the time are morons, and that paints an unfair stereotype. Like, for example, the stereotype that those users are morons: it's not the user's job to use a computer, it's the user's job to do whatever their job it, and the computer is a tool to do that. Yeah, users should know a little bit about how to use their tools, but that's a little difficult to enforce. IT guys in general have a terrible attitude towards the people it's part of their jobs to help, and that makes interacting with them unpleasant. And corporate-ordered creepiness is often implemented via IT. IT gets a bad rap and they often deserve part of it.
But regardless, not using those tools is like managing a fleet of servers by SSHing into each one individually. Even if you have failproof processes where you never forget a step, it just doesn't scale. IT has management breathing down their neck constantly, along with half a dozen other teams all with their own concerns and problems: networking keeps moving switchports to different VLANs and forgetting that they need to update the routes to the printers; security says they need this AV tool installed to hit a certification management wants to put on the homepage; management found out last week about a guy who's done nothing but manage his fantasy football team for the past three months and thinks the solution is to watch everyone's screen at work. I'm not claiming IT is unique in this regard to be clear: devs with too many project managers have the same sorts of complaints. But fundamentally when IT does something stupid to your computer, there's a very good chance that it's been caused by something akin to someone in a completely different department doing something insecure and now IT has to prevent that from happening again. Centralized tools that allow you to control computers remotely, install software automatically, and change settings as a super-superuser are required for managing a fleet of devices operated by people who want to get things done.
My personal policy is that work-owned equipment is for work stuff only and I will never use it for personal stuff. If I want to listen to music or whatever, I'll use my own device. This avoids every problem with employee privacy on work devices. If I could wave a magic wand and make every person follow that perfectly then none of this would even be a controversy. But people do want to do personal things on work computers, and IT departments have things they need to get done across entire fleets, and the intersection of those things causes problems.
> If it gets to the point where management thinks that's even an appropriate solution then management has clearly lost the plot and OS permissions won't help.
I generally agree, but it helps everyone—IT especially—to just say "Apple won't let us do that"; rather than having to say, "it's possible but I won't do that".
> Now, I absolutely get why people have bad attitudes towards IT. IT is often unfairly biased against users. After all, the only users they interact with most of the time are morons, and that paints an unfair stereotype. Like, for example, the stereotype that those users are morons: it's not the user's job to use a computer, it's the user's job to do whatever their job it, and the computer is a tool to do that. Yeah, users should know a little bit about how to use their tools, but that's a little difficult to enforce.
The big part of people's bad attitude towards IT is that, from user perspective, they're noticeable only when they suddenly make it more difficult or impossible for the user to actually do their job. And they do it often enough that they're seen as an outside force that's at best annoying, at worst dreaded.
Now sure, the typical user may not know the other side of the coin, and in many cases the annoyances are legitimate from the POV of safety and effectiveness of the company as a whole. But then, occasionally IT seems to not see the costs either.
I'm biased here, but I have this negative bias towards IT despite being rather experienced and savvy computer user, because I've been on the receiving side of changes that make it hard for software devs to do their work, in companies that make money selling software.
My favorite example is Windows Defender "realtime protection" - a functionality that adds a noticeable cost to individual I/O operations (writes) on any file except those on one of several exclusion lists (excluding by location in the filesystem, excluding by the process making the I/O call, etc.). This feature has really bad interaction with typical software dev work - version control, building software, running tests, and other things a dev does constantly, tend to do a lot of tiny I/O operations, and they all suffer the penalty. This can easily make all your actual work activities take 2-3x longer - or more, when you account for the disproportional distraction it causes[0].
Now, the corporate IT decides the endpoint machines are not allowed to add additional exclusions to the list, even if otherwise the user has local administrative rights. The list is fixed, contains mostly system stuff, and all your dev tooling and source code is not on it. I wonder if anyone tried to calculate the total cost of this one decision - money lost by software releases being effectively delayed 2x, and in associated extra salaries for one of the most expensive employees in any tech company? Is it worth it, relative to whatever this decision saves? Is it worth sticking to it, and ignoring tickets from software dev begging for help, and/or replying to them that the company will reimburse them for a laptop cooling pad?
--
[0] - https://xkcd.com/303/. Or, when single `git add` of a file takes 2 seconds instead of near-instant, that slowly makes you avoid touching it. `git commit` taking 1 minute instead of few seconds (for executing post-commit hooks) is the difference between being in the flow and browsing HN. Etc.
I say this as a dedicated Linux user of 25 years: neither Linux nor Mac have anything approaching the remote mass administration capabilities of Windows. Windows brings a ton of problems with it, but the ability to just GPO literally anything you want is the big reason it's popular among back office admins.
"Continuing to use the apple fridges requires a subscription to applecare to fix and diagnose any problems we previously could fix, the TCO of this hardware is now higher...."
My last fridge literally had the ability to press some buttons to get error information as an encoded sound. An app is used to decode the audio to obtain something that can be read. Sadly it was a break in a component that cannot be swapped out.
I've fixed appliances, and the best source of information about what is wrong is usually the microcontroller. Sometimes it's just a hex error code, and that's enough. A firehose of text like MacOS currently produces is unusable.
Given that Apple already had a way to unhide the private info, and that we are on the .0 release, this could just be a bug. It could be a new thing going in the log that isn’t working right.
Also, I can see why ShareKit has potential to contain very private info. I don’t know that I’d love for my computer to save a list of share sheet activity in plain text.
> If you used Macs before Sierra, chances are that you were happy to browse their logs when necessary
Citation needed, I say chances are 99% of Mac owners have never opened system logs.
With that level of neglect among Apples system developers, the logs may as well just be piped to /dev/null anyway, because ain’t nobody got time for digging through that volume of logs to troubleshoot anything. It’s a far cry from 10 years ago, when if you were having something wonky happening, you could go right to Console and find the whole story spelled out for you.