At almost every software company I’ve been involved in, used custom-made tools for various tasks. These tools range from simple shell-scripts for search&replacing data to large deployment-script or even programs that take care of administrative tasks like monitoring, log aggregation and so on. At the good companies, these tools are maintained inside a software repository system SVN or GIT. But tools like these need to be deployed to a lot of different server and development environments, both in internal and external networks. Creating SVN checkouts is a possibility, but what about things like dependencies or easy up- or downgrades. And do you want external systems give access to your source code repository? And how do you make sure everybody uses the latest release with the newest features and bug fixes?
One of the best answers is something almost every Linux user is already familiar with: package managers. They are easy to use, it’s fast and can do so much more work for you than simple repository checkouts ever can do. Using Linux packages managers as the preferred way of deployment for software is not yet discovered by the php-community. Strange actually, since package managers are capable of handling issues that most deployment-tools are struggling with like dependencies, upgrades, downgrades and multi-environment setups.
Since this subject is pretty large to handle in a single blog post, it is setup in 3 different chapters. First, we begin by creating a package from scratch. In the next chapter, we show how to collect and maintain these packages inside your customer repository and in the last chapter we will talk about connecting your software repository to your package manager and how to deal with multiple repository-formats.
During this blog post I will talk about creating your own custom package repository. However, before you can setup a repository, you need packages. This previous post talks about setting up your custom packages.
Welcome to the first part of CybOS. We talk a bit about the bootsector. From part 2 on, everything is “kernel based”, which means we have setup the system and jumped to our main kernel. From there, things get really interesting so I jump a bit fast to the boot code. However, in the end of this post, the source code for the bootsector (and second stage loader) can be found so you can see what’s going on.
Somewhere in 1998 or even earlier, I started my own little project in creating a - functional - Operating System from scratch. Not a linux clone and not a MS-DOS wannabe. Just a simple OS that is functional in such that some tools, games etc could actually work, not caring about Posix compliance, fancy graphics or all hardware support you can think of..
So, today, 12 years later, where are we?