Is that working? Right, okay. The title's a bit misleading, but I'll get to that in a second. For those who don't know me, I'm Joe Shields. I'm a Debian developer. I kind of do the same thing-ish in Ubuntu every now and again. And for the purposes of this talk, the relevant bit is that I work for the University of Oxford

as a systems manager on their high-performance computing centre. So we have researchers who need to do big calculations, whether it's simulating protein folding or testing out cryptography algorithms or whatever.

They need to run stuff. They've got a desktop. We've got hundreds of servers. They come to us. So what is this talk actually about? It's partly about something that we did at the uni, but it's more about why. And that why is explained with this statement here, which you'll see a lot on the internets,

which is we don't need mono. You hear this a lot. You see it a lot. You see people saying that mono is unnecessary, that there are loads of other things you should be using instead. The monos are just a copy of Java, so use Java, this, that and the other. Now, within HPC, especially in the UK, we have a technical term for this kind of thing,

which we hear from people like vendors. We hear this kind of very certain statement. And the technical term we have in the UK is this. It's bollocks. It's not based in reality. It's just based in silliness.

So the talk is basically explaining why we ended up using mono in production in our centre for doing some stuff. And if that sounds really boring, you may as well go get a beer or something. So why did we end up in this situation?

UK universities, as with most universities around the world that aren't Harvard, are massively underfunded. And in 2004, the UK government, through a group called the Higher Education Funding Council for England, I think, invested over a period of three years a billion pounds, which is not much these days with the pound the way it is.

And out of that one billion, the Oxford Supercomputing Centre got a three million investment basically in buying hardware, in buying actual computers. Whereas in previous years, what we'd had to do was save up all the money we could, blow it all on one computer,

and hope that would last us until we found more money down the back of the sofa. Out of that, unfortunately, due to cronyism, politicking and assorted other issues, we had to spend more than half our budget on building a very simple air-cooled machine room in an empty room.

And somehow our 500,000 estimate from IBM turned into 1.7 million from the University of States department. But there you go. We had 1.3 million to buy shiny toys. And what we planned to do with that was to buy three different computers that served different purposes

and different researcher needs, and some stuff to glue that together. Just things like shared disk areas, networking infrastructure and all that. So we'd never had that much money before. Money is nice, but it brings problems.

So, first problem is, traditionally what we had had, we'd only ever had two systems at a time, and it was a lot easier to just treat them as two completely disconnected systems and say, that's computer one, that's your username and password on there, that's computer two,

username and password on there. When we create the accounts, they're the same, but you know, passwords, you forget to update it on one of them, and this, that and the other. And we were using NIS, Sun, I think NIS, to handle sort of inside a cluster, keeping that password updated on that one cluster.

So we thought, well, that doesn't sound too good, and when we've got three systems, four systems, five systems, that's just going to piss everyone off. So we had to centralise all our authentication stuff, so you'd have one username and password, get you onto all our kit, no matter how new or shiny, and only have to change your password once

and worry about managing your account once. And we thought, NIS is just not going to cope, it's going to fall over dead, because it sucks. And there's a NIS Plus, which nobody cares about because it sucks, and there's LDAP, which kind of sucks as well, but it at least can handle all of these extra bits we wanted to do. So, LDAP is great, but not everything behaves the way you want it to,

the way you expect it to with LDAP. So we ran into a problem in our testing, for example, that we could store passwords in the LDAP directory, but the PAM module that handles password changing on account login

wouldn't update any of the shadow fields, so your password would still be expired, even though it tried to change it. And we keep running into issues like this with the standard tools that think they're smart, but they aren't. So, we had to hatch a grand plan. This plan took about 18 months before we even got into hardware testing. The plan was, do something about it.

Find something that can do LDAP management in a decent way, or if need be, write something. As a systems manager, I know that there's only one answer to any problem that needs a quick fix and a bodge, and that answer is Perl,

because you can never go wrong with Perl. Except if you're trying to do something big and complicated and scary, and anyone who's ever looked at the RT code will agree with that. It's not always the answer, because Perl very often, I'm not saying it's always the case, I'm not saying it's fated to be the case,

but often Perl is a write-only language. You'll write some Perl, and then the next guy will try and look at your code and go, buh. It's very, very easy, because Perl has lots and lots of shortcuts and tricks and hacks to write something unmaintainable, and if you try writing big, verbose, easy code, that can also become big and bloated and unmaintainable.

So, I wrote a version in Perl, and I needed a few weeks for recovery afterwards, and thought, this isn't working, so we're going to have to tighten down what we need to do, and so we redid our plan. We had to write something.

