In my experience, this kind of thing is no different than any other system I've used over the years. Windows, Linux, OS X -- all of them end up with odd problems that require a bit of digging around the web to sort out. Singling out OS X as "then you're SOL" seems like FUD to me.
When you have a problem in Linux, it may require some searching, but the solution usually makes sense at some level. Unless you're doing something very strange or bleeding edge, it's more likely that what you find won't be totally incomprehensible or inexplicable.
As for Windows... just restart it, you'll be fine. ;)
It only makes sense because you understand Linux. Windows is a black book to me, but I've worked with Windows hackers who had the same intuitive understanding of how their system worked as the neckebeardiest BSD hacker has of theirs.
I don't find this latest OS X buglet to be difficult to understand, but then, I've been using OS X for ages.
Are you suggesting Linux problems are easier to fix because you can read the source code to the kernel?
I'm sure on some level that's true, as you have the option to learn how, say, your WiFi drivers operate to decipher why your signal drops to three bars every 20 minutes.
However, in Windows, I generally know where to find configuration info: In one of three registry hives, which follow a pretty easy to parse tree structure.
In Linux, I'm totally lost finding where to configure different pieces of software. Each distro puts their various configs in different spots. Some in /etc/local/whatever, /etc/whatever/, /usr/share/local/whatever.d/, /opt/whatever/, /etc/opt/whatever.conf/, /usr/local/share/whatever.d/ and so on. Some times there are duplicates, which one is the correct one? How do I know? And on top of this, every config file uses different formats.
Wat? OSX is an open source OS (at the kernel level and more) but its UI isn't. Also, are you actually implying that you would've downloaded the Gentoo source, sifted through the source until you found the file with the bug, then debugged the compiled binary to see what exactly is happening? Yeah, I totally download all of Android's source when my app crashes.
Graphics drivers aren't open source either. A very large amount of actual Mac OS X performance problems and crashes come from the combination of the graphics drivers and CoreGraphics/Aqua. Both of these systems can use main memory and therefore might be influencing or be influenced by paging issues.
If you can get a reproducible case and capture enough useful diagnostic information you can give that to Apple to try to get a fix in some future version of OS X. Have a look at /usr/bin/sysdiagnose and /usr/sbin/spindump among other tools. I'm sure there are more diagnostic tools internal to Apple, which would require that you have a case that is reproducible from a new OS X install rather than from a system with files copied over. If you can identify the one file from ~/Library or wherever that triggers it, then you can pass that along as the repro case.
In general people (like me) just don't have the time to hunt down every crash, hang, etc. we find when using a computer. So I can understand if one doesn't bother with capturing diagnostics and repro cases or with downloading Darwin or Android source to debug a crash. I can also understand where huge frustrated discussions like this one come from. But deep down there is an answer, and it likely is not from some huge corporate failing on Apple's part.
Obviously, there's a level of understanding that requires source access, but problems for which that level of access is necessary as few and far between. This problem, for instance, is not one of them. I highly doubt that most people who are using an OS for which they have source access are either interested in or capable of doing analysis at that level.
>When you have a problem in Linux, it may require some searching, but the solution usually makes sense at some level.
Well, since you used "usually" and "some level", the same exact thing holds for OS X.
If THIS particular one doesn't make sense, it's because nobody bothered explaining the mechanism yet -- which should be trivial if investigated.
Isn't it obvious that "safe mode" boot foregoes running some system stuff? That probably lets some script the chance to fix something (bad permissions?) that it couldn't fix when the full system, sandboxing, mdworker etc were running.
Usually true, but Linux hardware problems are another matter. If its FireWire based you just type random things from forum posts until something happens.
You really shouldn't write random things from internet in your terminal.
Maybe the hardware problems is for the stereotypical consumer isn't interested in Linux if you compare to Windows and Mac OSX. Different story on server-hardware/software though.
