So now I've come to terms with whatever it is that is wrong, I have to find a solution to this problem. Before it's too late. I've got a start up now, responsibilities and expectations to meet. Failure is not an option.

I'm convinced challenging myself is still the only solution. The approach was wrong, that's all. Instead of seeking out intellectual challenges, I must venture out into the unknown. I'm way too comfortable with intellectual challenges. There's just not enough surprise and fun in them to keep me going anymore.

I've spoken with many people, mostly random people on the internet. It's a hobby of mine. It teaches me new things every time. People are hugely interesting. I've learned, for example, that there's a children's hospital in Cambodia with a leaky roof, and that one of the kids broke his leg while trying to fix it. You might say that information is completely useless to a Dutch software engineer, but you couldn't be more wrong. It brings personal stories from all over the world into your living room. The world becomes smaller this way, and you'll see that people are actually pretty much alike all over the world.

I haven't traveled much in my life. I wish I had. I've been to New Zealand twice. And I've been too Germany and Belgium. That's it. Really. There is no good reason for me to stay in the Netherlands, other than my work. Just like the trip I had planned this year. I was going to ride around Iceland. I couldn't because I had a start up that demanded my attention. It's been like this for the past two and a half years. The last time I had a proper holiday was back in 2009. Not a single week went by since then that I didn't spend time working. Just taking some time off would bore me to death. I need to have a proper reason not to work. It sounds silly, I know. The question becomes easier now; what should I do during my time off?

This has been the topic during many of my conversations online. I'm especially interested in what events have changed people profoundly. Next to the birth or death of a loved one, people often tell about their biggest adventure. For some it was a road trip through the United States, for others it was climbing the Kilimanjaro. It's not so much the deed that has changed them, but the people they've met along the way. The people have had the deepest impact on me during my travels and I didn't even know. Just think back when you were on your last holiday. The first thing you'll remember is that remarkable person. In my case, it's a Vietnam veteran who actually enjoyed the war. I'll never forget that guy. To meet other interesting people I'll actually have to hit the road. But to where exactly?

"Why not work down you bucket list?" asked a random person on IRC. "I don't have one" I replied. I mean, I've seen the movie, and more recently the adventures of Karl Pilkington. I know what it is, but I simply never made one. I've learned another thing that day. It's bloody hard writing your own bucket list. Plus, when you have it, it keeps changing because of all the awesome stories you hear. I've already done the boring stuff. I've done the bungee and skydive, I've got my motorcycle license and I've killed a homeless person. Actually, I'm not sure about the homeless part. The most fun I've had in the past few years is on a motorcycle. So many of my bucket list items will have some motorcycle ingredient in them.

1. Dakar Rally

I've always dreamed about this as a kid. Visiting the DAF museum with my parents, walking along those mighty Dakar trucks. I don't care much for races, but the Dakar Rally is one of the exceptions. Riding a motorcycle through some of the harshest conditions must be exhilarating. It must be a tremendous challenge, too. I understand I can't just do this tomorrow. This will need proper preparation, training and financial support. I want this too!

2. Mongol Rally

This I might actually pull off in the near future. It's awesome. The idea is to get yourself from London to Ulánbátar using a cheap car or motorcycle. And they're not kidding. For motorcycles, the maximum engine capacity is 125cc. For cars it's 1000cc. You know, the vehicles you'd normally use for your daily commute across town. My trusty Transalp is out of the question. Hell, anything I'd normally ride is way too big. So I'm looking for a couple of Honda VT125C, XL125V or CBF125 bikes. Yes, a couple. I'm not going to do this alone. 20,000 kilometers through deserts and mountain ranges is not something to be taken lightly. People have died during this rally, so I'd rather have someone with me to cry over my handsome corpse. Anyway, if I do make it all the way to Mongolia the bikes will be sold and the money will go to charity. Isn't that wonderful?

3. Lofoten and Iceland

Pretty much the trip I had planned for this year, with a little detour to visit the most beautiful place in Norway. Or so they say. This is my backup plan. If everything else fails, I'm sure I can do this no matter what. I've got the equipment, the health and the energy to do this. Maybe it's wise to do this relatively safe trip first before I plunge myself into the big unknown. On the other hand, going on a rally completely unprepared has its benefits too.

4. New Zealand State Highway 6

It's the most beautiful strip of tarmac I've ever laid my eyes upon. It goes from Picton, along the west coast of the south island to Invercargill. It's only 1,162 kilometers, but surely worth the trip. I don't have to tell you what I'll be using to see every meter of that road, right?

5. Chile Coast Line

Excluding the Antarctic coast line of course. Hop on a motorcycle, start in Arica and ride south along the South Pacific Ocean to end up in the southern most part of Argentina. Some parts of Chile just have no roads, so I'll have to cheat my way down south through parts of Argentina. Visiting some of the most sparsely populated areas in the world, this trip will be a once in a lifetime experience. Fuel is going to be the biggest problem I think. That's probably the reason why not a lot of people have tried.

6. Japan

I've never been there before. Its culture is vastly different from ours, and still familiar. I've got a few Japanese acquaintances, all of whom have told me that I have to come visit some time. And they're right. Why not? Of course I'll be using a Honda to ride my way through the country and see the sights. I've been told they won't just allow me to use any old bike I can find. Their regulations are even more strict than the new Dutch ones. But that won't stop me from trying.

7. Buy an Island

Yep. I want my own island. It doesn't have to be big, fancy or anything like that. I just want my own little piece of land surrounded by water. I've got no idea what I want to do with it once I have it. It's just one of those things everybody wants, but nobody actually tries to get. I've looked it up. Some islands are surprisingly affordable. Granted, they're a bit hard to reach and have no beaches, but that won't stop me from building a bunker on top. Of course my island has to be fortified. What's an island without proper defenses? I don't want those British imperialists taking over my island.

8. Get married, settle down and have kids

Who doesn't want that? A nice house, a beautiful wife and a bunch of great kids. I just know my life will be complete when I come home from work, the dog jumps up waggling its tail, my wife is in the bedroom with the neighbor and the kids are playing in the front lawn. Haha! I'm only kidding. There are only seven points on my bucket list that have survived careful consideration.

Speaking of cluelessness, the cyber prefix isn't really what I was planning to talk about. It's a lost case anyhow. The current state of the security industry is what I'm really interested in. Especially the companies that specialize in "cyber security". It's an interesting market, mostly because most of it shouldn't even exist. To clarify my statement, let me explain a few security basics first.

