I apologize in advance for a very long answer to what you would consider a very simple question. Unfortunately, combining an entire operating system from many different bits in a consistent and unified manner is not a completely trivial task. I am currently working on my own Xen distribution, I will share my experience so far (besides Linux From Scratch):
1 - Decide the scale and stick to it
If you have any hope of completing this project, you need to write an explanation of what will be for your new OS, and do it after it is completed in one paragraph. Print it and stick it on the wall in front of you. Read it, repeat it, practice saying it back and all else that can help you keep it right before any desire to succumb to the creep function .
2 - Solve the package manager
This may be the most important decision you make. You need to decide how you will maintain your operating system in relation to updates and new releases, even if you are the only subscriber. Anyone, including those using the new OS, will certainly find it necessary to install something that was not included in the base distribution. Even if you push the OS to power the kiosk, it is important that all deployments are constantly updated intelligently and consistently.
I ended up working with apt-rpm because it offered the flexibility of the popular .rpm package format, using the well-known common sense when it comes to dependencies. You can use yum, apt with .deb packages, slackware style.tgz packages or your own format.
Decide this quickly because it is going to dictate how you structure your assembly. Keep track of the dependencies in each component so that you can pack it later.
3 - re-read your area, then configure the kernel
Avoid kitchen sink syndrome when creating a kernel. See what you want to do, and then decide what the kernel should support. You will probably need support for a complete gadget, compatibility with file systems from other popular operating systems, security hooks suitable for people who are browsing a lot, etc. You do not need to support crazy RAID configurations, improved netfilter and minixfs targets, but wifi works best. You do not need 10GBE or infiniband support. Carefully study the kernel configuration. If you can not justify the inclusion of the module for its potential use, do not check it.
Avoid pulling trees out of patches if you don't need them. From time to time, people come up with new scheduling algorithms, experimental file systems, etc. It is very, very difficult to maintain a kernel that consumes from anything other than mainline.
Of course, there are exceptions. If getting out of a tree is the only way to meet one of your goals, set out in your scope. Just keep track of how much extra work you will do for yourself in the future.
4 - re-read your area, then select your base user area
At a minimum, you will need a shell, basic utilities, and an editor that works without a window manager. Paying attention to dependencies, you will say that you also need the C library and everything that is necessary for the basic commands to work. As Eli replied , Linux From Scratch is a good resource to check. I also highly recommend taking a look at LSB (the standard Linux base ), a specification that lists common packages and components that are expected to be included in any distribution. Do not follow the LSB standard; compare its offerings with your area. If the goal of your OS does not require the inclusion of anything, and nothing depends on it, do not enable it.
5 - re-read your scope and select a window system
Again, referring to the everything including the kitchen sink syndrome, try and resist the urge to just tickle the KDE or GNOME installation on the base OS and invoke it. Another common mistake is to install the full version and work backwards by removing unnecessary things. For the sake of reasonable dependencies, it’s actually better to work on it from the bottom up, and not from top to bottom.
Quickly decide in the user interface toolkit that your distribution will be approved and received (with library support). Define the sequence of user interfaces quickly and stick to it. Nothing is more annoying than opening 10 windows that behave in completely different ways as far as control allows. When I see this, I am diagnosing an OS with multiple personality disorder and want to treat my developer. There was only noise associated with moving the Ubuntu window, and they did it sequentially. The inconsistency was a change in behavior between versions. People are very upset if they cannot immediately find the button or increase their mouse mileage.
6 - re-read your volume and select your applications
Avoid shell syndrome here. Choose your applications not only based on your scope and popularity, but also how easily they will be supported by you. It is very likely that you will apply your own patches to them (even simple ones, such as instant messengers that update the blinking light on the toolbar).
It is important to remember each architecture that you want to remember when choosing what you want to include. For example, if Valgrind is your best friend, keep in mind that you cannot use it to debug problems on some ARM platforms.
Imagine that you are a company and will be an employee there. Does your company conduct a Joel test ? Consider a continuous integration system such as Hudson . This will help you save a ton of effort as you move forward.
When you start combining all these components, you will naturally create your own SDK. Document this as you go, don't break it down on a whim (always refer to your area). Its perfectly acceptable to just let linux be linux , which turns your SDK into formal guides than anything else.
In my case, I was lucky to work on something that was developed strictly as a server OS. I do not need to deal with desktop reservations, and I do not envy anyone who does this.
7 - Additional offers
They are in random order, but noting that they can save you some time:
- Maintain a set of patches for each line of upstream code that you modify in a numbered sequence. An example would be
00-make-bash-clairvoyant.patch , this allows you to maintain patches instead of whole forked repositories of code upstream. Congratulations on that. - If the component has a test kit, make sure you add tests to everything you enter. It's easy to say "great, it works!" and leave it at that, keep in mind that you are likely to add even later, which may break what you added earlier.
- Use any version control system used by the authors when pulling upstream code. This greatly simplifies the merging of new code, greatly simplifies and reduces the time from re-basing your patches.
- Even if you think that upstream authors will not be interested in your changes, at least warn them that they exist. Coordination is important even if you just find out that the function you just entered is already in the planning process and will be implemented differently in the future.
- You can be sure that you will be the only person who would ever use your OS. Create it as if millions used it, you never know. Such thinking helps to avoid coolages.
- Do not drag the alpha code up, no matter what the temptation is. Red Hat tried this, it didn’t work out well . Stable releases if you don't fix bugs. Basic bug fixes usually result in an upstream release, so make sure you watch and coordinate.
- Remember that this should be fun.
Finally, understand that switching an integer from scratch to a distribution is exponentially harder than branching an existing distribution and just adding what you feel is lacking. You must reward yourself often by loading your OS and actually using it productively. If you're too upset, constantly confused, or find yourself putting off work on it, consider creating a lightweight Debian or Ubuntu fork. Then you can go back and fully play it from scratch. It is no different from prototyping an application in a simpler / faster language before writing it for real into something more complex. If you want to go this route (first), gNewSense offers utilities to deploy your own OS directly from Ubuntu. Note that by default, their utilities will cut out any non-free bits (including binary blob kernels) from the resulting distribution.
I highly recommend going all the way from scratch (first), because the experience you get is much more than creating another plug. However, it is also important that you truly complete your project. Best is subjective, do what works for you.
Good luck with your project, see you at distrostatch.