Agile 2017 (Part I)

This week I’m at Agile 2017, both as a speaker and as an attendee. Since I’m having such a great time I thought I’d share some of my experiences from the conference.

The conference

Agile 2017 takes place in Orlando, Florida this year and is a 5-day event with agilists from all over the world gathering to share experiences and learn.

I’d like to start off by highlighting what an open and welcoming conference this is. While I haven’t been to hundreds of these things, I have seen my fair share and Agile 2017 is unique in several ways. It’s a big conference to start with, with over 2200 people attending this year. Even with that large number of people, it’s surprisingly low-key. People are open to chat and mingle, are kind and show lots of respect. Finally, even though there’s groups of people from a large number of companies, they’re all very inclusive and open to others joining them. I’ve never before experienced this kind of atmosphere, not even at smaller conferences.

Major highlights

The major highlights from the conference so far were the keynotes from David Marquet and Jez Humble.

David kicked off the conference on Monday when he spoke about his experiences from his book ‘Turn this Ship Around’. It was an inspiring presentation about self-organization and leadership and engagement at every level of the organization.

Jez spoke about continuous delivery and while interesting to see up-to-date facts and figures (like that Amazon releases every 11.6 seconds on weekdays) most of it was familiar to me. Until he started with his bonus material: a 15-minute session in which he totally annihilated James Damore’s “manifesto” and highlighted some of the most important contributions women have made in IT. The audience was in full and total agreement, having given several rounds of applause and leaving some in tears.


I am a speaker at this conference, which I consider to be a great honor. Wednesday afternoon (3:45pm) was my turn and even though it was the third day of the conference at the end of the day, a sizeable crowd showed up to my presentation. The presentation went reasonable well (I made some last minute changes which, at certain moments, made it a little uncomfortable for me as I had to look up what I had planned next), interaction was good and I got some great feedback to improve the presentation even further for future speaking opportunities.

After having lived to this moment for months, after it being over me and a colleague celebrated (he had become a PST – Professional Scrum Trainer – that day) with a nice drink in the bar. Major milestone reached, up to the next one!


The conference is still ongoing with at least two great sessions still coming up. The sponsor area has just closed, which is a shame really as it was a great place to meet people and talk about this, but with the conference party coming up later today there should be no shortage of opportunities to mingle.

Once the conference is over I’ll share part two, so stay tuned for that.

The adverse effect of version numbers

“We’ll fix that in the 2.0 release!” Sound familiar? To me it does, as I used to say this quite a lot up until a couple of years back when I got introduced to Scrum. Around that time I drew the painful conclusion that version numbers may have a very adverse effect: to draw any software development into a waterfall-like process and postpone the release of value.

The problem with version numbers is that they are abused for something they are not. They’re not targets, they’re not milestones, and they’re definitely not a reason to postpone delivering value.

I’ve seen a lot of situations where version numbers were actually hurting a product, postponing any release for long periods of time. The worst example I’ve come across is no release for 7 years (and counting), which is for a 2.0 release for an immensely popular VPS control panel. Until this date, any fix or improvement is being “moved to 2.0” only never to be heard from again. Another example is a product heading for a 2.0 release that never even made it and got thrown away in the end. That was, after a timespan of about two years and at least 20 2-week Sprints invested (think of how much that has cost!). In both cases, and I have to admit these are extremes, no value was delivered (yet).

Value should be delivered very frequently, regardless of a version number. Bugs or defects should be fixed immediately and should never be postponed until a “version number release” or any other value release, because they are negative value. All a version number should be is a label on something that has been achieved in the past, like the time in which you’ve ran half a marathon or like velocity: an indication of what has been achieved in the past.

Version numbers are actually very useful if used properly, because they allow you to keep track of different versions of software, a document, or something else. But if you make them more than just a label or an indicator of something achieved int he past, the very frequent and adverse effect is that the delivery of value gets postponed.

The American Dream at Prowareness

I am in the very luxurious position to work at an amazing company called Prowareness. Prowareness is a company where you can make your ‘American Dream’ come true and I’d like to tell you more about that.