The biggest security problem is the user. An untrained user can be easily influenced by an attacker. Be it through a malicious email attachment, phishing or just simple social engineering. You'll be surprised how many people are willing to give up their password when I tell them I need it to "fix their internet". It's also the easiest attack vector. Even well trained people can be tricked into believing a well constructed lie. Good security begins with proper procedures, physical security measures and security aware personnel. Once you get that kind of covered, you can start worrying about the security of your digital infrastructure. The basics are rather simple. Everything that is not encrypted can (and will) be intercepted and/or manipulated. Do not trust data that comes from an unverified source. There can be no verification without proper crypto. Crypto is hard, don't try to do it yourself. Use publicly available, well maintained and open source implementations of public-key cryptography. OpenSSL, GnuTLS, GPG and OpenSSH are good examples. And even then, make sure you understand what you're doing. Private keys are private. Don't give them away in any way, shape or form. Obscurity never adds any security. White listing is better than blacklisting. Passwords are bad. Don't trust code you (and everybody else) can't read. With these basic rules in mind you can easily identify and fix potential security problems. It's not hard, it just takes persistence and an eye for detail. Don't assume third party libraries are trustworthy. Test those first!

Every IT professional knows these rules and follows them when implementing a new system. If not, it's hardly a professional. Replace people like that. Security is a part of the job. There's no need for external "security specialists". And now, here we are, with a hugely inflated market filled with companies claiming to add security to your organization with their products. Here's a rule of thumb; when a company tries to sell you security, they're lying. There are well established open source solutions for just about every security problem you can think of. All the other so-called security products solve problems that didn't exist before that company created the solution for it. These security companies apply FUD on a large scale to sell their products. It's having an effect on public opinion, and through that, legislation.

The Dutch situation is interesting, because certain companies have teamed up with executive and legislative parts of the government to form one the worst FUD campaigns in recent history; cyberwar. Public opinion is manipulated by companies like Fox-IT through mainstream media. Most media outlets seem to be too lazy to check their sources, and are happily copy-pasting everything Fox-IT tells them. And boy, do these guys suck. I often cringe whenever I see one of their "cyber security" professionals on TV. One mistake after another, completely disregarding aforementioned security basics. Year-old security topics are presented as news and proof of their prowess (Mifare, etc). Just a few gems from their website.

Most organizations are aware of the importance of a sufficient and comprehensive IT security infrastructure. However most of the time no precautions are taken for mobile telephony despite the fact that confidential and sensitive information is communicated over the air and can easily be gathered by listening in on these mobile conversations. [...] The SecuVOICE smartcard with integrated crypto-component (chip) encrypts your voice conversation. This prevents anyone, including telecom providers and intelligence agencies, from intercepting your private conversation. This solution will make sure your confidential information stays secret.

They really don't get it, do they? GSM's A5/1 was compromised because of a lack of peer review. This, in turn, was caused by the industry's choice to keep it a closed standard. The Fox-IT solution is replacing the old closed standard with a new closed crypto chip.

Cybercrime is becoming a growing threat to society. In the battle against digital crime Fox-IT has pooled its knowledge in its Cybercrime unit. This special unit monitors and prevents cybercrime, helps organizations and authorities to be prepared, and investigates incidents. Fox-IT offers these services mainly to authorities, financial institutions and critical infrastructures, but they are accessible to every organization.

I have no words for this. Hi, I'm the security guy. Please eat my FUD an buy my ridiculously expensive products!

And look at this. They say it's used to secure state secrets with. Closed security soft- and hardware is being used to secure my personal data. These things can be replaced by RSA (there's a number of well tested chips out there), TrueCrypt and GPG. All of them actually secure enough and above all; free as in both beer and freedom!

There's another company which I hear about every now and then. It's Unit 10. They're the guys who the police hire when there's some cyber work to do. Just click the "Secure Login" button on the bottom of the site and try not to laugh.

To top the entire security theater, there's @Byte_Fighter. The toughest cybersheriff the internet has ever seen. He's just the guy who's responsible for fighting the good fight in the cyberwar. I kind of feel sorry for him. He's obviously a nice guy. Hell, he even likes Blackfield. I think the prosecutors office had to appoint someone, and Lodewijk pulled the shortest straw. He tries so hard to fit in, but fails miserably.

