Currently showing posts in category: front page

git branch auto-magic: git-splice, git-transplant, git-deps, and announcing git-explode!

By , June 14, 2018 11:00 pm

For the last few years I’ve been enjoying the luxury of SUSE’s generous HackWeek policy to work on building four tools supporting higher-level workflows on top of git. I’d already (quietly) announced three of them: git-splice, git-transplant, git-deps (more details below). But I’m now excited to announce that I’ve just released the fourth: git-explode !

git-explode automatically explodes a large topic branch into a set of smaller, independent topic branches. It does this by harnessing git-deps to automatically detect inter-dependencies between commits in the large source branch and using that dependency tree to construct the smaller topic branches.

I recently presented all four tools at a Meetup of the Git London User Group, and thanks to the awesome services of the host venue Skills Matter, I’m delighted to announce that the talk is now online:

video of my talk on git auto-magic at the Git London User Group Meetup

If you don’t have time to watch the whole thing, you can look at the slides, or just keep on reading to see which ones you might be interested in. I’ll list them first, and then talk about the motivation for writing them.

Continue reading 'git branch auto-magic: git-splice, git-transplant, git-deps, and announcing git-explode!'»

Share

Credify – Reputation as a Service

By , May 4, 2018 7:30 pm

I went to a blockchain event this week out of curiosity, and heard a talk which really impressed me in that it could solve many unrelated problems with online sites in a single stroke. But before I tell you what it was, let’s set the scene with some example contexts in which I could see it helping in the future.

Some websites such as StackOverflow and Reddit have achieved a fairly impressive and high profile degree of success by harnessing gamification, i.e. a system based on a reputation metric (sometimes labelled “karma” or “gold”), together with a set of rules and rewards engineered in a way which incentivizes the desired behaviour, namely the contribution of high quality content. These generally work pretty well, but their systems can still be abused / manipulated in undesirable ways, and also typically there is no mechanism by which a user who has acquired a high reputation score on one site can benefit by transferring that reputation to another domain. (Although reputation earned within one community within the Stack Exchange network does give you an initial boost when joining other communities within that network.)

A different problem I’ve been mulling over for years is how to create a reliable marketplace for placing bounties on FLOSS engineering problems. Companies such as BountySource are already having some success doing this, but it feels to me that we’re still a long way from fully realising the potential for a freelance FLOSS development industry. One of the big problems in this space is figuring out how to measure good behaviour and reward it appropriately, whilst discouraging bad behaviour. Sound familiar?

A third area I’ve been considering is that of bug/issue trackers for public FLOSS projects (and even commercial products). Unfortunately it’s not uncommon for these systems to get spammed to hell and back by idiots. For instance GitHub is so scared of this problem that they’ve chosen not to open this particular Pandora’s box. However a karma-based approach could drastically improve the signal-to-noise ratio on these systems.

After spotting the common theme between these use cases, I concluded a few years ago that building a Reputation as a Service (RaaS?) platform to track reputation in a reliable manner, and allow federation of reputation between different communities, could make a lot of sense. That way each service which relies on reputation metrics doesn’t need to reinvent the wheel.

Fast forwarding several years, blockchain is a proven technology, and its transparency, immutability, and global decentralized nature all suggest that it’s a near perfect technology on which to build my (probably unoriginal) RaaS idea. And the good news is that there is already an organisation apparently well on the way to solving this: Credify. (No need to google it – the links are below!)

One significant hurdle to building RaaS (which needs to support thousands or even ultimately hundreds of thousands of transactions per second in order to work on a truly global scale) on a blockchain is the poor scalability of the blockchains offered by the likes of Bitcoin and Ethereum. However Credify has neatly side-stepped this by building on top of EOS, and they’ve taken advantage of the blockchain to design a much more powerful system which rewards not only good behaviour but crucially also good recommendations and punishes bad ones.

One of their obvious initial targets is the online product/service review industry, since sites like Yelp, TripAdvisor, Amazon etc. are plagued with fake reviews, and that translates to a huge financial impact within those markets. However I’m very interested to see whether this kind of approach will extend to less commercial areas like the ones I highlighted above.

If you want to play around with Credify, here’s a referral link. Or if you just want to learn more, check out their very nifty home page. If this thing takes off like I suspect it will, I suspect there might be some advantages to becoming an early adopter.

Share

Report from the OpenStack PTG in Dublin

By , March 9, 2018 7:30 pm

Last week I attended OpenStack’s PTG (Project Teams Gathering) in Dublin. This event happens every 6 months in a different city, and is a fantastic opportunity for OpenStack developers and upstream contributors to get together and turbo-charge the next phase of collaboration.

I wrote a private report for my SUSE colleagues summarising my experience, but then Colleen posted her report publicly, which made me realise that it would be far more in keeping with OpenStack’s Four Opens to publish mine online. So here it is!

Continue reading 'Report from the OpenStack PTG in Dublin'»

Share

Abstraction As A Service

By , December 19, 2017 7:55 pm

The birth of abstraction layers

The last five decades of computing have seen a gradual progression of architectural abstraction layers. Around 50 years ago, IBM mainframes gained virtualization capabilities. Despite explosive progress in the sophistication of hardware following Moore’s Law, there wasn’t too much further innovation in abstraction layers in server computing until well after the dawn of the microcomputer era, in the early 2000s, when virtualization suddenly became all the rage again. (I heard a rumour that this was due to certain IBM patents expiring, but maybe that’s an urban myth.) Different types of hypervisors emerged, including early forms of containers.

Then we started to realise that a hypervisor wasn’t enough, and we needed a whole management layer to keep control of the new “VM sprawl” problem which had arisen. A whole bunch of solutions appeared, including the concept of “cloud”, but many were proprietary, and so after a few years OpenStack came along to the rescue!

The cloud era

But then we realised that managing OpenStack itself was a pain, and someone had the idea that rather than building a separate management layer for managing OpenStack, we could just use OpenStack to manage itself! And so OpenStack on OpenStack, or Triple-O as it’s now known, was born.

Within and alongside OpenStack, several other new exciting trends emerged: Software-Defined Networking (SDN), Software-Defined Storage (e.g. Ceph), etc. So the umbrella term Software-Defined Infrastructure was coined to refer to this group of abstraction layers.

Continue reading 'Abstraction As A Service'»

Share

Announcing OpenStack’s Self-healing SIG

By , November 24, 2017 4:15 pm

One of the biggest promises of the cloud vision was the idea that all infrastructure could be managed in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.

In OpenStack, most of the components required to implement such an architecture already exist, and are nicely scoped, for the most part without too much overlap:

However, there is not yet a clear strategy within the community for how these should all tie together. (The OPNFV community is arguably further ahead in this respect, but hopefully some of their work could be applied outside NFV-specific environments.)

Designing a new SIG

To address this, I organised an unofficial kick-off meeting at the PTG in Denver, at which it became clear that there was sufficient interest in this idea from many of the above projects in order to create a new “Self-healing” SIG. However, there were still open questions:

  1. What exactly should be the scope of the SIG? Should it be for developers and operators, or also end users?
  2. What should the name be? Is “self-healing” good enough, or should it also include, say, non-failure scenarios like optimization?

Continue reading 'Announcing OpenStack’s Self-healing SIG'»

Share

Panorama Theme by Themocracy