 Oh, there we are. Okay, so before we get started, I'm going to have to apologize a little bit. If you look on the schedule, it says that I'm going to speak about NBD and how I try to compare it against Debian, which was the grand idea that I had when I submitted the talk. But as I was writing up the slides, I realized that may have been a bit impossible to do that. So I think there's still something interesting there, but the comparison against Debian is not part of the talk because it really makes no sense. The idea of this talk is to see, I mean, I've been maintaining NBD for 15 years now, and I've made a few mistakes, and I'm here to talk about those mistakes so that maybe you can avoid making the same mistakes. That's essentially what this is about. So a little bit of history. I became a Debian developer in February of 2001, and I'm not sure exactly when anymore. It's gotten lost through history, but at some point in March or April of that same year, a friend gave me an old M60K Macintosh, which had a broken LCO-40 processor in there, which meant that if you tried to do something with the FPU, it would sack faults or bus error on you very quickly. So couldn't really use it. So the next month, I bought me another M60K Mac, which came with a hard disk of a whopping 80 megabytes. 80 megabytes is not much, not even in those days, but I tried to build something on that machine. I did not have the disk space to build anything, so I tried doing it with NFS at first, and that failed because of all the technical issues that I won't get into right now. So in April of that year, I mailed to the M60K mailing list saying, hey, I found this nice interesting thing called NBD, and with that it works because the issues that we had with NFS don't apply there. I used it to do a build over a 10 megabit network, and it seemed to work. And since I did this anyway, I started uploading it into Debian, and that was in June of 2001, now just over 15 years ago. Something we can learn from that already, actually. Beware of the M60K Mac, I guess nobody here is going to buy an M60K Mac anymore. Let me rephrase that, if it wants to do that. Be careful what you play with, you might end up maintaining a network storage system, probably not also something people are going to do. Actually, there are other network storage systems, NBD is not the only one, there are things like iScusi and ATO for Ethernet, but I don't think people here will be interested. The real lesson to take home from this is that if you just play with something, even if you think it's not useful at this time, it's a good way to figure out new things to put into Debian. I do think that by maintaining NBD and by adding support to several things, I've improved Debian in some ways, and wouldn't have been the case had I not bought that 68K Mac so many years ago. Anyway, something else. When I started NBD, it was totally undocumented. There were some lines in the kernel source code showing you how to run it, but that was pretty much it. The code was not commented, there were no man pages, there really was nothing. So I got this from a Git history because it was way too long. In October of 2005, I added some Doxygen comments so I could at least understand the code. By that time, I had taken over upstream maintenance. In about a month later, I described the protocol and asked somebody to write an ethereal disaster for me, which happened. Several years later, I converted that blog post into something that I could add into the code repository. About a month later, for the very first time, somebody started actually contributing to NBD. Before that, I had people sending me one or two patches and they never reappeared, but after I added this to the code repository, somebody actually started contributing a significant amount of code. I think he submitted 50 or 60 patches over the course of a few months. So that was actually a welcome change. Two years ago, we wrote up a Starftial aspect based on the documentation that was there, etc. Since then, we've actually had more commits related to that particular document than to the actual implementation of the NBD protocol itself. So, what can we take home from that? You could take home that writing documentation is way too hard, so you shouldn't do that, but I don't think that's the right lesson. You could take home that writing documentation takes time. It took me 15 years to do it properly, but I also don't think that's the right thing to take home. You could take home that writing documentation takes time away from other things, and I think if you look at people in WN and outside WN and open source in general, they like to write codes, but documentation is this other thing that doesn't really happen, and somebody else will have to do it because I just do the code. You could take that home from this as well, but I don't think that's the right thing to take home from it. If you write documentation, people will send you patches if only to the documentation, but often also to the code if the code is properly documented. So, you could say, I don't want to have patches, so let's not do that, but I don't think that's the right attitude in an open source or free software world. I think the right thing to take home from this is that documentation actually allows people to understand your code and understand how everything works, and by writing documentation you make it easy or even possible for them to understand and help you out, so doing that may actually be more important than actually writing the code. Naming things. The original version of the protocol did not have any way to negotiate certain things. I mean, the server just sent some data to the client, and then the client could either accept that or disconnect and try it again with something else, which was difficult. So, in 2010, this was during DevCon, by the way, I decided that enough was enough, and I just created an incompatible change between the two protocol versions. While I was doing that, I formally referred to this as the new style of negotiating, and the other one as the old style of negotiating. And then later that year, we found that there was a little bug in the new style, and we then referred to the fix as the fixed new style. This was originally formally, but over the years, actually, they have now become the official names. There's a fixed new style version of the protocol, which is weird because it's already six years old. It's a bit annoying because it's difficult for me to change it now, and if I'd known that six years ago, I probably wouldn't have made that mistake. So what do we take home from that? Be careful what you name things, because you're going to stuck with it. You're going to be stuck with it, and if it's a stupid name like I did, it's going to be very annoying and embarrassing, and you're not going to be able to change it easily. I tried, but yeah, too late now. So having a good name is usually a good thing to do. Like I said, the old style protocol had a few issues, so I created a new style one. The intent was always that I would eventually deprecate and disable the old style protocol when there would not be any clients in the wilds anymore. After six years of new style, I thought the time was ready, especially when a bug was introduced that only existed because of the combination between old style and new style, so I just dropped it from the implementation, and at that point I found that many third-party implementations of the MBD protocol were really still using the old style protocol and depending on it, and were not ready to move to new style yet. So I probably should have planned that better. There were some issues that I could have avoided. Most of the issues that existed have been fixed now. The implementations have been updated, but I probably should not have done so. So that's something I learned. I mean, if you're going to deprecate something, it's best to be explicit about it, make a plan for the deprecation, publish that plan, let people know that from that time on they will not be able to use the older interfaces anymore. And don't wait six years with it. Six years is way too long for something to be deprecated because people eventually think that it's not actually deprecated because it's been there for so many years anyway, right? Make it clear in the documentation, in the code, in the comments, in your .sig, in wherever you can announce it that you might want to deprecate it or deprecate it because you... Or if you... One final thing you might want to consider is, well, do you really need to deprecate it? I think in this case it was necessary, but maybe it's not, right? Security issues, I've had my share over the years. In fact, the second one and the first one are really the same thing because the first one was fixed on the master branch. Sorry, it was fixed on the release branch and I forgot the master branch. And then six years later, somebody said, yes, six years later, Ian Jackson told me on IRC, oh, I found this weird issue and I don't know, but sometimes it crashes and I go, oh, oops. And it turned out that I forgot to merge the commit to the master branch and, yeah, well, then there's a second CVA there. And then in 2013 we had one and in 2015 we had two, but one of them actually was already fixed in 2013 without realizing that it was a security issue. So they had assigned one security number from 2013 back in 2015, which is a bit weird. But anyway, it happens. I mean, if you write a server, security issues will probably happen. There's nothing essentially wrong with that. There's nothing to be ashamed about security issues. Just be prepared for it and make sure that you know how everything works. The first time I had to deal with a security issue, it took me about three or four weeks before I could get it fixed. By the time we got to the final one, it was a bit quicker. So this is something you might want to be prepared for. I mean, better to be prepared for the worst, right? It's better to avoid security issues if you can, but, well, they happen. Of course, like I said, it's better to avoid them usually by doing proper design for that. It's fairly usable to do that. Oh, and don't forget to fix all branches, like I might have forgotten. We're almost at the end now. There's a few WN-specific NBD features that I implemented. I wrote some depth configuration for the client and the server. And when I was doing the system D NBD unit the other day, I found out that the client version of the depth configuration was so broken that it must not have been used for four or five years or something because it could not possibly generate a valid configuration file. So I threw that out because, obviously, nobody was using it. I added installer supports and a system D NBD unit and an init script. Some of these features were interesting, but I'm starting to be convinced that depth config is not as useful as I once thought it was, but maybe some people disagree. I think that's what I had planned for today. I still have some time for questions if people have any, but other than that, I think we're done. No questions. I thought that means... Yeah, I'm going to ask a question. Oh, good. Thank you. You were talking about deprecation. Yeah. And you left it in, bits in for six years. Yes. That's what the third release cycle of Debian, so the first one you announce it, the second one you leave it then, but you've deleted it. That's about right, isn't it? Well, yeah, possibly. This is, of course, an upstream deprecation that I'm talking about. Also, the way I deprecated it was, I just added the warning, this is now deprecated, and when I threw it out, it was almost an overnight decision and that might have been a mistake. But, yeah, timing-wise, it's probably okayish, planning it and announcing it and sticking to the plan might have been a better idea. Yeah. I mean, the biggest fear, and we see it on some of the faster-moving projects, is they announce something, they deprecate it, they drop it, and it's gone in one release cycle of a distribution. Right, yeah, and that might be a bit too quick. Other questions? No. Okay. Either that means it was very interesting or it was very boring, I hope, the first. Thank you very much, then, and see you around.