I'd had time to look at all the other things I could find for managing accounts in the way that we wanted to do them, and there was nothing already out there, or there was nothing out there that was close enough to what we wanted to be worth editing either. So we had to do something pretty much from scratch.

We wanted to make it so that anyone using a proper OS could have a nice clicky gooey to do all their account management tasks, and that's not just changing a password, but it's things like checking on how many credits they've used on our systems and dealing with their email account details and all this, that and the other, and for people on legacy operating systems without an X server,

they could still get some functionality through Putty. So we wanted to make sure that the gooey stuff was layered on top of an engine of some kind, and we wanted to make it so that the app could be extended over the years as new needs arose, as we found things got annoying in a console, we could just add stuff as and when.

And one thing that for us was an important requirement is there's stuff that users need to do, like change a password, and there's stuff that sysadmins need to do, like change a user's password, and it's silly to have two different tools to do the user stuff and the admin stuff,

so we wanted the same tool, using the same backend, to handle both, and simply to deal with permissions, this, that, and the other, to make sure that users don't go creating accounts, only sysadmins can. There's so much overlap, it didn't make any sense not to have the same tool for both.

So, what do we need to worry about? First issue, developer team. Me, in my spare time, we're not doing other sysadmin stuff, which is not a huge team for 1.3 million quids worth of kits, worth of administration stuff. I think that makes sense. So, small team, we kind of knew what we were buying,

to a degree, with two thirds of our planned system, so we knew at the time that AMD processors were great at memory bandwidth, and we had a lot of codes that were memory bound, so we would very, very, very likely be buying AMD64 for one cluster.

We knew that for floating point performance, it was hard to beat Xeon, so we would very likely be buying a Xeon cluster, and we knew that we had a third set of users, who rather than having code that runs on a cluster, their apps only work on one computer with lots of cores and lots of RAM,

so we had to buy a computer with lots of cores and lots of RAM, or a set of large computers with lots of cores and lots of RAM, and that was really up in the air. We didn't know what to expect, and we couldn't legally insist on one thing or another, because then it comes to public money and public tendering and favouring one company over another and all of these problems,

so we had to write our tender in a way that said, just give us something with lots of cores in one box, give or take. And similarly for the operating system, you can kind of get around it by saying that we'll take any OS as long as it can run Linux binaries, but we have had people give us, for example,

Open Solaris or Solaris proper version bids saying, it'll run your Linux binaries 100% perfectly. But we can't legally say that we can't do it, so we had to think, well, we might have Windows on a cluster, we might have Mac on a cluster,

we might get a big HP integrity system running HP UX on Itanium, we might get IBM coming to us with a P series running AIX on Power. We really didn't know what to expect, so that was one thing, again, that we had to worry about, is if our users log into our system and that system is weird,

they still need to see the same tool presented to them that they would see on the cluster, they could see even on their own desktop. We need to make it so that it's the same on all of them, so we have to think about that requirement. For example, there are development tools out there that aren't particularly favoured on all architectures.

There are closed tools out there that are very x86 or AMD64, so we had to worry about it. We didn't make it too tight a requirement just in case, but it was something we tried to think about, and when I say we, I mean me. And the final requirement is if everything goes horribly wrong and the very simple, nice concept of doing everything

in a nice cross-platform way didn't work, it had to be easy to fall back on C libraries, and there are billions of C libraries out there for Linux, which is the OS that really mattered to us, that could do pretty much anything, and just in case, we had to be able to use them.

So, first requirement. Malloc band. I have got better things to do with my time, like dealing with users, than worrying about memory allocation. So, nothing that needed me to worry about managing memory was even considered as a framework to deal with.

Second issue. Nothing, if possible, on only the main architectures. Third issue, source, fine, binary, fine, cross-platform, really like it, but if need be, fine, we'll do without it. And the last issue.

I did a degree on Java, so I learnt one or two things about Java and the process and how to use C from it or not. So, I did a search for proper development environments that would make my life easier. In aptitude, which has got 20 odd thousand packages in general,

so I was bound to find something, and I had a look at the list. I read up a bit on those IDEs and the languages that they were centred around, and I tried a few little programming tests in those IDEs to see, well, that seems quite nice,

I like the syntax, it's intuitive, it makes sense, the IDE is user-friendly, and there was a short-listing process which kind of didn't have that many choices on it. Of all the things available, and this is late, I think early 2007, sorry, MonoDevelop was the only one of the ones that I tried

