> Instead of building on those unique strengths, Apple has provided token support which must leave even its own engineers wishing for better, as they wade through the logarchives supplied in sysdiagnose dumps.
Lol, no. Unified log was designed first and foremost for Apple engineers and through some convoluted series of events that I am evidently not privy to ended up becoming exposed to developers as well. Except it was pretty much useless to developers because they couldn’t figure out how to use it. And not because the tools to use it effectively weren’t there, no, not at all; Apple engineers rely on them heavily (there are private, easy to use frameworks to work with log archives; the new, public OSLog framework that came out last year has an admittedly useful subset). No, the problem was that nothing was documented, most of the stuff that Apple was using to parse the logs and reassemble them remained private, and without these it’s hard enough to slog through the log stream let alone when you compound it with the many idiosyncrasies like private logging or trying to figure out which subsystem things are coming from. Really, Console is just the cherry on top because it gets even less love that logging guts itself because nobody has to use it internally.
There's a certain kind of arrogance that comes from assuming that proles - I mean end users - couldn't possibly understand our technical logs, and if they have a problem they should come to us, or wait until we've analyzed the telemetry and pushed a fix.
Quite frequently, logs show up things like missing files and directories, incorrect permissions, unexpected configurations etc. which can be fixed by a sufficiently technical end user, without needing to go through support.
There's a similar problem with error dialogs. Product people always push to keep technical details out of those dialogs, even if technical users would find the details useful for accomplishing their goals, figuring out what went wrong and working around it. It's more forgiveable for dialogs, as long as there are logs.
When the logs are similarly indigestible, the software is simply less usable by technical users. Quality better be damn high, because if it breaks, and there's no way to look into the hard shiny shell, it can generate an amazing amount of frustration to people who are used to making stuff work.
(Of course the % of users who are sufficiently technical is decreasing all the time.)
> There's a similar problem with error dialogs. Product people always push to keep technical details out of those dialogs, even if technical users would find the details useful for accomplishing their goals, figuring out what went wrong and working around it.
Lol, yes; the number of times I've seen a message to the effect of "Something broke. Contact your system administrator.", and I stare at it, and I mutter "I am the sysadmin, you stupid machine!" is excessive.
I will also note that leaving technical information in dialog boxes is better even for non-technical "end" users, as it isn't like the app worked anyway (so the user isn't satisfied right now) and it allows those users to screenshot the dialog and show it to their friends or paste it to a forum and have other people help them (which I have seen people do constantly with my error messages, into which I always provide the most low-level raw/useful technically information I can about the error).
I've always been baffled by this. Especially in pop-up dialog boxes, you can have drop-down arrows hiding the ugly bits (but that said, a core dump is usually not that useful).
I always thought: "Something Happened" might be the worst, ever, but I recently came upon this when setting up a Dell Desktop running Windows 10, trying to use a wireless keyboard. (I learned to always keep a USB keyboard around for bootstrapping purposes):
- "No keyboard detected, press any key to continue…."
To be fair, for as long as I worked at Apple, there was one dude who maintained Terminal, and I'm pretty sure it was his side-hobby. Nice guy! Name escapes me at the moment.
IIRC there were a handful of people that basically maintained all of the /Applications/Utilities (now /System/Applications/Utilities) together. Maybe half an engineer for Console?
Isn't the "Single Responsible Individual" practice fairly common at Apple? That is, maybe one person "responsible" for some specific class, app, or system, in addition to day to day work? I've read about the maintainers of things like NSOperation or the iOS Simulator, which always shocked me, given the complexity of those systems. If that's the case, it's completely unsurprising to me that Apple may have a software quality issue.
When I worked at Apple ~7 years ago on iOS I recall pulling up Console all the time. There are a lot more tools but not really for log analysis. Don’t know if that’s changed since but most of the internal tools were around really deep introspection (eg plotting power against various events on the system, etc) rather than logging itself
I mean Console works if you know what you’re looking for and how to filter out the junk. But in my experience people at Apple usually know the right subsystem and stuff and sometimes projects will even have the right log incantation for you to paste so you can just use that. I should also note that the new Console is ~4 years old, so there’s a chance you didn’t use it much ;)
Console.app always gets in my way whenever I'm trying to watch the status of some self-reporting processes. I just find it utter junk to use in the development flow - and even for trying to debug general purpose computer issues, its nothing but frustration for the average user.
I think there is a deep-seated bias at Apple against TUI's, and this is well and truly expressed in the flaming pile of junk that is Console.apps' GUI.
For me, tail and grep are always the better option when it comes time to look for messages, or try to observe what's going on with a system.
That said, it is also very shocking to sit and watch an idle MacOS machines' logfiles. Either most MacOS software is barely held together with bubble gum and duct tape, or there are a lot of messages being spewed by folks who forgot to turn their terrible debug logging off ..
Logging on macOS is extremely lightweight (lots of fancy stuff, much of which I don’t understand, there’s some in-memory stuff to prevent disk writes, settings stored in the commpage) if you don’t actually look at what comes out the other end, so there’s a bias towards “log a bunch and pick it out of a sysdiagnose”. You’re supposed to filter on stuff except Console is not very good at that.
Console is one of those things that as an iOS developer drive me nuts. It's absolutely a piece of trash. While Xcode drives me nuts as well, its at least usable (and 12 so far is much improved; although it only took 12 releases to make code completion work). It's like Apple decided to budget $XXXB to make things, and then decided that there was no additional money for Console.
One decent programmer could make Console a useful app.
I'm confused... When I start Console (on Catalina), there is a sidebar with a section labeled "Reports" which contains several groups of log files. It changes depending on what exists, but I currently have "Crash Reports", "Diagnostic Reports", "system.log", "Spin Reports", and a few more.
One of them is "Log Reports", which lists every log file in /private/var/log/.
Console.app also makes plenty of use of structured data: right-click on a log entry (in the live-scrolling main view), and it offers you a dozen different facets to filter the view: hide/show by Thread/Application/Subsystem/User/Category/etc,
I've actually thought about using Console for development. It's far better at least compared to my current go-to "tail -f"
Console certainly looks pretty but you’ll find very quickly that if you actually want to use it it’s really not that great. First off, streaming logs takes so much CPU that in
Big Sur when you open the app it just shows a pane warning you of the performance implications of actually “turning on” logging (which itself is kind of stupid, because one of the useful features of unified logs is that they store log messages from the past efficiently). And then filtering is kinda janky, and actually viewing the content of a message is a pain, and good parts of it often get censored, and…
(By the way, I have yet to see anyone use the other logs in the sidecar because it’s easier to just open that folder in Finder.)
Developers need the developer beta to work on their apps right now. He’s not using the beta for fun. Apple, realizing this, could have improved the performance of this developer tool.
While I like to crap on Apple for all the things they do wrong on their overpriced walled gardens, I can still excuse a performance regression in a beta that is trying to add proper support for a new architecture.
It’s pretty bad on Catalina too. Steaming logs in Console takes a substantial fraction of a core, so it’s not something I want to leave running in the background.
Cool. Thanks. Was wondering if it was something intrinsic to the logging system. I find Console a little easier to explore in, but the log command much better for most things beyond that.
I suppose it might be ripe for wrapping with a TUI that can help with predicates and options...
I remember years ago there was a very obvious console message (related to an invalid date) that was spamming the system log frequently for at least a month, across multiple minor OS updates, in nearly every application. It was actually noticeably impacting the CPU because it appeared so often.
Now I’m wondering if this console “rewrite” happened around the same time, perhaps in response to it. Maybe after seeing one difficult-to-wrangle log message, they concluded that gaining complete control over all logging was the only solution?
In any case, they went way too far. Console is effectively useless now; I got so tired of opening it up and finding nothing of value that I stopped even looking, and just apply every other possible debugging method first.
Their push for multi-process solutions like XPC have made logging even more useless because by default the new log system refuses to show output from sub-processes AT ALL. So imagine an app that previously had a nice sequential log for in-process actions A, B, and C; after migrating to sub-processes, now you see only the output of action B because the A and C actions are in different sub-processes! While there is a way to enable the output from all of them, it’s not the default and it’s not obvious and it’s just another stupid debugging hurdle.
And of course the API side of logging, i.e. OSLog, is still unusable if you have exotic needs like, I dunno, sending the logs somewhere where you, the developer, might take a look at them. Feels like having sessions telling us about improvements to logging without solving that one first is a bit pointless.
For lighter-weight logging, replace "debug" with "info" or "default". If your program has debug symbols, you can also toss in the --source flag to add the filename and line number for each logging statement, if available.
The new logging is a significant improvement once you get used to it, IMO.
GP meant from remote devices, like a phone, to somewhere the developer can see it, like a logging service. OSLog can't even log to a local file, making it fairly useless for in app logging even in testing, as there's no way to see your app's logs in the app, no?
As a non-mac user I am fascinated by blogs like this. Does Apple care? Like, if they just ignore the issue, will enough people stop buying their products that they will even notice? When Apple releases a new product, it seems to me the person who wrote this post will buy it regardless and there is absolutely no incentive at all for Apple to address the problem.
This doesn't even mention that at some point in one of the last 4 or 5 macOS/OSX releases, Apple made it so that processes started by launchd (i.e. GUI apps) no longer have stdout/stderr file descriptors that point to anywhere.
They used to "point at" the Console, which provided a handy, non-platform specific way to get debug output from a GUI app. But oh no, we can't have that. Got to use whatever the logging API flavor of the month is to get anything into the Console (that correct logging API (i.e. one that actuallyworks) has also changed over the last 4-5 releases).
Lol, no. Unified log was designed first and foremost for Apple engineers and through some convoluted series of events that I am evidently not privy to ended up becoming exposed to developers as well. Except it was pretty much useless to developers because they couldn’t figure out how to use it. And not because the tools to use it effectively weren’t there, no, not at all; Apple engineers rely on them heavily (there are private, easy to use frameworks to work with log archives; the new, public OSLog framework that came out last year has an admittedly useful subset). No, the problem was that nothing was documented, most of the stuff that Apple was using to parse the logs and reassemble them remained private, and without these it’s hard enough to slog through the log stream let alone when you compound it with the many idiosyncrasies like private logging or trying to figure out which subsystem things are coming from. Really, Console is just the cherry on top because it gets even less love that logging guts itself because nobody has to use it internally.