Showing posts from November, 2017

Small Business Accounting Software Woes

I'm so disappointed with the online accounting software options available to me; and I've spent far fa r too much time in the past couple of days looking for an accounting solution for my new business. The current state of affairs makes me wonder if just using a spreadsheet might be as easy. I am posting my experiences here for two reasons. To inform others who might have similar needs, and To inform the hopefully smart people at these companies, so maybe they will improve their products. Let me start with a brief summary of my needs: Track time (esp. billable hours) Tracked time should include date, and project/client, and some description of work performed. Multiple currency support. I have international clients that I need to bill in their preferred currency. Invoicing and payment tracking for above. Payroll -- preferably integrated with someone like Gusto . Support for two employees with plans to grow.  Double-entry accounting (including bank reconciliatio

TLS close-notify .... what were they thinking?

Close-Notify Idiocy? TLS (and presumably SSL) require that implementations send a special disconnect message, "close-notify", when closing a connection.  The precise language (from TLS v1.2) reads: The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.  close_notify  This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.  Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.  Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection.

CMake ExternalProject_add In Libraries

First off, I'm a developer of open source application libraries, some of which are fairly popular. TLDR: Library developers should not  use ExternalProject_Add, but instead rely on FindPackage, demanding that their downstream developers pre-install their dependencies. I recently decided to try to add TLS v1.2 support to one of my messaging libraries, which is written in C and configured via CMake. The best way for me to do this -- so I thought -- would be to add a dependency in my project using a sub project, bringing in a 3rd party (also open source) library -- Mbed TLS . Now the Mbed TLS project is also configured by CMake, so you'd think this would be relatively straight-forward to include their work in my own.  You'd be mistaken. CMake includes a capability for configuring external projects, even downloading their source code (or checking out the stuff via git) called ExternalProjects . This looks super handy -- and it almost  is.  (And for folks using

Licensing... again....

Let me start by saying this... I hate the GPL.  Oh yeah, and a heads up, I am just a software engineer, and not a lawyer.  Having said that.... I've released software under the GPL, but I never will again.  Don't get me wrong, I love open source, but GPL's license terms are unaccountably toxic, creating an island that I am pretty sure that original GPL authors never intended. My Problem.... So I started by wanting to contemplate a licensing change for a new library I'm working on, to move from the very loose and liberal MIT license, to something with a few characteristics I like -- namely patent protection and a "builtin" contributor agreement.   I'm speaking of course of the well-respected and well-regarded Apache License 2.0. The problem is, I ran into a complete and utter roadblock. I want my software to be maximally usable by as many folks as possible. There is a large installed base of software released under the GPLv2 .  (Often witho