A short while ago I read a book in which the American Dream was explained in a very short and concise way: the freedom to pursue the ultimate individual happiness (whatever that may be). Two weeks later I was listening to a speech from our CEO regarding the growth of people within Prowareness. He wants Prowareness to grow and to keep growing. When asked why, he didn’t give the answer most people would expect (which was money). He explained he wanted to provide a platform or a movement in which individuals could grow, because the growth of an organization’s employees will accelerate the growth of the organization itself. So individual growth was the ultimate goal for organization growth. Followed by money, of course.

To me this is having the American Dream incorporated in Prowareness. Prowareness provides people with the freedom to pursue their ultimate individual happiness and Prowareness provides you with the tools and needs for that.

A great example of that freedom is the principle of Vision Groups. Every four weeks on a Tuesday afternoon all Prowareness employees gather in Delft and get one assignment: to not work for the next four hours. Instead, they get to spend time on any topic they’re passionate about. They get time to innovate, to explore, to talk to colleagues, to create new products, and most of all to learn. The effort spent on a Vision Group may eventually result in participation in a Dragons’ Den where people can win an investment of up to €25,000 in their vision. One of these visions has resulted in a new organization (under the Prowareness Group umbrella) called DevOn after having won the Dragons’ Den.

Naturally, we are not limited by the Vision Groups. We can spend time on personal growth whenever and wherever we want; the Vision Groups just provide a platform. There’s plenty of opportunity to grow and explore their our personal dream (for example by speaking at events or attending the monthly Guild session at Prowareness). The only limit is usually time, or sometimes imagination, but there’s people willing to help with that as well.

My American Dream is the American Dream and right now I’m pursuing that dream at Prowareness by taking the steps to expand Prowareness to the USA.

Why you should train your contractors

As an Agile coach I’ve had the chance to observe a number of organizations in both small and large training settings. With several of those organizations I’ve observed the same problem: the unwillingness to invest in their contractors and thus having them absent from trainings. Even if those people are part of the same teams as the organization’s own employees that are attending the training. Sometimes the contractors were literally sitting outside the room the organization’s own employees were getting trained in.

The people that attend the training often don’t like this either. They realize more than anyone how important it is to have the entire team aligned, be it on terminology, mindset or something else. They are the ones that have to do the work, they are the ones that a certain performance is expected from, and most importantly they are the ones that are going to be delivering most value.

A training is often a sizable investment for an organization as trainings don’t come cheap. On top of the cost of the training itself there’s the cost of not having those people at work during the day(s) of the training. For contractors these costs could be  considerably higher compared those of the organization’s own employees. But should the focus be on cost, or on return on investment? Isn’t it more important what the training will  bring the organization rather than solely what it costs? Why isn’t the focus on what value the training will add?

A strong argument I always see against training contractors is the idea that organizations have that such an investment will be an investment in a different company (namely the employer of the contractor). I think they couldn’t be more wrong. Those contractors work for them right now, meaning that’s where they’ll add value. That’s where the ROI of the training will end up and so the organization benefiting most from training contractors is the organization currently hiring them.

An organization’s growth is often linked to the growth of its employees and/or contractors. If people stop growing, either on a personal or a professional level, so will, eventually, the organization. In other words: not enabling that growth can be interpreted as deliberately holding the organization back, not training your contractors (as well) is a disinvestment.

So I would urge anyone who’s in a decision-making position related to trainings taking place at an organization to please also includes any contractors: train teams, not people.


SAFe: Scaled Agile Framework – or is it?

Last week I’ve had the pleasure of taking part in a Leading and Implementing SAFe course. During this four-day course I would be introduced to the Scaled Agile Framework, learn how to implement it, and learn how to share it with others.

To summarize the outcome of course in just one line: it sucked.

How is SAFe a framework?

To me, a framework is a light-weight set of boundaries within which there is a lot freedom to do as one sees fit. If you see the SAFe Big Picture you’ll understand my initial skepticism at the term ‘framework’. Nonetheless, I was looking forward to having my skepticism rebuked and to learn how to see and use SAFe as a framework. All this in order to be able to better help organizations that need scaling scale.

