different versions of macOS, kexts, firmware, etc.combinations of hardware, including case/enclosure, cable, host Mac.In principle, all these tests should be deterministic, so with negligible noise or error, but in practice there are a great many other factors which can come into play, including: Having decided what to benchmark, we then need to get its best estimate, either with small dispersion or known variance. And if the test doesn’t explain exactly what it does, we simply can’t trust what it’s doing. So any benchmark which runs crafted code calling low down functions in C doesn’t tell me as much as that using standard FileHandle calls from Swift or Objective-C. That’s important, because some benchmarks use quite different code from that normally used by apps, and features in storage can also be tuned to deliver better benchmark results even though in real use they’re slower. What I want to know, though, is how fast storage will be when in use, typically doing mundane tasks like reading and saving files, and when copying in the Finder. For those in the trade, it’s to show how fast their product is compared with their competitors. For some, it’s to prove that their purchase choice performs better than those of others. We run benchmark tests for different reasons. This article explains some of the difficulties in interpreting this avalanche of data, and how we can move forward. Then all I had to do was to, basically speaking, replace the occurrences of " NSMenuExtra" by " NSStatusItem", since the two APIs are almost the same.Over the last couple of weeks, I’ve read more benchmarks and other performance measurements on SSDs than I’ve ever seen before, thanks to so many of you who have contributed results from your own tests. So, how did I port MenuMeters to El Capitan, then? Well, I just gave up having ⌘-dragging. In El Capitan, Apple added a more stringent check of the allowed NSMenuExtra's, and MenuCracker no longer works. MenuCracker was an NSMenuExtra that pretended to be one of those allowed ones, which, once loaded inside SystemUIServer, removed these checks, so that more NSMenuExtras can be loaded without any problem. MenuMeters used this to inject their own NSMenuExtra's to SystemUIServer in fact MenuMeters' author is one of the main authors of MenuCracker.Įssentially, until Yosemite, SystemUIServer had a fixed list of allowed NSMenuExtras. But until Yosemite, there was a known way to work around it, available as an open-source code as MenuCracker. But since 10.2, Apple had a code that blocked SystemUIServer to load non-system-provided NSMenuExtra's. In fact until and including OS X 10.1, Apple allowed it. But this happened later than the need to port MenuMeters to El Capitan 10.11.)Īnyway, due to this better behavior of NSMenuExtra's, people often wanted to write their own. (On macOS Sierra 10.12, Apple finally implemented and enabled ⌘-dragging for all NSStatusItem's, including this port of MenuMeters. I have no idea why ⌘-dragging was not provided for the latter by the system. One good thing about the former is that you can rearrange them by ⌘-dragging the menu items. The latter can be displayed by any app written by any developer. The former are loaded and displayed by SystemUIServer, a process provided by the system. There are in fact two types of such menu bar items, one known as NSMenuExtra's and another known as NSStatusItem's. As you very well know and is shown in the screenshot above, there can be various utilities put on the right hand side of the menu bar.
0 Comments
Leave a Reply. |