2010-05-16 - initial switch §
While researching the annoyance of a 1 minute boot delay 'waiting for device sda8 to appear', I figured that a kernel update was in order. Unity Linux had a new option that I just had to try out. I thought I'd write a bit about this..
Simplification has been a long-standing dream of mine. I've only recently been trying to apply it more and more rigidly, especially with the concept of the chain of trust. Whenever I see an opportunity to replace something complex with something with less moving parts and less complexity, I make an honest effort to try that new something.
I've been using Linux for a long long time now. It's an example of my breaking that dream of less complexity. In fact, I've dropped earlier simpler tools and impressive expertness in order to learn and use Linux on a daily basis. There are more things at play with my decisions on software tools than just the notion of simplicity. Linux represents a level of freedom that I've never known before, and it's worth the learning curve.. the level of complexity that I've never known before.
Linux itself is still way too complex. The layers of complexity and the various tools that work together are challenging to understand. There are fundamental philosophies which I struggle to agree with.
We can look at one significant set of them by looking at the philosophies of Richard Stallman's software. His collection of tools are each created to solve as specific and indivisible a problem as possible. This reduces duplication of effort and code. The small tools can be chained together in incomprehensibly convoluted ways through the pipeline mechanism.
One of the core components of my computing experience is the Linux kernel's scheduler. It's responsible for .. scheduling. Processes like programs and little spinoff processes created by those programs are all competing for CPU time. This is an extremely complex task and it's done in an entirely convoluted manner.
- As a somewhat-unrelated side-story, I want to talk about the GNU Hurd project. Instead of being like the Linux kernel which uses one gigantic monolithic kernel which does everything, the Hurd kernel is split into many pieces which pass messages. Sound familiar? It's just like all of Stallman's small utilities which can be made to work together to achieve more complex goals by pipelines.
- The Hurd kernel project has taken an outrageous amount of time. This is partly due to the incredible adoption of the Linux kernel, which takes mindshare away from non-Linux-kernels like Hurd. It's also partly due to the complexity of the Hurd's microkernel design. Stallman has said that it turns out to be extremely difficult to debug code like this.
- I always thought that a good solution would have been to build all of the small components as twins. All proper code should have two sides to it. One side is designed with testing/debugging in mind, and the other side is designed for actual use.
- I don't know enough to explain anything other than using my own programming as an example. In the future I'll probably find my present programming embarrassing, but it's done using this "twins" concept.
- The whole program is "written about" by being broken down into individual problems. Those individual problems become individual little routines which only know how to do that one thing. Those individuals end up being paired with another piece of code which only knows how to test that one thing. This is the twins concept. There are probably a whole lot of different terms for this concept out there, but I can't think of any at the moment so this will have to do.
- So I always imagined that a solution for the Hurd kernel project would be to make each of their little modules as twins. One side is the actual code and the other is a sort of debugging version of that code.
- Messages get passed between modules. When a system issue occurs, it's difficult to know what went wrong where. By using the twins concept, a message gets passed to the debug twin, processed and reported by it and then transferred to its pair. The message packet is processed "for real" and then it gets sent out to its normal destination, only to be received by the appropriate debugging twin.
- So when a problem happens, the exact contents, history and path of a message can be known.
- I'm totally bullshitting here, but I just wanted to get this idea off of my chest.
Back on topic. So I learned about the Brain Fuck Scheduler (BFS). It's a replacement scheduler for Linux. I had heard nothing about it, but there was some discussion within Unity Linux about it, and I did a bit of reading on it.
The first thing I learned was that it was a black sheep project. It was done by a single person and it was rejected from the main Linux kernel project. It's philosophies are fundamentally different.
This is always intriguing stuff for me to hear about. Something that's actually done and working that was accomplished by one single person can be quite spectacular. When it's one rogue doing it in spite of differing philosophies, I can feel their passion.
BFS is a replacement for a key component of the most key part of my operating system. It being done by one passionate hacker is intriguing enough, but what really interests me is the leading philosophy:
- [1] The goal of the Brain Fuck Scheduler, referred to as BFS from here on, is to completely do away with the complex designs of the past for the CPU process scheduler and instead implement one that is very simple in basic design.
Simplification. That's gold.
In terms of the chain of trust, it's dangerous to rely on the work of any one single point of failure. The single-hacker nature of this system is intimidating, but I can very easily switch back to the traditional CFS scheduler of the everyday Linux kernel. I do also hope that BFS begins to reach a wider audience and finds additional developer support if and when it needs it.
The BFS FAQ has some additional good reading.
Apparently like every good hacker, this one does documentation but doesn't particularly care to wrap a whole website around it. The project's files are found at ck.kolivas.org/patches/bfs/
... oh, and BFS is working just fine. So far.. I approve! I've had some brutal issues with a hard-locking system and such, thanks to some stupidity of mine. See how to hard lock a Linux system, the dangers of tmpfs for more on that. With that issue out of the way, I don't know if there are any other issues with my system which BFS may or may not reveal or solve. I'll report back with any issues.