To accomplish this renewed intellectual challenge I need to find something, well, challenging to begin with. As a self proclaimed polyglot I like to venture out into the big black beyond where the less main stream programming languages, methods and trolls^Hcommunities can be found. It was during one of my quests I came across a little village named Google, where well spoken men (I haven't seen any women just yet) had acquired a new programming language named Go. I had heard of it before, but never tried to learn it. Normally I would not touch anything Google with a ten foot pole. But then I saw this familiar name; Ken Thompson. Unix people may simply refer to him as "God". I was told he prefers "ken", but I digress. He is the creator of the second-best language I ever used. I love C for it's simplicity and expressiveness. I also hate it for loading the gun so many times before I aimed it at my foot.

With a new tool to play around with, half the preparation for my intellectual challenge was complete. The other half is a project. Something that explores the most interesting aspects of the tool, while staying relative and above all fun. Go is a systems language. It can be used to replace C. It compiles right down to an executable. It's fast, or it has at least the right background to become as fast as the current contenders C and C++. And staying true to the Unix philosophy, I want to create something that does one thing and does it really well.

I love Ruby. There. I said it. Get rid of all those nasty prejudices, I don't fit any of those. Alright, I'm a little elitist, I'll give you that. My interest in this programming language and its community brought me to CodeBrawl. It's a really neat website that holds a programming contest every week for the Ruby community. It's usually a simple task which enables fellow Rubyists to show off their mad skills while keeping it understandable for newcomers. Last week's contest involved a terminal administration tool. I started working on my idea, but quickly ended up with a fully fledged IRB replacement. It wasn't anything near the scope of the original contest anymore, so I didn't participate. It made me curious though. How hard could it be not to replace IRB, but replace my default shell all together?

The shell, Bash in my case, is one of those tools that makes a Unix-like operating system so powerful. I usually just take it for granted. It never occurred to me to find out how the damn thing actually works. It manages your terminal, your environment, helps you execute things, embeds a fully functional programming language, does some completion magic and the list goes on. The shell is basically the glue that keeps Unix together. So for me to write a replacement for it seems like a slightly daunting task. I can use my experience in creating a programming language from the (now stagnant) JBISC project, I can use Go and I'll learn a thing or two about Unix in general.

So in short; I'm going to try to write a Bash/Zsh replacement using Go in my spare time. Which I don't have any.

I'll use the democratic uprising in Tunisia as a starting point. It's a classic example of a corrupted state being reset in its cycle of corruption. All states go through this cycle. They have been going through it for millennia. It kind of goes as follows; the people live in freedom, freedom and its inherent free market causes inequality, the people only object to the inequality when it's too late, oppression takes place, followed by a popular revolution and the cycle resets. This happens on every scale within society. Because of globalization, societies have scaled up to the point at where we can't truly speak of individual municipalities anymore and at the same time a global society is taking shape.

Every single country on the face of the earth is interconnected. We're already part of an international society. This mega society is not exempt from the aforementioned cycle. The first signs of inequality on a global scale have been evident since the end of the second world war. The western capitalist empire has successfully placed itself on top of the economic food chain, with its most rich and powerful figureheads pulling the strings. Freedom, and as a result, democracy, has been slowly eroding under the pressure of multinational business interest. The revolt has started already in the most oppressed regions of the global society, setting things in motion nobody can stop. The people's wheels have begun turning again. Revolution is inevitable.

I'll try to describe a possible series of events triggering the global revolt I've predicted. I don't know if these things will take place, but the end result will be undeniable. This is just one of the plausible courses our society can follow to eventually end up resetting the cycle.

We'll go back to Tunisia. Because of international communication networks like the internet the spark of revolution quickly spreads across to like minded people in similar situations. After Tunisia, Egypt, Libya, Bahrain and Yemen the popular uprising strikes Saudi Arabia and sweeps across the rest of the middle east and (northern) Africa. With unified political and social revolutions the Arab nations form a collective, effectively crippling western control over the region. This new Arab block liberates Iran merely by being there, as a bastion of a new democratic hope. Tensions in Israel rise while the Palestinian people call for the new Arab block to intervene. Israel is forced to retreat from the occupied regions by the united Arab nations. Because Israel doesn't comply with the Arab demands, oil supplies to the nation are cut off. The United States heavily protests and sends in its navy to supply oil to Israel. Western companies working on Arab oil fields are sent home and Arab oil is nationalized. This causes the United States to use its military force in the region to reclaim the major Arab oil fields. Many people die in one of the most bloody campains in the regions since the second world war. The war did not only cost lives. The federal deficit of the United States reaches a critical tipping point. Because of the oil shortage and the weakened state of the United States economy, the stock markets crumble and the United States goes into another depression. After the United States, Europe and Russia soon follow. The United States military is called back to fend of the first major domestic democratic uprisings. The European Union falls into disarray, fails to manage the quickly evolving situation and individual member states take the law in their own hands. The civil war in the United States is long and bloody, spreads to Mexico and Canada and results in the creation of several new countries. Individual European countries go through both left- and right-wing coups, resulting in a scattered landscape of dictatorships and democracies. The island nations of Australia and New Zealand go though similar popular revolts after their governments fail to address the new economic hardships. Meanwhile, developing industial nations like India and China find their main source of income depleting rapidly. India fails to maintain unity after civil war breaks out. First between the government and the people, later between different factions. China undergoes a popular uprising as well, but eventually fails to uphold democratic values. At the same time China falls, the people of the two Koreas join forces in popular revolutions against the capitalist and Stalinist regimes. They join the newly formed democratic socialist pact that used to be Russia and Eastern Europe. China and parts of India join the pact.

The world has changed. North America is decimated, the new democratic countries slowly industrializing their economies. Latin America continues its conservative socialist agenda, radicalized by the crisis. Western Europe has a hard time rebuilding its countries without foreign aid, and the new democracies are promising but fragile. The huge socialist democratic pact of Russia, China and India dominates the world economy. Many people from Europe, Australia and New Zealand migrate, while former Indonesia becomes a large collection of small island states. Many of them join the new Arab democratic collective. With the marginalization of foreign aid, central Africa is hit by famines and epidemics. Millions of people die each year, causing continuous civil unrest, quickly spreading south.

The post-western world might look bleak, but to me it's a great new start. Many young democracies will be formed in the void the western capitalists leave behind. It's a cleansing, albeit shifting world power to the current industrial giants China and India. Again, this change is inevitable. If the course of events will be just like these, I don't know. But mark my words. Something really big is about to happen that will eventually involve everybody.

It all started in the spring of last year. Motorcycle instructors kind of assume you've already got a car license. Since I'm a stubborn guy I decided I had to learn to ride motorcycles first. Because of that, I didn't understand the basics of operating a petrol engine. I knew how it works technically, but I had never operated one in my entire life. So, unsurprisingly, I failed to display any skill during the intake test. I kind of fumbled about and slowly lost all hope of learning how things were supposed to work within the time frame I had imagined. But no worries, the instructor said he was convinced he could teach me to get that motorcycle do useful things. All of this was done on a restricted (25kW) Kawasaki ER-5, by the way. It was modified to allow the passenger, which in this case was the instructor, to override both the clutch and the brake leavers. I'm glad those were installed, or else I might have pulled a wheelie on my first day.

After the intake we agreed on a lesson plan. Because the instructor had no idea how many lessons I needed to pass the first of the two practical exams, we agreed that I would get the theory certificate first. That way I could immediately hit the road after passing for the first exam. For people who are unfamiliar with the Dutch motorcycle courses, it works as follows: You take three exams. Theory, agility and traffic. The order of the first two doesn't matter, but you'll have to pass both of them before you're allowed to take part in traffic. It's a pretty sane safety precaution. The theory exam was a breeze. Of course I barely made it, but I wouldn't expect anything less of myself.

The course prior to the agility exam was a little harder. We had the roof of a parking facility for our low speed maneuvers. To make matters worse, or better, depending on who you ask, they've upgraded the bikes to unrestricted Kawasaki ER-6n's. These little naked bikes pack quite a punch. Nevertheless, it was a lot of fun riding figure-eights and doing other tricks. It builds confidence, which is important on the road. I don't think many of the maneuvers were that useful in real life, but they help you getting to know the bike's dynamics. I especially enjoyed the emergency stops. You weren't supposed to lift the rear wheel, but I did anyway. I've been playing on that roof throughout summer, perfecting every exercise they had in store for me. Because of the hot summer last year, the motorcycle did overheat every once in a while. The exam went okay-ish, and I barely made it. I still don't know why I made all of those mistakes back then. Lucky for me, the examiner let me pass anyway. I guess I have my instructor to thank for that.

With the two exams done, I was ready to hit the road. It was exhilarating at first, until I hit traffic that is. I've been riding bicycles all my life, and I thought traffic on the main roads wouldn't be that much different. I couldn't be more wrong. Everybody seems to be in a hurry, and there's always a single car going 10 Km/h slower than the speed limit. The driving skills of many of the people I've met during my lessons were, well, lethal. I had to learn the hard way how I have to anticipate everything in a split second before entering a situation. On a motorcycle, you're barely visible to the sleepy car driving companions around you. I've had several near-accidents during my lessons. Of course you're right when you say I'm partly to blame for those situations. I should have seen those situations coming. Because of my inexperience and bad judgement I failed the traffic exam twice. The CBR (the Dutch organisation responsible for the drivers licenses) is known for it's slow bureaucratic way of doing things, and it's getting worse every month. This, and the fact 2010 was a very snowy year, caused months upon months of delay. That's why I've only been able to pass my exam last month.

During all of this delay, I've had plenty of time to look around for candidate motorcycles. I had kind of set my mind on a KTM 990 Adventure, but buying an apartment and furnishing it completely turned out to be a bit more expensive than anticipated. So I could buy a second hand KTM of questionable quality, or I could buy Honda's new Transalp. I had a few use cases in mind. It had to be practical (e.g. it had to be able to carry me plus luggage), it had to be able to do both 20 Km home office trips and thousands of kilometers on a holiday. Oh, and preferably black of course. Just before my exam I found a black 2010 Transalp in Veldhoven, not far from where I live. It was brand new except for a few months of modeling work in the company's show room. The same day I received my drivers license, I went to the dealer to test ride a Transalp. I was impressed, and almost immediately decided to buy one. Even though I tested a 2008 occasion, it just felt right. The luxury of that Honda is a far cry from the cramped Kawasaki ER-6n I was used to. A few days later, at the same time a friend of mine bought his car, I bought my very first motorcycle.

Even though it was money well spent, I'm far from finished spending money on this thing I'm afraid. I've got a list of parts I'm planning on adding to this bike during my ownership.

Bought:

• Honda Transalp XL700V ABS Pearl Concours Black 2010 (0KM - 2011 license plate)
• Honda center stand
• 12V kit
• TomTom Urban Rider Pro
• Givi D313S windscreen

Todo:

• Continental TKC 80 tires (Rear: 130/80/17, Front: 110/80/19) to replace the stock Bridgestone Trail Wings (aka Death Wings because of some people dying because of them, apparently)
• Touratech long-distance footpegs
• SW-Motech EVO side carrier
• SW-Motech TraX EVO M. 37 L panniers
• SW-Motech HAWK fog lights
• Touratech headlight protector
• SW-Motech crashbar
• SW-Motech engine guard
• Touratech throttle cover
• Touratech radiator guard set
• Touratech mudguard flap
• Honda heated grips
• SW-Motech 30mm bar risers
• SW-Motech 12v tank bag

The Transalp after I just got it. After more modifications have been done I'll upload another photo.

The Qnap is wonderfully stable running Debian, and it's doing it's job next to my other new acquisition, an HP Microserver. It replaces my old IBM System x3200 as a home server. Everything fits nicely in the meter cupboard of my new apartment.

There are a few advancements in work lately. I'm about to start my own company, I've released my Sinatra-based web framework to the public and I'm still working on two appliances. A monitoring, and a social torrent application.

I've got a new laptop as well, a Lenovo T410s. It's a great machine, and everything seems to work pretty well. It's running Debian of course. Too bad the same can't be said about the docking station that comes with it. Not a single Linux driver (neither Intel or Nvidia) is capable of using the two digital display connections on the docking station. I'm looking at a nice dual 24" setup, with only one screen working. RandR support is well, not that great either. I can't wait for some advancements that would make X11 a thing of the past.

I hope I've got more news to write on this site every now and then. I've been rather busy lately with work related stuff. I will be getting my motorcycle license next year, but judging by the current weather forecasts that'll take a while.

After receiving the unit the problems started. The first thing I noticed was that the web interface uses Flash elements to draw certain graphs, while using HTML5 canvas for others. The QNAP is packed full of nice features, like WebDAV, Apple and Microsoft Networking support. None of which I'll ever use. NFS works, kind of. It's basic NFS but without the bells and whistles you'd want to have as a seasoned sysadmin. There's even an application for video surveillance. I almost died when I read the message it threw at me. I needed Internet Explorer 6.0 or later to use that functionality. QNAP? It's 2001 calling. They want their software back.

Anyway, when you disable everything down to the bare minimum you've got a fancy web interface for the Linux NFS server and software RAID. You're even allowed to SSH into the Linux install to take a look around. It's a simple, but appropriate Linux environment with a slightly tweaked kernel and Busybox core utils.

At this point I was content with the TS-410. A simple NFS appliance, happily humming along. Until it fell of of my network that is.

I still don't know what happened. I wasn't doing anything with the thing when it crashed. I can't get it to reconnect. It boots, it clearly initializes the network interface. But then, nothing. No DHCP request, no activity what so ever. Even after reboots and hard power cycles the thing doesn't come back to life. It does boot without it's disks, however. But when I plug in the disks like it's asking, it crashes again. The disks are fine, by the way. My guess it's a kernel panic of some kind. The power button doesn't respond either, so that means either init is waiting for something or the kernel has died.

The first reaction of embedded software engineers is to grab the nearest screw driver and undress the thing to it's bare minimum to find a known interface we can work with. (Our methods with women are surprisingly similar by the way). This specimen has two free 4-pin I/O headers, a 2-pin empty jumper and a wide I/O header for the front buttons, LEDs and so on. Since this thing has a Marvell Feroceon 88F6281 on board, it has to have some kind of serial tty headers on the board somewhere. My bet is one of those two 4-pin thingies.

After searing the web for a few minutes, I came across a very familiar name. Martin Michlmayr, of FOSDEM fame, has been working on getting Debian to work on the QNAP TS-410! Having Debian on my storage box makes it so much better. According to his page, I was looking in the right direction. One of the two 4-pin headers allows for a serial terminal which is activated by connecting the two jumper pins. Too bad it's not RS232. It's a 3.3V TTL, which needs to be converted. I've ordered a universal shifter from Sparkfun to get the job done.

When I get the shifter I can finally find out what keeps the QNAP from booting properly. Afterwards I'll install Debian.

To be continued.

All of the old blog content has been migrated from the old Wordpress database to individual markdown files. The entire site is managed using Mercurial. Every time I push to the server, the entire site is regenerated. I'm sure this site will survive a slashdotting now.

As you can see, it's HTML5 with some CSS3 magic. If you can't read this properly, please update your browser. I've tested this using Chromium 6.0.472.59 and Firefox 3.6.9. If you're using a recently updated open source browser and this site looks like crap, please let me know.

There's some really neat stuff I can do with this. I've even got syntax highlighting out of the box!

 1 module Fucking
 2   class Awsome
 3     def self.man
 4       "You're the man!"
 5     end
 6   end
 7 end
 8 
 9 the_man = {
10   :who => Fucking::Awsome.man
11 }

Neat, huh?

Using Bluetooth and a PPP connection to be exactly. Debian doesn't make it easy for you, but it has all the tools you need to get this stuff to work. You'll need the standard Bluetooth utilities and a PPP dialer. We'll use wvdial because we're lazy, okay? Feel free to fiddle around with pppd yourself.

apt-get install wvdial bluetooth
/etc/init.d/bluetooth restart

Before we can do anything, you'll need a service listening in to help with the PIN authentication process. You only have to do this once usually, so run this in a separate terminal. Debian, and many other distributions actually, kind of forgot to supply the default authentication agent that comes with bluez. There's an example script that kind of does what we need to do, so we'll use that. When your phone connects for the first time, it'll ask for a PIN. Just enter your favorite four numbers and do the same when the example script asks for it. Just run the following command.

/usr/share/doc/bluez/examples/simple-agent

Now we've got the software we need, let's start by connecting to our phone. You'll need to know two things. First, the name of your phone and second, the fact that it's actually listening for incoming Bluetooth connections.

hcitool scan

Is your phone in the list? Great, remember it's MAC address or save it in an environment variable. We'll need it later on.

hcitool cc $MAC

Now you've connected your phone's Bluetooth device with your machine's. The next bit is required to check on which channel the dial up networking service is listening.

sdptool search --bdaddr $MAC DUN

It should list the channel number. If it doesn't, your phone doesn't allow you to use it as a dial-up modem. Save that number. We'll need it again. $CHAN will do. The next bit (we're almost there!) connects the Bluetooth device to a serial modem device called rfcomm0. You need one in order to use software dialers.

