For one of our clients, I had to get provision new AMI images based on Ubuntu 18.04 (“bionic”). Some of the services require the Codedeploy agent installed to perform deployments on those machines. This works pretty well on current Debian releases (eg. “stretch”), but no on Ubuntu (which is pretty widely used IMO).
To get the Codedeploy agent running on the current Ubuntu release, I’ve headed to its official Github repository, which already contains a pull request with a fix. Unfortunately, that fix does not fix the agent itself, but parts of the installation routine. The installer script will download a prebuilt .deb image from an S3 bucket, which then will refuse to install because it has dependencies which cannot be met on current Ubuntu versions. The Codedeploy agent is written in Ruby and requires Ruby 2.0, 2.1, 2.2 or 2.3. Newer versions are not (officially) supported; I’ve modified some checks to let the version checks pass, and it works so far. I’ve opened a pull request on Github to get it eventually merged.
Weeks have passed since then. My PR has not been merged, and no useful proposal from upstream was given. They want additional tests for the code, which have not existed before. It frustrates me, because I had to implement some ugly hack to install Ruby 2.3 from previous Ubuntu LTS version (“Xenial”) to get it work on the current Ubuntu bionic. This only works if you don’t have any other projects that depend on Ruby 2.4 or higher (because I’ve pinned the Xenial repository for ruby packages).
Update: I have closed my PR. AWS has merged the very same set of changes into master, and has been rolling out updated packages in most regions.
The v0.1.14 release fixes a regression introduced in v0.1.13.
I’m proud to announce the availability of python-rrdtool 0.1.13. It contains backported bug fixes and improvements from the upstream repository.
Since python-rrdtool have found its way into the original rrdtool distribution, some people have asked about the future of the project. In fact, the Python bindings part of the official rrdtool distribution and the python-rrdtool are maintained separately, but they share improvements from each other. Due to the nature of release engineering, Linux distributions may see the inclusion of the updated bindings with the rrdtool bindings packages sooner or later, and users who wish to use a more pythonic way to install the bindings, python-rrdtool is the way to go for users that prefer installing packages via pip or similar utilities.
Being a bugfix release, python-rrdtool 0.1.12 fixes an issue with the lastupdate function.
The update has also been merged upstream, so daily-built rrdtool packages will also contain the changes.
This can be caused by the mDNSResponder service not working correctly. If you don’t see the expected computers and/or servers in the sidebar of your Finder window, you may try to kill the mDNSResponder service to get it restarted. That solved the problem for me.
In terminal, simply execute the following command:
sudo killall mDNSResponder
I’ve been having this issue for quite a while: The mentioned message pops up several times a day, and I don’t know which program causes this message to appear. After searching the web it seems like its caused by the Skype client for Mac when displaying adverts in its home section. For me, it’s clearly a security issue and needs to be fixed, because malicious URLs could be opened with that.
You can fix this by blacklisting URLs Skype uses to contact to retrieve the adverts. Instructions can be found in this forum post (german).
Today, several pages were merged to consolidate existing posts and contents.
Update: Improved theme style.
Today I’d like to share some information with users registering .com domains. Other TLDs may be affected as well, such as .net or .org (they’re all managed by the same registry).
A few days ago I’ve registered a new .com domain which unlikely was in service at any time before the registration (I even checked with the archive.org time-back machine). Later that day, I received an email with subject “DOMAIN SERVICE NOTICE”. It was sent by an third-party and asked me to subscribe a “service package”. Two days later, I’ve got another email for the very same domain. It has not been used anywhere, so I guess the registration information is retrieved by an automated process. This is probably not allowed, especially not since it gives the impression that responding to such requests is required in order to use the domain.
Please do not reply to these emails. They generate additional cost and may publish your domain name to untrusted resources. Such behavior is not serious business, so please be careful with emails like these.
Today I’ve released python-rrdtool version 0.1.3, which fixes some bugs when building the module in build environments that do not have specific rrdtool build headers included. Now all the graph and xport functions are available again.
To update or install, use pip:
pip install --upgrade rrdtool
There are some discussions going on about the number of Python bindings for rrdtool. The version I’ve created is just one of a few, and was probably the first one that offered Python 3.x support. Some people were asking if it may be possible to get this merged into the regular rrdtool distribution. It might be. But from a certain point of view I think it’s a better approach to distribute the bindings via PyPI, because it’s more pythonic, and it allows building for multiple Python versions at once.
A few weeks ago, OS X El Capitan (10.11) was released. I took the chance to test it for a few days – just to replace it again with Mavericks (10.9). Let me explain why.
When Apple released Yosemite in 2014, they did a major update to it’s design. Not only the system font has changed from Lucida Grande to Helvetica Neue (and to San Francisco in El Capitan to address some readability issues on non-retina displays), but also many things under the hood have been changed. These changes to the UI system made Yosemite and El Capitan responding slower than Mavericks. But that’s something that you’ll eventually only notice if you’re having a dual-boot system with both versions running on the same device. I can definately work faster with 10.9 as with any newer OS X versions, because everything responds faster.
With El Capitan, Apple simply continued where they left off with Yosemite. Especially in bringing their Apps up-to-date with the new UI design introduced with Mavericks and improvements regarding security mechanisms with the system itself. They also have improved the performance. Unfortunately, the performance is still not the same as with Mavericks.
Some further issues discovered with El Capitan were:
- Finder canceled renaming files when the list of file reached the bottom. This was freaking me out when renaming files in directories with hundrets of items.
- PDF documents look somehow blurry. This wasn’t the case with Yosemite and Mavericks.
- They have a new beach ball. But I see it even more often than in previous OS X versions. Not good.
- Disk Utility was redesigned. While it perfectly fits into the rest of the system design, some things have been changed (especially the partition stuff works a bit different). Humans don’t like changes, you know… 🙂
So at the end of the day I ended up restoring my Time Machine backup to have Mavericks back on my device. For users of retina-based devices, Yosemite or newer is a must, as only those versions have full retina support.