Here’s a trip down the memory lane – “How Linux got to be Linux: Test driving 1993-2003 distros“. The article looks at some of the early Linux distributions, remember what was already in and what came later. Complete with screenshots.
I don’t remember for sure which versions of which distributions I used in the early days, but Slackware, Suse, RedHat and Mandrake were definitely among those. Slackware was probably my first one, when I found the floppies in the only book on Linux at my college library. Then, somehow, I found RedHat (I think 5.1 or so) in one of the local computer shops. Later I tried Mandrake and Suse, cause those were laying around at work. But RedHat stuck with me ever since. I think I’ve used pretty much every version, including the move to Fedora, CentOS, and even the Red Hat Enterprise Linux, which we had the licenses for at some of my early work places.
Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations. It touches on the following:
- Command-line flags, with the link to gflags.
- A/B flags
- Dynamic flags, which are more difficult
- More complex systems.
I’ve dealt with feature flags before, but never found an elegant way to scale those. Some of the issues that I came across were:
- Naming conventions. With more and more features added to the system, naming things becomes more and more difficult. Especially, when features cross over from one part of the system into another and need to be supported in different sub-modules. In a way, this reminds me of the old argument in the blogging community about using hierarchical categories vs. flat tags, with categories providing more order and tags providing multiple paths to the destination.
- Modularization issues. Feature flags are often need in the larger applications. The kind that provides a lot of features (duh!). But those large applications often consist of smaller parts, or modules. Deciding whether or not to implement the feature on the application level, and/or on the module level is difficult. Especially if those module features will need to be later grouped into application features.
In terms of implementation, I haven’t used any special tools or libraries. It was basically a set of configuration files, with feature variables defined per environment and altered during the deployment.
These days, something more robust than that is necessary for some of the projects at work. Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel. For a good starting point, have a look at PHP Feature Flags website. The ones listed so far are:
So, I guess, PHP is well covered when it comes to feature flags tools. The above cover cookie-based, IP-based, URL-based dynamic features, configuration-based features, and A/B features.
The point now is to actually utilize them in the project. After all, the lack of feature flags is one of the 5 toxic things for the scalability, as per this page:
- Object Relational Mappers (ORMs)
- Synchronous, Serial, Coupled or Locking Processes
- One Copy of Your Database
- Having No Metrics
- Lack of Feature Flags
I haven’t decided which library to use yet – will need to try them all and see which one is the most appropriate, but for now I don’t think I’ll dive as deep as cookie/URL/IP based features or A/B testing. Even the simplest configuration-based implementation will be helpful.
An international team of astronomers have released two petabytes of data from the Pan-STARRS project that’s also known as the “world’s largest digital sky survey.” Two petabytes of data, according to the team, is equivalent to any of the following: a billion selfies, one hundred Wikipedias or 40 million four-drawer filing cabinets filled with single-spaced text. The scientists spent four years observing three-fourths of the night sky through their 1.8 meter telescope at Haleakala Observatories on Maui, Hawaii, scanning three billion objects in the Milky Way 12 times in five different filters. Those objects included stars, galaxies, asteroids and other celestial bodies.
Wow … this is mind blowing at the very least …
See the image above? That’s the result of half a million 45-second exposures taken over four years. They’re releasing even more detailed images and data in 2017 — for now, you can check out what the team released to the public on the official Pan-STARRS website.
Well, apparently I’ve been leaving under a rock for the last few years. When it comes down to IRC clients, I’ve been mostly using XChat. Turns out, XChat has been abandoned for years, and it’s still around mostly because Linux distributions care so much about it that they patch it and ship it.
As with anything in the Linux world, there are plenty of alternatives. And one of them was right under my nose all these years – HexChat:
HexChat is an IRC client based on XChat, but unlike XChat it’s completely free for both Windows and Unix-like systems. Since XChat is open source, it’s perfectly legal.
HexChat is often shipped right next to where XChat is or used to be. For Fedora users, it’s as close as “dnf install hexchat“.
Warning: you will lose a lot of sleep if you follow the link below. :)
No matter how well you know Vim, bash, git, and a whole slew of other command line tools, I promise you, you’ll find something new, something you had no idea existed, something that will help you save hours and hours of your life by shaving off a few seconds here and there on the tasks you perform on a daily basis, in the repositories link to from this site.
I think I’ve spent most of my Sunday there and my dotfiles are so different now that I’m not sure I should commit and push them all in one go. I think I might need to get used to the changes first.
Some of the things that I’ve found for myself:
- PHP Integration environment for Vim (spf13/PIV).
- myrepos – provides a
mr command, which is a tool to manage all your version control repositories.
- bash-it – a community Bash framework.
- Awesome dotfiles – a curated list of dotfiles resources.
… and a whole lot of snippets, tips, and tricks.
P.S.: Make sure you don’t spend too much time on these things though :)
Let’s Encrypt has only experimental support for the Amazon Linux AMI, so it’s kind of expected to have issues once in a while. Here’s one I came across today:
# /opt/letsencrypt/certbot-auto renew
Creating virtual environment...
Installing Python packages...
Traceback (most recent call last):
File "/root/.local/share/letsencrypt/bin/letsencrypt", line 7, in <module>
from certbot.main import main
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/certbot/main.py", line 12, in <module>
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/zope/component/__init__.py", line 16, in <module>
from zope.interface import Interface
ImportError: No module named interface
My first though was to install the system updates. It looks like something is off in the Python-land. But even after the “yum update” was done, the issue was still there. A quick Google search later, thanks to the this GitHub issue and this comment, the solution is the following:
pip install pip --upgrade
pip install virtualenv --upgrade
virtualenv -p /usr/bin/python27 venv27
Running the renewal of the certificates works as expected after this.
P.S.: I wish we had fewer package and dependency managers in the world…
Wait, what? That’s exactly what I said when I read this blog post. I am still making my way through the JSON API specification. And now it seems I might be wasting my time, as I should be learning HAL.
Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.
HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.
Sometime I think that I should just stop learning. What’s the point? By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.
Paul M. Jones announces the availability of PHP Package Development Standards for review:
This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.
PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.
Have a look at php-pds/skeleton GitHub repository.
Personally, I welcome this initiative. PHP ecosystem exploded in the recent years with the help of composer and Packagist.org. There are over 120,000 packages just on the Packagist.org. I think, it’s good to have some standards and best practices. The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs). But we could have some more guidelines in order to have some consistency.
PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices. They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.
Looking at the packages that I am involved with, only a few minor changes are necessary to comply. Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.
Chris Hardie, who works for Automattic, shares his observations on where the power in a distributed organization comes from, versus the traditional one.
In an office setting, I see power and influence gather around…
- The person with the newest, coolest and/or most expensive clothing
- The person with the larger corner office
- The person with the most assistants
- The person with the most impressive sounding title
- The person with the closest parking space
- The oldest, richest, whitest males
- The person who’s allowed to create or interrupt meetings
- The person with the most impressive social and public-speaking skills
- The person who uses their power to get what they want
In a distributed organization, I see power and influence gather around…
- The person who produces output and solutions that exceed expectations
- The person who can connect deeply with colleagues over a distance
- The person who can effectively and concisely articulate their own views and ideas
- The person who helps their coworkers be the best versions of themselves
- The person generous with their understanding of how to navigate the organization’s processes and culture
- The person who can give voice to unrecognized or unspoken truths
- The person who learns fastest from their mistakes
- The person who uses their power to empower others
It’s of course not fair to generalize this way. There are healthy traditional organizations where appearances are not necessarily the basis for power. There are probably unhealthy distributed organizations where power centers around the appearance of lots of activity that produces few good outcomes. But my experience so far is that a distributed organizational structure inherently facilitates an experience of power, empowerment and leadership that is better for the people in it, and for the work they are doing together.
I don’t have much experience working for a distributed organization, but judging by many Open Source projects, which are, in essence, distributed organizations, I’m inclined to agree with the above observations. I wouldn’t be able to put in words so well though.
Conky is a light-weight system monitor for X. It supports all kinds of metrics – anything from CPU, memory and network, to emails, music players, and more.
It reminds me of the old days, before Gnome and KDE took over the desktop environments – I think everybody had something similar running as part of the screen background.
The installation on Fedora is trivial – conky is packaged and available with a simple “yum install conky“. The configuration, on the other hand, is not so much. GitHub repository provides quite a few fancy user configurations, but there was a change in configuration file format in the version 1.10, and things aren’t as smooth as I would like.
It’ll take a bit of playing around, but I’m sure I’ll eventually lose enough sleep over this to just give up and have something semi-decent on my screen.