rfcomm bind 0 rfcomm0 $CHAN

Now we've got a serial modem, we can get to the tricky bit. I personally don't understand every single statement used to dial into the KPN internet service, but here goes. Put the following in your /etc/wvdial.conf:

[Dialer kpn-nokia-bt]
Modem = /dev/rfcomm0
Baud = 3600000
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1, "IP", "internet", "0.0.0.0"
Modem Type = Analog Modem
Area Code =
Phone = *99#
Username = KPN
Password = gprs
Ask Password = 0
Dial Command = ATDT
Stupid Mode = 1
Compuserve = 0
Force Address = 
Idle Seconds = 0
DialMessage1 =
DialMessage2 =
ISDN = 0
Auto DNS = 1
New PPPD = yes

Most of it is understandable, but the Init* sequences differ from provider to provider. The last step is to run the dialer. Keep this application running, and you'll have an internet connection. Just make sure you haven't got any other connections active. It'll mess up the default gateway.

wvdial kpn-nokia-bt

There. An internet connection. Go download some porn^H^H^H^Hopen source software.

During my few years as a software guy, I've come across three distinct types of software people. Software engineers, code monkeys and pretenders. Everybody in my field of work is one of those three. There's no in between, no gray area. It's almost as if it's genetically predefined. Maybe even hereditary, who knows. Everyone who has worked on software projects for longer periods of time with the same people will recognize the three stereotypes. I've come across these three in both commercial and open source projects. In this post I'll try to examine the three types, and tell you how you can make use of the individual qualities while staying clear of the weaknesses.

