-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
I think we need to move in a new direction. While what I have done has been informative I do not think it is an optimally productive path for the operating system.
I am going to work at getting a LFS working. During this process I want to create a library that can aid in creating a new package type. I propose that the package creation files that we use contain all information that may be of interest to the user.
A new package standard is to be created for Orbos that intends to be more straight forward to the user.
This new package standard is required in order to make dealing with versioning and build flags easier.
I intend to make building the operating system as entertaining as possible while allowing the user to still learn what is going on within the build process.
One of the most interesting systems I have used was a source based system that felt like you were playing a video game. Its commands modified the system in a very intelligent way. Installing things was captivating and interactive. There was no restart the process, it was gruelling and difficult process that did not lend itself well when mistakes were made.
The name of this system was Source Mage GNU/Linux.
I think that command line programmers need to take a lesson from them.
I think we need to make things fun like that.
In SMGL you typed things like `cast <program>` and `dispel <program>`.
These commands installed and removed programs.
It really felt like I was wizarding away at my computer while I used the distribution. While the commands may be different in Orbos I would like to maintain this level of entertainment within Orbos that I learned from SMGL.
There is a build protocol that is to be followed within building something from scratch to make sure everything builds cleanly. A series of Stages as they would be called in Gentoo or Funtoo.
There are books written about the bootstrapping process so I am not going to enter that area in a technical manner within this wiki article.
At a specific point in the install we can start being able to build packages and modules. At this point we can start working on the intermediate and beginners way of doing things.
The intermediate way of doing things in this reference means being able to use packages. The standard packages will most likely be some form of the compressed tarball. Many vanilla distributions use this but it was the surviving Slackware line that taught me about the simplicity of the tarball and how it can be used for package management.
Moving into the beginners way of doing things will be when we have module support and creating a prebuilt solution for the end user will become easier in many regards. The modules will be squashfs volumes. I first encountered this in the porteus distribution but the slax distribution does this too as porteus is slax based. The concept of this is amazing and leads to many new possibilities and new ways of doing things that have not been done yet.
This allowed for very easily creating livecd images and impressively simple installation methods.
Newer advancements in the Linux kernel will allow for overlaying the read only squashfs volumes with a read write volume in new ways. This will allow us to have seperate read write volumes per read only volume which should automatically organize changes of modules and prevent the clutter that would happen if all modules shared read/write space.
Delta management should be used within the update process for the modules. This will allow the least required bandwidth exchange for updates.
Most things are going as planned within the original roadmap defined in January.
The general process of downloading sources, compiling them and packaging them is split into 3 parts.
Part 1 - Anything to do with downloading the sources. This is currently incomplete as we have a source list for the base system within the Linux from Scratch infrastructure.
Part 2 - Anything after the sources hit the disk from cleaning previous source directories to performing the compilation and everything in between.
Part 3 - Anything that goes into the creation of the module. Usually this just entails creating the package and placing it in the correct location to be activated.
Part 2 is pretty much done for native compilations, It has been tested by compiling the temporary tool chain in chapter 5 of the Linux from Scratch book. It may need modifications for doing cross-compiles, Aka 64 bit multilib.
This testing led to many improvements to the functionality of the development tools.
I added a few things to the tool chain to provide the features we need and more may be added in the future to provide a fully featured starter build system.
| What | Why | Added Dependencies |
|---|---|---|
| Clang. | A secondary compiler.(Part 2) | libffi python2.7 |
| Squashfs. | In order to make modules.(Part 3) | zlib |
With these additions the toolchain raised from
- Aria2c for downloading anything we may need.
Aria2c allows for metalink, torrents and any type of download we may need.
Having a means to download the packages you want to build directly from the toolchain lessens the restriction on having to download all sources before you start building.
This will allow Orbos to be built entirely by source if the user chooses to do so.
- Create a test suite that checks to make sure everything required to do what we need to do is installed within the host system. - Done but could use improvements.
- Streamline the environment setup to make participating in early development easier. -Done but could use some minor improvements.
- Bringing all the documentation up to sync with the code, My local ideas wiki and my github released ideas wiki.
- Creating issues of feature enhancements I would like to put into the current code base before expanding it.
- Work toward the functionality of the feature enhancements.
- When we are happy with how the current functionality operates we will proceed onto creating packages.