DIET-PC (DIskless Embedded Technology Personal Computer) is a Do-It-Yourself open source thin client software kitset, allowing IT professionals to construct generic- or special-purpose thin clients, or other network appliances, using commodity x86 PC or PowerPC Mac hardware.

DIET-PC is based on an embedded Linux O/S running entirely in RAM, loaded over the network via TFTP. The O/S is fully self-contained and, with the possible exception of the application service protocol, communicates with its environment solely by means of industry standard IP protocols. Consequently the Linux nature of the O/S is largely hidden from and irrelevant to the user. Incorporated technologies include Etherboot, SysLinux, Linux kernel, Squashfs, Unionfs, Busybox, X.Org, RDesktop, TightVNC, Citrix ICA Client, and Xine.

The sole purpose of a DIET-PC is to launch a small, stateless client program that connects to a remote server by means of an IP protocol. The program can be a general-purpose graphical client such as an X11, RDP, ICA or RFB display manager, or a special-purpose client such as a character-based or GUI database front-end. Thus DIET-PC is suitable for purposes such as a point-of-sale or factory floor terminal, touch-screen kiosk, etc. as well as a general purpose thin client.

DIET-PC's kitset approach aims to avoid unnecessary bulk by allowing the developer to select only the components relevant to his or her system, and to improve efficiency by optimising DIET-PC for his or her needs. Consequently, to deploy DIET-PC the developer will need a Linux development platform and some Linux system administration or UNIX shell experience.

To help developers customise components to their needs with minimal difficulty, DIET-PC compromises run-time efficiency a little in order to aid debugging and to better conform to Linux standards. Fully featured GLibC and Init are used, rather than cut-down embedded alternatives, and a writable filesystem with a conventional layout is used. Administrative tools that are not necessary for end-user operation, such as vi, are included to allow on-the-fly problem resolution.

The price paid for standardisation and self-containment is greater resource utilisation. Although DIET-PC will run on 80386 and up, it is really intended for Pentium or better with at least 32 Mb of RAM. DIET-PC on new hardware will outperform most commercial thin clients for a comparable price.

The still experimental PowerPC port of DIET-PC will run on any PowerPC-based Apple computer with a "New World" ROM (OpenFirmware).

DIET-PC vs Other Thin Client Flavors
Summary

• Intended for IT professionals with Linux experience, not end-users or amateurs
• Developer-friendly
• Smaller (than equivalents at the functional high-end)
• Simpler (with respect to code complexity, not integrator convenience)
• Traditional software layout and configuration methods
• Less features
• Better tested
• Potentially faster
• More secure

DIET-PC's target audience and design philisophy differs from that of most other Linux-based thin flavors, so it does not aim to compete with them. In fact, the DIET-PC developer has a close working relationship with the Thinstation developers, from which both projects have benefitted.

The principal difference between DIET-PC and other Linux thin client flavors is that DIET-PC is predominantly a flavor by developers, for developers. It is deliberately promoted as a general embedded framework rather than a thin client appliance. This is not to say that DIET-PC cannot be deployed as a thin client with relative ease, but rather that the focus is on underlying technologies rather than "icing on the cake" such as web-based configurators. DIET-PC is not intended as an end-user product, but rather as a starting point for an IT professional to build an end-user product.

Accordingly, DIET-PC aims to be more developer-friendly than other flavors. DIET-PC filesystem layout and underlying glibc are "traditional", rather than the abbreviated layout and obsolete/cut-down libc used by most other flavors, so that in most situations the developer ought to be able to transplant binaries compiled on his/her native Linux platform directly into DIET-PC, rather than use a dedicated cross-compiler or build environment.

Despite this, DIET-PC is small - not particularly small by embedded standards, perhaps, but almost certainly smaller (uncompressed) than any other Linux thin client with comparable features and hardware support. There are several smaller embedded Linux flavors with a GUI (typically UcLibC plus Kdrive/TinyX or SVGALib), but these are much more limited than a full-featured GlibC-plus-Xorg solution, and are usually intended for use with very specific hardware. DIET-PC is intended primarily for (relatively) high-performance graphics on widely-available general-purpose hardware. While you could use DIET-PC for non-GUI appliances (eg. a router or firewall), there are many alternative embedded Linux flavors that are better suited to this task. Its lightweight but conventional design could make it useful for distributed processing projects, however.

A major technical difference between DIET-PC and most other thin client flavors is the use of a read-write (ext2, initramfs, or unionfs) root filesystem, rather than a read-only one. This avoids the need for complex non-intuitive workarounds, and creates a more familiar working environment for experienced Linux system administrators. Shell script integration is kept to a minimum in DIET-PC, and also kept fairly concise and readable.

The other major technical difference is that DIET-PC is not "variable-driven". There is no single configuration file, parsed by shell scripts and used to dynamically generate application-specific configuration files, as there is in most other flavors. Each DIET-PC subcomponent is configured in the "normal" way for that software, following existing standards and best practices wherever this is open to intepretation. With the exception of ICA Client and boot scripting, DIET-PC avoids inventing a new DIET-PC-specific layer of abstraction above that of the underlying software components. The result is a dramatic reduction in complexity (particularly the amount of shell script required), at the expense of convenience for inexperienced integrators.

Reduced complexity means less bugs. The DIET-PC developer is also very fastidious with regard to pre-release testing, which produces a reliable, high quality result, albeit with a slow release rate and a small range of evaluated hardware. The DIET-PC developer is a strict adherent to the KISS principal, and therefore likely to be unsympathetic to requests for features that have simpler but costlier alternatives, eg. embedded browser etc.

Reduced complexity means less code to run. If the integrator includes only the packages he/she needs and builds his/her own kernel tailored to the target hardware, as recommended, the resulting system will perform better than one-size-fits-all plug-and-play equivalents.

As the DIET-PC developer has a background in high-security IT environments, DIET-PC also has a security focus. Properly locked down with developer conveniences turned off, it is more secure than any other open source thin client flavor known to the developer. As always, however, high security comes at the cost of reduced operator convenience.