The software engineer is the guy who has defined the geek stereotype. The not entirely socially accepted people, you know the type. Some of them even fit in the inflated stereotype, including mom's basement and the lack of sunlight. Software engineers have been tinkering with some kind of technology since way before their education began. They love to create and improve upon things. They excel at it. They've got deep knowledge in their field of expertise and have at least a few other cards up their sleeve. With this type, education doesn't mean squat. It's worthless. They usually teach themselves whatever they need to know. If they're not convinced they need to know something, they won't even try. Some of the best engineers out there haven't even finished high school. Forced education will demotivate them into leaving your organization, or worse, sending your organization into disarray. Even if you know they're wrong, the best way is to let them find out by mistake by themselves. This way the all important geek ego doesn't get damaged. The geek ego is the only thing driving the software engineer. Don't try to erase it. You'll end up with a passive and ultimately useless employee. The best way to put that ego to good use is to put the engineer in an environment where he can both look up to people to gain more knowledge, and look down upon others to inflate his ego. Beware when mixing engineers. There are loosely defined groups of engineers out there. The borders are defined by dull things like choice of editor or code indention guidelines. These things might not interest you much, but to the engineer it's more than a religion (there are some nutters to look out for!). Next to the ego, the level of motivation is defined by the amount of innovation in his work. The engineer needs to keep innovating, or else he'll lose interest in your project and work on his own in your (valuable) time. If you want to create new solutions, you need these people. The initial investment might be a little steep, but you'll end up with a better solution in the long run. I've seen project leaders make the same mistake over and over again. The decision to skip engineers when initializing a new project will come back to haunt you for the rest of the project's lifetime.

