The kernel of my home office

 I consider myself a rational person. By that, I mean that I make important decisions in my life based on weighing pros and cons, similar to a chess game. So what to make of my decision to confront Koodoo over their exorbitant charges for my spouse's mobile phone use? This one .  It would be reasonable to look at the legalities, and the likelihood of them caring what I think, and decide that the work of trying to hold them to account is a pointless waste of time. Certainly, the replies I've had in the forum here: https://community.koodomobile.com/billing-66726/will-anyone-at-koodo-take-responsibility-for-their-services-7804585 have mostly been of the "sucks to be you" variety. So let me describe in detail what it's like to try and get someone at Koodoo to reverse the charges of a blatantly egregious overuse charge. To talk to someone at Koodoo, you have to talk to a bot for a while to convince them that you need to talk to a person. It's pretty entertaining on

Do you trust your service provider? What does that even mean? For an individual with a relationship with a corporation, trust is not the same as trust with a person. Particularly with a complex service model, you have to have some trust in your service provider, even if you are reluctant about that, because you don't have a choice. For example, you don't have a much of a choice about what kind of service plan you get for your mobile phone in Canada, and those plans are constantly being changed by the providers, so trying to keep up with what the best plan for you is, is difficult. But aside from the aspect of "buyer beware" that covers all consumer relationships in Canada, mobile phone service is complicated by the fact that those mobile phone providers are using public resources that they make use of within a regulated system. In other words, they're selling us a package that includes resources that are only leased to them (i.e. the radio spectrum) from us, under

What Are Managed Services? " Managed services " is an offering of many businesses that provide Internet services. In the past couple of years, it's a term I've used to describe what I offer in my Blackfly Solutions Drupal and CiviCRM hosting business . You may not know whether you would want such a thing, since it's a very badly named thing.  This post will try and give a reason for why managed services is a thing at all, how it can be a good thing, and why it may be what you want. Here's the short version: managed services exist to fill the gap between what machine automation can reasonably provide and what people actually want. In a subsequent post, I'll explain how containers can be a useful tool for delivering managed services. What Do You Mean by Services? A "service" in the "managed services" context is the consumer-oriented one, i.e. something a consumer wants that they get from a service provider. For example: "hosting for

Happy families are all alike; every unhappy family is unhappy in its own way. - Leo Tolstoy Like happy families, successful mass mailings are easily taken for granted as normal, but they are more an exception than a rule. Most mass mailings fail in one or more ways. And the ways that a mass mailing can fail are probably more diverse and interesting than you think. So when you ask "why am I not receiving my mass mail" or "so-and-so isn't getting my mass mail", it's rarely a simple answer. Even if it used to work fine. To put some perspective on this - if you're getting only 10% of your mass mail opened, it's not bad. Industry-wide, a 7% click through seems to be about average. In this post, I'm going to follow a piece of mass mail and show you all the different ways it can fail to be successful. I use CiviMail for my mass mailings, and but I think most of it will be tool agnostic.  To keep it simple, I won't try and go through all the ways you

On Sunday last, a (Linux) server in my infrastructure that was running a fairly conservative number of docker containers in production was brought to its knees. The monitoring data (from prometheus) showed that cpu was all gobbled up (from an average of less than 2% to a steady 75%-ish) and remained gobbled up until the server was rebooted. Notably, the disk usage and throughput went down during the event, and memory usage did not change notably, nor was it notable high. On review of the messages log, one of the last entries before the event was documentation of an apache OOM (out of memory) event. On this server, apache is only running inside containers, which are generally limited to 500Mb (by docker). So presumably, a docker container running apache ran out of memory and tried to recover some memory and that was what triggered the event. Reviewing the log of requests before the emergency, it's not clear which container or url or urls might have been generating so much memory u