Showing 31 posts
Are you a macOS user occasionally dealing with Windows systems or trying to switch platforms? Are you a Windows user that believes that the Windows-native keyboard shortcuts are objectively bad? Are you annoyed by something as simple as copy/pasting text not working consistently across apps? If so, this post will equip you with an AutoHotkey configuration file that brings macOS keyboard shortcuts to Windows. Read on.
I just spent sometime between 30 minutes and 1 hour convincing the Mac Pro that sits in my office to successfully codesign an iOS app via Bazel. This was after having to update the signing key to a newer one and after rebooting the machine due to the macOS 10.15.5 upgrade—all remotely thanks to COVID-19. The build of the app was failing with an errSecInternalComponent error printed by codesign. It is not the first time I face this, but in all previous cases, I had either been at the computer to click through security popups, had had functional Chrome Remote Desktop access, or did not have to install a new signing key remotely.
Here I am, confined to my apartment due to the COVID-19 pandemic and without having posted anything for almost two months. Fortunately, my family and I are still are in good condition, and I’m even more fortunate to have a job that can employ me remotely without problems. Or can they? For over a year, my team and I have been working on allowing our mobile engineers to work from their laptops (as opposed to from their powerful workstations).
In the previous posts, we saw why waiting for a process group is complicated and we covered a specific, bullet-proof mechanism to accomplish this on Linux. Now is the time to investigate this same topic on macOS. Remember that the problem we are trying to solve (#10245) is the following: given a process group, wait for all of its processes to fully terminate. macOS has a bunch of fancy features that other systems do not have, but process control is not among them.
macOS includes a sandboxing mechanism to closely control what processes can do on the system. Sandboxing can restrict file system accesses on a path level, control which host/port pairs can be reached over the network, limit which binaries can be executed, and much more. All applications installed via the App Store are subject to sandboxing. This sandboxing functionality is exposed via the sandbox-exec(1) command-line utility, which unfortunately has been listed as deprecated for at least the last two major versions of macOS.
Bazel likes creating very deep and large trees on disk during a build. One example is the output tree, which naturally contains all the artifacts of your build. Another, more problematic example is the symlink forest trees created for every action when sandboxing is enabled. As garbage gets created, it must be deleted. It turns out, however, that deleting file system trees can be very expensive—and especially so on macOS. In fact, calls to our deleteTree algorithm routinely showed up in my profiling runs when trying to diagnose slowdowns using the dynamic scheduler.
Since the publication of Bazel a few years ago, users have reported (and I myself have experienced) general slowdowns when Bazel is running on Macs: things like the window manager stutter and others like the web browser cannot load new pages. Similarly, after the introduction of the dynamic spawn scheduler, some users reported slower builds than pure remote or pure local builds, which made no sense. All along we guessed that these problems were caused by Bazel’s abuse of system threads, as it used to spawn 200 runnable threads during analysis and used to run 200 concurrent compiler subprocesses.
Bazel’s original raison d’etre was to support Google’s monorepo. A consequence of using a monorepo is that some builds will become very large. And large builds can be very resource hungry, especially when using a tool like Bazel that tries to parallelize as many actions as possible for efficiency reasons. There are many resource types in a system, but today I’d like to focus on the number of open files at any given time (nofiles).
This is a tutorial to guide you through the shiny new pkg_comp 2.0 on macOS using the macOS-specific self-installer. Goals: to use pkg_comp 2.0 to build a binary repository of all the packages you are interested in; to keep the repository fresh on a daily basis; and to use that repository with pkgin to maintain your macOS system up-to-date and secure.
For various reasons, I have trained myself to lock my computer's screen as soon as I vacate my seat every single time. This may seem annoying to some, but once you get used to it it becomes second nature. The reason I do this is to prevent the chance of a malicious coworker (or "guest") to steal my credentials at work. However, Mac OS X has traditionally not made this simple.
Past weekend, for some strange reason, I decided to dump all the MBP's hard disk contents and start again from scratch. But this time I decided to split the disk into multiple partitions for Mac OS X, to avoid external fragmentation slowdowns as much as possible. I already did such a thing back when the MBP was new. At that time, I created a partition for the system files and another for the user data.
I recently subscribed to the Planet Cocoa aggregator and it has already brought me some interesting articles. Today, there was an excellent one titled Getting started with Cocoa: a friendlier approach posted at Andy Matuschak's blog: Square Signals. This post guides you through your first steps with Cocoa. Its basic aim is making you gain enough intuition to let you guide yourself through Cocoa documentation in the future. If you have ever programmed in, e.
Mac OS X has supported for a very long time putting Macs to sleep. This is a must-have feature for laptops, but is also convenient for desktop machines. However, it hasn't been since the transition to Intel-based Macs that it also supports hibernation, also called deep sleep. When entering the hibernation mode, the system stores all memory contents to disk as well as the status of the devices. It then powers off the machine completely.
Some days ago I updated my system to the latest version of Mac OS X Tiger, 10.4.10. It hasn't been until today that I realized that there is a new cool preferences panel called Processor: It looks like this: As you can see, it gives information about each processor in the machine and also lets you disable any processor you want. There is also another "hidden" window, accessible from the menu bar control after you have enabled it.
If memory serves well, today makes the sixth month since I have got my MacBook Pro and, during this period, have been using it as my sole computer. I feel it is a good time for another mini-review. Well... to get started: this machine is great; I probably haven't been happier with any other computer before. I have been able to work on real stuff — instead of maintaining the machine — during these months without a hitch.
As I mentioned yesterday, I have a couple of disk images in my Mac OS X machine that hold NetBSD's and pkgsrc's source code. I also have some virtual machines in Parallels that need to use these project's files. In order to keep disk usage to the minimum, I share the project's disk images with the virtual machines by means of NFS. (See Mac OS X as an NFS Server for more details.
Mac OS X’s native file system (HFS+) supports journaling, a feature that is enabled by default on all new volumes. Journaling is a very nice feature as it allows a quick recovery of the file system’s status should anything bad happen to the machine — e.g. a power failure or a crash. With a journaled file system, the operating system can easily undo or redo the last operations executed on the disk without losing meta-data, effectively avoiding a full file system check.
It is a fact that hard disk drives are very, very large nowadays. Formatting them as FAT (in any of its versions) is suboptimal due to the deficiencies of this file system: big clusters, lack of journaling support, etc. But, like it or not, FAT is the most compatible file system out there: virtually any OS and device supports it in read/write mode. Today, I had to reinstall Windows XP on my Mac (won't bother you with the reasons).
Even though aliases and symbolic links may seem to be the same thing in Mac OS X, this is not completely true. One could think they are effectively the same because, with the switch to a Unix base in version 10.0, symbolic links became a “normal thing” in the system. However, for better or worse, differences still remain; let’s see them. Symbolic links can only be created from the command line by using the ln(1) utility.
Yesterday, we saw how to install Mac OS X over multiple volumes, but there is a minor glitch in doing so: all "extra" volumes will appear as different drives in the Finder, which means additional icons on the desktop and its windows' sidebars. I find these items useless: why should I care about a part of the file system being stored in a different partition? (Note that this has nothing to do with icons for removable media and external drives, a these really are useful.
As you may already know, Mac OS X is a Unix-like system based on BSD and Mach. Among other things, this means that there is a single virtual file system on which you can attach new volumes by means of mount points and the mount(8) utility. One could consider partitioning a disk to place specific system areas in different partitions to prevent the degradation of each file system, but the installer does not let you do this (I suspect the one for Mac OS X Server might have this feature, but this is just a guess).
I think I've already covered all the areas I had in mind about these two operating systems. And as the thread has lasted for too long, I'm concluding it now. Here is a summary of all items described: IntroductionHardware supportThe environmentSoftware installationAutomatic updatesFreedomCommercial softwareDevelopment platformAfter all these notes I still can't decide which operating system I'd prefer based on quality, features and cost. Nowadays I'm quite happy with Kubuntu (installed it to see how it works after breaking Ubuntu and it seems good so far) and I'll possibly stick to it for some more months.
First of all, sorry for not completing the comparison between systems earlier. I had to work on some university assignments and started to play a bit with Haskell, which made me start a rewrite of an utility (more on this soon, I hope!). Let's now compare the development platform provided by these operating systems. This is something most end users will not ever care about, but it certainly affects the availability of some applications (specially commercial ones), their future evolution and how the applications work e.
As much as we may like free software, there is a lot of interesting commercial applications out there (be them free as in free beer or not). Given the origins and spirit of each OS, the amount of commercial applications available for them is vastly different. Let's start with Ubuntu (strictly speaking, Linux). Although trends are slowly changing, the number of commercial programs that are addressed to Linux systems is really small.
Ubuntu is based on Debian GNU/Linux, a free (as in free beer and free speech) Linux-based distribution and the free GNOME desktop environment. Therefore it keeps the phylosophy of the two, being itself also free. Summarizing, this means that the user can legally modify and copy the system at will, without having to pay anyone for doing so. When things break, it is great to be able to look at the source code, find the problem and fix it yourself; of course, this is not something that end users will ever do, but I have found this situation valuable many times (not under Ubuntu though).
Security and/or bug fixes, new features... all those are very common in newer versions of applications — and this obviously includes the operating system itself. A desktop OS should provide a way to painlessly update your system (and possibly your applications) to the latest available versions; the main reason is to be safe to exploits that could damage your software and/or data. Both Mac OS X and Ubuntu provide tools to keep themselves updated and, to some extent, their applications too.
Installing software under a desktop OS should be a quick and easy task. Although systems such as pkgsrc — which build software from its source code — are very convenient some times, they get really annoying on desktops because problems pop up more often than desired and builds take hours to complete. In my opinion, a desktop end user must not ever need to build software by himself; if he needs to, someone in the development chain failed.
I'm sure you are already familiar with the desktop environments of both operating systems so I'm just going to outline here the most interesting aspects of each one. Some details will be left for further posts as they are interesting enough on their own. Here we go: Ubuntu, being yet another GNU/Linux distribution, uses one of the desktop environments available for this operating system, namely GNOME. GNOME aims to be an environment that is easy to use and doesn't get in your way; they are achieving it.
Let's start our comparison by analizing the quality of hardware support under each OS. In order to be efficient, a desktop OS needs to handle most of the machine's hardware out of the box with no user intervention. It also has to deal with hotplug events transparently so that pen drives, cameras, MP3 players, etc. can be connected and start to work magically. We can't forget power management, which is getting more and more important lately even on desktop systems: being able to suspend the machine during short breaks instead of powering it down is extremely convenient.
About a week ago, my desktop machine was driving me crazy because I couldn't comfortably work on anything other than NetBSD and pkgsrc themselves. With "other work" I'm referring to Boost.Process and, most importantly, university assignments. Given my painless experience with the iBook G4 laptop I've had for around a year, I was decided to replace the desktop machine with a Mac — most likely a brand-new iMac 20" — to run Mac OS X on top of it exclusively — OK, OK, alongside Windows XP to satisfy the eventual willingness to play some games.