Linux: Past, Present, and Future

Theodore Ts'oVA Linux Systems

tytso@mit.edu

Linux Past

July, 1991 --- Linus Torvalds releases the first version of Linux

1992 --- First fully functional system released. X Windows ported to Linux

1994 --- TCP/IP support added. Release of Linux 1.0

1995 --- Ported to Alpha and Sparc platforms. Release of Linux 1.2

Linux History, Con't.

1996 --- SMP supported. Release of Linux 2.0

1997 --- Month Linux magazines started in Japan, Poland, Germany, Yugoslavia, and the U.K. Estimated 3.5 million users

1998 --- Linux is discovered by the mass media; lots of magazine articles

January, 1999 --- Linux 2.2 released. Estimated 7-10 million users.

In the last year....

Major Linux companies go public Red Hat in August, 1999 VA Linux in December, 1999

Linux development for 2.3 kernel series continues.

Currently, estimated 20 million users.

The Mindcraft Benchmark

Now quite infamous

Microsoft's IIS server losing market share Security Issues Performance on Dynamic pages beaten handily by

Apache

MS engineers decide to find a weak spot in Linux/Apache, benchmark it, get an independent 3rd party to verify the results.

Standard Marketing Ploy

Nature of the Benchmark

Static files only

4-way SMP CPU

4 100 megabit ethernet card

Required special service pack which was just released, that rewrote the entire networking stack and made it use fine-grained locking. (This in a service pack?)

Only Something Went Wrong...

Mindcraft released the results

Results were so counterintuitive that the Slashdot community goes ballistic

Weaknesses in the benchmark were quickly found The "independent" benchmark was really conducted on

the MS campus, with MS engineers present. A change in any part of the benchmark conditions

caused the results to change drastically. Benchmark didn't reflect real-world conditions.

Yet the Results Were Real...

The Mindcraft benchmark did point out a real problem.

It was actually helpful to the Linux Community It encouraged developers to focus on fixing this

problem. It shows that Linux was real enough threat that

Microsoft was taking Linux seriously. Ultimately, it helped Linux from a marketing perspective as well.

Microsoft Just Filed a Bug Report.....

Linus Torvalds reflected at his Usenix talk... At first I was pissed.... ... then I realized that MS had just filed a bug report... ... just in a non-traditional place (the WSJ instead of

the linux-kernel mailing list).

Linux Present

2.4 almost ready to be released (really!)

2.4 is much more scaleable 64 Gig memory on IA32 64 bit file access on 32-bit platforms (LFS API) 32-bit uid, gid Much better SMP scaleability

Fine-grained locking (networking, VFS, etc.)

Better BUS support (PCMCIA, USB, firewire) NFS v3, NFS improvements RAW I/O

Other Linux Developments

Development of Linux on the Desktop GNOME and KDE making impressive progress Sun has just recently open-sourced Star Office

Expansion of Linux into the Embedded sector Various companies (FSM labs, Atipa, Lineo, Red Hat)

agressively attacking this market Various products are being built around Linux

Tivo MP3 players

Linux Future

Still a lot of work to be done!

Linux needs more work on scaleability Better SMP scaleability, NUMA support

Hopefully without sacrificing performance on UP and 2SMP systems

Better I/O performance (especially for block devices)

Linux as an Industry Resource

OS enginering as a cost center, not a profit center

Multivendor, cooperative efforts Example: Trillian, Monterey

X Consortium Model Vendors contribute code for better functionality

Do what is necessary in that company's economic self-interest

Because of the overhead in merging changes to a moving mainline, incentive to merge those changes into the mainline

Plays well with Linux

Challenge for companies that want to leverage Linux (and really, the open source community in general)

How to get changes into the kernel?

Case study of how NOT to do things: Hot swap PCI code: donated by Motorola Changes were scattered all over the kernel, and were

"ugly" Motorola threw the work over the transom, no

preparatory work, and no followthrough

The Linux Kernel Development Community

There is no cabal Deliberately avoided a formal core team --- motivated

by watching some of the political problems in the early NetBSD, FreeBSD, OpenBSD days

The Linux Kernel Development Community

There is no cabal Deliberately avoided a formal core team --- motivated

by watching some of the political problems in the early NetBSD, FreeBSD, OpenBSD days

There is a cabal There is a group of people who know each other and

trust each other.

The Linux Kernel Development Community

There is no cabal Deliberately avoided a formal core team --- motivated

by watching some of the political problems in the early NetBSD, FreeBSD, OpenBSD days

There is a cabal There is a group of people who know each other and

trust each other. Very much an old boys club meritocracy

Getting changes into the Kernel

Changes must be clean Long-term maintainability is more important than any

specific feature, or a particular vendor's timeline Be prepared to prove that no simpler solution will work. Good test for cleanliness: a change should solve more

than one problem. Justify the change two ways: why you need it, and show how it

fixes an existing problem in the kernel

Changes should be small. Break megapatches into functional chunks

Getting changes in, con't.

Communication, communication, communication Talk to folks in advance --- some people may be

working on the problem already. When submitting the patch, explain why certain

approaches were taken etc.

Be prepared for changes LKDC may want to make changes before they are

comfortable with it. Most common reason: to make the code more general.

Suggestion to Companies

Hire or allocate one or more kernel engineers Make joining the kernel development community be

part of their job description Part of their time should be spent helping to improve

the general linux kernel (not necessarily just the specific project(s) their company is focused upon.)

Functioning as the liaison between the company and the LKDC, they can help feed enhancements into the Linux kernel so they are accepted into the mainline.

Many companies have used this strategy quite successfully.

Conclusion

Linux: coming from its hobbist past, moving into a computer industry future

Challenge: Keeping the advantage of Linux-as-a-hobby, while growing Linux into the enterprise space.

This requires a partnership between the Linux Kernel Development Community and our Industry partners

Some amount of cultural impedence matching may be necessary, but I'm confident we can be successful