Unlike the software engineer, the code monkey has learned his trade in the educational system. He wanted to do "something with computers" and ended up getting a software engineering degree. These are your typical loyal nine to five employees. They know exactly what they can do and they'll be happy to give you a CV. As long as you put them in a position where they can use their already gained skills they'll do their work pretty well. They won't be as fast or as good as the engineers, but they're constant and reliable. Surprisingly, the work they do hasn't that much effect on their motivation. A constant supply of coffee and a socially interactive workplace will do fine. Code monkeys are great at communicating with your customers, managers and everybody in general, really. Unlike software engineers. You need code monkeys to translate between users and software engineers. Don't be tempted into letting them actually design the desired solution. They'll manage to get something working, but it'll be sub-optimal and badly implemented. Make sure a software engineer makes all the important technical decisions. When an engineer comes up with something that doesn't match the code monkey's CV, you'll have decide between two options. Get a new set of code monkeys, or, if possible, educate them using in-house or external experts. Software engineers often lack the skills to teach new tech to code monkeys because of the inflated egos. So don't even try to make that work. The great thing about code monkeys is that they appreciate education and actually consider it a positive attribute of your organisation. You can only educate them to a somewhat decent level. Monkeys will only do just enough to be able to work with the new tech. The software engineers leave another big chunk of work next to communication and specification. Monkeys are absolutely vital in testing and maintainance work. These things aren't challenging enough for software engineers, so you'll need a couple of code monkeys to keep your project running on the long term.

The third and final type is the pretender. These are dangerous. As the name implies, they pretend to know the programming trade. Every time the software branch regains market share after a dip, a new influx of these wannabes floods the job market. They come from all sorts of jobs. I've seen carpenters, truck drivers and garbage men applying for a job. Lured by promises of a large paycheck offered by companies actually looking for experienced software engineers, they bluff themselves past clueless HR departments into software engineering teams. If the team is big enough, they manage to stay employed for a considerable amount of time. It's important to have a mandatory trainee position before actually hiring people. I wish it wasn't necessary, but the pretender made it so. Some of them are real professionals in bluffing. I've even been tricked into accepting one of those. They know all the correct terminology and know how to use it. They usually come across as friendly, compassionate code monkeys. It's only when you let them produce code they'll show their glaring inability. This is more of a tip if you're in HR. Ask your software engineers for a programming test, and let them review the applicants. That'll filter out most of the pretenders.

Now, back to the case of the code monkey. Although essential, there's way too many of them these days. The amount of capable software engineers is reducing. Rapidly. I don't know exactly what causes it, but I've got a hunch. The modern educational system isn't engineer-friendly. You're rewarded for being a code monkey. Engineering isn't something that is rewarded anymore. Too much standardization, compliance regulations and programming guidelines have crept into education along the years. Tools initially created by engineers to give code monkeys a decent working environment are now working against the engineers-to-be. We need more research driven education to give engineers a chance to both get a degree and learn some new tech while they're at it. I've seen too many people with a decent set of skills leave the educational system, just to escape the constant brain battering that's taking place at the moment.

This may come as a surprise from a long-time FSFE, EFF and FFII supporter. I really don't think the Pirate Party is a good idea. As a matter of fact, I think it's a very bad idea to be honest. There are a few things wrong with it, which I'll try to explain one by one.

It's a one-issue party. I absolutely detest one-issue parties. They contaminate the democracy by ignoring important issues that just have to be dealt with by the government. The worst thing you can do with a problem is ignoring it. Voting for a one-issue party makes sure your vote only counts for that single issue. For all of the other issues, some of which even more important than your favorite subject of debate, your vote contributes to the group of representatives abstaining. In other words, your vote keeps a larger part of the people's representation in government from doing it's job. You can't just assume all of the other governmental problems will be dealt with in a proper way. It's your duty as a citizen to make sure your vote actually represents you. If you don't care about anything, don't vote. One-issue parties are, in my opinion, even worse than not voting at all. It's okay to kick the status quo every now and then, but utterly destroying a perfectly functional system is one step too far.

So let's see what the Pirate Party thinks about health care. Nothing. Or what about education? Not much. The economic crisis? The Pirate Party couldn't care less. This is the proper way to look at the party. Just imagine a government run by the Pirate Party. It would be absolute chaos. Nobody would care a hoot about you. Just the safety of your personal information. Nobody would care about job security, just the intellectual property it generates. Infrastructure? Yes, some fiber optic cabling maybe. But they can't be bothered with roads or plumbing. The entire government would cease to function, cease to exist. This is not how democracy was intended.

All bashing and gnashing of teeth aside, I do agree with every single point the Pirate Party stands for. I completely support their efforts. I'm quite the proponent of privacy and open innovation. Ask my boss. I just don't think a political party is the proper way to complete their goals.

So how should they, you might ask? I'd suggest joining a political party closest to your ideals and trying to use it's internal democratic structure to promote your agenda. I think, hell, I know, many of the people within the Dutch Socialist Party will agree with most, if not all of the points citation (dutch). I'm not trying to lead a half-assed slander campaign against the Pirate Party in favor of my own political background. Quite the contrary. I'm trying to save the democracy the Pirate Party upholds as one of it's core ideals. And, maybe more importantly, we need their help! All of the "main stream" political parties have less and less interest in upholding citizen's rights. And I have to admit, even my own. Raising public awareness will make privacy, open innovation and strengthened citizen's rights part of the political agenda again. As it should be.

So in short, I think there's a lot an organization like the Pirate Party can achieve. They're just using the wrong tool for the job. I wish them the best of luck.

People who have read this blog before (yes, all three of you!) might know where I'm going with this post. I'll try to keep this as neutral as possible, and I'll try to refrain from any biased negative comments towards the educational system. I initially wanted to list all of the useful things I've learned during my time, but that would make this post awfully short. I'll just make this some kind of chronological report of all of the things I remember of the past four and a half years.

Back in the day I knew exactly what I wanted to do. I wanted to combine computer science with a bit of engineering and electronics. Luckily for me, the Dutch educational system offered a four year course teaching exactly that. Although, in hindsight they didn't, but that's beside the point. I visited the school a few times to make sure my cash ended up somewhere worth while. A few teachers seemed to be quite competent, so I decided to enroll.

