Hi, so while we are figuring out how to fix the image, we will start with a lecture,
One Way Forward, Finding a Path to What Comes After Unix by Liam Proven.
Hi, thank you. So this is my fourth FOSDEM talk, remarkably enough. Thank you for coming back
to listen to me again. I have presented three previous talks which were all on the theme of
the progression of the software industry and some misunderstandings. The first one was called
The Circuit Less Travelled and I talked a bit about alternate operating systems, people have
probably never heard of or met. Then in 2020 I did one called Generation Gaps which talked about
how the perceived threat of switching generations of tech and losing backwards compatibility is a
boom, not a cost. Then the last one I did in 2021 was called Starting Over and I talked about a
proposal for a next generation of operating system discarding 50 years of legacy baggage using a
memory technology called Optane from Intel which has since been cancelled, shows my an airing
finger on the pulse. Now I kind of want to go in a slightly different direction with this one. So
since I proposed this talk, something very sad happened, something inevitable but nonetheless
regrettable, a giant of 20th century software design, Niklas Theot died. So because of that and
in a small tribute I tried to slightly rework the introduction of the talk. Now Theot was famous
probably for what I feel was kind of only a relatively minor aspect of his career. For example
Theot studied and later taught in California for quite a while as a young man where he had a nickname
of Bucky and I rather like the idea of this dignified computer scientist was Bucky Theot.
In the days when he was teaching and studying the Unix system was being developed and people use
teletypes and teletypes are very roughly a printer with a typewriter plugged in and typewriters don't
have things like control and alt and shift and so on. And Theot proposed a mechanism for how
controller keys would work, modifier keys would work and the mechanism is still used, it's called
Bucky bits in his honor. He is of course famous for Pascal but one thing that I found is not
fully understood sometimes is how and why Pascal came about. Theot and the British computer scientist
Tony Hall were working with the Algol programming language committee to design the next version
of Algol and Theot proposed a relatively simple change to the language. The Algol committee rejected
it and went with a counter proposal which was rather more complicated and that became Algol 68
and killed the language forever. As a result lots of other programming languages got their chance
to grow in the sunshine when this giant fell and one of those was BCPL, BCPL gave rise to B, B gave
rise to C and Unix grew in part because Bucky Theot pulled out of the Algol committee. A lot
of what we work in and use today came from this. He didn't just do Pascal but Pascal had ramifications
people might not know today. The original operating system for the Apple Lisa was largely implemented
in Pascal. A version of Pascal or a derivative of Pascal called Concurrent Euclid was used to build
an operating system called Tunis which was a Unix. There was a Unix built in Pascal.
So now with lots of people getting interested in more typesafe languages to descend from C like
Rust and Go and D and whatnot. People were building Unix compatible operating systems in a Pascal
derivative in the 70s. Pascal of course became a huge hit partly due to Bolland's turbo Pascal and
that gave rise to Bolland Delphi and set much of the course of Microsoft Windows 3.
The more of all that, he didn't care and Theot instead went on and wrote a successor language
with more and better modularity called Modular but he immediately discarded that and he moved on to
a modular version of Pascal with more concurrency called Modular 2. That for a while was
the fastest compiler on the PC platform and was briefly very successful. He ignored that as well.
Late in Viet's career, only a few years before he retired, he wrote a wonderful short article
called A Plea for Lean Software. I have a screen grab of it which you can't see which is a slightly
skew if PDF from Viet's own homepage. It's only a few pages long. It's very readable. I really
recommend if you haven't seen it, Google it. But as a proof of the validity of the concept of
extremely lean, tiny, simple software, he moved on from Modular 2 and he came up with what is
arguably the masterpiece of his career, a system called Oberon. Oberon is a tiny Pascal-like language.
It has built-in concurrency primitives and the language also comes with a compiler and an editor
and an IDE which are all implemented in Oberon itself. Now, I wrote an obituary for Nicklaus
Theod for the register in early January and I couldn't come up with a clear source for how
many lines of code there were in Oberon. So I went to the project Oberon website. I downloaded the
zips of the core operating system. I unpacked them and I ran WC-L against them and it came out to
only just over 4,000 lines of code. 4,623 lines of code in 262 kilobytes of text files. That's an
operating system and a tiling windowing interface and an editor and a compiler.
When people talk about Lean Software and talk about how much smaller software could be,
I don't think people fully understand the scale of the issues we are facing these days.
So, when I talked about Oberon as an interesting candidate for maybe a successor to Unix for
a new technological generation, well, you know what, I think trying to propose a Pascal-related
language to an audience of Linux and Unix folks was probably the wrong audience.
The talk seemed to go down well but I've not heard of any results or anybody
particularly investigating although development in Oberon is still quite active. So,
I've come up with something else that might be a bit more familiar and close to home territory here.
FOSDEM is a FOS conference. It's all about FOS and unfortunately, or for better or for worse,
maybe I should say FOS these days is about Unix and Unix-related operating systems. Now,
a lot of people misunderstand that, I think.
So, Unix today is increasingly about Linux. I can see an open BSD developer in the audience down
there but increasingly Unix means Linux. But what is Unix? Now, the definition of what is
Unix changed in 1993. I just want to ask you guys, stick your hands up if you can remember the year
1993. We got quite a few grumpy old gits. Well done. Congratulations. Thank you. But about half
the crowd probably can't clearly remember 1993. In 1993, I can go to the 60s sadly for me. In 1993,
what Unix is changed. And a lot of people still haven't heard the news. Because in 1993,
Novell bought Unix system laboratories from AT&T and they donated the trademark of Unix to the
open group, famous for Motif and CDE and a few other things. They kept the Thrust Code and much
good it did them because there is a successor company to Novell which spone off Caldera and Caldera
bought Skow and changed its name to Skow and went crazy and sued its own customers. A derivative
sort of subsidiary company called Cinewoth are still trading. They're still selling operating
systems based on the original AT&T code base. Unix doesn't mean based on AT&T code and it hasn't
for 31 years. Unix now means passes open group compliance tests and those used to be called
POSIX. Effectively what used to be called POSIX now means Unix. If it passes compliance tests,
it's Unix. We have to pay for the trademark, right? So there are a few operating systems that
have paid. HP UX doesn't have a future because it only runs on Atenium and there's no more Atenium
kit. IBM AIX, I don't know if anybody heard but last year IBM shut down the AIX development team
in Boko Vatan and passed maintenance over to a team in India. Mac OS both on Intel and X6.
Both on Intel and ARM is certified but at least two or three Linux distributions have passed the
testing. They were all Chinese CentOS Linux derivatives but the point is they passed the
test and for a while the company's paid. Unix is Linux. Linux is a Unix. It's not Unix like
it is Unix and that upsets some Linux folks who like to think they're rebels.
Now, I had a family tree of Unix from Wikipedia here but you can't see it. It shows the original
development series at AT&T, Unix 3rd edition, 4th edition, System 5, lots of derivatives branching
off at various dates and of course off on its side with no direct connection Linux.
But I would argue if you take a step back, BSD did descend from originally the AT&T code base.
Cisco and AIX and Solaris and SunOS before it and HP UX and all of them still have roots in that
code base. You can consider all of the monolithic proprietary Unix as one branch. They've all got
shared ancestry. On the side of that there's all the branch which is Linux which is a separate
code base but taken by the same design. I would say Unix arguably is just all those as one. You
know what the implementation differences now are relatively minor. You know, I'm presenting,
he says. I'm using LibreOffice. I'm using a version that was released about two days ago.
I don't think that's why you can't see it. But LibreOffice, Firefox, bunch of other stuff,
you know, Chrome, Chromium, blah blah blah. They run on Mac OS, they run on Linux, they run on all
the BSDs. It's all close enough. But there is another branch of this family. Several systems
passed the testing and are called Unix that aren't because it's just a compatibility layer.
IBM's EOS still carries the branding. But it's a weird mainframe operating system which doesn't
even use things like ASCII. It's, it can act like, no, Unix but it's not a Unix. But there is
another branch of the family. The microconnors. There's a bunch of microconnel operating systems
out there which are Unix-like enough to pass the test. There's Mac OS, which is what I'm running
on here. There's QNICS, which not enough people have heard of. I think QNICS is very cool. It's a
Canadian system. It's tiny and it's mainly used in embedded systems. It runs lots of traffic lights
and engine management units. But if you ever owned a BlackBerry 10 device, that was QNICS.
And there's a couple of open source ones that have not set the world on fire like the GNU Heard
and Minix 3. Minix 3 is a true microconnel. But sadly, Dr. Andy Tannenbaum has retired.
Minix 3 is looking stagnant. I don't think there's been any commits in several years.
It'd be a great project for somebody to pick up. Minix has tens of millions, maybe hundreds of
millions of users. And probably half this room run Minix and you might not know it. Because Minix
runs on the embedded management chip inside all modern Intel processors from the Core i3,
i5, i7 onwards. They've all got Minix in there somewhere. But Intel didn't contribute much
code back and didn't contribute any money back. And so it didn't help Minix 3 at all.
So we've got two families, the big monolithic Unixers and the microconnel Unixers.
But they may not share the code base. But we all know what a Unix looks like, right?
It's probably written in C or something very much like C. It's probably got one big file
system that's rooted at a folder called slash. It's probably got a shell which uses the familiar
little cryptic short commands. It's probably got case sensitivity. But there are exceptions,
macOS 10, sorry, macOS. It's not case sensitive. It's case preserving. Still a Unix. It's still
compatible. It's passed the test. But you know what? All these charts, all of these sort of
generation diagrams and so on, show the AT&T Unix line going on and things branching off it at
third edition, fourth edition, fifth, sixth, seventh. And then they stop. But it didn't stop there.
And I think that's quite important. And my computer won't go to the next slide.
Have notes. Great. Thanks. So there is another line of descent. And I have a wonderful spinal
tap gag that you can't see. Research Unix continued in AT&T after the industry took what,
worked and ran with it and made it huge. But Dennis Ritchie and Ken Thompson and some others
did what Niklas the Up did. They ignored what the industry were doing with their earlier product
and they kept on. And there was research Unix eighth and then ninth and then tenth edition.
Very little trace of them seems to remain. I've tried to write about them. And when I've said
stuff that Wikipedia has links pointing to sources, mostly I get people angrily telling me I'm wrong,
but they can't actually provide an alternate story. What came back, what happened next,
I think, was interesting and significant. And a lot of this industry have neglected it.
By 1992, Unix was a massively important commercial system and the roots of what became
free BST and net BST were happening. But let's look at somewhat like the, what defines something
as being a Unix or Unix-like system. It's not about a GUI because Mac OS X passes the test,
but there's no X or anything like X in here. There's an optional X package, but it's not
defined by the GUI. It's not defined by case sensitivity. It's not defined by the kernel.
It's just, does it look like a Unix? Does it feel like a Unix? Well,
in the end, at the end of the 1980s, a change happened which brought the Unix industry of
proprietary workstations into conflict with the PC industry and cheap X86 kit. Because suddenly
it was affordable to buy, a reasonably capable 32-bit computer with a reasonably fast expansion
bus so you could have fast networking, cheap. And suddenly this created the conditions for
open source Unixes to take root and flourish and thrive. They grew in the soil of Windows.
I know a lot of people like to hate Windows, but Windows created a marketplace of cheap
32-bit hardware that was ideal for Linux to grow. Windows was not a particularly useful
platform on 286s and 286s were not particularly useful for most Unix-like systems.
What the Open Source Unixes that took root in the late 80s, early 90s, did not account for how
the hardware they were running on had changed. Traditional Unix was a mini-computer operating
system. It ran on a big shared box with no display of its own, no keyboard of its own,
just dumb terminals. And a lot of what and how Unix is and how it works is because of that.
It's focused on text files, it's focused on piping, it's focused on text editors.
It's because of the mini-computers that it evolved on. But by the 90s, computers won't like that
anymore. By the 90s, computers were standalone boxes with a graphical screen and a network card.
And Unix doesn't account for that well. I mean, Unix does networking, sure, you know,
there's things like NFS, but it's a bolt-on. You have to run external commands and mount
external file systems in particular places. Graphics are bolted on. There's very little
conception of them in the traditional Unix kernel. So, you know, everybody likes to hate on X11
these days, it works for me. But Wayland, they like to talk about how they're modernizing the
Linux and Unix graphics stack because Wayland works on FreeBSD. Well, Unix is about files,
everything in Unix is a file, right? So, go on, then, Wayland enthusiasts, tell me,
where in the file system can I find a window on the display of a Wayland box?
Go on, then, point me at the file that has the dimensions of the window.
Point me at a file that says where it is in the Z-order. Can't you show this is a
Unix display system? Because it doesn't sound like one to me.
But you know what? The research Unix team, well, thinking about stuff like that, and they
started to put stuff like that into Research Unix 10, and that finally became a product that was
announced in 1990. It's called Plan 9 from Bell Labs. It is effectively Research Unix 11, but
they didn't call it Unix, and they didn't call it Unix for a good reason. It looks a lot like
Unix because it's built in C and it's case sensitive and it has a fairly familiar shell,
but it's got networking right in the heart of the design where it should be. So, you can have
access to the file systems of other Plan 9 machines on your network, and they can have access to
your subject to permissions and so on. It has a built-in graphical windowing system, which went
through several iterations, but the one that it has now is called Rio, and in Rio, a window is also
a folder. It's a directory, and in that directory there are text files. You want to write to a window,
you put text in a file in a folder. That's what Unix is meant to be about, not
wretched gamer hacks like variable refresh rate and so on. I don't know, I don't. I'm frankly
indifferent to Wayland because there's not a single desktop I like to use that runs on the Wayland yet.
So, Plan 9 takes the idea of everything as a file and really means it, whereas it was just a marketing
slogan for traditional Unix, and that includes Linux and OpenBSD and FreeBSD and NetBSD and DragonflyBSD.
Everything really is a file. You don't need a network-aware windowing system to put windows on
another box on the network in Plan 9 because you can get it at their file system and you can just
write files into the file system and windows just happen. It makes X11 look very over complicated,
which the Wayland people would agree with, but it makes Wayland look like it was something
invented by Microsoft. And in a way, Plan 9 also invalidated all that 80s work that went into
micro kernels because a lot of the problems of micro kernel implementation just kind of go away
in Plan 9. It's not that it's better, it just kind of makes some of it irrelevant. One of the big
problems of micro kernels is you put all of the bits of your operating system that would be in the
kernel in separate little blobs, servers that run in user space, but they have to communicate with
each other to get the job done and that communication is slow and it becomes a bottleneck. Plan 9 just
has put it in the file system, which is the Unix way. So the original Plan 9, when they showed it
in the year 1990, at that point they had a code comparison and Plan 9 was actually just about
the same size as the new Mach micro kernel that Carnegie Mellon University was showing off then.
And I don't know if you know what happened with Mach. Mach had a whole load of operating systems
based on it. It was very cool in the late 80s. Deck OSF 1, which later became True 64, was based on
Mach. The PowerPC version of OS 2 is based on Mach. Only one of them is still around and really gets
much attention and it's Mach OS 10. And the way that they got it to work is they took a big chunk
of code from originally, I think it was 4.4 BSD, but now it's from free BSD, and they had that as
the Unix server, which provided all that nice Unix file compatibility stuff, but it was a bit too
slow, so they stuck it into the kernel. That's the XMU kernel behind Mac OS. It's Mach and a lot of
the stuff in free BSD that provides all those handy APIs. But all in kernel space. It's not really
a very micro kernel design anymore. So, as an aside, in case all of this sounds a little bit too
theoretical, one of the problems, if you put everything in the file system, of course, is where?
Where is it going to go? What's the layout of the file system? Back in 2011 on the register, I
predicted that the next big thing in Linux virtualization would be containers. It was the same
year that Docker launched. It's one of the couple of times in my life I really called it. Containers
are sort of CH routes on steroids, of course. All the file paths for a given process get a new
route directory, and since everything is relative to route, that means they're isolated. But the
problem is that on Unix there isn't a good clear separation between different types of namespace.
Unix doesn't just have the file system namespace. It's got user IDs, and it's got group IDs, and
it's got process IDs, and they're not in the file system as such. So, if you just have a different
file system, your process can still see other processes. It can talk to them. There is a feature
in the kernel now called C groups, which splits up those namespaces as well, and so it provides a
kind of isolation by sub namespacing multiple different traditional Unix namespaces.
But Plan 9 did that in 1990. It first shipped in 1992. Every process has its own namespace. Every
process has its own view of the file system. Every process is in a container.
That was announced a full decade before the first pre-BST would jail. This was a project put together
by two geniuses who really had a pretty good idea of where the industry was going to go,
and the industry ignored it. But, of course, there's always a bad side to go with a good side,
if Plan 9 is so clever, why aren't we all using it? Well, some of the reasons are easy.
Like Unix itself in its early days, it was a research operating system. It wasn't intended as
a product for commercial use. It wasn't sold, and it wasn't open source. But in 2000, Plan 9
3rd Edition did become open source under its own license, but they fixed that in 2014 when it was
re-licensed under the GPL. It's very, very minimal, and the conceptual design, especially the
namespaces, have penalties. So, because there isn't a real view of the real file system underneath,
there's a bunch of stuff we take for granted on Unix, which you can't do. There's no way to move
a file from one place to another, except by copying it and then deleting the copy.
There's no way to move a whole directory tree. The recommended way to do it is tar it and un-tar it
where you want it to be. There's no links. There's no hard links or soft links, because that would
break the clarity of there being no one mass underlying hierarchy, so no links. I know that
sounds a massive limitation, but you know what? As I said, I'm old. When I started in this industry,
I put in large commercial systems based on DOS, both the 4, even Windows 3, and DOS until DOS 5
didn't have a move command. You couldn't do it. The best you could do was copy it and then delete
the original. And you know what? I ran large file servers supporting hundreds of users.
Plan 9 is weird. It's unforgiving. It's strange, but you know what? It's...
They had an idea. They had a set of solutions to industry problems 30 years ago, and the industry
ignored them. So it's kind of understandable that they're a bit sore about that. There are many
talks of Plan 9, and I wrote about one of them a year or so ago called Nine Front. It has a famously
cryptic website, which is full of weird little in-jokes and things. I think it's fair. It's
legit. The whole industry has ignored that they've got better solutions to the stuff we've
implemented with massive stacks like Kubernetes. I'm somewhat neutral on the whole flat pack and
snap controversy in Linux these days, but you know what? The snap model is easy. You copy a
big compressed file. That's your app. The flat pack model is OS Tree. OS Tree is Git, but for binaries.
Anybody here who thinks they really understand how Git works and how it distributes those changes,
there's not. If you can't explain it and you don't understand it, it's not a good model.
The OS Tree people had a slogan in the early days. They said it was a better DOS than DOS and a
better Windows than Windows. Well, Plan 9 was a better Unix than Unix, but it wasn't better enough.
They didn't call it Unix because it breaks so much compatibility.
Plan 9 is kind of Unix 2.0. There was more work after that. There is also a successor to Plan 9
called Inferno. It solves other interesting problems, but I haven't got time. I deleted a whole page
and slide about that. The late great Bucky Viet made a plea for Lean software. When I wrote this
yesterday, I couldn't find a word, a line count for the successor to Oberon. Oberon is a tiny
single processor operating system. There is a successor, one of several called A2, which understands
multiple processors. It has a network stack. It has a web browser. It's a very basic one,
but the point is it's got a more conventional GUI. I estimated yesterday that it's maybe,
let's say, about 5 to 10 times bigger. There's a team in Russia actively working on A2,
and I asked on their Telegram channel last night, and they got back to me today. I said,
maybe it's 5 times bigger than the 5,000-odd lines of Oberon or 10 times bigger. Yeah, I was wrong.
It's 8,000-odd lines. That's a preemptively multitasking, multi-threaded
SMP operating system with a GUI and an IP stack in 8,000 lines.
Debian 12, for comparison, contains 1,341,564,204 lines of code. Source the Debian 12 release
announcement. One and a third billion lines of code, one and a third thousand million lines of code.
Nobody can read that. You won't live long enough to read that. For comparison, Google Chrome,
the Chromium code base, is approximately 40 million lines of code. If somebody tells you
they've gone through the Google Chromium code base and cleaned it up and removed all the Google
algorithms, they're lying to you. There are a lot of big lies in this industry, and one of them is the
scale of the problem that we have, of billions and billions of lines of code that nobody can
understand. Now, computers, another big lie is that computers stopped getting a lot quicker a few
years ago. About the time that Intel released the Pentium 4, that space heater that some of you
might remember, Intel released it in 2000. They promised that by 2005 they'd have a 10 gigahertz
one. It didn't happen. Instead, we got the Pentium M, and that evolved into the Core series.
They're smaller and they're cooler. More's law doesn't hold anymore. What we get now is Kumi's
law. Kumi's law says that over time, chips get smaller and use less power, not twice as fast.
What we get now is width, not speed. We get more cores, more co-processors. Brothers and
Level law. Amdahl's law. Look that one up. It's quite fun. Amdahl's law says when you parallelize
a piece of code, the scales you get from more threads of execution top out quite rapidly.
If you have an infinite number of cores available and you can take 95% of your code base and make
it parallel, you'll get a maximum 20 times speed up. That often actually requires in the region
of 1,000 to 2,000 cores to support that. After that, it stops working. Nobody can automate making
code parallel. It's not possible. As far as we can tell, this never will be possible. A human has
to read the code and make it parallel. That is never going to happen with the size of Linux and
so on today. It's not possible. We can nibble around the edge with our many eyes making all those
buds shallow. We can tweak little bits. We can refine subsystems. We can't rewrite the whole thing.
It's no longer manageable. This has built a multi-trillion dollar industry around the world,
but it's very, very hard to make big improvements anymore. The hardware isn't helping anymore.
Software is vast and vastly complicated and nobody understands it anymore.
Let's compare this with Plan 9. I got a few letters and emails and a phone call when I last
wrote about Plan 9. One chap said, oh, yeah, yeah, about the size. The kernel is 5,191,091 bytes.
It's 5 meg. The entire distribution is all sources, documents, the local Git repository,
and binaries is about 530 meg in the AMD64 version. That is not just an operating system. That is
a clustering system, a cluster-aware file system. It's a container management system
and a networked GUI in half a gig. Plan 9 has 38 system calls. I have been trying to find a list
of how many system calls there are in Linux. In 2016, I found an estimate that kernel 4.7 had
335 syscalls. In 2017, that was up to 341. I found a chart for 6.8 and fed it into Libre
Office and looked at the number of rows because it's weird and it's formatted. I think there are 520
syscalls across all the architectures. That's the bare kernel. Plan 9, 38.
There is another problem with Plan 9. It's not Unix and you can't run Unix apps on it.
You can't port Unix apps to it. It's too different.
They have some solutions. There's a thing called Ape which is a wine or wine lib. You can recompile
POSIX code for 8 and get it to work, maybe, if you're lucky. They also have a Linux emulator
called Linux Emu, which is a bit like the FreeBSD one. It's 32-bit only. It's old. It's largely
unmaintained. Now, the open Solaris Linux Emulator was unmaintained until Joian modernized it for
SmartOS and they got it up to parity with kernel 5 and 64-bit, but it was a lot of work.
It also has a hypervisor called VMX. It's limited. It only can give a VM one core. I think it might
be only a 32-bit VM and the documentation says VMX can and will crash your kernel.
But it is there. But look, there's all the technology that's come along. We all have 64-bit
computers now. We all have loads of memory. There's 64-bit Plan 9 in the form of 9-front.
Over in Linux world, there are these things called micro-VMs. Amazon have got Firecracker for AWS.
There was also a project called Intel Clear Containers, which merged with another one to become
Catech Containers. Tiny virtual machines designed to boot an operating system in milliseconds,
run one program and then quit. They're trying to make VMs as small and quick as containers.
There is already a hypervisor for 9-front. Maybe we can make a Linux micro-VM for 9-front.
So you run Firefox and it starts up a kernel and it loads Firefox and it's running in a window on
your desktop and when you close Firefox, the VM goes away. It doesn't mean adding loads of bloat
to Plan 9. It doesn't mean it has to have a huge emulation. Just run the real kernel. We can do
that these days. There is stuff we can do. There's a thing called KubeOS that some people may have
seen. It runs every internet-facing program in a separate VM for enhanced security. But
we can do some stuff on the Linux side of this. When I predicted containers, I went back to IBM
inventing virtualization in the 60s. IBM couldn't make mainframes in the 60s interactive. So what
they did is they put a hypervisor on the mainframe and they ran a dedicated interactive operating
system, one per user, in a VM. How about we make a Linux that's designed and can only run in a VM?
How about we have a Linux that has no hardware support? It can only talk to VertiO devices.
It boots with Pixi or something like this off a file system. There's already a 9p server and
client in the Linux kernel. It boots off a directory. It has no hardware support, no file
systems, no disk drives, no serial port emulation. All that goes out the window. It can only run in
a VM. We make it boot really quickly. We can do it today on Hyper-V and KVM and Xen and
VMware and all these things. We can get this working now.
And then we can make a plan line that could run Linux programs and was Linux compatible,
which means it is Unix compatible. And so I had this idea a while ago and I took it to a couple
of plan line communities like on Reddit. And I expected people to shout and call me an idiot
and tell me it was a stupid idea. Well, okay, some of them did. But what surprised me is people
said, why would you want to do that? You can run plan 9 in a VM if you want that plan 9 stuff.
Just run it on Linux and then you can run your web browser on the host. Well, I'm interested in
trying to go the other way. Can we provide a plan 9, this Unix 2, that can run our old programs
while we find ways to bring this stuff across? Can we make the whole Waylon versus X argument
go away? There's an X server for plan 9. It's called X. Spanish for X, I think.
Probably going to crash a lot, but the point is you could have graphical apps in your tiny
container rendered on the desktop. Linux is really mature. The VSDs are really mature. Each
successive release doesn't change much anymore because the code base is so big, so complicated,
so hairy, we can't change it much anymore. But there is another path here. Now, I proposed a
path involving Smalltalk and Lisp and Dylan and Oberon and why I was fosdome the wrong crowd for
that, I think. But here's a very unixy way forward. Here's a way to build a next generation
better system that brings in containers and a windowing server and networking right into the
operating system. Does it with 10% of the syscalls of a modern Linux system, maybe more like 5%
these days? None of the plan 9 people said to me, you can't do that, that's ridiculous.
They're like, could if you wanted. Well, I can't. I can barely program my way out of a paper bag.
I write about this stuff. I explain it. That's my job. But I'm just throwing this idea out there.
There is a possible path forward. It's all open source. It all already exists.
We could start working on this now and actually possibly have a plan for a next generation
of unix-like system. There isn't billions of lines of code that nobody can ever fix.
I'm throwing the idea out. Have fun with it. That's the end.
So we have time for a few questions.
Will you publish the slides on the FOSTA and webpads? Absolutely. And the script as well if you'd like it.
May I just tell you want to restart everything from scratch, which is good because I really think
more lines of codes, it's not good. And kids now they don't know what means to make it less.
Less RAM, less CPU. So they need to learn that part of the schooling. I completely agree.
Hi. Thank you for your very interesting talk. My question is you compared the size of plan 9
and let's say a successor 9 front with a Debian. So what the point is that the communities that
are creating new Linux distributions are much larger while let's say 9 front is the work on
that stopped in the 90s and there is the plan 9 stopped in the 90s and there's this 9 front
community which are only very few people. So I would assume that when more people would work
on 9 front it would also just grow to the same size as unix or VSD systems today and then we
have the same problems again. It might well be, yes. I mean that's kind of human nature, isn't it?
But I think that there are core hard problems which we do not have any way to tackle
with the vast code bases of things like Linux. The problem may recur but that's the problem
for our kids if they're not living in caves in the Arctic thanks to climate change.
I wanted to maybe disperse your bubble but I have tried that sort of thing when you try to
take a simple system and bring it up to some bigger project. It doesn't work because you end up
for performance reasons re-implementing all the complexity on bigger systems. You may get something
slimy because you started from scratch, you know the problems but you end up adding a lot of the
complexity and particularly when it comes to things like plan 9 it's all these things you
mentioned like the fact you cannot move files or the fact that you need some ways to
share the view between processes or the fact of simple hardware support and heavy-dip performance
that bring back all that complexity. It could be, it could be. I looked up the hard link,
sim link and move issue. Oh brilliant. Don't get too excited that's no mine.