that seemed like a serious thing for me to use given all the previous constraints. So, how did I end up with this? How does it tick those previous boxes that I mentioned? Number one, I don't care about memory, that's what Mono does for me, so I don't like having to care about things.

CPR arches, there's like some really fringe stuff that Mono doesn't like, but other than that, all the CPUs work fine with it. OS is fine on Windows, on Mac, on Linux, maybe got it working on K-free BSD, I think regular free BSD works,

but the big commercial Unix is not so hot, so AIX would have been screwed, and HPUX would have been screwed. But, as I said, it wasn't the hardest of requirements, and we kind of preferred Linux anyway, so we would have found a way to fiddle our tendering process to ignore the nonsense anyway.

If we had to use C, with Mono, with C sharp, using C is doable, and with Java, for example, it's not, or certainly in 2000, with the Java version available then, it wasn't. As I mentioned, I learned C in three years

doing a degree at Southampton, and it was very, very C-centric. The concepts and stuff were different, and there was a bit of not so much. I'm off of sleep today. So everything was done with Java. All the high-level stuff was done with Java, teaching of algorithms, Java. I think the malloc implementation in Java was weird.

So I know enough Java to be able to use it, and C sharp was closer to Java to jump into it and go, I kind of know my way around this, and I can ignore the Java that was really stupid.

As it ended up, we didn't know what it would do. It was a graphics ALT-X700 with enterprise on it. It came with Mono. The Mono question wasn't an issue. The processor didn't do anything whatsoever,

which is good. We ended up with a system with 250 cores. It's terrible. And it's just an admin tool. It's all the other systems. The GUI is at the moment. It's the G-pop GUI

and the Mono GUI. And some of these have appeared at the time. So I stopped the app. It was this big mock thing that was thousands and thousands of lines and it appeared in Java and on certain people's apps. I took them so things appeared using that strategy.

We got the plug-ins in there. Someone named it the future. It was Mono. We took that and gave it a look, give it a look. And at the moment,

I haven't done a collaboration with our system, but everything is on top of the old LDAP. So we all have our own LDAP server running on Debian through SML, encrypted LDAP,

and it works enough that I'm going to show it in theory.

Right, here we go. So that's the GTK chart version.

That's running on my desktop in the office back in Oxford. As you can see, there's this big list on the left of functions. Each of those functions is a different assembly that just advertises itself as the main executable. It says, I need these security requirements. Here's my icon.

So I click on, say, password expiry, and then it waits because of the SSX forwarding, X forwarding to my functions. Oh, there we are. So you'll notice there's a grayed-out OK box here. There's a grayed-out select me time here.

Right, click that. We'll try searching for a user. I can't remember any of my users. OK, so let's select Jamie Leech. His password will expire April 24th.

So it might be authenticate and wait some more. I now have admin access, and we've got a kind of sudo-like thing built into the user model

that we've got in our LDAP directory. So every user can have a super user assigned to them. So I can have a regular user who can gain privileges of an account leader, and an account leader can edit his own user's passwords or whatever. That's all built into the design of the LDAP schema

as well as in the tool. So now I'm an admin. I'm assuming that do has been updated. It might not have been. I'll get that one here. It might be working. It might not. Oh, there we go. So now I've got the OK box. I've got the select. So I can search back on Jamie eventually.

Reset password expiry. Select box, wait a bit more. So I'll give an extra day of expiry just for fun.

It happens in the LDAP server. So more demoing. Quit that. Wait for it to do something. See, there's one reason to use Curses is it's a bit happier on bad Wi-Fi. Again, I lost my access.

Any Curses written in C sharp. And all the same functionality to the LDAP server which is expiry. Control L should refresh.

Control L. Alright, that's it. Well, that's probably my code fault. You can see the theory. The GUI is very similar. So anyone used to one can use the other. It's got one after Jamie.

So you can see it's the same tool. It's the same UI style. And it's using the same back end. Each of the functions you'll see there's a smaller list because I haven't written a Curses GUI for lots of them because I'd have to write more widgets and I'm lazy. But it's the same stuff pretty much.

So that's the live demo done. So I've got to breathe again. And really get this back up. Right, so why am I here talking about this? One thing and my battery up. Yes, okay, so

as an employee of Oxford University and I'm sure many of you who work for pretty much anyone find out how to sign an IP agreement

says that anything I do on their time is owned by them. Full stop, end of story. The idea being that they want to sell it to everyone to try and cover some of their horrible deficits. So, everything is copyright University of Oxford. All rights reserved and a few extra for luck.