The first two years were a breeze. Most of the stuff was actually quite easy. None of it was interesting, compelling or even slightly useful. There might have been a few exceptions to this rule. I remember learning C++. It's an odd choice for a programming language. You have to keep in mind most people attending these classes haven't written a single line of code in their entire life. Throwing C++ at them won't make much of a difference. So all of the people who didn't already know how to code automatically left. After the first two years, more than half of the students had left. Which was a shame, because some of them were quite smart and clearly possessed the required talent. But the educational system didn't motivate these people at all, so they dropped out. Anyway, back to C++. It's a great language, once you get the hang of it. It has a huge learning curve, which makes it absolutely useless as an educational language. If your goal is to teach people some programming basics, grab a language that's accessible to novice programmers. In that respect, almost any language would be better than C++. I'd suggest Lua, Ruby or Python. Pascal used to be a good choice, although the world has passed that era a few eras ago. It got even worse by the way. Students initially started out using Borland C++, creating nifty win32 GUI point-and-click applications. That's no way to learn a language. Only afterwards people learned an application didn't necessarily come with a GUI. After C++, and if you were able to write C++ on paper during a test, you could go on to the advanced course. C. Yes, you've read that correctly. C. It's like learning how to construct a roof before you've learned how the foundation works. Instead of teaching that C++ offers methods to easily work with strings, you learned that C lacks those and works with character arrays. Throw some pointer magic in there while most people didn't even grasp the difference between for- and while-loops, and you end up with total chaos. The very basics of software engineering, e.g. writing software, were neglected to a degree of absolute shamefulness. If I didn't have years of experience writing software, I think I also would've dropped out.

Next to writing software, we also learned useful things like teamwork. Teamwork usually translates in one of two things. Or you work your ass off to get the project finished in time, or you just make it seem you do all the work, while you're actually just relying on your teammates to finish the job for you. The second kind of people tend to be more successful, since they actually have the time to study for all of those other things the educational system tries to shove down the student's throats. During the first two years this system has made some of the best people leave out of pure frustration. I didn't, but I did have trouble finding the motivation to be the one doing all the work all the time.

The rest of the curriculum during the first two years wasn't that interesting. Most courses needed a whole semester to teach something that can be taught equally well by reading some relevant Wikipedia articles for an hour or so. That's what I ended up doing, too. It's amazing how much nonsense some of these courses try to teach, ranging from extremely dated theories to outright lies. Too bad the educational system doesn't approve of people pointing out the absurdities during tests. To pass the test, you're expected to copy over the same things you've been taught in class. You're not, I repeat, not allowed to think for yourself. On the other hand, some things were quite lacking. I've already covered programming basics, but things like maths and logic were completely non-existent during the entire four and a half years. How do people expect students to create decent solutions if they're not even told how some of the most basic principles in engineering work?

The other two years were interesting in their own right. Now the students (the ones who were left) grasped the basics, or that's what they were being told anyway, the fun stuff could begin. It turned out to be quite a challenge. During these two years two semesters were dedicated to internships, and the other two to "regular" education. The educational semesters seem to have been designed to test the student's ability to cope with vast amounts of stress. First off, they managed to cram 100 hours worth of work in a single week, for five months straight. During these semesters students had to follow all kinds of weird courses, some of which even had dependency problems by scheduling a course parallel to it's predecessor. Next to these courses a project was organized, which in itself cost more than 40 hours a week. Again, it was mostly one or two people doing all the work, while others were idly slacking along. The worst thing is, these projects were actually fun. I especially invested lots of time into these projects to make the best out of the end result. Playing around with Embedded Linux, networking and electronics is way too much fun to sacrifice for a few of these lame courses. I ended up doing another semester worth of overtime because of this decision. All of that while the slackers graduated before me. I still don't understand why there are companies actually hiring these people. These people end up automating banks, public transport and other sensitive areas. It's a horrifying idea. Anyway, the two projects I've done have been quite successful. I've learned most of what I know today about X11 and Embedded Linux during these two semester projects. I'm actually putting that knowledge to good use right now. The sad thing is though, there's not a single teacher who understands what I've built. They ended up hiring post-graduates to teach the students about the technology we've been playing around with. Luckily these guys know what they're talking about, and I admire them for their effort. I sure as hell couldn't function as a teacher within that educational system, let alone actually bring my message across.

During the same two projects, the educational system had to introduce something which most engineers hate the most. Paperwork and bureaucracy. And lots of it. Every feature needed it's own set of documents, seals of approval and meetings. Writing these documents took way more time than actually developing the damn thing in the first place. For every line of code there were 60 lines of documentation. I'm not even counting comments here, it's 60 lines of bullshit for every line of actual code. I've still got the source tree of those projects, and it's awful. We ended up with almost 300 pages of text, and a product lacking features. All of those features had been documented though, and that has to count for something, right? Right?

The other two semesters were internships. No courses, just a full-time project to invest your time in. Most of the students called these internships vacation, because of the sheer contrast of a normal 40 hour week to the 100 hour week we were used to. Of course we had to write a report, but that's it. We were expected to show up after 100 work days with a report, a presentation and a happy employer. Some of us even managed to get a contract out of these internships. I already had a contract at my first internship, so that doesn't really count. I've had a wonderful time hacking on Linux-HA, OpenBSD, VLC, X11 and way more cool stuff. If I replaced all of the educational mumbo-jumbo with internships, I could've been a full time kernel developer at one of the big sponsors or something. I could've learned so much more in those four and a half years.

So, while everybody went to work at their new employers after graduation, I had to endure another semester worth of education. I had a few courses left, all of them having something to do with drawing pictures and schematics instead of actually writing the damn software. Coincidence? I think not. Luckily I was given the chance to participate in a new Embedded Linux project for a group a companies, headed by my university. This way I didn't have to do all of the courses again, but only a small subset of them. I don't know how I did it, but I have pulled through. The Embedded Linux project is starting to look quite promising, and all of the courses have been dealt with. I've got a final meeting with the project members tomorrow. After that, I'm a free man. I'm actually quoting one of my teachers here.

So, looking back on these years. What have I learned? Most of the things I've learned, I've taught myself. I don't believe having all of those teachers around has made that much of a difference. I've only met a few teachers who were actually interesting, and managed to teach me new things I'm able to use in my job as a software and network engineer. Don't get me wrong, most of them are great people, but they just can't keep up with what has happened in the last, say, 20 years. The educational system hasn't entirely wasted my time, but it's gotten damn close. I think I could've achieved way more in less time under a much lower budget. There's something wrong with this system, and it should be fixed.

user@box:~/kitchen$ make
Make what?
user@box:~/kitchen$ make sandwich
What? Make it yourself.
user@box:~/kitchen$ sudo make sandwich
Okay.

Before we start, I have to tell you I've only tested this using Trac 0.11.6 and NGINX 0.7.64 on Debian GNU/Linux. It'll probably work everywhere, except on Windows. Trac's FastCGI simply won't run.

Just like NGINX hasn't got modphp, modpython is equally absent. Which is a good thingtm. Trac supports running every site in FastCGI mode since 0.9, making it entirely NGINX-compatible. There's even a config sample on the wiki, which we are not going to use.

