Tobi Waves

by Mark Burgess

The increasing availability of mobile communication devices changes our society. Appointments become fluid and can be changed up to the last minute as an SMS will inform the other party of the new location in space and time. People who are physically in the same room can easily avoid any communication with each other as they keep connected to their "friends" over their mobile devices.

On a sociological level the availability of mobile communication devices has not yet been integrated into the framework of our social standards. Where is it appropriate to use a mobile phone? Does the availability of a connection to your peer grant you permission to change appointment times at the last minute? Is it acceptable to have a mobile and turn it off?

Challenges for system management in this context are: Diversity as many different technologies will be around until (if) a unified standard emerges. Stability in the face of environmental noise.

We must find new ways of keeping the systems within our realm of responsibility in some organization. Firewalls make little sense in an environment with a wild mix of interconnected private and company devices. VPNs are giving a hint at things to come.

How can we find system management methodologies for diverse, mobile and changing device populations. Looking at natural behavior of birds (swarms) or ants (hives) give clues on how organization can work in such environments. Even today kids can be seen to swarm around town governed by SMS messages they exchange.

For system management this means that strict central control is a thing of the past. Maybe stable existing structures which allow for other devices to integrate them self will work. There is no point in trying to stop the advance of these new technologies. We rather have to integrate them into our environment and adapt the environments to them.

A secure system is one where the risks are known and have been deemed acceptable.

by Richard Moore of IBM

Richards group is occupied with getting RAS (Reliability, Availability and Serviceability) into Linux.

In order to get Linux established with previous "Big Iron" customers, a whole new set of requirements becomes important.

As Reliability is not really achievable, the aim is to reach pseudo reliability which means to hide failing elements of the system from other system components, probably taking a performance hit while doing so.

In a 2 CPU machine the failure of a single CPU can be recover gracefully by shifting the workload to the one working CPU.

The Serviceability component means that the system must have the means to detect failing components, best before they fail completely and then replace them. Serviceability is not limited to error detection but encompasses all elements which make a system serviceable. So this includes manuals, problem correlation, debugging tools, logging. Compared to what is available for IBM 390 the Linux offering is still in an embryonic state. Many tools are available, but they are often not yet integrated into the mainline kernel nor is there a consensus on which tools to use. The consensus is still Syslog which is not easily machine parseable and thus does not lend itself to automation.

The big advantage of Linux is that there is virtually no old code in the system compared to old systems like Windows or big iron machines which have a rich heritage of old code. Linux developers have a tendency to not shy away from ruthlessly eliminating bad code. They rather break an interface then keeping a bad one around. The effect is, that the systems are cleaner and easier to maintain.

The documentation problem gets solved in part by the much better code quality in Linux (due to peer review) and the extreme size of the kernel developer community. Also because source is available a lot of documentation is in the source itself.

Due to the versatile workloads of Linux systems all functionality in the serviceability must be tailored to the specification of the local setup. There is not much use in a mobile phone dumping core into its flash ram.

Murry Stokley of FreeBSD Mall is one of the FreeBSD release engineers. In this talk he told about FreeBSD development, organization and what is new and cool in FreeBSD 5.0.

Development and release management

Everything is on CVS

There is a current branch and a stable branch. Material from the current branch gets merged back into the stable branch when they have gotten enough testing.

Over the last 12 months 160 people have committed code directly via cvs to the FreeBSD kernel. Non commiters are welcome to submit patches via the gnats bug tracking system.

FreeBSD is highly organized with elected leadership, developer documentation, release engineering, core team.

Tinderbox environments constantly test the current release.

Release 4.x remains supported in the foreseeable future as most FreeBSD sites have very high stability requirements.

New Features In 5.0

Support for kernel scheduled entities which leads to better threads

Device file system

Bluetooth and Firewire support

Mandatory Access Control

UFS2 with bigger inodes to store extended attributes

GEOM - modular disk I/O transformation framework

Device monitoring daemon devd to manage pcmcia and other plugable devices

Soft Updates (fs enhancement) with snapshots and background fsck

No more perl dependency in the base system

New platforms: ia64 and sparc64

More information is on (www.freebsd.org ...)

by H. Peter Alvin of Transmeta

As the Linux kernel developed, the root file system became more important and had to be able to live in more and more different places, like configurable locations on the disk or even on the network. Eventually even in RAM as initrd entered the scene. This caused all sorts of special cases needing handling to support all these variants. And all this is happening inside the kernel which is tough for development as testing is really painful. So the ideal case would be to be able to organize the booting process in user space.

The solution is to have a virtual root for the system, called rootfs using ramfs code. As the kernel starts, / is rootfs and the actual root filesystem becomes a simple overlay mount. This means that it is possible to use an initial ram disk and get rid of it later. As the kernel threads live in their own world (rootfs).

To simplify matters further, initrd gets replaced with initialramfs which is populated by loading one or several cpio archives. The cpio archives can come from the disk, from the net or even be compiled into the kernel itself. They provide the files required in early user space. To allow initialramfs to be small and still provide a useful environment, a special stripped down C library called klibc was developed to provide library code for this case.

Programming in this environment is almost as simple as normal userspace programming. Malloc works as expected, file and socket handling is there. Still there are restrictions, as all the rest of the system is not up yet. STDIO is available but it is very slow especially for reading, as klibc does not implement buffering to save space.

Candidates for early Userspace

With this infrastructure the possibilities become endless. The following candidates for early user space come to mind:

Partition detection

Determining the root filesystem type

Network booting

Caveat

Note that this is very much an ongoing development and only available in 2.5.x. (www.kernel.org ...) has more information.