I’ve been playing around with go for a few years now and vendoring for a couple. Like about everyone else, I have some strong opinions about how vendoring should work. I think the newish dep tool is my favorite so far (good thing, because we’re all going to be stuck with it) but there is one thing that is really bothering me about it.
Part of my philosophy around vendoring is that you should only manually update what you have to to make progress in your own code.
I’ve worked quite a bit on storage and networking products based on Linux servers. One thing that I run into often is the need to share development machines with a team of other developers. They get re-imaged quite often. Since they come and go, we don’t bother to spend much time customizing them and there is usually just one user that we all share.
The worst about all of this for me personally is that they always come up with bash and emacs style line editing in the shell.
I’ve used DigitalOcean (DO) before. I think I spun up my first tiny droplet a few years ago and I ran this blog on one for quite a while. However, it had been a while and I never got into it enough to have needed much automation. Now, I’m a DO employee and I will be using it frequently.
The problem is that DO droplets come up with access only to the root user.
I have a weekend between jobs. I left my job yesterday and I’ll fly out to NYC to start a new one on Tuesday. As I leave, I’m realizing it was stifling my creativity. Now that I’m free, I feel it returning and I hope to post with a little more frequency.
With some time on my hands this weekend, I looked for a better way to host this site; you know more responsive, easier to manage, and all that.
This post proposes an alternative to merging and rebasing that will require some enhancement to git to work. As far as I know, this isn’t possible with git in its current form but I think it would be worth the effort to make it happen.
I’ve been using git since about a week after it was first available for download way back when BitKeeper pulled the rug out from under the Linux kernel.
I was playing around with a change yesterday hoping to optimize out an extra database round trip. I thought I could accomplish it without having to change the structure of the code at all just by replacing a list comprehension – which triggered a query to the database – with just a query which could be passed directly to the next query. This would save a round-trip and should be less racy.
DNS on my MacBook Pro has been a mystery to me. But, I can figure it out most of the time after a little bit of digging. This time, I have given up for the moment after spending too much time on this issue.
The Problem This started sometime during the day on March 1, 2016. Everything was working before. I’m not aware of any updates to the OS or anything I did.
I’m just returning from the latest OpenStack Neutron mid-cycle in Rochestor, MN. It turned out to be great mid-cycle for me. I wanted to share a new idea that came out of it.
The Problem One thing that has been on my mind for a while now is wasted IPv4 address space by Neutron. I guess I was waiting for someone else to bring the solution because I wasn’t personally feeling the pain yet but it is time to solve it once and for all.
An exciting new feature was just merged to Openstack Neutron in the Mitaka release; it’s called address scopes. Address scopes build from subnet pools added in Kilo. While subnet pools give us a mechanism for controlling the allocation of addresses to subnets, address scopes give Neutron a way to know where addresses are viable. They are also the thing within which addresses are not allowed to overlap.
If you’re unfamiliar with them, you might want to review subnet pools before you read on.
Back in 2012, a new IP allocation was made called “shared address space.” At first glance, you might think that this allocation is just like the old RFC 1918 allocation. Maybe the IANA decided that we could use a fresh allocation of these things because our address space is feeling a little cramped.
That wasn’t it. ISPs and other service providers needed an address space that can be reused in different geographies, doesn’t overlap with any global IP addresses and, just as importantly, won’t overlap with any private IP address usage on customers’ private networks.