After creating your Trac environment using trac-admin, you'll have to deploy the site first. Since I'm using Debian, it's going to end up somewhere under /var/www/. I've also put my Trac sites in /var/trac/, just to make things a little more complicated. Put your files wherever you fancy, I'll keep using these paths. Say, we're about to host helloworld's project trac page.

trac-admin /var/trac/helloworld initenv
mkdir -p /var/www/trac && chown www-data:www-data /var/www/trac
trac-admin /var/trac/helloworld deploy /var/www/trac/helloworld
chown -R www-data:www-data /var/www/trac/helloworld /var/trac/helloworld

Replace www-data with whatever user your NGINX is using. This will initialize your Trac environment and deploy the site-specific static files to the webroot. This will also provide you with the FastCGI server, which in turn can be started using Lighty's spawn-fcgi. As always, I'll supply the init script you can use to automate this. This time though, I've simplified things a bit. Since all of the Trac FastCGI processes are the same anyway, we can use symlinks and the init script's basename to unify our configuration. The only thing you have to do to start the site's FastCGI daemon during the system boot is to copy the fcgi-trac-base script to /etc/init.d/, and the following.

ln -s /etc/init.d/fcgi-trac-base /etc/init.d/fcgi-trac-helloworld
update-rc.d fcgi-trac-helloworld defaults
/etc/init.d/fcgi-trac-helloworld start

Now we've got Trac itself running, it's time to get NGINX to actually serve the site. I've chosen, because of SSL limitations, to host Trac sites under https://www.domain.tld/trac/project instead of a sub domain. I think the config's easy enough to change this behavior. The first thing we want to do is to make sure static content, like CSS and images, is served directly by NGINX instead of tunneled through FastCGI. All the following configuration goes, in order, into your domain's server { } block.

location ~ ^/trac/([0-9a-zA-Z\-_]*)/chrome(.*)$ {
  alias /var/www/trac/$1/htdocs$2;
}

All of the static content will now be caught before Trac's even touched. This increases the speed of serving this content drastically. Next up, calling Trac itself. It becomes a little tricky from here, since we're juggling with regular expressions and variables. Once you've set them up correctly though, you shouldn't have to edit a single line anymore when adding extra Trac sites. First, we want to store which Trac site we're accessing. In this case, we want the helloworld part from our Trac URI.

if ($uri ~ ^/trac/([0-9a-zA-Z\-_]*).*$) {
  set $trac_host $1;
}

We'll make good use of this variable. The next step is to call the right Trac FastCGI server. Because we've used a self-configuring init script, we can safely assume the location of the listening UNIX socket. We can even use this variable to point to the right authentication file, if you wish to secure your Trac sites. The right way to create this authentication file is using Apache's htpasswd.

mkdir /etc/nginx/trac
htpasswd /etc/nginx/trac/trac.helloworld.passwd johndoe
chmod 400 /etc/nginx/trac/trac.helloworld.passwd
chown www-data /etc/nginx/trac/trac.helloworld.passwd

I'll explain the following block in parts, because there are quite some gotcha's hidden between the lines.

location ~ ^/trac {
  auth_basic            "Trac";
  auth_basic_user_file  /etc/nginx/trac/trac.$trac_host.passwd;

I've used a regular expression match in the location instead of a regular location definer because otherwise the PHP interpreter out of my previous NGINX post would try to parse anything that ends with .php, including PHP files in Trac's browse source functionality. It would fail of course, but Trac will also fail to produce the pretty syntax highlighted source code. You do have to make sure Trac's configuration comes before PHP's.

  fastcgi_split_path_info ^(/trac/[0-9a-zA-Z\-_]*[/]*)(.*)$;

It took me a while, and some help, to figure this out. To get the right PATHINFO FastCGI variable, you can't just use the regular expression in the previous if-statement. It will work, except for URIs with urlencoded characters in them, like spaces. NGINX keeps these %something characters, while FastCGI's PATHINFO expects these strings to be supplied decoded. The special function fastcgisplitpath_info corrects this error, and will supply you with a correct value stored in the $fastcgipathinfo variable. You'll have to be using NGINX 0.7.31 or later to get this to work.

  fastcgi_pass   unix:/var/run/trac-fastcgi-$trac_host.sock;

Now we can pass everything to our eagerly waiting UNIX socket, which has been set up by the fcgi-trac-base init script. As you can see, it's important the project name throughout the config matches exactly. Otherwise, some components might fail to find the right locations.

  fastcgi_param  HTTPS            on;
  fastcgi_param  QUERY_STRING     $query_string;
  fastcgi_param  CONTENT_TYPE     $content_type;
  fastcgi_param  CONTENT_LENGTH   $content_length;
  fastcgi_param  SCRIPT_NAME      /trac/$trac_host;
  fastcgi_param  PATH_INFO        /$fastcgi_path_info;
  fastcgi_param  AUTH_USER        $remote_user;
  fastcgi_param  REMOTE_USER      $remote_user;
  fastcgi_param  REQUEST_METHOD   $request_method;
  fastcgi_param  SERVER_NAME      $server_name;
  fastcgi_param  SERVER_PORT      $server_port;
  fastcgi_param  SERVER_PROTOCOL  $server_protocol;
}

Finally, we can add the right variables to get FastCGI the information needed to serve the Trac pages. Remove the HTTPS variable if you don't use HTTPS for your Trac sites. Also, remove the _*_USER_ variables if you don't use NGINX's HTTP authentication for Trac.

Now you can easily add new Trac sites by following the next steps.

trac-admin /var/trac/$PROJECT initenv
trac-admin /var/trac/$PROJECT deploy /var/www/trac/$PROJECT
chown -R www-data:www-data /var/trac/$PROJECT /var/www/trac/$PROJECT
htpasswd /etc/nginx/trac/trac.$PROJECT.passwd $USER
chmod 400 /etc/nginx/trac/trac.$PROJECT.passwd
chown www-data /etc/nginx/trac/trac.$PROJECT.passwd
ln -s /etc/init.d/fcgi-trac-base /etc/init.d/fcgi-trac-$PROJECT
update-rc.d fcgi-trac-$PROJECT defaults
/etc/init.d/fcgi-trac-$PROJECT start

I've combined all of the config into a single file you can place in your NGINX config directory, which you can include inside any server {} block.