Whether organizations actually need scaling or a scaling framework is an interesting discussion. I think that if you need scaling you should first look at your products and your architecture. Self-organizing teams with the help of a clear vision and a good architecture can get a long way.

Unfortunately, the way I interpreted the way SAFe was put down this week was as a methodology. These are small selection of some of the concerns I have after having taken the course.

Let’s start with the roles: Release Train Engineer, our “facilitating” Super Scrum Master; Release Management, the Super Product Owner of the Release Train; System Architect, who together with the RTE and PM act like the steering committee of the Release Train (also, drawn above the teams, like hierarchically superior). All set and ready to go, all required.

The format in which work should be sent to the teams is also set for you: User Stories coming from Features or Enablers, coming from Epics; Enablers that are used for work supporting other User Stories or Features; and if you open the Value Stream level there’s something called Capabilities as well. Additionally, there’s a selection of templates available for most of these items to fill out. All having been done during the course and available from ScaledAgile’s website for your day-to-day use.

My biggest concern, however, was the ‘Agile Release Train’. Calling a Release Train ‘Agile’ when the recommended time-box is 10 weeks is beyond me. Sure, teams could release more frequently (and I quote, because of “individuals and interactions over processes and tools, and stuff”). But once you’ve seen the monstrous PI planning board with all its dependencies between teams you may wonder how that could ever happen.

In other words: my skepticism was not only not rebuked, it was definitely reaffirmed and has even worsened.

SAFe the way I would have liked to see it

If SAFe really is a framework, I would have loved to see it like that. Perhaps with a various complementary practices that would make it work for specific scenarios, in which alternatives to certain practices would have also been discussed.

The power of SAFe to me is keeping synchronized across teams and Release Trains in a larger organization, in which each release train is an independent part of the organization focusing on a specific product or value stream. There would be direct contact between the customer(s) and the teams in each release train, where each release train would have their own tools and practices to handle how work comes in. Whatever works for the teams should be the practice, not whatever someone else tells them to.

I love the end-of-increment Inspect and Adapt opportunity, but without all the practices that SAFe introduces and without the compulsory interval of 8 to 12 weeks. It’s great to inspect and adapt with a bunch of teams working on the same product or value stream, serving the same customers. Just like the PI planning: a high-level “planning” event which can be used to identify dependencies and remove them on the spot. I’d call it PI refinement rather than planning and I would never give commitment to finishing a list of work or reaching certain objectives for the next 10 weeks. I’d be doing my customer a disservice in nailing down what we’re going to do for 10 weeks rather than giving them the opportunity to take a different course at a shorter interval. But I like the synchronization nonetheless.

I’d have loved to see SAFe as an enabler for Agile at scale, because that is what organizations need. Practices come from experience and that’s where coaches come in: to help an organization find a practice that works from them, in which there is multiple practices to be compared. That is what SAFe (or any other scaling framework) should enable.


Looking at this constructively, I see SAFe as an intermediary step for very large and very traditional organizations towards true agility. I think it’s loads better than sticking to a waterfall-approach and if an organization implements SAFe the way I heard it, they’d be far better off.

To reach true agility you’d need to take a lot of additional steps. Mostly you’d need to experiment, see what works for your organization, your teams, keep inspecting and adapting and changing things if they make more sense. And to me, that’s the danger of a methodology over a framework: it makes things fixed rather than up for change. Whereas a framework should give you those boundaries in which your organization can shine.

A response to ‘Agile does NOT work!’

I recently read a blog post on LinkedIn from Oleg Vishnepolsky from DailyMail Online and stating that ‘Agile does not work’ and ‘And never did’. The blog contains some interesting statements and asks for responses. Well, here is one:

1) Short-term thinking that results from following short iterations and daily stand-ups

Where does this short-term thinking take place? Who does it? What have you tried to change that?

I think you do want your development teams focusing more on the short term when it comes to what value they should deliver rather than on the long term. That doesn’t mean the long term isn’t important though, and being agile doesn’t mean you should forget the long term either. It means you should use the frameworks, tools, and methodologies that allow you to respond to an ever-changing world.