However, there is a process. It's relatively new. It's relatively unpleasant. And it's based in their current process for licensing patents. So I've had to do things like fill out eight page forms named by IP to intellectual property due diligence questionnaire, I think.

I've had to do a lot of this stuff. And the process started and that's true and I finished these slides months ago. So, I have made a request to the appropriate people and that's currently in the hands of the head of research, I think,

was the last thing I heard was that it's with the research people. It's been handed on by the University's IP sales people to them. It's going to happen. I've made sure it's going to happen but there are delays on every stage and I still have to worry about doing my day job. So, I can't spend all my time trying to chase up your address.

Short version. So, before we get to the Q&A, I assume it happens given how late everything's running. A couple of points that I'm expecting to hear once the hands go up. Why aren't I using QT because QT does everything. Short version is back in 2007

QT was either commercial or GPL and much as I wanted to make the tool we've got free software I couldn't guarantee that I'd get permission for that from the University and the license the commercial license for QT pretty strictly said you cannot use the GPL version

as a demo. You have to buy the commercial version and then use that for your tool if it's not free from day one. So, that was my understanding of it anyway. I could be wrong on that but that was my reading of licensing and I'm not a lawyer but I didn't want to have to worry too much about this stuff. So, I've kind of avoided it for licensing reasons

and that's fine now that it's triple licensed with LGPL but I don't want to have to rewrite everything from scratch. So, I went to QT with GTK, I've stuck with it and I'm really too lazy to change now. So, that's why not QT. Next one.

Python. Okay, I know that if there are any people in the room I'm going to hear about this. Professionally, we've had lots of problems with Python. Every time a user comes to us and says, hi, we've got this Python thing, we kind of hide and hope they don't try following up in their email. We've had problems with

libraries not behaving right on some architectures. We've had problems with needing certain versions which change the way that the other is done. So, Python, I was kind of relatively disposed against it. Which is kind of the short version.

I've had a play around with Python subsequently and I fiddled someone's scripts I'd done back in the early days of the Wiimote packing to make a play session 3 remote act as a keyboard so you could use it to commit to TV and I found it I didn't really like the syntax

and I can understand why people would like the way that it works but I found the syntax unpleasant for the way that I approach coding and given the problems we've had with Python stuff at work, I wasn't too happy with using it. So that's why not. So no one needs to ask questions about those two items.

Because now it's question time. Anyone? Most of the time it's just called a discipline and if you have lazy people doing stupid stuff, it's going

to be stupid in any language. And Python just makes it very easy to be really really stupid. Yes, it's very good at that. If you have certain discipline coding standards you can even write really awesome pearls. I think that's entirely fair. Some languages

make it easier to be stupid than others. I repeat things for the camera. You're right that you can write a very nice pearl. It is technically possible, I've heard rumours on the internet to write a very nice PHP. But some languages I know it's

my fetch. Some languages just by design enforce a little more structure than others. And to an extent I like having that little bit of structure enforced when I'm trying to do something serious and I'm attacking something together in five minutes. And I'll just go straight to pearl because it is great for that. But once I have to start being disciplined it's good for me as someone who's

not too bright to have the language kick my arse when I'm not being disciplined. I'll tell you one of the other issues that would have arisen if I had gone with Java is

as you saw we ended up with an Itanium system and for a very very long time we were having to turn away users who wanted to run big memory Java stuff that needed a Java newer than 1.4.2. Because the newest Java available on Itanium was Java 1.4.2 until about six months ago.

And there was a sudden update from Susie to give the Java the runtime from BEA web server which was 1.5 and it kind of exploded randomly with the user codes so we pretended it didn't exist so we had problems actually very similar problems with version

and distribution that we faced with our users with Python. So even if the JNI thing has never been needed if it was never a requirement I'd stay in stone I would never need to do C then Java would have been a much stronger contender than it was. As it was the existence of JNI and I don't think

JNA has quite made it into a stable release of anything yet is it? JNA is supposed to be a fixed JNI which looks a lot like the invoke I don't think it's anywhere does anyone know better than me on that? Well it's a legal issue because if that thing ever makes it into Java

then it means that Microsoft was actually right when they made those changes to the language that they got two billion dollars for so it's not likely it's going to happen I'm not going to comment on whether Microsoft has ever been writing about anything because then I'll get my ass kicked even

it's going on YouTube so that was why not Java basically I agree entirely that some languages and you can write beautiful Perl I've seen very nice readable Perl but I'm not good enough to write it anyone else?