Archive for the ‘software’ tag
I’m excited to announce the first new Blue Static product in 13 years!
Mailpopbox is an email server that helps provide
anonymity by accepting email to any account at the domain (i.e. a catch-all wildcard). All messages
are delivered to a single mailbox, from which your email client downloads all the messages.
This is version 2.0.1, which you may find surprising for an “initial release.” I’ve been running
Mailpopbox myself for more than three years, adding features and fixing bugs. So it has been fairly
well-tested in production, and I decided it was finally time to release it.
Mailpopbox is also the first product to use GitHub for issue
tracking, rather than Bugdar. I’m doing this as an experiment, so we’ll see how that goes. Pull requests are welcome
via GitHub too, though the repository source of truth will remain self-hosted here on Blue Static.
You can download Mailpopbox 2.0.1 and read more on the product page.
Today I’m releasing MacGDBp 2.0.2 to address a major issue with the auto-updater and some other
minor product bugs.
Somehow when upgrading the Sparkle updater framework when working on MacGDBp 2.0, the auto-update
relauncher binary lost its executable
bit. This resulted in the
auto-update installation hanging indefinitely. Unfortunatley there is no way to automatically
recover from this state. Users can run:
chmod +x MacGDBp.app/Contents/Frameworks/Sparkle.framework/Resources/Autoupdate.app/Contents/MacOS/*
… and re-run the in-product updater. Or simply download version 2.0.2 which has resolved the
You can download MacGDBp 2.0.2 from the product page.
In March I quietly promoted the 2.0 beta 1
release to be the final, stable build. I decided to not do a blog post because there were no changes
from the beta build.
Today I’m releasing 2.0.1 to address some issues. Thank
you to everyone who reported these bugs. The release also improves dark mode support in the source
viewer, which you can see below.
You can download MacGDBp 2.0.1 from the product page
or by updating via Sparkle.
While I did state that the first beta of
MacGDBp would be out by the end of the year, I decided against pushing a new build before
immediately disappearing on holiday for two weeks. But today is the day!
Version 2.0 is not a complete rewrite, but virtually every aspect of the app has been updated and
improved. The biggest changes are under-the-hood, particularly around the interaction between the
frontend and the remote debugger, which now accurately tracks “transactions.” This allows MacGDBp to
fetch the contents of long arrays or large objects without issue. In addition, several components
have been refactored to improve the project’s code health and the app’s robustness. These
improvements fixed numerous long-standing bugs in the app.
The biggest new feature, by popular demand, is the ability to set symbolic breakpoints. This will
pause the debugger any time a function of a given name is called, rather than having to rely solely
on file/line breakpoints.
Unfortunately, the app will remain un-sandboxed and not code signed. The Sparkle updater is not yet
compatible with the app sandbox. And Apple’s annoying
two-factor authentication requirements rule out (for me)
obtaining a signing certificate. Sparkle will still verify the updates’ signature, however.
Finally, MacGDBp 2.0 sports a new, unified interface. All of the panels and windows have been
collapsed into a single, tabbed window.
See the changelog for the full list of new features
and bug fixes.
You can download MacGDBp 2.0 Beta 1 from the product page.
First, welcome to the new Blue Static! The site has a fresh coat of paint, it has been made more
mobile-friendly, and I have updated much of the content, pruning extremely old things while keeping
still-old-but-maybe-interesting items around for posterity. For the first time in the history of
the site, Blue Static is no longer powered by PHP: the entire site is now rendered as static files
It has been well over seven years since this site was last updated, and that is because I no longer
have the substantial amounts of time I once had to dedicate to Blue Static software. Since I now
spend all of my working hours writing and maintaining software, the allure of doing so as a hobby
has unfortunately diminished.
Over the past few months, I’ve pondered how to move forward with the various Blue Static projects.
I’ll outline some of those decisions now:
MacGDBp still has a large number of loyal users. I’m happy to report that in these intervening
years, I’ve worked sporadically on the next major version. The first beta of MacGDBp 2.0 will be
released before the end of the year! The entire core debugging engine has been rewritten and made
more robust, which has fixed many bugs and added new features. The new version will also be code
signed and notarized to be compliant with Apple’s increasingly locked-down macOS.
RGB Converter will remain available for download, but because Apple has removed
in macOS 10.15 Catalina, the widget will not be updated anymore.
Bugdar is the project that I’ve struggled to make a decision on. It is fairly safe to say that
any 2.0 greenfield rewrite will not happen. However
all of Blue Static’s bugs remain in the Bugdar instance that runs on this site, so it cannot go
anywhere over night. I am not currently enamored with other options, such as Github’s issue tracker, so
despite Bugdar’s visible age I will continue to run it for Blue Static’s purposes. There may be an
infrequent maintenance update, but I do not expect to make major changes to the software at this
What drove these decisions is that I have largely stopped writing software in PHP. It is
no longer my language of choice, and my interests have moved on to other programming languages and
software domains. MacGDBp remains important to me beacuse others find it useful and the code is
still fun to work on.
I’ll close with a teaser: there is at least one new project that I will be publishing in the future
under Blue Static. It has to do with email and is geared towards power-users.
Look forward to MacGDBp 2.0 Beta 1 coming to a Sparkle update near you!
I’m pleased to announce MacGDBp 1.3. This release features a new tool that allows you inspect values in the variables list via a HUD (screenshot below). This inspector will allow you to see long strings and to select/copy text values. To access this feature, go to Window → Inspector (Shift+Cmd+I). The currently-selected variable (which now, in 1.3, remembers itself across debugger stepping) will have its full value displayed in the HUD window.
Under the hood, there are two significant changes. The first is a rewrite of the receiving side of the socket layer (it now precisely uses the message length when buffering memory), which should eliminate the “buffer is incomplete” errors that occasionally popped up. The second is that the PHP stack will no longer be managed internally. After every debugger step, the entire stack will be now re-created because Xdebug proved to be unpredictable for keeping in sync with an internal state. Debugger actions may now seem a little less snappy, but I think accuracy is more important than speed here. In 1.4 I’m going to use a caching mechanism that will speed up performance by reducing network access.
This release also features a bunch of bug fixes, a couple of which would cause the debugger display to not work under certain circumstances. As always, the change log and commit log have all the details on the release.
I’ve posted today a git repository called Toolchain. This is a collection of scripts that I use that others may find helpful. You can find the repository here. In this post, I’m going to talk about one of the items in Toolchain called Gitcrement.
Gitcrement is a set of two scripts that solves the problem of creating build numbers when using git for source control. Unlike Subversion, where the repository revision is the perfect choice for a build number, git has no such luxury because it uses SHA1 hashes for identifiers.
This is where Gitcrement comes in. Gitcrement is a simple interface to a database that contains a sequential ID number (the build number), a username, the current date/time, and a git SHA1 hash.
The gitcrement.py has four commands: init, next, list, and current.
To create a new Gitcrement database, go into any git repository root and type “
gitcrement init“, which will create a new database file called .gitcrement.
When you want to create a new build number, simply type “
gitcrement next” to record the current user (
`whoami`), date and time, and whatever SHA1 hash
`git info .` would reveal.
To see the current build number type “
gitcrement current” and to get a list of all the build numbers type “
That’s all there is to it. To make this system useful, however, it needs a script that can be run in Xcode to automatically call “next” and save the value as CFBundleVersion in Info.plist. So, there’s another Python script called xcbuild.py, which you can use as a Custom Shell Script Build Phase. This will advance the Gitcrement number every time you build the “Release” target in Xcode.
Gitcrement requires Python 3.0, which is not installed by default in Leopard. You can find it here or through MacPorts or fink.
Also, you may need to edit the installation paths in the tops of both files to point to where your copy of “git” is (in gitcrement.py) and where you install the “gitcrement” script (in xcbuild.py).
You can download Gitcrement here:
Link in Gitweb
People sometimes ask me why I don’t charge for the software I write. I explain to them that, to me, it’s not about the money. But that’s only part of the story. After thinking about it there are a few reasons why I release everything as open source.
1. You’re Giving Back to the Community
This is what the entire FLOSS community and its mentality is about. You have this great software and you want to give back to the greater community by making it open source. Doing so means that all developers can see how you’ve chosen to implement certain things, they can borrow code, and they can help improve software by submitting patches. For me, I learn a lot of programming languages and techniques by dissecting open source software, and I feel it’s only fair for me to give back to the community as much as it has given me.
2. You Don’t Worry About Business
I’ve been reading some articles about indie development and I watched all of the C41 videos. From doing so, I’ve realized that starting an independent software shop is a lot of work. You have to get a credit card processor, you have to have a licensing infrastructure, you have to worry about piracy, and (arguably the most difficult) you have to find the right price for your software. We’re software developers, not business people. This is not my idea of a good time and I’d much rather spend time developing rather than doing the aforementioned tasks. Going open source frees you from all of that.
3. People Can’t Have Expectations
That is sort of a half truth. People will always have expectations about software, regardless of whether or not they pay for it. But when you develop open source software, you’re essentially a volunteer. People get what they pay for. I try to do my best in creating software and supporting it, but because it’s open source, there’s no expectation that I have to. As a full-time college student, I don’t have a lot of free time — I develop when I can. If I had paying customers, there’d be an expectation for future versions on a reliable time scale, but I’m not under that pressure. Additionally, I do not have to support this software with immediate email responses, blog follow-up comments, or forum posts. I do so because I like doing so. If this were a business, people would have high expectations for support, but because I do open source work, if I deliver good support, it’s only a bonus. If I don’t, they really can’t complain because they don’t pay for anything.