T2 adheres to standards.
T2 gets as close to standards as it can. But with a pragmatic view. For example it uses the FHS (File Hierarchy Standard) and LSB (Linux Standard Base), but with exceptions where impracticable.
T2 makes no assumptions about the past.
If you have been using one of the major distributions like SuSE or RedHat you'll realise a lot of items have been patched in. This increases the dependency on those distributions (intended or not). It is hard for the larger distributions to revert on this practise because of backward compatibility issues (when upgrading). T2 will patch some sources (for example when a package does not comply with the FHS), but leaves it to an absolute minimum - for example no added features or branding.
The same philosophy applies to T2 itself. T2, and its package system, have gone through several redesign phases and little consideration is given toward backward compatibility. This may be inconvenient, but the fact is that every incarnation of T2 is cleaner, yet more powerful than its predecessor.
T2 is built optimally.
With T2 all packages are built with the optimisations you want and the target platform. Other distributions usually build for generic i386 or Pentium. With T2 you can automatically build Linux, glibc, X.org, KDE, GNOME and the other CPU intensive packages - yes the whole distribution! - optimized for your CPU.
T2 uses few resources.
T2 build and installation scripts are Bash scripts. Due to the optimization for a given CPU, the non-X11 based installation and setup as well as the lightweight init scripts you can save many resources on old computers. Additionally space optimized alternative C libraries such as dietlibc and uclibc as well as minimal add on tools such as busybox and embutils can reduce resource use drastically. Also available are more lightweight choices in various other areas from Xfce to lightweight http servers, init systems, ...
Services have to be turned on explicitly
Also packages and services have to be turned on explicitly, manually. When you boot a fresh T2 installation you'll find the minimum of services configured to be active.
From the system administrator's perspective this is ideal for new installations. It compares favourably with cleaning up and closing all services of a bloated commercial distribution.
T2 is ready to burn on a CDROM.
After building T2 from sources you can burn the (target) T2 distribution directly onto CDROM for installation on other machines (and pass it on to other people).
T2 can easily be installed over a network.
The installation process is terminal based. Installing remotely and configuring the new system over a network connection is not uncommon.
There is no other distribution like T2 Linux.
By now it should be clear T2 does not look like any of the other distributions. Debian, while also a collaborative effort, is a great distribution but is in many ways more like the commercial editions. The BSD variants come closer.
The only one that has come close recently are OpenEmbedded (Yocto) and Gentoo. It is interesting to see where these build-it-yourself (meta) distributions compare and differ to the System Develoment Environment T2:
Table 1.1. T2 SDE, OpenEmbedded (Yocto) and Gentoo compared
| T2 | OpenEmbedded (Yocto) | Gentoo |
|---|---|---|
| Bash based | proprietary BitBake based | Python / Bash based |
| chroot build | ??? | chroot build |
| developer and end-user oriented | developer oriented | end-user oriented |
| fully automatic package build type detection | BitBake recipes with inheritance | each package needs a full ebuild script |
| autodetected dependencies | manually hardcoded dependencies (many monkeys method) | manually hardcoded dependencies (many monkeys method) |
| sophisticated wrappers | ??? | hardcoded e.g. CFLAGS |
| installable, live, and firmware ROM images | firmware ROM images | rebuild on each system, LiveCD creation as add-on scripts (Catalyst) |
| multiple alternative C libraries | multiple alternative C libraries | just the single packages, no whole-build support |
| multiple init systems | ??? | just the single packages, no sophisticated pre-configuration |
| cross build of X.org and more | cross build of some (how many ???) | no integrated cross build support, seperate Embedded Gentoo effort |
| cluster build, distcc, icecream, ... | ??? | - |
| separated target config and custom file overlay | seperated target config, likewise | emerge, edit compile on each system |
| thousands of packages | mostly embedded package subset, not all desktop and server packages | more and more packages get removed (into external overlays, such as E17 et al.) |
The biggest difference is that Gentoo does not include the facility to predefine targets and their custom setup permanently. Instead on Gentoo everyone re-emerges all the packages via pre-built binaires or source code on each system. Inconvienient for developpers is, that Gentoo does not include an auto-build-system like T2 does. Each package needs a full .ebuild script where even the tar-balls extraction is triggered manually - and often even the resulting files are copied by hand. Gentoo and OpenEmbedded also are based on hardcoded dependencies - in contrast T2 determines them automatically and stores them into a cache.
The biggest difference to OpenEmbedded is that T2 uses normal shell scripts to implement the build system, while OpenEmbedded bases on a properitary BitBake tool and associated meta-data that must be explicitly installed and is yet a properitary format to learn. Getting started as well as the learning curve is way easier in the T2 world and thus it is most comfortable to use T2 as a foundation for building your own (specialized) distribution. It is therefore we call it a System Development Environment, abbreviated to: SDE. Also the T2 build system is faster and supports distributed cluster builds (via distcc and icecream) and compiler caching (via ccache). You can find more information about these tools at http://distcc.samba.org/, http://en.opensuse.org/Icecream and http://ccache.samba.org.
It has been stated T2 Linux is more BSD with a GNU/Linux core than anything else: T2 has a ports collection (called package repositories), a make world (called ./t2 build-target) and like OpenBSD prefers the disabled feature by default method. This may make OpenBSD T2's closest relative.