In fact, long-term is quite important in order to be agile. You need to focus on quality and prevent technical debt. You should invest in test automation. You should focus on creating the right amount of documentation (be it code documentation, infrastructure as code or something else). You should invest in gathering and sharing knowledge. Those are all examples of the long-term thinking required.

If someone doesn’t think about these things, I’d say they’re doing themselves and their company a disservice. You should help them understand why these things are so important, especially when you want to be agile, and help them keep focus on them as well.

2) Architecture that often times can not be deployed piecemeal

What kind of architecture are you talking about? What challenges are you facing when trying to deploy your architecture? What’s the relation of this to being agile?

One could argue that delivery and deployment aren’t the same thing. I’ve seen cases where entire work-flow systems were being replaced and in certain cases that wasn’t being done one piece at a time, simply because it was either too costly or too complex. That doesn’t mean those teams didn’t work iteratively and didn’t go get feedback as soon as possible. It just meant the final deployment to production was postponed to such time where the work-flow could be implemented as a whole.

I do believe that there’s only a certain number of situations in which piecemeal deployments, for software, are extremely hard or impossible. But in order to do piecemeal deployments your application or architecture does need to support it. In most cases I’ve seen, piecemeal deployment is hard because the architecture isn’t right in the first place.

3) Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?

What kind of deployments are you talking about and what is blocking you from doing them continuously? What makes your infrastructure so complex you can’t deploy continuously? It could be your infrastructure isn’t ready for continuous deployments yet.

But yes, I believe every company can afford automation. Because every company that I’ve seen that doesn’t invest in it pays the price in the long term. They struggle rather than grow and have to invest in automation along the road anyway, but at an increased cost.

I would like to note that deployment should be a business decision. While you’d want your bug fixes out ASAP, I could imagine not wanting to change your functionality continuously. It’s perfectly legitimate to do some deployments every X weeks and introduce them properly to your users. I’ve had a company offer customers the option of either continuous deployments or one every 6 months. Those that chose the 6 months were still involved in the development effort and gave feedback frequently, but they only got the changes after they had prepared their staff for it.

4) Business expectations that they do not need to give you any requirements and that they can change their mind at any time.

I’m especially curious where this one comes from? How are development teams expected to deliver value without having any requirements? How are they expected to focus when they can change direction from second to second? How could the business be expected to be less involved when the development effort needs them to be more involved?

In my opinion the business has the responsibility to talk to development teams and explore the requirements together. Naturally they can change their mind at any time, but a proper preparation may prevent changes of mind down the road. Because changes of mind are often the result of questions being asked too late or too little, as new insights lead to new solutions. If you don’t have a transparent situation to begin with, how are you expected to inspect and adapt to that situation properly?


Yes, Agile is being used as a buzz-word and yes, there’s probably some Agile Coaches whom are in it for the money rather than to achieve true agility as meant by the Agile Manifesto. That doesn’t mean agile isn’t good or dead or whatever. Agile isn’t easy. Being agile isn’t easy. I do believe it’s the right option and the right way forward, but it takes time and continuous investment in order to be and remain agile.

A note to the author of the original blog post: my questions are genuine and I’d be more than happy to discuss these topics with you.

WebHostScene is live!

WebHostScene is live! It’s a website I started recently when I found myself needing to write a tutorial and to write about web hosting. There’s not too many content on it yet but that will definitely change over time.

Having WebHostScene means I’ll obviously spend less time blogging here. No worries though for those few of you that do like to read my occasional ramblings. They will still appear ever now and then!

For now, please enjoy WebHostScene and I’d love to get your feedback on it!

Getting started with LowEndSpirit

A couple of years ago we saw an interesting new concept pop up: LowEndSpirit! An IPv6-only VPS (with 20 IPv4 NAT ports) for just €3/year! That’s cheap beyond anything anybody had ever seen at that time and it did actually change the market (for the good and for the bad).

The idea for LowEndSpirit came from Anthony from Inception Hosting. He wanted to revive the original LowEnd spirit which was the reason for LowEndBox (and later LowEndTalk) to start. While these sites still exist, there is hardly anything left of the original spirit: doing as much as you can with very little. At that time the price limit was set at $7 and the VPS you could get for that had about 64MB RAM, some disk space, and some bandwidth. Not much, but enough to run WordPress on if you tried hard enough.

