This post is long overdue. Quite a few people have asked me while all of the software I create does not have the “or (at your option) any later version” that the FSF seems to suggest. (I am not against contributing to projects that do have that clause, however.) This post will explain my reasoning, and hopefully cause others to see the potential problems with it. I am absolutely not against people using this clause in general; I merely want them to be fully aware of what they’re getting into before doing so. Also, please note that this applies to any license where an “any later version” clause is used, including the GFDL. I’m not just talking about software.
FreeBSD has a bootloader vastly different than GRUB or LILO. The equivalent of stage1 in GRUB (which is used to locate the rest of GRUB and load it) is boot0 in FreeBSD, which is actually used to directly chainload Windows (or any other dual boot setup using the FreeBSD bootloader). The problem with boot0 is that, because it fits entirely in the MBR’s boot code area (which is 440 bytes), it doesn’t load a configuration file at all. FreeBSD still gives you a way to configure it, however, with boot0cfg. Read on for a simple tutorial on the basics of boot0cfg. Continue reading →
In the last post, I discussed my reasoning for switching back to Apache from Cherokee. In this post, I’ll be talking about mod_macro [cri.ensmp.fr], and how it makes configuring Apache fairly easy, and making tweaks dead simple. One of the big complains about Apache is the difficulty in making changes to all virtual hosts on a server. mod_macro not only makes adding new virtual servers easy, it makes tweaking all of them trivial. Read on for a quick tutorial on mod_macro.
Sadly, the current version of the Cherokee web server [cherokee-project.com] has some serious outstanding flaws. Most notably, up until recently (where it was reverted in Chrome, not fixed in Cherokee) Chrome could not submit POST forms over HTTPS. Google said in the Chrome bug that web servers that were broken by this change didn’t conform to the SSL spec, and even after it was reverted, they say it was only reverted because quite a few servers still “broke” SSL specs. While Cherokee people (perhaps rightfully) said that Chrome shouldn’t have landed that change (and the change did hit stable very rapidly, due to Chrome’s rapid release schedule), having a web server that cannot accept POSTed data is unacceptable, no matter whose fault it is.
More over, there haven’t been any commits in the master branch of Cherokee’s source in over six months. The creator of Cherokee posted on the mailing list a week ago that he’s working on a totally new version, because most of the core code is being written to be more compatible with protocols like SPDY, and to fix “a few long standing SSL bugs.” Unfortunately, with no release (or even commits) at all being made in six months and with several fairly large bugs, I cannot continue to run Cherokee. Part of what I loved about Cherokee (aside from the gorgeous web administration interface) was the agility behind it: new versions with new features and bug fixes were released constantly. It felt much like Chrome does, including that serious bugs are very rare, and are usually patched out extremely quickly. The only serious bug I ever encountered with Cherokee was the HTTPS POST bug, which was technically only triggered by a change in Chrome, despite the former rapid releases.
So for these reasons, I have switched all of my web servers back to Apache from Cherokee. Personally, I probably won’t be switching back yet again once the new Cherokee with the rewritten core is released, but I know I won’t be recommending Cherokee for new servers at least until the new version is released, and even then probably not for heavy production use. The complete lack of communication (up until a couple of emails explaining the situation last week) makes me wary to use or recommend Cherokee in production.
For some reason, Amazon doesn’t give you a direct link or QR code to get the APK for their Appstore; they only will send it to you over SMS or e-mail. So, here’s a QR code to grab the APK straight from Amazon, using their official link [amzn.to]:
The two biggest feature requests for RingyDingyDingy pre-0.5 were Gmail and Google Voice integration. My goal was to implement them both for RDD 0.5… but, unfortunately, I could only implement Google Voice integration. It seems like this is going to be a long-term/permanent problem, as well, because Google intentionally caused this. Read on for why RDD can’t support Gmail.
I’ve just published RingyDingyDingy version 0.5 to the Android Market. I re-published it a few days ago after a long hiatus, and brought it back as a FOSS app. Before publicizing it, I wanted to give it some time to settle down, and add a few wishlist features. Well, it’s now at a state that I feel comfortable with, and has most of the features I wanted to add.
That being said, you can grab it from the Android Market here [market.android.com], and the Google Code page is here [code.google.com]. If you don't have access to the Market, you can also grab the APK from the Google Code page.
Finally, I'll be posting more here over the next few days about what I've learned on the way to RDD 0.5.
I really like using mercurial-server [lshift.net] for hosting my Mercurial repositories. Because it uses SSH and public keys, it’s quite secure, and works well with multiple users. However, it doesn’t have public access for pulling repositories. For that reason, I also use hgweb (shipped with Mercurial) to make my repositories publicly accessible and pullable, especially with the highlight module (also shipped with Mercurial) that uses Pygments [pygments.org] for syntax highlighting.
So in this post, I’ll be explaining how to use mercurial-server to host your repositories, while also having them publicly browsable and pullable with hgweb. I’ll also be demonstrating how to hide repositories from hgweb, while still keeping them working with mercurial-server.