Funtoo Linux Vision
The Funtoo Linux Vision is developed and evolved primarily by Daniel Robbins.
- 1 Project Vision
- 1.1 Focus, Focus, Focus
- 1.2 Examples
- 1.3 Things To Do
- 1.3.1 Cron
- 1.3.2 Genkernel replacement
- 1.3.3 Core System Security Hardening
- 1.3.4 PAM Maintainer
- 1.3.5 LiveCD
- 1.3.6 Alternate Architectures
- 1.3.7 Enterprise Support
- 1.3.8 Core System Audit
- 1.3.9 Desktop Support
- 1.3.10 Portage Improvements
- 1.3.11 UID/GID Framework
- 1.3.12 Eclass Refactoring
- 1.3.13 End User Install Experience
- 1.3.14 Install Documentation
- 1.3.15 Documentation Maintenance
- 1.3.16 Funtoo Stable
- 1.3.17 Funtoo Profile
- 1.3.18 Funtoo Linux Page
- 1.3.19 Wikipedia Pages
- 1.3.20 Anything Else?
Daniel Robbins originally wrote the Gentoo Linux Philosophy, and in it he defined the concept of an ideal tool as being something that "just works", does not get in the user's way, and responds to the will of the user rather than forcing the user to work a particular way.
Funtoo Linux is a project of people who agree with the philosophy of the ideal tool, and who are passionate in our desire to improve technology to be as close to this ideal as possible. The focus of our efforts is the Gentoo Linux distribution. It is our belief that Gentoo Linux is a very good Linux distribution but has deviated from the original vision as outlined by Daniel, and is capable of being improved significantly. We are passionate about improving Gentoo Linux.
The development focus of Funtoo Linux is currently directed at the core system, meaning anything on a stage3, portage, core languages, kernels, server applications, and up through X11 and simple window managers. Desktop environments are purposely excluded from our area of focus as there is plenty to fix in the "lower" parts of the system. The goal is to get the above-mentioned parts to a level of quality and maturity that is significantly higher than that in Gentoo Linux right now.
Focus, Focus, Focus
This project's vision still leaves a lot of ambiguity about where to focus. Use these guidelines to determine what to focus on first. These priorities are listed in order of priority, so the next paragraph is the top priority, followed by next priority, etc. Just because something is lower priority doesn't mean it is "less important" - it just means to address the higher-priority things first.
Does It Build?
- Does it Build Reliably?
The first test - does the software build from source properly? This isn't just about emerging ebuilds on your system -- do stage builds work with no issues using Metro? If not, this needs to be fixed first. Funtoo Linux continually builds updated operating system releases, and these must build reliably at all times. The focus here is for 100% correct and efficient builds using Metro, and then emerging initial applications on a Funtoo Linux system.
Does It Run?
- Does it Run Well?
OK, it builds. Does it run properly? Does it work? This is pretty vague, so let's put some specifics here. When installing Funtoo Linux from a stage3, does everything work? What complications or failures were encountered on initial install? These should be fixed, or work-arounds should be put in place, and long-term fixes should be worked on to improve the user experience. Remember that the focus of Funtoo Linux is on the core system - this is the stuff you touch when you first install Funtoo Linux. You should regularly re-install Funtoo Linux to check for any issues and prioritize user install issues and the initial user experience.
Can I Use It?
- For Real Work?
OK, it builds, and it runs. But can I actually perform tasks with the tool? How easy or hard is it to perform these tasks? The technology must be designed to support the user in performing these tasks, rather than forcing the user to jump through hoops to get something set up correctly. Things should be automated as much as possible without taking control away from the user. Reasonable, secure defaults that are suitable for production workloads must be used for all applications. Things should emerge without blockers or missing features that must be enabled manually by the user. And a pet peeve - if emerge stops to tell the user that they must define a USE variable to continue, this is something that should be fixed one way or another. Then, when everything is said and done, it should work.
Is It Documented?
- For free software projects, documentation is key.
If software builds, runs and works, others still may not be able to use it until proper documentation is available. Upstream documentation isn't always complete or easy to understand, so often additional user documentation is required. If manual steps are required, they should be documented clearly and correctly. The documentation option of choice is the Funtoo wiki as well as man pages.
For source code, verbose comments should be used. You may be working on the code now, but someone else might be working on it six months from now. Developers are expected to write clear comments that are sufficiently non-technical and provide the necessary context to allow less experienced developers to understand critical parts of code, and ideally all parts of the code. Please see Coding Standards.
Is It Well-Designed?
It builds and runs, and I can use it to perform real work. But is the system well-designed? Does it work reliably? Are all available patches and fixes in place to ensure a reliable computing experience? Is Funtoo Linux providing the best technology possible to users? And is this technology easy to maintain? Remember, all things being equal, less code is better than more code because it is easier to maintain. Are there verbose comments in code where necessary?
Are We Getting Better?
OK, we're doing all of the above steps. Here is the next test - are we getting better? Is the quality, security, usability and maintainability of the distribution improving over time, or is it going up, and then going down, and we're not really making any forward progress? The ultimate goal at the end of the day is to make forward progress in the quality of the distribution. This requires better automation, better tools, better processes, and investment in research and development and new ways of doing things. It also requires the right attitude. If we are doing a lot of work and the overall quality of the distribution is not improving, then our efforts are not making a long-term difference, even though they may be addressing immediate bugs and issues. We must ensure that our efforts are worthwhile, and they are making a positive long-term difference in the quality of the distribution.
What is The Real Problem?
Building on this theme - when a bug is encountered, what is the real problem, or root cause? Strategic thinking as well as in-depth troubleshooting is required to identify the root cause of a problem. Should we just fix root causes? No, this is impractical, because doing this takes a lot of time. Instead, workarounds are often used to quickly restore quality to acceptable levels. However, just implementing workarounds is dangerous, because bugs tend to multiply while the underlying issue goes unresolved. The proper solution is to implement workarounds but to not lose focus on the need to address the underlying issues, or root causes, of the problem. In fact, much of the focus of Funtoo Linux is on this last step - aggressively fixing a bunch of immediate issues so we can start to address the deeper problems once and for all...
...and addressing root causes of problems often requires a significant change in software architecture. Funtoo Linux is a project that is not afraid of making significant, even aggressive, architectural changes in order to fix problems. This is what our users expect us to do, and as long as these changes are properly tested, managed, planned, automated and communicated to users, they will not get upset. As stated in the previous paragraph, the Funtoo Linux project is zealous about addressing these core architectural issues -- but we need to get a handle on the more fundamental challenges first. Once workarounds are in place, we'll take a stab at some core system change that will pay dividends well into the future.
Below, you will find examples of existing efforts that have aligned with these goals. This section will give you a feel for how real projects can be started that align with the Funtoo Linux vision defined above.
Boot-Update was designed by Daniel Robbins to provide a more elegant way to configure boot loaders under Funtoo Linux. This project was prioritized for several reasons. For one, it had to do with the initial installation experience (see #Does it Run?) Also, lack of GRUB2 support, as well as GPT/GUID support, was identified as a critical weakness in current Gentoo Linux functionality (see #Is it Well-Designed?) Because of this, a new unified configurator was written which uses /etc/boot.conf as the global boot loader configuration file. This represented a change in boot loader architecture (see #Architecture) under Funtoo Linux, in order to improve usability and flexibilty over existing solutions, and to attempt to reduce or eliminate a class of problems related to boot loader configuration, which is especially troublesome with GRUB2.
Metro was designed by Daniel Robbins and is used to address the "#Does It Build?" question. The existing solution, catalyst, was difficult to maintain (see #Is It Well-Designed?), so Metro was developed to provide a new mechanism for building OS releases.
Not all improvements involve large software development efforts. In fact, the majority of fixes involve relatively small fixes to ebuilds. These fixes are often made to fix a Metro build failure (see #Does it Build?) or address some quality issue (see #Is It Well-Designed?). The www-servers/nginx ebuild was improved to provide better default settings for production systems, with corresponding changes made to sys-libs/pam to allow this to work. dev-lang/python contains fixes to ensure that Metro builds complete properly and a valid /usr/bin/python symlink always exists.
OpenVZ support is a specific priority of Funtoo Linux. Funtoo Linux maintains a patched sys-cluster/vzctl with various patches to fix a variety of problems. In addition, openvz-rhel6-stable and openvz-rhel5-stable ebuilds have been created to ease installation of production-quality OpenVZ kernels (see #Can I Use It?) In addition, OpenVZ documentation exists on the wiki (see #Can I Use It?)
Currently, effort is under way to replace sys-apps/man with sys-apps/man-db, since sys-apps/man doesn't properly support UTF-8 and has a host of other bugs. The goal here is to provide the best available technology to our users. In addition, the cron.daily/weekly/hourly system has been identified as having critical bugs. These are areas that need to be improved to ensure that the quality of Funtoo Linux is on par with other modern distributions.
Funtoo Network Configuration
Funtoo Linux Network Scripts have been redesigned to have a simpler #Architecture that is more easily extensible, and is also much easier to maintain due to its vastly reduced code-base (see #Is It Well-Designed?)
Things To Do
The cron system in Gentoo Linux has a number of serious bugs (references needed.) It would be good to re-architect the cron system to work properly and ensure that jobs always get executed when they should. In addition, having a job management framework would be useful when someone wants to fire off jobs on irregular intervals.
Genkernel has not aged well and is prone to failure, and current versions from Gentoo have multiple bugs. A better replacement with a better architecture which properly leverages ebuilds for building the initrd is needed. Update 2011-05-24: Daniel has forked genkernel and has begun to enhance it.
Core System Security Hardening
Permissions and ownership, as well as configuration, can be improved in the core system to enhance security.
Having someone to perform ongoing maintenance of PAM is desired.
It is time for Funtoo Linux to have an official LiveCD. Work is under way to make this happen but the effort needs testing and support.
We are looking for developers who will take initiative and support non-x86/amd64 architectures, and who will work to make them better. Work is already under way on Sparc.
Much work has been done on OpenVZ support, but there is much more to do. In addition, more ebuilds besides nginx need tweaking for optimal server performance. This is more of a direction than a goal because there is so much to do.
Core System Audit
Periodically, a developer should do an audit of a particular ebuild and look for ways to improve and refine it, or replace it with a better ebuild. This also includes doing an assessment of patches that are in other distributions but may not be available yet from upstream. A plan should be developed to improve these packages that offer tangible benefits to users, and maintainability benefits to Funtoo Linux. The goal here is to have the absolute highest quality ebuilds available.
Desktop support is currently not a high priority for Funtoo Linux, but we would like to offer a minimal, fully configured OpenBox X11 environment and also work towards refactoring X11 startup to make things simpler and more maintainable (Tarsius is working on this, contact him if you want to help). In addition, some work should be done to integrate improvements to LCD font rendering that are available in overlays, and to ensure that OpenBox looks awesome by default. Some limited work is happening in this area.
Much has been done here, with our git-based tree, mini-manifests, community-based merges, and current work on a unified path structure in /etc/portage, but there is also so much more to do. Much of this work is currently being done by Daniel Robbins.
The current UID/GID handling in Portage is limited as numeric UIDs and GIDs are often hard-coded in ebuilds. A new framework is needed to allow Portage to gracefully adapt to new or alternate numeric UID/GID settings. This framework would be integrated into the Portage core.
Useful eclasses should be redesigned and integrated into the Portage core to improve Portage performance. In as much as possible, dependencies on bash-based frameworks should be deprecated in favor of core Portage features that provide similar functionality. Update 2011-05-24: Daniel has written new kernel ebuilds that do not use eclasses, so that refactoring of the code can be done. These are working well.
End User Install Experience
Periodically, new installations of Funtoo Linux should be performed for the purpose of evaluating the user install experience. These experiences should be documented and new and alternate configurations should be tested as well. The goal here is not to build an installer, but to fix quirks and inconsistencies related to core ebuilds and the overall install process.
Funtoo Linux needs its own wiki-based install documentation that is detailed yet easy to navigate. Ancillary topics should be covered on their own pages rather than being stuffed into the main install document.
The Funtoo Linux FAQ has some broken links and needs periodic maintenance as Funtoo Linux moves forward.
We are in need of a maintainer for Funtoo Linux stable.
We are getting ready to implement the Funtoo profile, as some prerequisites are now in place in our version of Portage.
Funtoo Linux Page
The Funtoo Linux wiki page should be written more like a real Wikipedia-style page rather than how it now appears. Much of the content on this page is out-of-date or can be incorporated into other pages.
You may know a way that the core system can be improved. Many times, these involve incorporating your custom "tweaks" into Funtoo Linux core so that others can benefit from them, or providing better support for certain ebuilds that you use regularly.