With these small LowEndSpirit boxes (priced very competitively) the intention was to bring back that spirit. LowEndSpirit grew from one location with one provider to 17 locations world-wide with 5 different providers. LowEndSpirit has become more than a label or a product: it’s a movement.

So what can and can’t I do with a LowEndSpirit VPS? Well, a LowEndSpirit VPS is perfect for a number of things. First and foremost they are great VPN boxes. There’s even an automatic installation and configuration script for it. Other than that there’s a great number of other things you can do with them: run a small web server, create a cluster of servers for different tasks, run TeamSpeak or Mumble, or even build a round-robin or HA cluster. Basically anything that fits the RAM and disk space but doesn’t hammer the CPU.

Things that you are not allowed to do with these is use them for torrents, CPU-intensive applications, tor, a proxy for downloading torrents, sending bulk email, and things like port scanning, (D)DoS, etc.

With that out of the way, let’s get on to this tutorial. This tutorial is here to help you get started with your LowEndSpirit VPS. I hope you have fun!

Before you start (and order)

LowEndSpirit VPS do not come with direct support other than in situations of host node issues and/or billing issues. These VPS require you to be able to diagnose and/or resolve problems yourself, with or without the help of the community and/or Google. There are no backups in place and sometimes not even RAID, meaning that if a host node (or drive) crashes you will have your container re-created and will have to restore data yourself.

If the above puts you off, reconsider buying a LowEndSpirit VPS. These are great machines at great prices, but you have to realize that you get what you pay for and they are not suitable for all uses.

IPv4 & IPv6 connectivity

A LowEndSpirit VPS does not come with a dedicated external IPv4 address. This means you will have to share one with other people, which is similar to what you have to do with some domestic ISPs. This means you can still access your VPS over IPv4, like a VPS with a dedicated external IPv4 address, though it doesn’t work out of the box.

A LowEndSpirit VPS does come with a dedicated IPv6 subnet (which is, ironically, more than most other providers will give you) meaning you don’t have to worry about IPv6 connectivity. In certain locations you even get a /64 subnet, which is the size of the minimum required assignment according to IPv6’s design.

You also get 20 NAT (Network Address Translation) ports, which means that for 20 port numbers the shared external IPv4 address is translated to your internal IPv4 address. The 20 port numbers you have are based on your dedicated internal IPv4 address, according to this schema: the last octet of your internal IPv4 address with 01 to 20 added to the end of it. Here are some examples:

  • has the following port range forwarded: 301 – 320
  • has the following port range forwarded: 1301 – 1320
  • has the following port range forwarded: 3301 – 3320
  • has the following port range forwarded: 13301 – 13320
  • has the following port range forwarded: 701 – 720
  • has the following port range forwarded: 1701 – 1720
  • has the following port range forwarded: 22101 – 22120

There’s one additional “special” port that you can use, which is number 21. This is set up (by default) to be the SSH port so you can log in via IPv4 right away. The schema is the same as the above. So if you internal IPv4 address is, your SSH port will be 3321.

You can use these ports freely, meaning you can configure any application to use them and then access that application over IPv4 using the shared external IPv4 address. Be careful with changing ports though, because if you change a port number it may be changed for IPv4 and IPv6, where your intention may only be to have an additional port number available for IPv4 access!

Great Firewall of China

A common occurrence is that people from China cannot connect to a Japan-based LowEndSpirit VPS because of the Great Firewall of China blocking your requests. This may apply to other locations as well. So if you live in China, be sure to check whether you are able to access a certain location before you order (or be aware of the fact that you may need another server to be able to connect to your LES VPS).

If you have issues connecting to your VPS it’s a good option to ask on the forums or in the LowEndSpirit IRC channel on FreeNode. There are always people around that are willing to help out and diagnose the issue.

Logging in for the first time

In the welcome email for your LowEndSpirit VPS there are several important things to remember, but only after having read the welcome email in full. Failing to do so may cost you money or may result in you ending up in an undesired situation due to different expectations.

