![\"\"](\"https://bitsplitting.org/wp-content/uploads/2025/04/ContactsHelped.png\" "\\"ContactsHelped.png\\"")
In the wake of AI coding assistants like Claude and Codex, which can seemingly perform the equivalent of a day’s work in a matter of minutes, many of us are wondering if the human role of “computer programmer” is coming to an end. Will the AI bots one day do all the programming for us?
\nMaybe so, but not yet. At this particular moment, human developers are especially valuable, because of the transitional period we’re living through. Just a few years ago, AI essentially could not program at all. In the future, a given AI instance may “program better” than any single human in history. But for now, real programmers will always win. Why? Because we are uniquely positioned to harness most of the power of AI while augmenting it with human taste, wisdom, and caution, among other qualities that an AI is thus far incapable of possessing.
\nThere are many examples of stunned programmers who describe how they asked an AI to create an app from scratch and it “just did it.” They wrote a few paragraphs clearly defining the functionality and user interface, and let the AI run with it. A few minutes, hours, or days later, and tada! The app is complete. It runs, it performs the tasks required, and the interface “isn’t even that bad.”
\nIf you interpret these examples to mean that any person can write down any list of requirements along with any user interface specs, and the AI will consistently produce a satisfactory product, then I’d agree programmers are toast. But in my experience that is not what’s happening.
\nThere is a confirmation bias at work here: every developer who has experienced such a remarkable outcome is delighted to share it. It helps to contribute to a mass (human) hallucination that computers really are capable of anything, and really are taking over the world. It’s exciting! But people are less likely to share all the times the AI failed in some ridiculous way. When it produced thousands of lines of inscrutable code, betrayed a complete lack of knowledge in some field, or spiraled into a loop of deeper and deeper “stupidity.” In the same way social networks are filled with photographs that portray a false reality of endlessly joyful vacations, flawless families, and universal good cheer, the AI victory stories we read are not a trustworthy reflection of reality.
\nWhy am I so confident about this? Because I work with AI every day. I patiently hold its hand, and pull it back when it follows the wrong impulses. I correct its mistakes. I rewrite its code. I sometimes speak to it sternly. I play one AI off another, asking ChatGPT to criticize Claude’s work, and vice-versa. In my opinion, the majority of code generated by AI systems is not great, but it’s the great quantity it can create in such a short period of time that makes it so powerful. And that’s why I go to the trouble to work with it at all. Because it’s so good at what it’s good at.
\nSpeaking of goodness, I share the majority opinion that AI is generally good. That is to say that I believe it will prove to have a positive impact on humanity. It will accelerate productivity in virtually every field, lead to insights in science and medicine, and offer accessibility advantages to millions of people. And yes, it will inevitably “take the jobs” of many unsuspecting victims. But as I hinted earlier, the suspecting victims all stand to gain. So be \u2026 suspectful? That doesn’t sound right. But be wary.
\nA mantra I’ve been repeating to myself lately is that an AI’s code can not be counted as “work” until a human has reviewed it and fixed any problems. If we’re going to talk about computers replacing humans, then the “work” that is done has to meet or exceed the standard that humans have set. We have these standards not just because we’re fussy, but because they lead to less buggy, higher performance, and more maintainable code. They’re not going to take our jobs by writing unreadable functions that are 4-times as long and defy platform conventions. Once they’ve completely taken over, they can write the code however they like. But for now, they need to abide by human standards.
\nAnd so I repeat that mantra, because I don’t want to fall into the same trap that I’m sure many programmers already have: committing AI-generated code without review. And when I say I don’t want to fall into that trap, I mean I don’t want to fall into that trap again. Or at least not too many more times. Or not too often.
\nThe truth is, it’s hard to avoid falling into that trap because of the illusion of perfection that AI so often projects. People used to talk all the time about Steve Jobs’s “reality distortion field.” It seemed that when he asserted some truth about a technology or product, people would eat it up in the moment, perceiving it all to be both inevitable and true. Only later, after taking a breath and pondering on what was claimed, would they determine he might have been completely bullshitting. He had a real knack for doing that, and AI has it to.
\nWhen I catch myself falling for one an AI’s bullshit ideas, I have to pull myself out of that reality distortion zone, apply my own wisdom to the task at hand, and set it back on course. Many technologies that seem like magic are, in fact, only useful or practical when a human plays a pivotal role. If, in horse-drawn buggy days, you had loaded a car full of people, pointed it the direction of a destination, and cued the horse to start moving, there’s a chance they would end up where they wanted to go. In that case, they would rejoice the miracle. The self-driving car is here! Alas, it turns out that as amazing as horses are, they can not be relied upon without the attentive management of a human.
\nThe time may come, perhaps even soon, when AI takes over programming completely. But in the mean time, a programmer who embraces AI, yet is skeptical about everything it creates, is better-equipped than any comparably-skilled human in programming history. I’ve written specifically about programmers, but I think this also applies to writers, artists, musicians, and people in every other profession whose products can be described by any stretch as “creative work.” Anybody who maintains strict control over the final product may find that AI enhances, rather than replaces, their creativity. The computers will come for all of our jobs eventually, but those of us who refuse or decline to embrace the most powerful creative tools we’ve ever been given will be the first to fall.
\n", "date_published": "2026-04-01T18:01:35-04:00", "date_modified": "2026-04-01T18:45:01-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2026/02/11/comfort-zone/", "url": "https://bitsplitting.org/2026/02/11/comfort-zone/", "title": "Comfort Zone", "content_html": "Once, in 1994 or so, I\u00a0was sitting in a cafe with friends, and I had the crazy idea that I was going to write my own web browser. I was a college student at the time, and had played with Mosaic and \u2026 well, probably only Mosaic. But had also played with Gopher, and other protocols like SMTP, UUCP, and NNTP. In some ways I was perfectly situated to pursue something great, but I was only 19 years old and had plenty of doubts. Browsers are big. There\u2019s a lot I don\u2019t know. And jeez, on top of everything, I need to finish my schoolwork! As fate would have it, I never ended up building that browser. It wasn\u2019t in my comfort zone.
\n\u00a0
\nInstead I went to work for Apple. When I say I \u201cwent to work for Apple,\u201d I mean that I threw myself at the mercy of a Cupertino staffing agency, convincing them that I knew the first thing about Macs (I didn\u2019t), and insisting that the only contracts I would take were for Apple. I don\u2019t know why I insisted on Apple except that my good friend, who worked for Apple, had recently hooked me up with a discounted PowerBook Duo 210. The agency connected me to a group within the company that needed a very short-term QA tester. I put on my nicest clothes for the phone call, to improve my confidence, and I got it! It was the best weekend of my working life. To that point.
\n\u00a0
\nI had a few more short-term assignments before they sent me to an on-site interview with the System 7 Engineering team, where I impressed the manager by describing a binary search method I would use for determining conflicts among classic Mac extensions: \u201cDisable half of them, test. Disable half again, test.” It was good enough to get me the job.
I was actually working for a group at Apple! Where? 1 Infinite Loop. At the time, there was no more prestigious address to work at in all of Apple.
\n\u00a0
\nThe moment I got my foot in the door, I let management know that I was really after an engineering job. \u201cI\u2019m going to be the best QA engineer you’ve ever seen, but I really want to write code for the Mac.\u201d Or something like that. Having the gall to say something affected things. I got the attention of the Director of the department, who liked my initiative and assigned one of his staff developers to be my mentor.
My mentor gave me tasks to pursue on my own time, out of work hours. I programmed every night, at home, doing whatever he asked me to. In retrospect he sounds a little sadistic, but I ended up with a text editor written in Motorola 68K Assembly language. It was a learning experience.
\n\u00a0
\nWhen a new engineering job opened up in that group, I was among the first to know. Of course I applied. And I was interviewed, put through the friendly (though not easy) wringer of justifying my worth to all my co-workers and was ultimately hired. I really cut my teeth in that group. Some of the people I worked with are absolute legends. Every time I felt over my head, I was terrified. Like many people I worried I had made the wrong choice. I was in the wrong job. But inevitably one of my mentors would pull me out, put my head on straight, and teach me to move forward. What a blessing.
\n\u00a0
\nAt one point I was assigned to a “special project.” I won\u2019t give too many details, because I still respect the confidentiality agreement that Apple expects from all its employees. It\u2019s been 25 years since I drew a salary from the company, but I\u2019m still \u201cemployee emeritus.\u201d Anyway, the only detail I\u2019ll share about this special project is that it involved a custom, Apple-made web browser. Before Safari. Or maybe Safari was getting started and I didn\u2019t even know about it yet, but we were going to make a self-contained web browser, expected to run on Mac OS 9. They put me in charge of it. No problem.
\n\u00a0
\nThat project never went very far. Years later, I wondered if it was, at least in part, because people at higher levels knew about the Safari and WebKit projects. If so, no offense taken! The browser I was asked to create was a billion times more complex than what I had in mind when i dreamed about doing something in that cafe, but far less robust than what Safari ended up being. Still, I did end up \u201cworking on my own web browser\u201d after all.
\n\u00a0
\nWhen faced with the prospect of making my own web browser in 1994, I said \u201cno”, or at least I implied \u201cno\u201d by omission. But when faced with so many other challenges over the course of my career, I said \u201cyes.\u201d \u00a0Again and again. I said yes to interviewing at a contract agency. I said yes to interviewing at Apple. I said yes to joining an engineering team. I said yes to making a name for myself. I said yes to working on a weird custom web browser. I said yes working long and hard, and ultimately I said \u201cyes\u201d to a lot of other things in life. And I’m still not very comfortable getting out of my comfort zone.
Three years ago, when I abandoned FogBugz after having used it for nearly 20 years, I landed on Help Scout, a fantastic support system offered by a company that seems to have a positive spirit and, cherry on top, is based locally to me in Boston.
\nThere are few companies I\u2019ve been as happy to spend money with. As a one-person support team, $22/month ($264 paid annually) gets me a reliable service that ticks all the boxes for my needs.
\nThis simple pricing system was a breath of fresh air compared to many other services, which often require minimum user counts of five or more, have overly-complex user interfaces, or which seem unlikely to remain a going business concern.
\nSince I switched to Help Scout, I have been convinced that they are the best at what they do, and that I\u2019d be in a real pickle if I were compelled to switch to anything else.
\nOver the past few weeks, many Help Scout customers have received notice that our plans will change to a new pricing model. Customers who haven\u2019t received notice yet probably will soon. The new system is based on a rolling average of customer interactions. As they cleverly frame it: \u201cthe number of contacts you help each month.\u201d Once notified, customers are granted six-months notice before the changes take effect.
\nThe problem, for most Help Scout customers, is that the new system increases their monthly costs. A little for some, and a whole lot for others. The closest approximation to my current $22/month plan starts at $50/month and covers an average of 100 customer interactions per month. They\u2019re obviously sensitive to the sticker shock this will produce, so they\u2019re offering a two-year \u201cLoyalty Discount\u201d of about $20/month, reducing my monthly cost to $28.60/month. That’s still a 30% rise, but coming out to $6, it’s something I can live with.
\nFor larger customers, the cost increase could be much worse. Imagine my company employed a three-person support team, handling customer interactions for 500 unique customers per month. Under current Help Scout pricing, I would pay $66/month. Exactly three times the amount I pay today. But under the new pricing structure, the minimum cost is $266/month.
\nHow do you know which pricing tier you’ll fall into? Once you receive notice from Help Scout that your plan is changing, you’ll be able to see a graph of your recent customer interactions on a custom plan migration page within your account. For example, my graph shows that I fall comfortably into the 100 customers per month tier:
\n
For new customers, they suggest for estimation purposes that the likely number of “customers helped” is around two-thirds the total number of emails you receive. So if you receive 150 emails per month, you might fall under the 100 contact tier, but if receive 200 emails per month, you most likely do not.
\nThe new pricing will benefit some customers. A brand new “Free” tier is a fantastic option for new customers who assist fewer than 50 customers per month on average. I fall into this range, so I wondered if this option might suit me. I contacted Help Scout and they agreed that I qualified for the plan, with the exception that I was using more than maximum 100 “tags” included in the free tier. I tag some Help Scout issues with GitHub ticket numbers, but if I were willing to delete some tags, I could switch immediately and start paying $22 less per month than I do now. That’s tempting, but the big problem with the free tier is that it removes access to the Help Scout API, and the ability to “Export” your data. Restricting data export is very 2005, and I wonder how it will play out in Europe.
\nIt’s also possible to imagine customers with a large number of agents assisting a relatively small number of customers. For example, if my imaginary three-person support team handled only 100 unique customers per month, the monthly cost would go down with the new pricing, from $66/month to $50/month. Or $30/month if they provide the same loyalty discount, but I suspect for customers positively affected by the price change, there will be no such discount.
\nFinally, customers who lean heavily on Help Scout’s AI features might see savings. Currently, customers who want to use these features have to pay at least $44/month per user, twice the standard plan. I wouldn’t know and don’t care how much these savings might be, because although I am not opposed to AI in general, I don’t appreciate or employ it in the context of customer support.
\nFor a customer in my particular position, whose monthly price will go up by $6, the easiest way forward is to do nothing. I’ll keep enjoying the same glorious product I have enjoyed for the past three years, at only a slightly elevated price. After another two years, we’ll see how things shake out. I contacted Help Scout about the “loyalty discount” and what happens when it expires, and they assured me that they would “do something” to keep people in my situation from seeing too much of a price hike. They claim to be aware of a problem there, but just aren’t sure how to manage it.
\nFor customers who will see a more painful increase in cost, as with the $66 to $266 spike I contemplated above, I have to imagine they will consider other options. While I maintain that Help Scout is the best at what they do, there are, of course, alternatives. I haven’t made a thorough evaluation lately, but my pal Paul Kafasis shared a list of potential options put together by Rogue Amoeba’s Support Manager Chris Barajas. You might stumble upon something you like while perusing these:
\n\nThat last option, FreeScout, is notable for being open source. Another option that came across my radar is a system called Zammad, which offers full-service hosting with the same refreshingly-simple “per user” pricing I once admired Help Scout for. And like FreeScout, Zammad is also open source. This means that either of these options can be self-hosted on your own server, akin to hosting your own WordPress installation.
\nI don’t relish the idea of maintaining my own help desk, but with the ever-looming threat of changes in functionality and pricing, for such a critical piece of infrastructure, I am considering it. With the wide-spread adoption of technologies like Docker, which bundle software into self-contained, easily-deployed packages, and services from companies such as Amazon, Microsoft, and Google, which make it easier to host such packages, it has never been easier to maintain a “self-hosted”, yet highly reliable web service.
\nWhile I respect Help Scout’s right and responsibility to manage the destiny of their own business, I think they are making a mistake with these changes.
\nIt’s one thing to assert that they are upsetting their current user base. I think they are, but worse, I think they will turn off prospective users as well.
\nPeople don’t like fluctuating prices. Businesses especially don’t like fluctuating prices. With Help Scout’s old business model, it was very easy to understand what you were paying for, and what you would receive. The new system requires work simply to determine if pricing is viable, let alone practical. And once you’ve settled into a tier, you run the risk of being “punished” for helping more customers. The idea that I might one day consider whether to help a customer today, at the cost of sending myself into a higher pricing tier, or helping them tomorrow, and saving a bit of cash, makes me both frustrated and a little sick.
\nI suspect that very-large companies will find these changes the most palatable. Not only because at greater scale the pricing is more predictable, but because larger companies have far more expenses, many of which probably dwarf the cost of their Help Desk software. The smaller the company, the more likely Help Desk software is to be one of the main monthly expenses.
\nIn a private chat, somebody suggested to me that small-time companies like mine are not Help Scout’s target market. That might well be true, but if it is, I think that is also folly. Most companies with 10, 100, or 1000 customer support agents started as companies with 1, 2, or 3 support agents. Help Scout’s new “Free” tier is a nod to the importance of luring in customers when they’re small and have little money to spare. They just seem to drop the ball a bit when it comes to taking care of customers at slightly-more-successful levels.
\nI am not sure what percentage of customers have been notified so far, but the number seems to be accelerating. I suspect the amount of negative feedback Help Scout receives will also accelerate. Hopefully this will inspire changes that make this transition more palatable for everybody.
\n", "date_published": "2025-04-30T10:15:39-04:00", "date_modified": "2025-04-30T11:02:27-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2023/05/25/apple-intelligence/", "url": "https://bitsplitting.org/2023/05/25/apple-intelligence/", "title": "Apple Intelligence", "content_html": "As WWDC draws near, anticipation of Apple’s long-rumored VR headset is high. The company is widely expected to announce an impressive, albeit expensive new product at the June 5 Keynote event. In short: people expect Apple to make a strong showing in this field.
\nPeople are justifiably less confident about Apple’s prospective plans in the area of artificial intelligence (AI), and particularly in the realm of large language models: the technology behind such imagination-captivating products as OpenAI’s ChatGPT, and GitHub Copilot (which itself uses another OpenAI language model).
\nI zeroed in on ChatGPT and Copilot because it’s easy to imagine the functionality of these services shining in the context of two important Apple products: Siri, and its Xcode developer tools. In fact, technology is advancing so quickly that the absence of something like ChatGPT and something like Copilot in these products seems likely to be viewed as major shortcoming in the near future, if it isn’t seen that way already.
\nThe industry-wide excitement around AI is so great that it’s hard to imagine any company of Apple’s stature letting a major developer conference come an go without at least mentioning the technology, if not enumerating the specific ways in which they are using it in their products. Most people I know are confident it will be mentioned in the Keynote, but less confident that any news will be Earth-shattering, or even Earth-tickling.
\nWhich leads me to my somewhat far-fetched prediction for WWDC: Apple will talk about AI, but they won’t once utter the letters “AI”. They will allude to a major new initiative, under way for years within the company. The benefits of this project will make it obvious that it is meant to serve as an answer to comparable efforts being made by OpenAI, Microsoft, Google, and Facebook. During the crescendo to announcing its name, the letters “A” and “I” will be on all of our lips, and then they’ll drop the proverbial mic: “We’re calling it Apple Intelligence.” Get it?
\nApple often follows the herd in terms of what they focus their efforts on, but rarely fall into line using the same tired jargon as the rest of the industry. Apple Intelligence will allow Apple to make it crystal clear to the entire world that they’re taking “AI” seriously, without stooping to the level of treating it as a commodity technology. They do this kind of thing all the time with names like AirPort, AirPlay, and AirTags. These marketing terms represent underlying technologies that Apple embraces and extends. Giving them unique names makes them easier to sell, but also gives Apple freedom to blur the lines on exactly what the technology should or shouldn’t be capable of.
\nApple Intelligence won’t be as good as ChatGPT or GitHub Copilot, at least not to start with. But it will be Apple’s. They can frame the pros and cons however they see fit, working their typical marketing magic to make its shortcomings seem less important, if not downright advantageous. And, being an abstraction on the already broad subject of “AI”, they can evolve its capabilities over time, gradually improving on it and increasing its brand recognition. In five years, when every other company is still talking about “AI”, or whatever other buzzword has taken its place, Apple may well have already incorporated the technology into its own A.I.
\n", "date_published": "2023-05-25T15:24:44-04:00", "date_modified": "2024-06-11T15:12:25-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2023/05/01/52-floppy-pickup/", "url": "https://bitsplitting.org/2023/05/01/52-floppy-pickup/", "title": "52 Floppy Pickup", "content_html": "On the latest Accidental Tech Podcast, John reminisced about the early days of the Mac, when a single 3.5″ floppy disk drive was typically used not only to boot a Mac, but also to run any applications, and to save any user data. He described the painstaking process of needing to insert a different disk whenever programs required access to specific executable code or data. Depending on the complexity of a workflow, you might be prompted to swap disks once, twice, or potentially dozens of times.
\nThe conversation reminded me of one of my first jobs at Apple. I was hired to work as a QA tester with the engineering team that shipped Mac OS system software updates. The first release I worked on was Mac OS 7.5, which was released in 1994. By this time hard drives had become commonplace and the kind of floppy-swapping John described had become a lot less common for most users. But when it came to installing new software onto a Mac, some amount of removable media juggling was usually required.
\nTypically at that time, major OS updates were installed from CD-ROM discs. The system used the same basic strategy: it would eject one disc and prompt you to insert another, until the installation process was completed. It was a little tedious, but because CD-ROM discs had a massively higher capacity than floppy disks, it usually only required a few swaps.
\nOne day during the lead up to finishing System 7.5, my boss brought a massive box full of floppy disks into the lab I worked in. The System 7.5 update was remarkably backward compatible, and supported computers as old as the Macintosh Plus and SE, which did not include a CD-ROM drive. In fact they did not even support the relatively higher density 1.4MB floppy disks of the era. That massive box was the System 7.5 installer, split across 50 or so (as best as I can recall) 800K floppy disks. I was supposed to make sure it worked.
\nAnother thing John recalled on the show was how some folks got amazingly good at floppy-swapping process, developing a muscle memory for fluidly withdrawing and inserting disks on command. Suffice to say, after testing that 50-floppy install process more than a couple times, my muscle memory was pretty darned good.
\n", "date_published": "2023-05-01T15:49:25-04:00", "date_modified": "2023-05-01T15:52:53-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2023/03/17/spelunking-apples-open-source/", "url": "https://bitsplitting.org/2023/03/17/spelunking-apples-open-source/", "title": "Spelunking Apple’s Open Source", "content_html": "Since the earliest days of Mac OS X, Apple has complied with the licenses for the dozens of open source components it includes in the OS by posting (sometimes a little belatedly) updated versions of the source code to its Open Source at Apple web page.
\nThis resource is useful primarily to developers, but may also interest curious technophiles who want to take a peek “behind the curtain” to see how much of the magic just beneath our fingertips is made.
\nIf you visit the page today, you’ll see a new emphasis on Apple’s high-level projects, such as Swift and WebKit. At first glance you might wonder if the extensive list of all the open source projects has been removed from the site.
\nThere’s no need to worry: the whole list, indexed by the pertinent platform and OS release to which they belong, is still available on a separate Releases page. Even better, each of these releases now has a corresponding GitHub repository, hosted in a dedicated organization reserved exclusively for open source distributions.
\nAs great as the old list of distributions by release is, it can be tedious to pinpoint exactly where a particular component’s source code might live. Sometimes it’s easy: for example, the source code for the version of the Vim editor that shipped with macOS 13 is conveniently located in a distribution called vim-136. But other tools can be harder to find. If you were curious about the “banner” command, which was historically used to generate ASCII text suitable for printing huge messages at dot matrix printers (!), and which is remarkably still available as a built-in command on every Mac, you’d have to know to go looking for it in the text_cmds-138 release.
\nApple’s decision to host these releases on GitHub, under a distinct organization, solves the problem. If you want to find the source code to an arcane tool like “banner”, just type it into a GitHub search of the organization. If there are too many false hits, as is the case for a common word like banner, try searching on something unique like a term from the command’s man page. The banner tool is credited as being authored by Mark Horton, and a search for “org:apple-oss-distributions Mark Horton” brings up more hits than I would have guessed (he also contributed to vim and vi, coincidentally), but a reference to the banner man page is the second search result.
\nI was inspired to write this blog post by a situation that came up in a programming Slack, where one person asked for “an API that could list the open ports and their owning processes.” Another replied that the command-line tool “lsof” is up to the task, only the person wasn’t looking for a command-line tool. Using the knowledge of Apple’s open source distributions, you could go look for, and find, the pertinent source code, and determine which API it was using.
\nWhen questions like these come up, many times the answer comes from a wise old sage who happens to know exactly what you’re looking for. Other times, Apple’s increasingly well-indexed open source distributions might be just the ticket.
\n", "date_published": "2023-03-17T09:37:39-04:00", "date_modified": "2023-03-17T09:49:22-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2022/08/16/disciplined-innovation/", "url": "https://bitsplitting.org/2022/08/16/disciplined-innovation/", "title": "Disciplined Innovation", "content_html": "Apple’s macOS 13 “Ventura” beta features a major redesign of the System Preferences application. In addition to renaming it “System Settings,” Apple revamped the interface with an organization style that is far more reminiscent of the iOS “table view” organization than of the macOS status quo:
\n![\"Screenshot](\"https://bitsplitting.org/wp-content/uploads/2022/08/SystemSettingsAppearance.png\" "\\"SystemSettingsAppearance.png\\"")
At first blush, there are apparent advantages to this design. Perhaps most significantly, the resemblance to iOS in both appearance and function may make the interface more navigable, and easier to understand, for users who are more familiar with iOS than with the Mac. The familiar “stack based” approach to delving deeper into the details of a particular preference pane has some advantages to the typical Mac approach of presenting detail as modal panels, which sometimes beg to be awkwardly nested in a pile of secondary or tertiary panels.
\nOn second, third, and many blushes beyond, however, the design of System Settings appears to represent a major regression in overall usability and aesthetics. It has been taking public jabs since the first deveoloper beta, prompting a challenging question from John Gruber in his interview with Apple’s Greg Joswiak and Craig Federighi. Federighi replied with a compelling argument in favor of unifying the design experience across platforms, and removing historic cruft from the legacy macOS designs. Federighi further complained that Apple was being “judged for its betas,” implying that the UI would see significant improvements over the course of the summer.
\nWe have seen improvements, but by the judgement of most Mac faithful (or at least the loudest among them), these improvements are not enough. Recently, a trending Twitter thread by Niki Tonsky reignited criticism, while many people pointed out that as the expected ship date for macOS Ventura draws closer, we are less likely to see dramatic improvements.
\nJohn Gruber returned to the subject in a piece yesterday, in which he asserts “the basic fit and finish of Ventura\u2019s new System Settings is just bad.” He lays much of the blame for this on SwiftUI, which he further asserts that with SwiftUI “so many little layout details are apparently hard to get right.”
\nI have heard several people acknowledge that the successful transition to Apple Silicon was accomplished in part by focusing on the underlying architectural change while having the discipline to keep the hardware the same. The thinking is that with such a dramatic change in the underlying technology of the Mac, it would have been reckless to attempt other major hardware changes at the same time. In short: the Apple Silicon transition can be judged as successful on the basis that anybody using such a Mac might not even know they were using a fundamentally different computer design.
\nWith Apple Silicon, Apple was able pull the proverbial table cloth out from under the exquisite place settings of the Mac, comprising its beloved hardware and software features, while leaving everything standing exactly as it was. That’s quite an achievement.
\nI think that SwiftUI would be judged as a more successful transition if Apple had pulled off a similar stunt. What if they had approached the challenge by making sure, first and foremost, that every Mac and iOS UI component behaved exactly the same as before? Then, as with the Apple Silicon changes, they could leverage the advantages of the new technhology to expand and improve upon the status quo, rather than attempting to replace it.
\nBy choosing to change the underlying technology while also introducing new UI designs and behaviors, Apple has effectively attempted to pull the tablecloth out from under the place settings, while also pouring tea, cutting the cake, and serving the sandwiches. Messes will get made, some dishes are bound to get broken, and they’ll take a long time to put back together.
\n", "date_published": "2022-08-16T15:42:32-04:00", "date_modified": "2022-08-23T15:04:42-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2022/07/20/dump-fogbugz/", "url": "https://bitsplitting.org/2022/07/20/dump-fogbugz/", "title": "Dump FogBugz", "content_html": "Once upon a time, there was a fabulous service called FogBugz. Well, technically it still exists, but over the past many years, since it was sold off by Fog Creek Software, it has both stagnated and diminished in reliability as a substantial number of us long-time users has grudgingly continued to use it.
\nSeveral months ago, the whiff of abandonment became too great for me to bear any longer, so I devised a plan to migrate my data out of FogBugz, and into more reliably maintained services. FogBugz effectively served as both a customer-service database, and a bug-tracking system. Most apps don’t strive to achieve this, so I had to plan for two new services to fill the shoes of this app. I settled on HelpScout for customer service, and GitHub Issues for bug-tracking. HelpScout has turned out to be more of a solid home run than GitHub issues, but I’m happy with both.
\nWhether you’re also looking to transition away from FogBugz, or just want a reliable means of backing up your data, you’ll need to use the FogBugz API to get your data out. Once you have a structured backup of all your case data and attachments, you’ll be in a good position to evaluate how you might migrate that data into a format that is suitable for importing to another service.
\nI’ve shared a pair of simple Python scripts on GitHub that will help you to automate dumping your FogBugz data. Simply download my dumpbugz files from GitHub, follow the directions in the README, and you should be left with a “Cases” folder that includes all of your data and attachments.
\nFor my transition to HelpScout and GitHub Issues, I wrote additional scripts to interface with the APIs of those services. Those are not ready for sharing at this point, but I may share them in the future. In any case, I hope the scripts make it easier for you to “Dump FogBugz” sooner than later.
\n", "date_published": "2022-07-20T23:30:35-04:00", "date_modified": "2022-09-17T17:24:03-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2022/06/18/purgeable-mac-apps/", "url": "https://bitsplitting.org/2022/06/18/purgeable-mac-apps/", "title": "Purgeable Mac Apps", "content_html": "For months now, I have been scratching my head over a small but persistent number of “crash reports” affecting a few of my apps. The issue is most prevalent in MarsEdit, where I have a handful of users who run into the issue multiple times per day. Luckily, one of these users is my good friend and colleague, Manton Reece. I’ve been peppering him with questions about the issue for weeks, while he stoicly puts up with the behavior.
\nEven with the assistance of a highly technical friend who can reproduce the issue at will, I had thrown my arms up in despair several times. I put “crash reports” in quotes above, because although my in-app crash reporter notices the app abruptly terminates, the system doesn’t create any obvious artifacts. No crash or hang reports. No “Quit Unexpectedly” dialog. The app is just … gone. I wrote a question in the Apple Developer Forums, which turned into a kind of de facto diary as I pursued the issue.
\nWhen I started to feel bad about asking Manton to try this, that, and the other thing, I finally asked if he could send me a “sysdiagnose” report. If you’re curious, the easiest way to grab one of these on any Mac is to simply press the Control, Option, Command, Shift, and “.” (period) keys at once. You’ll see the screen flash, an indication the system is starting to collect the reports. A few minutes later the report will be revealed in the Finder: a probably quite large zip archive. Open it up and see the wealth of information about nearly every aspect of the system.
\nYet even with this wealth of information, I was stymied. It wasn’t until I chanced upon the delightfully pertinent nuggets of information in “/var/log/com.apple.xpc.launchd/launchd.log” that I got my first whiff of a clue:
\n\n2022-05-03 09:15:22.088718 (gui/501/application.com.red-sweater.marsedit4.384452971.384452977 [13840])\n: exited with exit reason (namespace: 15 code: 0xbaddd15c) - OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches requesting termination assertion for com.red-sweater.marsedit4
Here we have a message asserting that MarsEdit was terminated, on purpose, and better still, it includes an explanation! As far as explanations go, “CacheDeleteAppContainerCaches” is not much of one, but it did give me something to go on. Searching for the term yielded pertinent results like this post about Apple Mail and Safari “suddenly quitting.” Unfortunately, they all seem to be scratching their heads as much as I am.
\nThe other thing that jumped out at me from the log was the term “OS_REASON_RUNNINGBOARD”. Searching for this results in only a few scant links, all related to Apple’s open source Darwin kernel. However, Searching instead for just “RunnningBoard” offered a glimmer of hope. A post on Howard Oakley’s blog, “RunningBoard: a new subsystem in Catalina to detect errors“, includes a particularly succinct description of the eponymous OS subsystem (emphasis mine):
\n\n\nCatalina brings several new internal features, a few of which have been documented, but others seem to have slipped past silently. Among the latter is an active subsystem to replace an old service assertiond, which can cause apps to unexpectedly terminate \u2013 to you and me, crash \u2013 in both macOS 10.15 and iOS 13: RunningBoard.
Unexpected termination. Yep. To you and me? Crashing. At this point in the story I’m going to elide several hours of long, tedious, and yet still somehow fun work, wherein I disabled System Integrity Protection on my Mac, so that I could attach to the pertitent system daemons and try to make sense of how, and when, they might decide to unilaterally terminate an app like MarsEdit. While digging deeper into the issue, I remembered that “explanation” from the log, CacheDeleteAppContainerCaches, and it reminded me of system maintenance software like CleanMyMac. I normally shy away from these kinds of apps because they are historically known to be overly-aggressive in what they decide to delete. In the name of science, however, I decided to run it, with care, on my Mac.
\nBoom! After running CleanMyMac once, MarsEdit, along with Numbers, were suddenly not running anymore. I had finally reproduced the issue on my own Mac for the first time. Anybody who has fixed software bugs, either for a living or as a passion, knows this is the critical first step to really addressing an issue. With some tinkering, I was able to narrow down the reproduction steps to running the “Free Up Purgeable Space” action. It turns out this is invokes a system API responsible for trying to delete caches, etc., from a Mac. Normally the system only does this when disk space is critically low, but CleanMyMac gives you the option to exercise the behavior at any time.
\nThat single log line quoted above turns out to hold another gem of information. The “code:0xBADDD15C” looks like it could be an arbitrary hexadecimal value, but it’s an example of an error code designed to both uniquely identify and suggest a mnemonic clue to the underlying issue. Apple documents many of these codes, which include 0xc00010ff (cool off), 0xdead10cc (deadlock), and 0xbaadca11 (bad call). I searched the system frameworks for this code and found it in the disassembly of “/System/Library/PrivateFrameworks/CacheDelete.framework”. Particularly, in an internal function called “assert_group_cache_deletion”. It was only after exploring the issue in the forums, did Quinn explain that the code in this scenario is a mnemonic for “bad disk”. I guess it was easier to spell out than trying to represent “full disk”.
\nEquipped with all this new information, what can we do about the unexpected terminations? Well, nothing. I do wish Apple’s framework would try asking nicely if the app would quit, before summarily terminating it, but I guess the thinking is that this functionality should typically only be reached in extenuating circumstances. After learning more about the issue, I confirmed with Manton that his Mac did have low disk space, so I guess it was just the system trying its best to free up space that caused the issue for him.
\nThe one thing I plan and hope to do as followup is to amend my built-in crash reporter so that it will not prompt the user or report a crash when the app terminates for this reason. I think it should be possible to detect the codes alluded to above, and simply let “0xBADDD15C” terminations happen without fanfare.
\n", "date_published": "2022-06-18T11:55:17-04:00", "date_modified": "2022-06-18T12:08:21-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2022/04/19/netnewswire-6-1-for-mac-subscribe-to-feed/", "url": "https://bitsplitting.org/2022/04/19/netnewswire-6-1-for-mac-subscribe-to-feed/", "title": "NetNewsWire 6.1 for Mac: Subscribe to Feed", "content_html": "Nearly ten years ago, inspired by Apple’s removal of the “RSS” button from Safari 6, I released a standalone Safari extension called Subscribe to Feed. The extension simply replaced the functionality of having an easy way to subscribe to the RSS feed of any web site you might be viewing.
\nThis worked great for many years, until Apple’s ever-increasing security controls changed the behavior of Safari extensions such that they couldn’t call out to desktop apps (such as a news reader) without requiring approval from the user each and every time. This made the process of subscribing to a feed more cumbersome, albeit still easier than manually searching for the feed URL, copying, and pasting it into an RSS reader app.
\nWhen Brent Simmons resurrected NetNewsWire, I saw it as a perfect opportunity to carry on the mission of the Subscribe to Feed extension. Native applications on the Mac can offer Safari app extensions that extend the browser in ways that are similar to traditional web browser extensions, but which are not subject to the same tedious security restrictions. The idea is that if the user knowingly installs an app and then enables the corresponding extension, they are probably happy to have its functionality performed without warning.
\nI implemented a simple version of Subscribe to Feed within NetNewsWire a few years ago, but held off on “announcing it” per se, because I was waiting for some pieces to fall together so that I could endorse it as a fully-functional replacement for the old Subscribe to Feed extension. One of my main criteria was that the extension should be useful to people even if they don’t use NetNewsWire.
\nWith the release of NetNewsWire 6.1, the app now has a preference for the Safari extensions so you can choose whether to open feeds in NetNewsWire itself, or in the default news reader.
\nSo if you are a fan of another RSS app that doesn’t have its own Safari extension, you can simply install NetNewsWire 6.1, configure the Safari extension to open feeds in your default app, and enjoy the full functionality of the “Subscribe to Feed” extension without ever launching NetNewsWire again. Though you might as well give it another look since it’s there …
\n", "date_published": "2022-04-19T13:35:00-04:00", "date_modified": "2022-04-19T13:41:50-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2021/11/01/the-talk-show-327-giddy-with-mac-ness/", "url": "https://bitsplitting.org/2021/11/01/the-talk-show-327-giddy-with-mac-ness/", "title": "The Talk Show 327: Giddy with Mac-ness", "content_html": "I had a blast chatting with John Gruber on the latest episode of The Talk Show. The timing worked out perfectly for us to abandon our usual jaded attitudes and just fully dote on the new MacBook Pros.
\n", "date_published": "2021-11-01T09:13:19-04:00", "date_modified": "2021-11-01T09:13:19-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2020/09/19/three-podcasts-and-a-blog/", "url": "https://bitsplitting.org/2020/09/19/three-podcasts-and-a-blog/", "title": "Three Podcasts and a Blog", "content_html": "I’ve been wanting to create my own crossword puzzles since I was a kid, but never quite got around to it. Earlier this year I decided to renew my commitment, and tweeted a bold claim:
\n\n\nMark my words: within 3 months I'm going to publish my first self-constructed crossword puzzle, and within 3 years I'm going to have one published in the New York Times.
\n— Daniel Jalkut (@danielpunkass) May 26, 2020
\n
Let’s see, June, July, August. Yup, I missed that target. But FOUR months later, I’m ready to catch up, and share the very first puzzle I’ve ever completed. I call it “Three Podcasts and a Blog” because I set out to build a puzzle around the “theme” of names of podcasts in the Apple developer/technophile scene. Only after I was almost done with the puzzle did I realize I’d included one blog that, in fact, has no podcasting counterpart. You’ll see the clue marked “oops!”
\nIf you want to solve the puzzle, I encourage you to download and use my own Mac app, Black Ink. If you don’t have a Mac or would prefer to solve on paper, I’m also including a PDF so you can download and print it:
\n\n\n\nSeeing as this was my first foray into the art of puzzle-crafting, I’m sure there will be lots of issues with the puzzle. Hopefully it’s still fun, especially for folks who are acquainted with Apple-related podcasts and blogs. Let me know what you think!
\n", "date_published": "2020-09-19T18:40:31-04:00", "date_modified": "2020-09-19T19:00:56-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2020/02/07/apple-news-encourages-frequent-blogging/", "url": "https://bitsplitting.org/2020/02/07/apple-news-encourages-frequent-blogging/", "title": "Apple News Encourages Frequent Blogging", "content_html": "When Apple News debuted, I was intrigued to learn that virtually anybody can submit their own blogs for inclusion in the service. Why not allow Bitsplitting, the Red Sweater Blog, and Indie Stack to be part of this service? For reader who enjoy Apple News, it could serve as a kind of substitute RSS reader.
\nApple did, in fact, accept my news sources, and for the past several years these articles have been available through the service.
\nI guess I’ve dropped the ball a bit as a blogger, though, because this week I received a terse email from Apple:
\n\n\nDear Daniel Jalkut,
\nWe noticed that you have not published to your Bitsplitting channel in three months or more. Your channel will be removed in one week.
\nRegards,
\n
\nThe Apple News Team
Regards, indeed. Apple will drop me in one week if I don’t publish something, or maybe even if I do; the wording is ambiguous. I’m a little annoyed at this, but I’m also a little annoyed at myself for not blogging more frequently, so I guess I’ll just say: “thanks, Apple News!”
\nUpdate: Manton Reece notes on Micro.blog that there may be a less encouraging rationale for Apple’s crackdown on inactive publications:
\n\n", "date_published": "2020-02-07T10:05:14-05:00", "date_modified": "2020-02-07T10:40:29-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2019/10/05/catalinas-custom-keyboard-viewers/", "url": "https://bitsplitting.org/2019/10/05/catalinas-custom-keyboard-viewers/", "title": "Catalina’s Custom Keyboard Viewers", "content_html": "\n@danielpunkass If you hadn’t heard, Apple News dropped RSS support for new blogs, and it sounds like they rarely approve personal blogs anymore. Weeding out inactive blogs could be the first step to removing them altogether.\n
Long-time Mac users will remember an app called “Key Caps”, which later become “Keyboard Viewer”, a feature of the Mac that is now accessible via the menu bar’s “Input Methods” item. If you’ve never played with this, I encourage you to enable it and check it out. Apple has detailed instructions for configuring the menu and these options.
\nI don’t use the Keyboard Viewer often, but when I do, it’s a real life-saver. I brought it up recently while I was debugging an issue with keyboard shortcuts in FastScripts, my scripting utility app. The Keyboard Viewer not only reflects every bona fide keystroke you make on a hardware keyboard, but also allows you to simulate keystrokes by tapping on the keys of the on-screen keyboard.
\nOn macOS 10.15 Catalina, Apple has evidently dramatically overhauled the Keyboard Viewer. I don’t see any hint of this on the Apple marketing sheet for the OS, but this is what the Keyboard Viewer looks like on my Mac now:
\n![\"NewImage\"](\"https://bitsplitting.org/wp-content/uploads/2019/10/DefaultKeyboard-1.png\" "\\"DefaultKeyboard.png\\"")
Well, isn’t that spiffy? But what I really want to talk about is that little Gear Button in the upper right corner of the window. Click it, and this what you get:
\n![\"Popup](\"https://bitsplitting.org/wp-content/uploads/2019/10/KeyboardPopup.png\" "\\"KeyboardPopup.png\\"")
A whole slew of options for tweaking the behavior of the virtual keyboard, and an enticing “Customize…” item at the bottom. When you select it, a dedicated application called “Panel Editor” opens up. It’s essentialy a construction set for building virtual keyboard layouts:
\n![\"Custom](\"https://bitsplitting.org/wp-content/uploads/2019/10/BitsplittingKeyboard.png\" "\\"BitsplittingKeyboard.png\\"")
This example is obviously comical, but the point is you can create and layout tappable regions that correspond to whatever keystrokes you desire. The options for configuring these keys even include options to perform multiple keystrokes, open apps, run scripts, etc. It’s a powerhouse of utility superpowers.
\nHow did they possibly find time to add all this great functionality in one OS upgrade? They didn’t. Folks who are familiar with Apple’s Accessibility Keyboard have no-doubt recognized my screenshots as being familiar from past OS releases. I personally had never seen it before, but it’s been hiding in the System Preferences Accessibility tab. What happened in macOS 10.15 Catalina is that Apple has evidently recognized its superiority in all ways to “Keyboard Viewer” and allowed the Accessibility Keyboard to simply take its place.
\nThis is an excellent example of software being designed to assist people with specific needs, yet actually being useful to everybody. That is the heart of accessible software design, and I think we’ll see more and more “accessible” software released from the relative obscurity of the Accessibility tab as we move forward.
\n", "date_published": "2019-10-05T12:26:15-04:00", "date_modified": "2019-10-05T13:39:25-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2019/07/22/a-real-gatekeeper/", "url": "https://bitsplitting.org/2019/07/22/a-real-gatekeeper/", "title": "A Real Gatekeeper", "content_html": "\n
In the years since Apple released the iPhone, with its “locked-down-by-nature” approach to application security, the company has progressively chipped away at the freedoms Mac developers have historically had to do, more or less, whatever the heck they wanted.
\nWith the introduction of the Mac Application Sandbox in 2012, Apple applied an iOS-like mechanism through which applications are entitled only to access their own data, and must explicitly request permission from Apple to access any resources “outside of their own sandbox.” At the time, I wrote that while the technology was promising, it left much to be desired.
\nAround the same time, they introduced Developer ID, a system for certifying at runtime that a given piece of software has been cryptographically signed by a developer whose identity is known to Apple. Applications that are not signed with Developer ID are allowed to run in macOS, but by default are met with a foreboding warning about the safety of doing so. The component of macOS that is responsible for limiting the launch of software from unknown developers is called “Gatekeeper.”
\nLast year, in 2018, Apple introduced a new notarization service, an expansion of Developer ID functionality. Developers submit their applications to Apple, where they are scanned for known malware, and have their use of specific system technologies vetted. The “notarization” on an app allows the system to verify at runtime that a given application passes a baseline safety metric for downloaded software.
\nFinally, in 2019, Apple announced that software signed with Developer ID certificates, that is to say all non-Mac App Store software, must also be notarized. The Catalina 10.15 public beta identifies software that has not been notarized as potentially risky because it “cannot be scanned for malware.”
\nIn effect: developers who ship software directly to end-users are now required to notarize their apps.
\nWhile working on the notarization process for my own apps, and a company I work for, I noticed an interesting error from “altool”, the command line program that is used to submit binaries to Apple for verification:
\n\n1 package(s) were not uploaded because they had problems:\nError Messages:\nTo use this application, you must first sign in to \niTunes Connect and sign the relevant contracts. (1048)\n\n
The error is easily worked around by logging in to App Store Connect and agreeing to any updates Apple has recently made to their contracts. I’m so used to more-or-less blindly agreeing to these changes, that it didn’t sink in for me at first what a potentially major change this is.
\nMy colleague Patrick Machielse noticed right away what the larger implication is: all Mac software, inside or outside of the Mac App Store, can now be held up by unsigned contract agreements with Apple. In a rush to fix a horrible bug and get it out to customers? Better review that new contract ASAP.
\nFor the past 35 years, any Mac developer who wanted to ship an update directly to customers could do so by recompiling a binary and distributing it. When macOS 10.15 ships this fall, the status quo will change. Mac developers must register with Apple and sign their products. They must submit their binaries to Apple for notarization. And most significantly of all, they must agree to the terms of Apple’s App Store developer contracts, even if they don’t distribute their apps through the App Store.
\n", "date_published": "2019-07-22T15:44:30-04:00", "date_modified": "2019-07-22T23:58:37-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2019/05/24/unloved-patches/", "url": "https://bitsplitting.org/2019/05/24/unloved-patches/", "title": "Unloved Patches", "content_html": "For a long time I have admired the WordPress project, for developing such a robust blogging platform that is ultimately open, and free, and anybody can contribute improvements to it. I encourage many of my customers to use WordPress with MarsEdit, because it seems like a “safe bet” going forward.
\nMy admiration has diminished a bit in the past 7 months because … I haven’t succeeded in contributing to it.
\nFor a long time, I heard reports from my customers that dates were being set wrong in posts to WordPress. The issue in summary is that if you have a draft post on WordPress, changing its status to “Published” doesn’t update the publish date from the time the draft was originally saved.
\nI didn’t really get a handle on this problem until it started affecting me. Sometimes I write the show notes for my podcast, Core Intuition, ahead of the time the podcast actually goes public. In these situations, the blog post has a published date corresponding to the time I first starting writing the post, and when we finally go to publish the podcast, the date remains the same.
\nI did the hard work of not only diagnosing the problem in WordPress’s source code, but also writing a fix, and writing unit tests to confirm the fix. I filed a bug with a patch that will fix the problem for my customers, and any other clients of the WordPress API:
\n#45322: Editing a draft post with wp.editPost causes its published date to be set
\nShortly after filing the bug, I went to the WordPress Slack to see what I could do about having my fixes integrated. I was lucky to have a positive response from a couple members of the WordPress team, and my bug fix seemed slated for integration.
\nTime passed. I wondered. I didn’t want to nag the hard-working members of the team, but I also didn’t want my hard work to have been for naught. Also, my customers, as well as other clients of the WordPress API, would benefit from this.
\nIt’s been on my TODO list for 7 months now to “check in” with the WordPress team about this. Unfortunately, every time I do, the only thing I’ve noticed is that nobody substantially responds to my inquiries. I’m in the dead zone.
\nI don’t think the WordPress team is bad, by any means, but I think this reflects a problem in their process. When somebody comes to your project with a well-thought-out, unit-tested fix, and is met by radio silence? The chances are high that they will never come back again. I have submitted WordPress patches in the past, but after this experience I don’t know if I will bother submitting them again. That’s a big change in my perspective on how the WordPress team works, and on how it should work.
\nThis post is about WordPress, but I think there are lessons for every open source project. Obviously, you can’t coddle every contributor. Some submissions will be bogus, some will be contrary to the aims of the project. But mine was a clear fix to a defect that affects multiple clients of the API. If it’s not a clear fix, I’m at least owed an explanation for why it hasn’t been committed after 7 months. In. My. Humble. Opinion.
\n", "date_published": "2019-05-24T17:31:37-04:00", "date_modified": "2019-05-24T21:36:46-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2019/05/24/blog-a-little/", "url": "https://bitsplitting.org/2019/05/24/blog-a-little/", "title": "Blog a Little", "content_html": "Over on Twitter today, I was inspired to ask people to write “just one blog post” today:
\n\n\nEverybody, join me in writing just one blog post today, to get that independent feeling back. https://t.co/bDFpxiVfqO
\n— Daniel Jalkut (@danielpunkass) May 24, 2019
\n
Later, it occurred to me that after 10+ years on Twitter, I am privileged to have a substantial following. I thought I would take the opportunity to help promote some folks who don’t have as much immediate reach:
\n\n\nDid you write a blog post TODAY? Tweet it to me within then next hour, and if it's not offensive, I will retweet it. Long live the indie/open web!
\n— Daniel Jalkut (@danielpunkass) May 24, 2019
\n
I tagged all my retweets to those responses with #LongLiveTheOpenWeb. I think it turned out to be a pretty cool cross-section of bloggers, and I sort of editorialized the kind of blogging that people were doing.
\nI think people neglect to write blog posts because the feedback loop is not as tangible as the onslaught of (sometimes mechanical) likes or faves that you can receive on a social network. With blogging, you need a little faith that you will gain an audience. And on the open web, you never know who might come along and expand your audience.
\n", "date_published": "2019-05-24T16:51:01-04:00", "date_modified": "2019-05-24T16:51:01-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2019/05/24/the-mac-open-web/", "url": "https://bitsplitting.org/2019/05/24/the-mac-open-web/", "title": "The Mac Open Web", "content_html": "These days, as the giant social networks behave more and more reprehensibly, many people are looking back to the “good old days” of the web, when self-published blogs were the primary means of sharing one’s thoughts.
\nBrian Warren has taken this enthusiasm, and combined it with his nostalgia for another classic resource: the links page. He’s created a new one called Mac Open Web:
\n\nA collection of open and indie Mac, iOS, and web apps that help promote the open web.
The solitary page is jam-packed with links to resources for creating and perusing content on “the open web,” that is to say “the web.” If you’re sick of Facebook and Twitter owning your experience of what is still a hugely diverse and free global network, then spend some time investing in writing and reading on the web “the way we used to do it.”
\n", "date_published": "2019-05-24T09:24:26-04:00", "date_modified": "2019-05-24T09:24:26-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2018/11/15/mac-sandboxing-privileged-file-operations/", "url": "https://bitsplitting.org/2018/11/15/mac-sandboxing-privileged-file-operations/", "title": "Mac Sandboxing: Privileged File Operations", "content_html": "At WWDC 2018, Apple announced with great fanfare that two beloved Mac apps, Transmit and BBEdit, would be returning to the Mac App Store.
\nEach of these apps had departed the App Store years ago, citing various reasons, but chief among them the limitations of the Mac App Sandbox, which restricts the functionality of apps in the Mac App Store.
\nI was curious whether Apple made any specific concessions to these developers, and whether those concessions would be opened up to “the rest of us” or not.
\nToday, Panic launched Transmit 5 on the Mac App Store. It’s a free download, and costs $24.99/year after an initial 7-day free trial.
\nI downloaded Transmit even though I own a copy of the direct-purchase version. I wanted an answer to my question, which I got, at least partially, by dumping the application binary’s “entitlements”, which represent the sandboxing exceptions that the app has received.
\nNew to me among the entitlements is “com.apple.developer.security.privileged-file-operations”, which is a boolean value set to true for Transmit. I don’t see any Google results for this key, so I’m assuming it’s something new that was added for Panic (and maybe BBEdit), and which may or may not be documented in the future for use by other developers.
\nAnother interesting entitlement is “com.apple.security.automation.apple-events”, which is documented by Apple, but only in the context of the new “Hardened Runtime.” This technology is aimed primarily at developers who are not developing for the Mac App Store, but who want to provide enhanced security for their customers. In that context, I believe this entitlement provides unfettered access to sending AppleEvents, excepting that in Mojave and later the app is still subject to fine-grained system alerts that require user approval for each application that is targeted.
\nIn short: it appears that Transmit possesses at least two “official” entitlements that could be made available, or are perhaps already available, to other developers. One way to find out: add them to your app and submit it for approval!
\nUpdate: Thanks to Jeff Nadeau for alerting me to the pertinent API that correlates with the privileged file operations entitlement. NSWorkspaceAuthorization can be used to request privileged file access from the user, and Apple includes a link for requesting access to the entitlement.
\nUpdate 2: It turns out my intrigue around “com.apple.security.automation.apple-events” was ill-founded. I assumed that a sandboxed app could use this entitlement to gain unfettered access to automating other apps, but in the case of a sandboxed app it turns out to work in conjunction with the existing “com.apple.security.temporary-exception.apple-events” entitlement, which requires enumeration of specific targets. Thanks to Jeff Johnson and Paolo Andrade for talking me through my misunderstanding of the situation.
\n", "date_published": "2018-11-15T15:57:21-05:00", "date_modified": "2018-11-15T17:46:04-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://bitsplitting.org/2018/10/05/terminal-security-profiles/", "url": "https://bitsplitting.org/2018/10/05/terminal-security-profiles/", "title": "Terminal Security Profiles", "content_html": "In macOS Mojave, Apple introduced a number of new security features that impact the day-to-day use of the computer. Activities such as running scripts, or using apps that access private information, are altered now such that users are prompted with one-time permission-granting requests.
\nOne consequence of these changes is that you can no longer access certain parts of your home directory from the Terminal. Don’t believe me? Try opening Applications > Utilities > Terminal, and run the following command:
\n\nls ~/Library/Mail\n\n
In all previous macOS releases, this would list the contents of Apple’s internal Mail files. As a privacy enhancement, access to these files is now restricted unless apps have requested or been proactively granted access.
\nIf you really wanted to regain access to these files via the Terminal, you have to grant the app “Full Disk Access.” This is a new section of the Security & Privacy pane in System Preferences.
\nWell, that’s fine. Now you can “ls” anything in your home folder, but absolutely every other thing you run in Terminal can as well. To grant myself the ability to list files in ~/Library/Mail, am I willing to grant the same access to every single thing I’ll ever run in Terminal?
\nThis isn’t earth-shattering: it’s been the case forever that tools you run in the Terminal have access to “all your files.” But the new restrictions in macOS Mojave shine a light on a problem: the bluntness of security restrictions and relaxations with regard to Terminal.
\nI’ve run into a variation of this problem in the past. I use the excellent TripMode to limit bandwidth usage when I’m traveling, and tethered to my phone. A consequence of this is that, unless I grant unlimited network access to Terminal, I can’t perform routine tasks such as pushing git changes to a server.
\nIdeally these permission grants would be applicable at the tool level, rather than at the application level. It would be better if I could say “let ls access my Mail” rather than “let anything I run from Terminal access my Mail.”
\nI don’t completely understand the limitations there, but I suspect that because commands in the Terminal are running as subprocesses of Terminal, there is some technical challenge to making the permissions apply at such a fine-grained level.
\nAs an alternative, I wonder if Apple could introduce some kind of “Security Profiles” feature for Terminal so that individual windows within the app could be run when different permissions? This could build on Terminal’s existing support for “Profiles” which already support varying Terminal settings dramatically on a per-window basis.
\nWith Security Profiles, a user would be configure an arbitrary number of named profiles, and security privileges acquired by Terminal would be stored separately for the active profile. Each profile would be considered by the system effectively as a different app. For example, given my uses of Terminal, I might set up a few profiles for the types of work I regularly do:
\nThese are off the top of my head, and just to give an idea of the kinds of profiles that might make sense here. Switching between these modes would also switch the system’s active list of entitlements for Terminal. If I run a script that accesses my Calendar items from the “Personal” profile, the system would prompt me once to ask my permission, but never prompt me again in that profile. When I switch to “Experimental” and run some unfamiliar third-party tool that tries to access my calendar, it would ask permission again for that profile.
\nI filed Radar #45042684: “Support a finer-grained permissions model for Terminal”, requesting access for this or something like it.
\n", "date_published": "2018-10-05T11:52:20-04:00", "date_modified": "2018-10-05T12:08:54-04:00", "author": { "name": "Daniel Jalkut" } } ] }