Difference between pages "Package:OpenRC" and "FLOP:Release Engineering"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(How do I tell one startup script to depend on another?)
 
 
Line 1: Line 1:
Funtoo OpenRC is the current implementation of the system startup and init script framework for Funtoo Linux. Official development sources can be found on [http://www.github.com/funtoo/openrc GitHub].
+
{{FLOP
 +
|Summary=This is a proposal to implement a strong release engineering infrastructure for Funtoo Linux. Funtoo currently is _only_ a rolling-release distro and does not have the _option_ to also be non-rolling. In order to create a more stable Funtoo system, this proposal will be offering a few things that we can do to make that happen.
 +
|Author=Fearedbliss
 +
|Maintainer=Fearedbliss
 +
}}
 +
'''Jonathan Vasquez (fearedbliss)'''
  
Funtoo OpenRC is an independently-maintained, forked version of the [http://roy.marples.name/projects/openrc/wiki OpenRC] init scripts ([http://www.gentoo.org/proj/en/base/openrc/ now maintained by Gentoo]). Funtoo Linux-specific changes generally relate to [[Funtoo Linux Networking|Funtoo network configuration]].
+
'''Version 0.2'''
  
== Commands ==
+
== Introduction ==
  
; rc-update
+
This is a proposal to implement a strong release engineering infrastructure for Funtoo Linux. Funtoo currently is _only_ a rolling-release distro and does not have the _option_ to also be non-rolling. In order to create a more stable Funtoo system, this proposal will be offering a few things that we can do to make that happen.
: add or remove a service from a particular runlevel, or implement [[Stacked Runlevels]]
+
; rc-status
+
: show current status of system services
+
; rc
+
: manage runlevel changes
+
  
== FAQ ==
+
The below proposals will not change Funtoo from a rolling-release system to a non-rolling release system. It will simply add the option to be non-rolling. Funtoo will also not be a binary distro. It will still be a source based distro but it will also have the ability to use binaries for a few select packages (Basically the Gentoo Reference Platform will be restarted and improved).
  
=== How do I tell one startup script to depend on another? ===
+
I believe that this will also make running Funtoo for users that want further stability and/or users that are running Funtoo as a server in an enterprise environment/or otherwise, more feasible.
  
The easiest way to do this is to modify the <tt>/etc/conf.d</tt> script that corresponds to the service that needs to depend on something else, so let's call this service <tt>this_service</tt>. Add the following to its conf.d file:
+
The following things are proposed:
  
<pre>
+
* Semi-rolling release model for Funtoo-'''RELEASE''' and Funtoo-'''STABLE''' (Funtoo-'''CURRENT''' will stay rolling release)'''
rc_need="other_service"
+
* A Complete Core OS'''
</pre>
+
* A set of monitored applications that will be checked for stability and consistency'''
  
Now, <tt>this_service</tt> will depend on <tt>other_service</tt>.
+
== Semi-rolling Time Based Releases ==
  
=== OpenRC is ignoring dependencies and not reacting to dependency changes ===
+
The semi-rolling release model is a hybrid between a rolling release and just a regular release. This means that instead of bring new packages in all the time (rolling release), and instead of just completely freezing everything and bringing new packages/features every X months, we can have a middle ground where we can branch the Funtoo-'''CURRENT''' git branch and then focus on stabilizing that tree. Once we stabilize it, people can use it without having to worry about major version upgrades. The user can then use this branch until another branch later in the future is created. The user can then easily upgrade to the new branch by switching their SYNC variable.
  
This can happen when your system's time changes suddenly (maybe due to realizing your system clock is wrong and resetting it) and OpenRC dependency cache files are created with future dates. To clear the OpenRC cache, type:
+
So essentially it is a slow rolling-release (or semi-rolling or rolling-release with speed bumps).
  
<pre>
+
Names for Funtoo's 3 git branches:
# rc-update -u
+
* Funtoo-'''CURRENT''' (Latest Developments - HEAD. This is the normal funtoo-current tree.)
</pre>
+
  
Alternatively, you can perform this step manually:
+
* Funtoo-'''RELEASE''' (Just a release in a specific point in time - a branch of Funtoo-'''CURRENT''' is created, frozen, and stabilize.)
 +
 
 +
* Funtoo-'''STABLE''' (This is the same as a '''RELEASE''' but it is supported for a longer period of time).
 +
 
 +
=== Which branch is for what person? ===
 +
The Funtoo-'''CURRENT''' branch is for people who want to be on the bleeding edge all the time. You will get the latest updates, and here is where all the development happens. Your system might not be fully stable all the time, and things might fail to compile. This is literally the traditional Gentoo rolling-release model. If you are used to using Gentoo/Funtoo, and want to continue using your system the way it has always been, this is the branch for you.
 +
 
 +
The Funtoo-'''RELEASE''' branch is for people who want to be rolling and receive new features but be more stable than Funtoo-'''CURRENT''' by using a frozen portage tree at a specific point in time that is audited for stability.
 +
 
 +
The Funtoo-'''STABLE''' branch is for people who prefer stability and don't need the latest features that are in the '''RELEASE''' branches. This branch is frozen for a longer period of time.
 +
 
 +
=== Example of 4 month RELEASE cycle, and a 2 year STABLE cycle ===
 +
For the branch developments: Let's picture a 4 month RELEASE cycle (semi-rolling), and a 2 years STABLE cycle. If we expand this starting from January 2013, we would get the following releases over two years:
  
 
<pre>
 
<pre>
# rm /libexec/rc/cache/*
+
Funtoo-13.1-STABLE  (January 2013)
# rm /libexec/rc/init.d/deptree
+
Funtoo-13.2-RELEASE (May 2013)
 +
Funtoo-13.3-RELEASE (September 2013)
 +
Funtoo-14.1-RELEASE (January 2014)
 +
Funtoo-14.2-RELEASE (May 2014)
 +
Funtoo-14.3-RELEASE (September 2014)
 +
Funtoo-15.1-STABLE  (January 2015)
 
</pre>
 
</pre>
  
Now regenerate the cache by typing:
+
This gives you 2 STABLE releases in two years and 5 RELEASEs in between. That's a total of 7 releases. STABLE releases only get bugfixes and security updates. RELEASE are for people that want to get the latest bleeding edge stuff, but still want to be stable within RELEASEs.
  
 +
For people that are used to the normal Gentoo/Funtoo stuff, you could just stay on the Funtoo-CURRENT branch.
 +
 +
=== Example of 3 month RELEASE cycle, and a 2 year STABLE cycle ===
 
<pre>
 
<pre>
# /libexec/rc/bin/rc-depend
+
Funtoo-13.1-STABLE  (January 2013)
 +
Funtoo-13.2-RELEASE (April 2013)
 +
Funtoo-13.3-RELEASE (July 2013)
 +
Funtoo-13.4-RELEASE (October 2013)
 +
Funtoo-14.1-RELEASE (January 2014)
 +
Funtoo-14.2-RELEASE (April 2014)
 +
Funtoo-14.3-RELEASE (July 2014)
 +
Funtoo-14.4-RELEASE (October 2014)
 +
Funtoo-15.1-STABLE  (January 2015)
 
</pre>
 
</pre>
  
The OpenRC dependency cache should now be up-to-date and OpenRC should behave properly again.
+
If we have have a 3 month (semi-rolling) cycle, we would end up with 2 STABLE releases and 7 RELEASEs within two years. This is a total of 9 releases.
  
== History ==
+
=== What will these branches contain? What will they focus on? ===
 +
Funtoo-'''RELEASE''' and Funtoo-'''STABLE''' branches will only focus on the stability of specific packages that we are deciding to maintain at a specific point in time. All outside packages can be installed and maintained by outside package mantainers.
  
The Gentoo modular init scripts were developed by Daniel Robbins for Gentoo Linux 1.0_rc6 during most of 2001 and released in September 2001 (TODO: add refs). After their development, the dependency-based init script system was maintained by a number of senior developers, starting with Azarah (Martin Schlemmer), with migration to the new init system assisted by Woodchip (Donnie Davies) who converted all ebuild init scripts to work with the new system. As Grant Goodyear notes:
+
== A Complete Core OS ==
 +
An operating system is not just a stage3 tarball. The stage3 will not boot by itself, but rather needs the user to compile a kernel and install a bootloader. We should have a well tested default kernel that is tested for stability. This will speed up deployments and will provide predictability for kernel modules, and other applications that rely on a kernel. We will also need to provide a way for the system to boot this kernel. Thus a default bootloader should be provided.
  
''My recollection is that one of woodchip's more impressive early feats was the
+
'''Core OS:'''
''complete replacement of all of the init scripts in Portage for Gentoo Linux
+
* stage3 (Minimal @system applications needed for a functional Funtoo base system)
''1.0_rc6. Through 1.0_rc5 Gentoo had used fairly standard rc scripts modified
+
* kernel (bliss-kernel can become the base of funtoo-kernel - or another kernel you think is good)
''from Stampede Linux, but for 1.0_rc6 Daniel Robbins (drobbins) and Martin
+
* bootloader (a default bootloader to provide a seamless, fast, and easy deployment experience)
''Schlemmer (azarah) had created a new dependency-based init script system that
+
''is still used today. Within a span of days Donny rewrote every single init
+
''script in the Portage tree and committed new masked packages to await the
+
''release of 1.0_rc6. Thanks to woodchip (and drobbins and azarah, of course) the
+
''transition to the new init scripts was nearly painless.'' <ref>http://www.gentoo.org/news/en/gwn/20040426-newsletter.xml</ref>
+
  
Roy Marples became a Gentoo/Linux developer in 2004 and maintained the modular network scripts for the Gentoo baselayout package. Towards the end of 2005, he became the primary maintainer for baselayout and the init scripts.
+
== Monitored Set of Applications ==
 +
In order for us to make a release stable, we will need to monitor a set of applications that we believe are essential for people that want to install servers and desktops. All of the monitored applications should work fine, they should be able to compile with no bugs (If the user is compiling), and they will also have binaries available. (The binaries will be compiled with the default and recommended USE flags that Funtoo developers believe give a functional binary).  
  
At the start of 2007, Roy Marples announced the ongoing development of baselayout-2, containing a rewritten init script coded in C and allowing POSIX sh init scripts instead of forcing the use of bash. By mid 2007, Roy Marples had re-implemented the Gentoo init script design created by Daniel Robbins, using an entirely new code base. Alpha and pre-release baselayout-2 snapshots were added to Gentoo's Portage tree as an optional component.
+
Proposed set of packages:
  
Towards the end of 2007, Roy Marples retired as a Gentoo developer. Baselayout-2 was still in the pre stage, and aside from the gentoo-fbsd users, it was masked. However, Roy Marples desired to keep the baselayout-2 project moving forward as an independent project. The Gentoo Council permitted Roy Marples to release OpenRC under the 2-clause BSD license, managed by him as an external project.  
+
'''Core Applications:'''
 +
* Critical packages of stage3 that provide the Funtoo base system.
  
Around mid-2010, Roy Marples decided to no longer maintain OpenRC. At this point, he transferred development back to Gentoo. However, Daniel Robbins continues to maintain an independent, forked version of OpenRC for Funtoo Linux, which includes a Funtoo-specific network configuration
+
'''Server Applications:'''
system.
+
{| class="wikitable"
 +
|-
 +
! Name !! Port
 +
|-
 +
| Apache || www-servers/apache
 +
|-
 +
| Nginx || www-servers/nginx
 +
|-
 +
| MariaDB || dev-db/mariadb
 +
|-
 +
| MySQL || dev-db/mysql
 +
|-
 +
| PostgreSQL || dev-db/postgre-server
 +
|-
 +
| SQLite || dev-db/sqlite
 +
|-
 +
| PHP || dev-lang/php
 +
|-
 +
| Python || dev-lang/python
 +
|-
 +
| Ruby || dev-lang/ruby
 +
|-
 +
| Perl || dev-lang/perl
 +
|-
 +
| DRBD || sys-cluster/drbd
 +
|-
 +
| Puppet || app-admin/puppet
 +
|-
 +
| Heartbeat || sys-cluster/heartbeat
 +
|-
 +
| Pacemaker || sys-cluster/pacemaker
 +
|-
 +
| Corosync || sys-cluster/corosync
 +
|-
 +
| phpmyadmin || dev-db/phpmyadmin
 +
|-
 +
| Fail2Ban || net-analyzer/fail2ban
 +
|-
 +
| nmap || net-analyzer/nmap
 +
|-
 +
| traceroute || net-analyzer/traceroute
 +
|-
 +
| Samba || net-fs/samba
 +
|-
 +
| NTP || net-misc/ntp
 +
|-
 +
| Dovecot || net-mail/dovecot
 +
|}
  
= References =
 
<references/>
 
  
[[Category:Projects]]
+
'''Desktop Applications:'''
 +
{| class="wikitable"
 +
|-
 +
! Name !! Port
 +
|-
 +
| GNOME || gnome-base/gnome
 +
|-
 +
| KDE || kde-base/kde-meta
 +
|-
 +
| XFCE || xfce-base/xfce4-meta
 +
|-
 +
| Awesome || x11-wm/awesome
 +
|-
 +
| Ratpoison || x11-wm/ratpoison
 +
|-
 +
| Xmonad || x11-wm/xmonad
 +
|-
 +
| Openbox || x11-wm/openbox
 +
|-
 +
| Fluxbox || x11-wm/fluxbox
 +
|-
 +
| Firefox || www-client/firefox
 +
|-
 +
| Google Chrome || www-client/google-chrome
 +
|-
 +
| Chromium || www-client/chromium
 +
|-
 +
| Chrome Plugins for Chromium || www-plugins/chrome-binary-plugins
 +
|-
 +
| Google Talk Plugin || www-plugins/google-talkplugin
 +
|-
 +
| Adobe Flash Player || www-plugins/adobe-flash
 +
|-
 +
| OpenJDK || dev-java/icedtea
 +
|-
 +
| ISO Master || app-cdr/isomaster
 +
|-
 +
| LibreOffice || app-office/libreoffice
 +
|-
 +
| GIMP || media-gfx/gimp
 +
|-
 +
| VLC || media-video/vlc
 +
|-
 +
| Filezilla || net-ftp/filezilla
 +
|-
 +
| Pidgin || net-im/pidgin
 +
|-
 +
| Hexchat || net-irc/hexchat
 +
|}
 +
 
 +
'''Command Line & Tools Applications:'''
 +
{| class="wikitable"
 +
|-
 +
! Name !! Port
 +
|-
 +
| genlop || app-portage/genlop
 +
|-
 +
| gentoolkit || app-portage/gentoolkit
 +
|-
 +
| Dash || app-shells/dash
 +
|-
 +
| GNU Screen || app-misc/screen
 +
|-
 +
| hddtemp || app-admin/hddtemp
 +
|-
 +
| logrotate || app-admin/logrotate
 +
|-
 +
| pwgen || app-admin/pwgen
 +
|-
 +
| syslog-ng || app-admin/syslog-ng
 +
|-
 +
| sysstat || app-admin/sysstat
 +
|-
 +
| Parallel Bzip2 || app-arch/pbzip2
 +
|-
 +
| Parallel GZ || app-arch/pigz
 +
|-
 +
| Parallel XZ || app-arch/pxz
 +
|-
 +
| vim || app-editors/vim
 +
|-
 +
| nano || app-editors/nano
 +
|-
 +
| Telnet || net-misc/telnet-bsd
 +
|-
 +
| Ethtool || sys-apps/ethtool
 +
|-
 +
| GPT fdisk || sys-apps/gptfdisk
 +
|-
 +
| smartmon || sys-apps/smartmontools
 +
|-
 +
| ccache || dev-util/ccache
 +
|-
 +
| Mutt || mail-client/mutt
 +
|-
 +
| htop || sys-process/htop
 +
|-
 +
| lsof || sys-process/lsof
 +
|-
 +
| vixie-cron || sys-process/vixie-cron
 +
|}
 +
 
 +
Of course this is just a list of applications that I've deemed important for server and desktop users. More applications should be added so that we can filter mostly used and important applications, from other more fringe applications.
 +
 
 +
== Other ==
 +
 
 +
/etc/gentoo-release -> /etc/funtoo-release  (rename this file)
 +
 
 +
should contain information for the currently installed release:
 +
 
 +
Example:
 +
<pre>
 +
Funtoo-13.1-STABLE  (January 2013)
 +
Funtoo-13.2-RELEASE (May 2013)
 +
Funtoo-13.3-RELEASE (September 2013)
 +
Funtoo-14.1-RELEASE (January 2014)
 +
Funtoo-14.2-RELEASE (May 2014)
 +
Funtoo-14.3-RELEASE (September 2014)
 +
Funtoo-15.1-STABLE  (January 2015)
 +
</pre>
 +
 
 +
[[Category:Internals]]
 +
[[Category:FLOP]]
 +
{{FLOPFooter}}

Revision as of 21:24, 23 February 2014

Original Author(s)
Fearedbliss
Current Maintainer(s)
Fearedbliss

Funtoo Linux Optimization Proposal: Release Engineering

This is a proposal to implement a strong release engineering infrastructure for Funtoo Linux. Funtoo currently is _only_ a rolling-release distro and does not have the _option_ to also be non-rolling. In order to create a more stable Funtoo system, this proposal will be offering a few things that we can do to make that happen.

Jonathan Vasquez (fearedbliss)

Version 0.2

Introduction

This is a proposal to implement a strong release engineering infrastructure for Funtoo Linux. Funtoo currently is _only_ a rolling-release distro and does not have the _option_ to also be non-rolling. In order to create a more stable Funtoo system, this proposal will be offering a few things that we can do to make that happen.

The below proposals will not change Funtoo from a rolling-release system to a non-rolling release system. It will simply add the option to be non-rolling. Funtoo will also not be a binary distro. It will still be a source based distro but it will also have the ability to use binaries for a few select packages (Basically the Gentoo Reference Platform will be restarted and improved).

I believe that this will also make running Funtoo for users that want further stability and/or users that are running Funtoo as a server in an enterprise environment/or otherwise, more feasible.

The following things are proposed:

  • Semi-rolling release model for Funtoo-RELEASE and Funtoo-STABLE (Funtoo-CURRENT will stay rolling release)
  • A Complete Core OS
  • A set of monitored applications that will be checked for stability and consistency

Semi-rolling Time Based Releases

The semi-rolling release model is a hybrid between a rolling release and just a regular release. This means that instead of bring new packages in all the time (rolling release), and instead of just completely freezing everything and bringing new packages/features every X months, we can have a middle ground where we can branch the Funtoo-CURRENT git branch and then focus on stabilizing that tree. Once we stabilize it, people can use it without having to worry about major version upgrades. The user can then use this branch until another branch later in the future is created. The user can then easily upgrade to the new branch by switching their SYNC variable.

So essentially it is a slow rolling-release (or semi-rolling or rolling-release with speed bumps).

Names for Funtoo's 3 git branches:

  • Funtoo-CURRENT (Latest Developments - HEAD. This is the normal funtoo-current tree.)
  • Funtoo-RELEASE (Just a release in a specific point in time - a branch of Funtoo-CURRENT is created, frozen, and stabilize.)
  • Funtoo-STABLE (This is the same as a RELEASE but it is supported for a longer period of time).

Which branch is for what person?

The Funtoo-CURRENT branch is for people who want to be on the bleeding edge all the time. You will get the latest updates, and here is where all the development happens. Your system might not be fully stable all the time, and things might fail to compile. This is literally the traditional Gentoo rolling-release model. If you are used to using Gentoo/Funtoo, and want to continue using your system the way it has always been, this is the branch for you.

The Funtoo-RELEASE branch is for people who want to be rolling and receive new features but be more stable than Funtoo-CURRENT by using a frozen portage tree at a specific point in time that is audited for stability.

The Funtoo-STABLE branch is for people who prefer stability and don't need the latest features that are in the RELEASE branches. This branch is frozen for a longer period of time.

Example of 4 month RELEASE cycle, and a 2 year STABLE cycle

For the branch developments: Let's picture a 4 month RELEASE cycle (semi-rolling), and a 2 years STABLE cycle. If we expand this starting from January 2013, we would get the following releases over two years:

Funtoo-13.1-STABLE  (January 2013)
Funtoo-13.2-RELEASE (May 2013)
Funtoo-13.3-RELEASE (September 2013)
Funtoo-14.1-RELEASE (January 2014)
Funtoo-14.2-RELEASE (May 2014)
Funtoo-14.3-RELEASE (September 2014)
Funtoo-15.1-STABLE  (January 2015)

This gives you 2 STABLE releases in two years and 5 RELEASEs in between. That's a total of 7 releases. STABLE releases only get bugfixes and security updates. RELEASE are for people that want to get the latest bleeding edge stuff, but still want to be stable within RELEASEs.

For people that are used to the normal Gentoo/Funtoo stuff, you could just stay on the Funtoo-CURRENT branch.

Example of 3 month RELEASE cycle, and a 2 year STABLE cycle

Funtoo-13.1-STABLE  (January 2013)
Funtoo-13.2-RELEASE (April 2013)
Funtoo-13.3-RELEASE (July 2013)
Funtoo-13.4-RELEASE (October 2013)
Funtoo-14.1-RELEASE (January 2014)
Funtoo-14.2-RELEASE (April 2014)
Funtoo-14.3-RELEASE (July 2014)
Funtoo-14.4-RELEASE (October 2014)
Funtoo-15.1-STABLE  (January 2015)

If we have have a 3 month (semi-rolling) cycle, we would end up with 2 STABLE releases and 7 RELEASEs within two years. This is a total of 9 releases.

What will these branches contain? What will they focus on?

Funtoo-RELEASE and Funtoo-STABLE branches will only focus on the stability of specific packages that we are deciding to maintain at a specific point in time. All outside packages can be installed and maintained by outside package mantainers.

A Complete Core OS

An operating system is not just a stage3 tarball. The stage3 will not boot by itself, but rather needs the user to compile a kernel and install a bootloader. We should have a well tested default kernel that is tested for stability. This will speed up deployments and will provide predictability for kernel modules, and other applications that rely on a kernel. We will also need to provide a way for the system to boot this kernel. Thus a default bootloader should be provided.

Core OS:

  • stage3 (Minimal @system applications needed for a functional Funtoo base system)
  • kernel (bliss-kernel can become the base of funtoo-kernel - or another kernel you think is good)
  • bootloader (a default bootloader to provide a seamless, fast, and easy deployment experience)

Monitored Set of Applications

In order for us to make a release stable, we will need to monitor a set of applications that we believe are essential for people that want to install servers and desktops. All of the monitored applications should work fine, they should be able to compile with no bugs (If the user is compiling), and they will also have binaries available. (The binaries will be compiled with the default and recommended USE flags that Funtoo developers believe give a functional binary).

Proposed set of packages:

Core Applications:

  • Critical packages of stage3 that provide the Funtoo base system.

Server Applications:

Name Port
Apache www-servers/apache
Nginx www-servers/nginx
MariaDB dev-db/mariadb
MySQL dev-db/mysql
PostgreSQL dev-db/postgre-server
SQLite dev-db/sqlite
PHP dev-lang/php
Python dev-lang/python
Ruby dev-lang/ruby
Perl dev-lang/perl
DRBD sys-cluster/drbd
Puppet app-admin/puppet
Heartbeat sys-cluster/heartbeat
Pacemaker sys-cluster/pacemaker
Corosync sys-cluster/corosync
phpmyadmin dev-db/phpmyadmin
Fail2Ban net-analyzer/fail2ban
nmap net-analyzer/nmap
traceroute net-analyzer/traceroute
Samba net-fs/samba
NTP net-misc/ntp
Dovecot net-mail/dovecot


Desktop Applications:

Name Port
GNOME gnome-base/gnome
KDE kde-base/kde-meta
XFCE xfce-base/xfce4-meta
Awesome x11-wm/awesome
Ratpoison x11-wm/ratpoison
Xmonad x11-wm/xmonad
Openbox x11-wm/openbox
Fluxbox x11-wm/fluxbox
Firefox www-client/firefox
Google Chrome www-client/google-chrome
Chromium www-client/chromium
Chrome Plugins for Chromium www-plugins/chrome-binary-plugins
Google Talk Plugin www-plugins/google-talkplugin
Adobe Flash Player www-plugins/adobe-flash
OpenJDK dev-java/icedtea
ISO Master app-cdr/isomaster
LibreOffice app-office/libreoffice
GIMP media-gfx/gimp
VLC media-video/vlc
Filezilla net-ftp/filezilla
Pidgin net-im/pidgin
Hexchat net-irc/hexchat

Command Line & Tools Applications:

Name Port
genlop app-portage/genlop
gentoolkit app-portage/gentoolkit
Dash app-shells/dash
GNU Screen app-misc/screen
hddtemp app-admin/hddtemp
logrotate app-admin/logrotate
pwgen app-admin/pwgen
syslog-ng app-admin/syslog-ng
sysstat app-admin/sysstat
Parallel Bzip2 app-arch/pbzip2
Parallel GZ app-arch/pigz
Parallel XZ app-arch/pxz
vim app-editors/vim
nano app-editors/nano
Telnet net-misc/telnet-bsd
Ethtool sys-apps/ethtool
GPT fdisk sys-apps/gptfdisk
smartmon sys-apps/smartmontools
ccache dev-util/ccache
Mutt mail-client/mutt
htop sys-process/htop
lsof sys-process/lsof
vixie-cron sys-process/vixie-cron

Of course this is just a list of applications that I've deemed important for server and desktop users. More applications should be added so that we can filter mostly used and important applications, from other more fringe applications.

Other

/etc/gentoo-release -> /etc/funtoo-release (rename this file)

should contain information for the currently installed release:

Example:

Funtoo-13.1-STABLE  (January 2013)
Funtoo-13.2-RELEASE (May 2013)
Funtoo-13.3-RELEASE (September 2013)
Funtoo-14.1-RELEASE (January 2014)
Funtoo-14.2-RELEASE (May 2014)
Funtoo-14.3-RELEASE (September 2014)
Funtoo-15.1-STABLE  (January 2015)