So, after having read the welcome email in full, here’s some of the important information in there:

  • The login information to the control panel (usually SolusVM)
  • The list of external IPv4 addresses mapped to internal IPv4 ranges
  • IPv4 login information (in case you want to get started right away)

Logging in straight away

If you selected the right Operating System (OS) during ordering and remember the root password you entered there, you can log in straight away using IPv4. In this example I will use the external IPv4 address and assume my forwarded port range is 3301 to 3320 (meaning I can connect via SSH using port 3321):

ssh [email protected] -p 3321

This will ask you to accept the server’s SSH fingerprint (type ‘yes’) there and then ask you for your root password. Fill that one out and you should be logged in! Welcome to your LowEndSpirit VPS!

You can now skip to ‘Configuring IPv6’.

Setting up an OS using SolusVM

If you haven’t selected the right OS during ordering or want to change it, you’ll have to log in to SolusVM to reinstall your OS. The login information should be in your welcome email. Open the URL mentioned in there and log in with the username and password provided. You should now get an overview of your servers:

Click on the server you just ordered, which will get you an overview of the server’s details including all available options:

To reinstall the OS, click the ‘Reinstall OS’ button which should give you a list of available OS:

Select one and click ‘Reinstall’. Now’s the time to grab some coffee, as it may take up to 10 minutes for the OS to be reinstalled. Once done, you can log in to your VPS as described above in ‘Logging in straight away’ and then move on to the next section.

Getting to know your IPv6 address

By default you get a randomly selected IPv6 address, so there’s really not any setting up to do here other than grabbing the address from SolusVM. You may also customize it, but that’s no requirement.

To find out your pre-configured IPv6 via SolusVM (you may also do it from the CLI, but that commands for that may vary between Linux distributions) you can click on the ‘Networking’ tab on the VPS detail page in SolusVM, which will show you the following:

Click on the blue ‘Manage’ button behind the IPv6 subnet to go to the detail page for that subnet:

This is where your pre-configured IPv6 address is listed. You can use that to log in to your VPS as well, if you have IPv6. There’s no need to customize the port for that one. So, say your IPv6 address is …, you can use the following command to SSH into your VPS (using 2001:db8::ed4c as an example address):

ssh [email protected]:db8::ed4c

Things to do first

Once you have logged in to your LowEndSpirit VPS for the first time, there’s two things you should (or need) to do first:

  1. Change your root password (or set up sudo)
  2. Update your server

How to update your server depends on which Linux distribution you used. I’m going to give an example for Debian-based distributions and CentOS-based distributions.

Debian-based distributions

To update your Debian-based distribution (including Debian, Ubuntu), run the following commands:

apt-get update
apt-get dist-upgrade

The first command updates the package index. The second command actually performs the update. You will be asked to confirm after running the second command. Press enter to confirm the update.

After this update it is recommended to reboot your VPS by running:


That’s it, you server should now be up-to-date!

CentOS-based distributions

To update your CentOS-based distribution (including CentOS, Fedora), run the following command:

yum update

You will be asked to confirm the update. Press ‘Y’ and then press enter to confirm the update.

After this update it is recommended to reboot your VPS by running:


That’s it, you server should now be up-to-date!

In the above examples I’m assuming a certain level of knowledge. If you are completely new to this it is best to look up how updating your distribution works in your distribution’s documentation.

Setting up a domain name

This part only works on LowEndSpirit VPS from Inception Hosting. For other LowEndSpirit VPS providers, please see this thread.

Because your VPS does not have a dedicated external IPv4 address, your server is not (automatically) getting requests on all ports over IPv4. It only receives requests on those ports you have been assigned. This means that if you want to set up a web server and point a domain name to it, it will not (automatically) end up on your server given that port 80 (for HTTP) is not forwarded to your internal IPv4 address.

Luckily, there’s a solution for this. LowEndSpirit providers deploy HAproxy to forward requests based on a domain name to the right port on the right VPS. You can configure domain names you would like to have tied to your VPS in SolusVM.

On the VPS detail page there’s a tab labeled ‘Proxy Domains’. This is there you can add domain named you would like to have “linked” to your VPS. Once a domain name is set up here, you can use it on your web server on LowEndSpirit VPS like on any other server.

Here’s a screenshot of how this works:

You can add and remove domains here easily. It could take a couple of minutes for a domain to become functional.

Support for SSL is yet to be set up, so for now (if you want to use SSL) it cannot be done using port 443.

A note on the chosen OS

When you pick an OS for your LowEndSpirit VPS you are likely going to end up with either a Debian-based or CentOS-based Linux distribution. Some only offer the choice of three: CentOS, Debian, and Ubuntu (Debian-based). Others may also offer OpenSUSE or other distributions.

A good thing to know about Debian and CentOS-based distributions is that they come with their own package manager. As can be seen above, the update commands for both were different.

Debian uses the APT package manager which uses .deb files. CentOS uses the YUM package manager which uses .rpm files. You’ll likely not notice the difference of these file types when using the package managers, but they may behave quite differently. So be aware that when you run a CentOS-based distribution you will have to use yum and if you run an Debian-based distribution you will have to use apt (or apt-get).

It is good to know that between Debian 7 and Debian 8 and between CentOS 6 and CentOS 7, a major change was made on how the OS works. Whereas Debian 7 and CentOS 6 uses the init system to start the OS and manage processes, in Debian 8 and CentOS 7 both distributions use systemd. While this shouldn’t change much performance-wise (if any, it could be a little bit quicker), the commands used to restart processes is different.

Whereas before (on Debian 7 and CentOS 6) you would run the following command to restart NGINX (for example):

/etc/init.d/nginx restart


service nginx restart

On Debian 8 and CentOS 7 you would run the following command:

systemctl restart nginx

Please take the above into account when using your LowEndSpirit VPS and especially when looking for help (be it on Google or the LowEndSpirit forums).

Need help?

If you run into any issues with your LowEndSpirit VPS do not file a ticket! Tickets are only a last resort since LowEndSpirit is an extremely-low-support product.

First thing you could do is perform a search on the LowEndSpirit forums regarding your issue. The solution is not always in the first result, so take your time for this. If that doesn’t get you a solution, try Google. Again, it’s not always right there. It doesn’t hurt to peek around a bit.

If searching doesn’t get you a solution, considering posting on the LowEndSpirit forums. Be as descriptive as you can so people don’t have to ask questions as a first response but may come up with possible solutions. Always be kind on these forums as people volunteer their time.

If that fails, consider asking around on the LowEndSpirit IRC channel on FreeNode or other internet fora. Sites like vpsBoard, LowEndTalk, and WebHostingTalk have a lot of users that may be able to help you out.

If you are absolutely 100% certain there is a host node issue that cannot be resolved by yourself you could file a ticket with the LowEndSpirit provider you are a customer with.

The above may sound a bit harsh to those new to LowEndSpirit, but this service may sometimes be ran at a loss or break-even. This means that any time spend on support is very costly and you should only ask that from your provider if there’s no other way to resolve it.

Merry Christmas

I just noticed that ever since I’ve started looking for a new job in October 2014 I haven’t posted something on my own blog anymore. While I could go into all the reasons for this, I’d rather share with you what my plans are with regards to my own little website (especially put in the context of me having left my position as LowEndBox/LowEndTalk community leader).

So, here’s an overview of some of my plans:

  • Blog more often. Yes, really.
  • Build a “database” of quality yet easy to understand tutorials.
  • Blog about cars. I love cars!

Nothing is set in stone, but I’m pretty sure I can live up to this little plan and hopefully be of value to some of my visitors!

Merry Christmas!

Some unexpected downtime

Over the past few weeks, my website has been badly reachable. Apparently, I have pissed someone off by banning him from a forum I manage: LowEndTalk ( As a result, he has been pounding my IPv4 address with attacks resulting in the IPv4 being permanently null-routed. I’ve now moved my website to a VPS with OVH where it benefits from their standard DDoS protection. I hope this will prevent any further attacks from causing downtime.

A new actual blog post will be up soon.

© 2017

Theme by Anders NorénUp ↑