Yes? Well, wow, I have back of the world room. It's more kind of a bit of a fiddler, so we are here to talk, not exactly to give you any magic that will make our think pads work better. But maybe you can help me find out which magic we could make together to improve it. Oh, what can we make to try to improve our laptop experience? Is it a tool? Is it our preferred tool? I mean, I am pretty sure there are people in this room that are closer to their laptops than they are of their special orders, which is not nice, but it's a fact of life. Well, what do we have in the think pad ecosystem as far as we are concerned?  And that's a big advantage for think pad users. Many Debian developers use think pads, as we can see here. And we do have, that's pure accident, but we do have an advantage. One Debian developer and one Seuss developer have direct access to Lenovo. They actually approached us through Seuss because they have a working relationship with Seuss to sell think pads with Seuss inside. And Seuss approached me because I am the kernel maintainer of think pad API. And we got some email addresses with Lenovo Japan, which are the people who really make think pads. We cannot use that for a whole deal, but when we have a major emergency or something that is really obscure, we often contact them. And if you're looking, they answer that with documentation, or yes, you can do that, here's how you do it. It's not a very open channel, but it is there. And that channel is about one year old, so it's a new thing. But the reason with this help, we haven't managed to make it perfect yet. I mean, those of you using two, six, 26.2, the newest kernel we have, you should be worried that it's not taking good care of the thermal constraints of your laptop if you are using the next series. Why? It's a simple bug in Linux. Is it going to be fixed? Yes. Why it happened? Because ACPI is quite complex, so that's not much we can do about it, except find out the bugs and fix them. There are three key people right now in the kernel space of things. Me, because I am the unfortunate or fortunate, depending on the day, maintainer of think pad ACPI, which is the kitchen sink driver for think pads. Basically, if it's not something really important like the disk driver system or the ACPI itself, or I don't know, the video drivers or other important subsystems, it belongs on my driver. So I am the one who has to talk to the hotkeys or until sometime ago, the hotspot base or the internal crazy things of a think pad, like the built-in mixer for the volume keys, the kitchen sink. Then we have Thomas Reninger from Seuss, which is the one who managed to get this contact with Lenovo. It does a lot of kernel work that's really spread so that I don't know exactly what he likes to do more. I have seen works from him and they are all related to think pad mostly on the brightness pad and stuff. Also some key issues like hotkeys are not working perfectly on whatever model. Please let's see what we can do about that, et cetera. And Matthew Garrett, which was a devian developer, I think he's from Budo now, but I'm not sure if he's not, I apologize for the misinformation. And he does a lot of kernel work. And also, I believe he was the main responsible person about moving things from think pad, SEPI to hall and other layers. And where it leaves us. We have a kernel that works mostly well. We have a kernel roadmap, unfortunately I didn't type it yet, but I can talk about it later and you can actually ask me to change priorities if you want. But we don't have a major task force in user land, that means devian or Zeus or Fedora, to actually make these mouse machines work perfectly. I mean, I spent about one week trying to get the hotkey mask right so that it would do the right thing if you get a node think pad like mine or a brand new one from Lenovo. It needs a bit of a different handling on the volume and brightness keys. Okay, so I managed to mostly teach the kernel what to do right. That's fine. Then we have mostly, I think, all Linux distributions overhiding that with enable everything mask. And suddenly, oh my, my brightness case don't work. And then I ask, why? And they just say, well, it's like this, this, this. Why do you have those keys enabled? I don't know because the disk enabled that and that went into how upstream and now it's enabled everywhere. It gets to a point that the people doing the kernel side of things doesn't exactly know what people are running. So we have a kind of communication problem there. I mean, I can mostly pay attention to whatever happens in devian but to be really, really honest with you, I don't. I have to take care of the problems in the kernel side of things. So my user land configuration is not exactly the default one. And when packages get updated, sometimes it doesn't predict my configuration because it's already customized. So sometimes I stop what I'm doing and I try to see what's happening and I try to correct that but unless people, I don't know file book reports I won't be knowing about that. I think SUSE has the same problem but they have a more tight key A system. So, and Ubuntu works really well in whatever the Ubuntu developers are using but the older thing pads are in no man's land. In fact, some of them as we have with Brighton keys started there. Well, mostly I would like to know and I would like to propose you guys to talk to each other and talk to me and we could share experiences here what's you have found to be best what's really causing the trouble right now we can all write down and see what we could do. Also, if you really want to we can go down into ThinkPad firmware land. I can explain how this box works. It should be about 90% correct for the newer ones too. And if any of you still has an older T model, a T for, I have the firmware here if you want that fixes the annoying fun. So it won't start going for no reason at all just when it needs to. Other than that, well, questions and answers time. As I said, a bit of feeders is not a presentation. So please, okay, let's talk about hotkey support. There are two kinds of hotkey firmware in wide use on ThinkPads, okay. The older one, which is not that old it means everything will be older than the 60 series. I'll type a bit here so it's easier, okay. Since my English is clearly not that good. So excuse me and please forgive me for using this, but it works, right. We have two classes of firmware, old and new. Okay, what's the difference? Lenovo found out that people were getting too confused by those three volume keys. What are those volume keys? In older ThinkPads, which means T4, she's an older, sorry, T60, and also same thing for X and R series, okay. They drive a separate mixer. There is a mixer inside this that's not the normal sound mixer and they are actually kind of a digital access to, they didn't want an analog knob that you would roll. So they put this in here. You really shouldn't be trying to do anything else with these keys on this ThinkPads. You screw up the dynamic range of the volume control. It was not designed for in sort of, I press here and I increase or decrease the volume of the AC97 mixer. It was not designed to do that. But people found out that they could do that. So far so good. That's why the driver lets you do that. And some people started using it. So far so good as well. It's your problem. And then they place that on distros and that's not so good. What happens is that in Windows, you have some sort of on-screen display that's always there. And we do not have that on Linux. We do not have a proper on-screen display interface. We don't. And actually my driver also has part of the fault because I do not export yet. An AUSA mixer to access this mixer. So people hooked on active events, things that are supposed to command the ThinkPads to do something, to use it for on-screen display. And then they did even worse. They hooked into input events that actually order your GNOME mixer to lower and higher the AC97 volume and that made complete mess. And there are the new machines. The new machines have a hardware mute button. I don't know if it's hardware or firmware because I haven't debugged their bios yet. But they do muting in hardware. And the volume keys are just that keys. Lenovo made me a big favor and they send the volume, key volume up and key volume down directly through the keyboard controller. So what happens in a machine like that is that if you didn't do anything weird to ThinkPads API, it never gets the events it uses to because they come up as keys, as normal keys. And then whatever, listen to normal keys, we'll get them and process them to highs or lower the volume. That's what should be happening. However, due to configuration issues and also because people always go there and mess with the hotkey mask, that's not what you're seeing. And we have something weird going on on the kernel side of things, in the interface that talks from the kernel to the embedded controller, which is actually the keyboard controller also in the ThinkPads. And that's causing some weird problems, including weird response from hotkeys and sometimes event loss. So I am not actually quite sure exactly why your keys stop working. What I can tell is that if you read the documentation for ThinkPads API, you'll see that you have some bits on the hotkey mask that are for volume.  That's the default. And if you have a new machine, it should just work because you get the events from the keyboard. Then it's just a problem of getting x, x.org, to actually know what those mean and map them to whatever x keyboard event it needs to, so that gets to non-mixer and erasers or lowers the volume or gets the same thing. So is it complicated? Yes, it's a lot more complicated than it should be. It should just work out of the box. The kernel side is prepared to work outside of the box, but that's something that New Zealand's not. When you, in another model, when you press any of the hotkeys, the volume hotkeys, any of them, it does two things. Actually, that's three things. First, the firmware or the hardware, I don't know exactly which, actually rises or lowers the volume controller that takes care of your headphone output and built-in speakers. It does not affect the line out which you can get on the docks, okay? It does another thing. It updates the CMOS non-volatile ROM so that if you reboot or shutdown, you get the same volume again. And the third thing, does it sends an ACPI event that can mask or not? That's what the hotkey mask does. And think that the CPI actually only echoes that back. It tells the kernel, oh, that's a valid ACPI event. Please echo that to user space and does nothing else. So it actually, you could hook on those events to use them as on-screen display, but you are not supposed to hook on them to do anything else. Somebody did, I think, I'm not sure it has been undone, but for a while, how was programmed to hook on these events and generate the active please raise volume, please lower volume events and that was causing a lot of trouble. But on the other hand, people would see the beautiful on-screen display and think, oh, now it works, it worked before. But you didn't get the feedback that you needed to know it works. That's why people in Minux are confused by the volume keys on the old style of Thinkpads, but people in Minux never were because they had that feedback so they did understand that, oh, look, that volume slider is not changing, but it told me that volume is lower and higher and I can't hear that in my speakers, so it's working and they were fine with that. They noticed that's problem and then they changed it so that you'll now have a new style of just keys. Easier for us to deal with that as well, I suppose, but now you cannot lower or hide your volume in BIOS or DOS or something like this. It's not important anymore. Does that mean that there's no way to simulate that first action that it takes which is modifying the internal volume thing? Well, very, very old Thinkpads do not issue ACPI events for volume keys, but they can't get them by pulling the CMOS in VR. And they could do that on new ones as well. I mean the opposite. I mean, is it possible to have a user space program that doesn't change any else's settings but does modify the hardware volume? I'm not understanding you correctly, I think, but... You talked about three things that pushing the volume button does? You cannot block the actions of the BIOS so that doesn't change the hardware. But what I'm asking is can you set them? Yes. Simulate those. Can you actually modify the BIOS volume values in user space? Yes, you can. But there's no such a thing on the new Thinkpad. They took away the mixer. You only have now a mute gate, which I am affording it. I just don't know how to program that mute gate. We could find that doubt. Someone sits alongside with me for a while with a new thing or we could ask directly and know about that. But I do know that they made something like that. You press mute, it mutes. If you press mute again, it remains mute. If you press any of the volume up or down keys, it emutes and follows the key press. And the next key press gets through the keyboard controller as if you... So they tried to emulate the old Thinkpad behavior in firmware. As I said, it really should work. If it's not working transparently, that means we either are not doing something in user space that we should be doing when we get a volume up and down from the keyboard controller or we are getting confused. I mean, Thinkpad SAP never sees those key presses, so I am pretty sure the kernel is not on this instance doing something bad. Brightness is not something else. Brightness control is wrong in the kernel side. It's not user space. Anything else you would like to talk about the volume keys? Thank you. So I like very much the old behavior of having two different mixes. And I have an X60 and I have also a T42P. And if I understand correctly, this old behavior is going to be changed. It has been changed. Okay. Is there a way to add back the old behavior? Yes. But I want to like what I am going to tell you. You will have to reverse engineer the EC firmware. Okay. And the embedded controller on Thinkpad does a lot of stuff. It has two I2C buses that talk to the batteries. The batteries are normal smart battery systems batteries. So you have the full documentation of all the protocol that goes to the batteries. It also emulates the keyboard controller and it takes care of a lot of other stuff such as AJA, DAPS, the accelerometers. The search code for the T4 for X series and also R5X series and a part of the X series. Well, somebody did that to work. You could try to get that work and improve on it and get your bios do the same. And then you will be able to get the older behavior. However, I'm almost sure that about half of what Thinkpad does is in the bios running on system management mode. I mean, as far as I know, the embedded controller doesn't even generate the CPE interrupts. So something is doing that. And if it's not doing it by itself, it means the bios is doing that. As far as I know, it generates SMM and traps only. I mean, it's probably too much work, not worth it. Unfortunately. What? Be my guest. Okay. You could also have a driver in kernel that trap at these keys on a very low level and emulated in kernel. The old behavior like so much so that nothing else can mess with it. That's doable and not even very difficult. I mean, we have input handlers in the kernel. You can do that if you want. And I would accept a patch for that on Thinkpad and CPE as well, so it's not a problem. Anything else about phone keys? Sure. It's not anymore about the keys, but it's something that I found one month ago. So I have an e60 and I have a docking station and I was quite surprised that my docking station didn't work out of the box. Dock stations are... No, wait, wait, wait. Because then I tried long time ago because the only way to use the CD on the e60 docking station is I had a long time ago. I tried to go back and it seems that all the information on the Wiki was correct and I didn't succeed. And then three weeks ago, I found that the Debian kernel has a patch which disabled the IEHC whatever in the controller. I'm sorry, I didn't get the first part. The libata, the docking station cannot use the libata bus or system because the Debian kernel has a patch that disabled the recognition of the PCI controller for the libata. Okay, let's talk about dock stations and that was it. Docking in the kernel was not exactly in good shape until about 2.6, 2.4 and thereabouts. It really was not in good shape, okay? It's not nothing magical, but nobody had worked on that for a long time and it didn't do the right things always. So we had some sort of helpers, think paid the CPI and other drivers. And those did work most of the time. For think paid the CPI, you could ask it to handle the dock and the bay and it would generate ACPI events that are privated to the driver. It's not a real generic event. It was IBM and a lot of numbers. And you could hook on that to order the system to eject, which means power off the bay and those to amount and do other housekeeping you wanted before you eject on something. The problem with that, that unfortunately think paid the CPI uses a really weird way to find out which ACPI node needs to do something. And that really holds things on the T60 and later because they started using SATA, Serial-ATA base and they still had the parallel-ATA base and suddenly they had two nodes and I would have to teach the driver to know which node should use to request an edge act or something like that. I never got to this point. Why? Because the roadmap was to teach the kernel itself how to do docking and undocking and generic way, not a think paid way or anything like that. That means that you need a patch to think paid the CPI to get it to work on certain thing pads and that patch break other thing pads. It depends on which thing pad you're using. Then somebody started working on a generic dock and the generic bay drivers. Those do work, but they were about half way done by 2624 and 2625 is much better. And I believe 2626 actually does what it's supposed to. And somebody talked, Libi-ATA, the hard drive subsystem about ACP high commons that needs to send to the disks and that causes conflicts and so I'm not pretty sure if they have this and that or not but Libi-ATA would say, oh, this hard drive has ACP high commons to send and it would grab the handle and then dock would come and oh, somebody's already using it, bay would come. Oh, somebody's already using it and can have only one driver per ACP high node and things wouldn't work. I believe this has been fixed but it may be that it has not gone to mainline Linux yet. I have seen patches but I was not tracking them. And if you ask, oh, and what are you using? I'm using the old thing padway on my computer because that way I still know whether that my driver is working right or not so it's a debugging effort for me. If you wanted to work on a T60, I can send you the patch but I did not look on the Debian kernel which kind of patches they have, I can look at it now. That's a big problem within paid ACP high. It, when it starts, it looks for every available device in the ACP high tables and it insert supports for those. If you are not docked when you start, it doesn't notice that. It's a known problem, it's a bug. I have never fixed it because as I said, the roadmap was to switch to the dock and pay drivers that are generic and not have this problem. I believe they even know how to swap the batteries nowadays they have some patches. So it's a no problem. If it really is annoying people, you please drop me a note by email and I can see what I can do about that but then we, well, it's a patch to think by the ACP high or something else. Then I'm a bit stumped, sorry, because I really don't know exactly what's broken I would have to look at the patch, okay? But it is supposed to with a very new kernel to just work out of the box and dock and dock cleanly. In fact, I suppose I think it even amounts things. Not in a nice way to screen blood murder that you are removing a device that still has fact system on it and say something about that self-indistructing five seconds or something like that but it will work. If you hook to the ACPI notifications which will not be over ACPI itself to be over UFNs because dock and bay is UFNs. So it means UDF. If you hook in a script of UDF you can do the amounting. I think they have that one thing to do but I haven't checked it. I can only look at that. But that's one thing to look at. Anything else about that? Another topic change. Yeah, what now? There are supposed to be a trust in computer model and all things patch. How is it support? What is supposed to be capable of doing in how it usable now? Can we do hardware key storage already? What user one internal support we already have for that model? I'm sorry, I didn't get it perfectly. Please. We have a trust in computer model in all things patch. Modem. Model. Model? Oh, yes. Okay, let's talk about the PTPM. I have actually tried to use the thing. Okay, so I can talk about it. You have, again, old and new thing patch. So what do you get? With the older ones, like the T43, you have a 1.1B TPM model. With the newer ones, you have a 1.2 TPM model and they are very different business, okay? For one, somebody was intelligent for once and the 1.2 TPM model has a generic interface that works on every model from every manufacturer. That was not true for the 1.1B. The BIOS can use it, it sets it up correctly. So in fact, you actually have a platform that could use to do code attestation, I think, they call that. It has a private key you can try to use for seeing things but something's a bit wrong with the user space support at least for the TPM on my computer, which is a natural semiconductor one and it doesn't get the public key correct. I don't know why, if you request the information from the kernel, it outputs the correct one but the TPM tools doesn't, it corrupts the data some way, so obviously it doesn't work. What should be able to do? When you boot the ThinkPad, if you haven't disabled the TPM on BIOS, it will generate checksums and it will start those checksums on registers. There's a table, I think we can think I put there and there's a table on the specifications that tells you what goes there but basically you can have registers that tell you if the supervisor password was typed and which one, or user password and which one, the hardware configuration success, what was the boot device, if there's something like a CD-ROM in the bay or not and change on any of those things, change those checksums and validate keys that are bound to those checksums. If you can get that user space program to actually talk correctly to your TPM, it will work but that's not much more to be said about the TPM, it's a closed-documented hardware you don't even get, there's a small password on this thing that lets you get and change the private key or ask it to regenerate the private key, you don't even have that, at least not on 1.1b TPMs, so it's not really safe to use, I mean, you can't even trust it to do what it's supposed to do correctly. And I should tell you that although I do not have access to it, I am pretty sure that one of those utilities you can get from people in .ru to reset the BIOS passwords, it actually does that by writing to the TPM non-voluntary, if you can do that, I'm sorry, I can't trust that chip ring. There was supposed to be also a secure memory within that stuff. Yes, that's exactly the memory you can write from a DOZ utility to hack the password in a stolen machine, I mean. Okay, nice, thank you. Probably our keys are safe but I don't think the data inside that TPM is really safe. The new ones work, okay, but again, they have the same problem, how much can you trust that? I don't know. I wouldn't use it for much, it's better to get a smart card with your open GPG keys inside and use that safer. Any more questions that you use? So if you had a chance to work with some of the brand new ThinkPads coming out the X300, X200, how well are they gonna work? Well, nobody asked me yet for support for the X300 beautiful blue LED on the Thinklight button or something like that, but mostly they should just work. Lenovo's not trying to do weird things on those models and they did add some new interfaces such as a toggle so that you can enable and disable the wireless USB device but they did that in a way that if I look at the ACPI tables, I figure right away how I should use that. They just copied the Bluetooth and changed names, something obvious and they actually sent me some documentation about that when I asked about Bluetooth so I should be able to write code for that. I'm not aware of any changes to those ThinkPads that should cause us trouble. So I would actually get one for myself. Oh yeah, something that has been brought to our attention pretty recently. The newer ThinkPads, mostly the X series, they use some kind of active cooling so if you have one with a very powerful processor, be aware that the phone cannot cool it enough. So what the BIOS does is that it requests the operating system to lower the maximum speed and if it doesn't do that, it will go over temperature until you shut down, you lose your work. That's a problem with two, six, two, six, two. I mean, the laced stable has this problem. Patch is already out. Should be on. But that's something to keep in mind. I mean, you've got expensive laptop which are two gigahertz CPU and if you want to run it at one gigahertz most of the time because of temperature, it's not nice. But people is open the thing and improve the thermal sink. It's not difficult to do because Lenovo is not doing a top of the line head sink. So you just remove the thermal compound plus something much better that overclocks like this and you get about five or six Celsius degrees out of it. So maybe it's enough to run at top speed. Other sink pads have issues with that thermal sink become loose and they're touching from the ship so you don't have a perfect thermal interface anymore and it starts with heating up. So if you are a sink pad starts getting warm, please do penetration and fix it as soon as possible otherwise it can get damaged. Anything else? Do you want to talk about, do you want to talk about something with the frimmer inside the blocks? Something about the harbor or anything? No, just use it. It's not completely related, but can I make a poll? How many of the sink pad users with the fingerprint reader use the fingerprint actually? I'm sorry, I didn't get it. Yes, I am the fingerprint, I'm one of the fingerprint entertainers. Okay. So I just want to know how many sink pad users with the fingerprint on it use this fingerprint on the system? Well, I don't have a fingerprint reader, so I'm not, yes, that's what I mean. I have tried it and it works, but I don't think it is integrated into the system. No, it's not. It's not integrated. It was to be used, I wouldn't use it with standard authentication when it works or when you ask me about the user name but do you know any plans for integrating it in the future? But it's very early stage. I think with PAM, you know, it already works with PAM. But PAM, do you mean you need to stop something? No, just PAM. What I have heard from other users that just work. Someone else used fingerprint reader in the fingerprint reader? Two, three, four, four. Four, thank you. You should ask how many key fingerprints in their laptops to make it fair. Okay, I have one. So you actually have about half user. You were saying something about it. You have ten minutes left. Well, I've heard that's not that safe, but I have looked into it and they used one of the best technologies about that so you can't easily, you can't, I mean, duplicate very easily a finger and pass that and it will give you a false reading. It's not that easy. But it appears that it generates a small number, a small signature and that's a problem because you can try to bridge force that. It should be pretty safe for your screen saver or something like that. I would use it. I would like to say something about it. It is like harder wise and implementation wise. It's reasonably safe. I have a little problem with it not being configured in a safe way because the problem is that it's now integrated with PAM and some stuff supported, some stuff not. One of the things that supported is for example SSH. So if someone's about, you can see, oh, he's about to enter his GD and whatever username and about swipe his finger. I can log in to SSH to his machine with his username. He swiped the finger. For some reason it doesn't work for him. I hit enter, it enters. So there should be some way to blacklist remote services on the PAM. In fact, there's a problem with the LibPAM. The original designer of F-Print, which is the project that currently involves more fingerprint readers and any of the things that's readers, said that Chi and Chi designed it just as a proof of concept. So it's not that safe. It has a lot of problems with, for example, if you have a screen locker, you don't, well, let's say that screen lockers and GDM and KDM don't behave as the same. Some of them you have to press enter to continue. For example, GDM does not, but KDM does. Some services doesn't behave exactly the same. So it's more like a LibPAM problem, a LibPAM problem that the F-Print designed. FAM is not exactly the most safe and easy design we have. That's the hard truth. So basically just a bit of background. There are two implementations. One which is think about specific, and it's called think finger, and it was started by Fabric Magic, one of the current developers, together with Timo Onig from SUSE. And so it got released 0.3 and it died. In the sense that it was probably just a quick act to show that this finger printer can work on Linux. And this has the same problem on SSH actually. So you could not any more log in SSH if you enable fingerprint authentication remotely, which was quite annoying. And then there was the new software, which is F-Print, which is available in Debian as well, is an experimental as fingerprint, think finger, which is an experimental tool. And this is, as Derek said, this is not only specific to ThinkPad. It's for all kinds of, something like a general library for fingerprint authentication. And it's not any more in early stage, but because it's actually, they changed the API two or three times, but it's work now. They need an involvement in some progress in LibUSB because there was a problem with the old LibUSB, but it's still not, I mean, not every day authentication, I mean, a radio, actually. Some terrible PAM, all magic and specifying. The problem with PAM is that I tested most of the screen server available on Linux with ThinkFinger and really in F-Print, and they behave all differently. They behave really all different. So for example, normally, it's in server needs to have fingerprint, it's locked, works sometimes, sometimes doesn't work. Sometimes it's so slow that you think it's not working after the fingerprint and actually it's working. You need to wait two or three minutes. For example, VLock works. I use VLock, so VLock works. Login works. All which is KDE related, I didn't test a lot. So it's still, it's still, that still works today. I, that's probably the main reason, I mean, I'm sure that's the main reason we didn't put it in a state. It's still an experiment. Obviously, that's a welcome touch as well. Yeah, I'm just, just to add a comment. Fingerprint is just another security mission. We don't rely 100% of it, but this project, Fprint, is going to make a huge, I wouldn't say improvements. I think it's going to add a lot of more features. If you are developers, and most of us are, please take it into account. Take a look to Fprint mailing list. We, with Luca and Serako, the one who is at the, at the corner, we're in deviant integration of value-metrical gadgets. We will be pretty happy if you join us with feedback. So that's all. Well, we have five minutes left. I would like to propose a small, small vote. What would you guys want me to do? To put in the priority queue for ThinkPad ACPI. What's missing? My Q and Q has also a mixer to control the older mixer, which is not going to have much with the new ThinkPad. Maybe I will be able to have a single mute control on new ThinkPad. That would be it. On the other ones, you have a full mono mixer. The second is to better integrate with the hardware monitoring. It's already good, but I could do a bit better. I could have a fun controller inside the car or something like that. The third would be to have better environmental control. As I said, it's a kitchen sink driver, so it's the place where I would put some kind of thermal sentinel and an emergency message because it's too hot or something, but that's something you could do as a space as well if you want. And also, I have a pending request to add support for RFQ, which I'm currently working on, for ultra-wideband USB and also wide area networking on Ymax or something like that, that some new ThinkPads have. Do you have any requests? Do you have any... I would like to clone your tree so I can help in the auto-mixer. My tree is available at jit. It's easier to show you. However, it's a patch-top crib. So it's not exactly you can clone and then merge and something like that. It will always show you the latest state of the driver and something you can work on it. It's ripple.r.sz the full URL is here. This one. You have many branches here, but there are only two of interests for people who want to work with it which are develop and master. Master something that I use to keep like a 2D lists and all patches that have been accepted on my line. Develop is the top of my working branch. Anything that is actually good enough that won't cause major issues ends up here. And as you can see, lots of it's RFQ work because I started doing that so that I could plug it into the API and I had to do a lot of working on that part of the kernel and I haven't finished yet so I am doing both. But you just clone that and I accept patches and anything like that. Unfortunately, you can't have a Git workflow with me because I'm not prepared to have trees that are not how-wond yet. So I do that too many people start talking and I become suddenly I have to act as a subsystem maintainer and I will do that. But right now it's a patch queue and patch queues get rewound all the time in Git so you can't just merge. It's an issue but so far nobody has really complained. I wanted to ask about how the state is with power management and power management? Some kernels ago when I last tested it I think that ACPM module was generating a lot of wakeups. Well, here's what we've got right now. Let's wait a bit. As you can see almost nothing comes from ACPM. It generates about no interrupts unless it's actually getting some sort of notification from your device. Or if you enable its nvrun pooling mode at which time it generates 10 interrupts per second. Or maybe if you want you can actually tell it to generate less or more but 10 is a good number. What we did see was that something was bothering ThinkPay the CPI through its proc interface and requesting data all the time. So if I do this it would be that's a small request for our temperatures to about, I don't know, 100 to 200 EC cycles. And that's slow. That causes a lot of wakeups. So someone was doing a lot of polling for thermal data or something like that and that causes all those interrupts you have. It has me to fix it. Not by me, someone was using it or something wrong and fixed it and I've had no reports since then. Is there anything that is still missing from the power saving side compared to, for example, windows? Yes, lots. But the main one is proper one screen display control so that we have less confused users. Okay, our time is up. We have to go.


I'm Michael Rogers. Now I actually work on the Node.js foundation full-time. And I'm going to talk a bit about how open-source has changed over the last decade or so. And some of the stuff that we've done recently in Node in this new modern open-source ecosystem that has really worked. And my hope is that what you take away from this isn't just like, hey, Node's doing really well now, but also a lot of things that you can use in your own projects and use in your open-source communities. Okay, so the first thing that we have to talk about is the fact that open-source won. So... Alright. You know, if I was up here 10 or 15 years ago, I'd be talking about how, you know, open-source is amazing and you can totally convince your boss that it's not going to kill everybody in your building. And, you know, but nowadays, you know, not only is every major company built in some way on open-source and supporting open-source in some way, but also every startup in the world is like this thin layer of code for their application on top of this giant open-source stack. So everything from operating systems and databases and languages and frameworks, all of the base technological innovation for everything that we do is all open-source now. So we've won, like you have to use this stuff. And the world that you live in once you win is quite a bit different than the one that you were working in when you hadn't won yet. And that's why a lot of older people and older generations of open-source and even some of the institutions that are really important to supporting open-source are kind of struggling to catch up and understand what this new world that we won looks like. The other really big thing that happened with GitHub, like, we're still understanding how much GitHub changes the way that we build software and communities. There's a lot of things that it does. It lowers the barrier to entry in general for doing open-source, but I think the biggest thing that they did that nobody's really talking about is that when you take that first step and you contribute to an open-source project on GitHub, you're starting to learn a skill set that is transferable to every other project that you're ever going to engage with in open-source. That didn't exist before. So if you were getting into open-source 15 years ago, like I did, if you went to give a patch into MySQL and then you went to get a patch into Apache, everything that you did to prepare that patch was totally untransferable as a skill. It wasn't just an entirely different community and release process and governance structure. It was also a different source code manager, a different ridiculous fork of bugzilla with their crazy component thing that nobody can figure out. And no project was consistent about this. The only thing that was consistent was that it was always confusing. And it seemed to be built for five people that work on the project a lot and not everybody else. So that's gone.  You had to host your own source control and issues and whatnot. So it made a lot of sense to centralize a huge amount of effort in these giant projects. And now you don't need to do that. The infrastructure is all there. All the skills are transferable. And so we can create new projects and new communities very, very quickly. There's very little barrier to entry. There's no friction in doing that. And there's no friction for the participants to move around those projects. So to illustrate this a little bit, in 2001, these are the stories of open source. These are the most successful projects in the world. In 2000, Apache had just kind of killed the IIS in terms of market share, which is kind of the first time that that ever happened to Microsoft. So people were really talking about that. And Linux was obviously taking off. And these projects are really big. Apache, I don't know if you know, but it has every feature ever. Like all of them. I mean, it has every feature ever. And then you can just, like, in a config, swap out the entire concurrency model. Like, that's how big that project is. And in that older world of open source, it made a huge amount of sense to do that.  And then, like, and then you have to maintain all of that. Like, why don't I just get this feature into Apache, like, the whole server, right? So we built these giant projects that over time became kind of inaccessible. And nowadays, like, these projects are still alive, and they still have contributions. But a lot of that is that they have a big established community, and they also have a huge install base. So a lot of people need to continue to maintain them and get their stuff in. So they're not going away. They're still pretty healthy. But you wouldn't be able to do a project of that size with that much code nowadays. It just wouldn't happen. As soon as you got to a certain size, somebody else would just, you know, fork it and reduce it and turn it all into plugins. But by the same token, now that we're in this smaller project space and people are doing all of these smaller modules and everything is getting tinier, the stories of open source today aren't about projects, they're about ecosystems. And the project that enables that ecosystem just ends up being a proxy for what we want to talk about for the entire ecosystem. Like, when people say that they're into Node, they're not really into Node Core. They're into, like, all of the stuff that they use on top of Node Core, right? They're into this huge ecosystem of stuff that they can do. When people say that they're into Docker, they're not, like, into, you know, the Docker thing that they install and the features that that enables. They're into, like, you know, I can build this image, I can build on top of these other images and these other layers, and there's this big ecosystem in this huge community contributing all of the stuff that I'm not going to have to do myself, which is great. So this is kind of the more common case. And going forward, I think that you're going to see a lot of the same things happen to these projects, to these, like, kind of critical projects that provide the compatibility layer for an ecosystem for a couple obvious reasons that I'll get into soon. But to kind of illustrate my example, this is language ecosystem growth. So the number of libraries for every, all these different languages. And they don't have pretty comparable growth. Like, these languages all seem to have, like, pretty iterative growth. A couple are growing a little faster. A couple have had a longer time to get up there. PHP is actually, like, the only one that's looking, like, really kind of good taking off there in 2013 once they got, like, a better package manager. But then when we add Node to this graph, the whole graph changes. Like, the entire top section comes in. And you realize that while these other ecosystems are growing incrementally, Node's ecosystem is actually growing exponentially. It's ridiculous. Like, we're now not only, like, the number one ecosystem in the world. We're not only, like, the fastest growing ecosystem in the world, but sometime early next year will actually be twice as big as the second biggest ecosystem, Java. And this shows no signs of slowing down. And I'll talk a little bit about why this isn't slowing down when we all thought that it probably wouldn't in a little bit. But having a huge ecosystem doesn't solve all of your problems.  And it may not have the same incentives as the ecosystem. So while this was happening, the largest ecosystem in the world, this also happened. These are contributions to Core. And you can see that they, you know, they're bits and spurts, but they've been going down for a long time. And they hit a critical point coming into 2014 where it literally drops off a cliff. I mean, it's, like, coming into 2015 there, it's going to zero. Like, nobody is working on the actual Core. And that's a huge problem because it wasn't done. And it had bugs and huge problems. And the other result of this that's far more striking is actually the number of releases. So the number of releases of Core drops dramatically. And there was really no way to pick it up in that project. And there's a huge amount of reasons for this. But the big thing to note is that in the ecosystem, it's really easy to create a new project and to get involved. And the slightest bit of friction in getting involved in this Core project, even though it's very important, was killing it off over time. So we can start to trace a lot of why it had these deficiencies to actually the things that made us popular when we started growing. And if you look at any big project, and especially languages, when they start to become popular, they build a culture and a community. And all of the things that are helping them win really define the people that show up and the people that stick around. And then literally the things that made them successful end up hurting them down the road. And that culture has a really hard time changing. So we're going to look at what was going on in Node in 2010 and then in 2014 when we started to have all these problems. So small, corner, large ecosystem. Huge advantage. There's no question that we would have ever been able to be successful without that. We don't have a giant standard library. This isn't Python. We just want to keep it as small as possible and then let this ecosystem flourish. So that also meant that as this giant community is growing, they're not actually trying to get modules in the core. They don't really have any reason to work on core. So this huge community that's growing over time isn't focused on core at all. We also have autonomy in the ecosystem. So each one of these little components can be published without getting anybody's permission. You can start it without anybody's permission. There's a lot of freedom there. But that means that the barriers to entry and contributing to core where you can break this huge ecosystem and it's just slightly harder to get involved in general and you don't get to own the project right away become really big barriers to growing that core contingency. Also, in 2010, foundation was kind of a bad word. And I'm as guilty for that as anybody. But I think really what we were feeling at the time was that foundations had been set up around these older open source models and their governance structures were really baked around some of the tools and processes that they used and as GitHub started to take off and we started to build these huge new communities, foundations were sort of like the antithesis of what we were doing. They were trying to get everybody to move to these older models of participation and we were trying to create new ones. So we felt at the time like it was this huge advantage that we didn't have institutional backing. We weren't inside of a foundation. The community could just own this thing. So it turns out that an abstract idea like a community can't own property legally. It turns out that like when you think that a community owns something, actually a single person owns it or a company owns it. And it really took until 2014 where that started to sink in where we would like to change some of these policies. We would like to change the way the project works and the governance structure and the people who work on this are not actually enabled to do that because this company controls it. Also, when projects get to this size and big companies start to rely on them, even if you aren't getting a lot of contributors, those companies will just kind of throw resources into it, usually, unless the project happens to be owned by a single company that they're a little bit freaked out about, right? That might be a competitor or might not be a competitor. So they won't throw those resources in if it's controlled by this single company. One of the reasons why you're seeing all these new foundations start up around Docker and Kubernetes and all these technologies is that there's just a ceiling that you hit when you're growing where the people who want to adopt you won't adopt you if you're owned by this one company or this one person. They need to know that there's an independent entity that they can invest in that actually owns this over the long term. I did that too. I hate that. That's not a feature. Why do they do that? In 2010, we were like, JavaScript is done. None of this other stuff is ever going to happen. These guys are going to duke it out in standards bodies forever and it's just going to be ES4 all over again and Crockford is just going to put his foot down and be like, you shall not pass. But at the time, this is actually really freeing because we got to just build a platform. We didn't need to argue about a language. We didn't think that any of our problems could be solved with a language, so we had to solve them ourselves. We had to implement a binary type before the browser really had a binary type because we really needed that and we couldn't wait around for it. That was a huge advantage then. But it turns out that actually the language isn't done. People are working on it. They're making changes to it. And we're not involved in that process at all because when we were building up our core community, nobody who wanted to talk about a language showed up because we weren't doing that. And now we're really on the outside looking in on new features and a lot of them affect us pretty dramatically. They affect node really dramatically and we need to get involved in this process. So what we're really looking at is a list of competencies that we built and then the things that were excluded from our community as a competency because we built these other competencies instead. So what we needed to do was find a way to go and build new competencies into our community and into our project. So for a lot of reasons, we ended up forking. We did this IOJS thing and we focused very specifically on only building up the competencies that we were lacking. So the advantage that a fork has is you take all the code with you, right? And in this case, we actually took pretty much all the contributors too. So we basically had all the competencies or most of them that node had. We didn't have the install base so we couldn't do things like, you know, fix bugs in older releases or dedicate to LTS support and these things that people really do want, we couldn't solve those because we were this new fork but that freed us up to focus on building new competencies and to building a project that really specifically tried to bring in new contributors and invigorate a newer community around it. So the first thing that we did was we took on this liberal contribution policy. This is a lot of work that was pioneered by Rod Vagg in a couple projects that he did but the basic premise is that when somebody shows up and they write a piece of code, it's not like just a one-line doc change or something. It's like a decent thing of code. You just add them as a committer. And this sounds really scary to a lot of people but what it actually is is just our policies catching up with our tools.  It was terrible. You can't do that to Git.  There's nothing that you can't undo in a Git repo. This is by design, right? But we still have these older ideas about commit rights and commit access and write access and we're just kind of catching up with them now. So you just add them, right? You're not allowing them to release necessarily. The release process might still be a little bit guarded, right? But why not just give them commit access? And it turns out that when you do that, when you show a little bit more trust in people, they actually engage a lot more and they stick around a lot more and you build a lot stronger of a community. Another thing that we did was we went to a consensus seeking model for governance. So consensus is like everybody has to agree on something.   If to do something everybody has to agree, then it only takes one person for it not to happen. And there's actually no incentive for that person to convince the rest of the group that they're right and that we shouldn't do this. They just get a veto. That's what a consensus system really is. It's everybody gets a veto on every decision. And in an open source project where you want to be effective, you can incentivize that kind of behavior. So consensus seeking is that we try to reach a consensus, but if we can't, we will vote. And a vote is kind of just the ultimate tiebreaker. And it's always there as a threat. So the interesting thing about this model is that we've never had to call for a vote. The reason we never had to call for a vote is because if I don't agree with you, but I'm not willing to put in the time to try and convince everybody else, it's pointless. Like, why would I even waste my time? So what ends up happening is that when a tough decision needs to be made, the people that are invested in that decision and know about it, get involved, they try to convince each other, they end up at like a pretty good solution and everybody else pretty much just accepts it. And nobody's incentivized to just step in and go, I don't want to do this. Okay. The other thing we did, so we don't want to load up people working on the project with a huge amount of process. Like, I don't know how many projects you've been involved in, but I've been involved in like a dramatic range of open source projects. And the ones that have a huge amount of process around getting anything done are painful. And they don't grow new contributor bases the way that they should. And it just, it really starts to feel icky. So we didn't want this consensus seeking to create some really formalized process that then everybody had to adhere to and it was very hard to get code in. So basically what we do is we err on the side of changes happening. So somebody sends a PR and people review it. And as soon as somebody is like, yeah, this is ready to go in, if nobody objects for a long enough time that all the time zones could object, then that just goes in. And so all this code is going in all of the time and the TSC, this sort of like, which is basically just like 15 people right now who are heavily invested in Node, really know a lot of the code, and we act as like a tiebreaker if something contentious comes up. But the default is for code to just make it in. Like it should go in, all of the committers, there's like 40 of them now, can all put in code, it's great. But when somebody does object, when there is some kind of contentious issue, that escalates to the TSC and then the TSC talks about it, tries to reach consensus, usually does pretty quickly. And then we move along. So we're just trying to keep the process moving. We're trying to keep changes happening, keep work going on. It's not designed as a giant system of safeguards that just like kick people out of wanting to be involved. All right, frequent loses, as often as we possibly can. This is kind of self-explanatory. But yeah, this was a big problem prior. So this was really important to note that we wanted to get releases out really often. We implemented a code of conduct. For some reason we couldn't get one in and we didn't have the project, so we implemented that because that's the same thing to do. And we have this autonomous working group model. I'll talk about that a little bit more, but essentially we have a bunch of sub-projects inside of core that are all essentially independent. At some point we reconciled the projects together. We merged them back. And you saw this happen as well with the kind of core OS Docker thing. And you're seeing this in a lot of the forks or alternatives that come up. And this is actually the best possible outcome. Because what you end up doing is you build all of these new competencies in this other community. And then you merge it with the original community that had all the other side of all of those competencies. It's actually a really good way to continue to build competencies into your community. But you have to keep the door open to reconciling, which is really hard to do. You have to have a lot of different kind of boxing matches and cover them that way because they like drama. But anyway, Joyant created the Node.js foundation and said they're going to put all of their Node property basically into the foundation. So that was great. So immediately we could start working with Joyant and with the foundation to possibly merge back together with an existing foundation, they would have had a governance structure that they would have needed to impose on the project. And we had just built a new one designed to solve all these problems. We couldn't just take somebody else's off-the-shelf governance model. So that was really important. At this point I got involved, Bert got involved, a few other people from IOJS and we worked with the foundation to build a new governance model for the foundation. I don't know if you've ever had to start a foundation to just keep the lights on, to just keep everything moving. And it takes actually a lot of money to do that as well. Accounting services for specialized things like foundations and open source projects are kind of expensive. So you need to have fundraising, you need to have all of this infrastructure kind of stood up just to keep the entity alive. And in America you also have really, really tough tax laws that you have to comply with. So it's all very specialized. But we wanted to make sure that the people that were running the foundation could run the foundation under the best governance model for them and the project could remain under the governance model that we had more or less built in IOJS. So we ended up doing what we said, okay, foundation has a governance model, the project has a governance model, and there's a wall in between them where the community and the contributors own the project and that process. And essentially the people who end up funding the foundation can keep the lights on and do all of the things that we put in it doing than programmers are. Programmers are pretty bad at accounting. We also got long-term support. People have wanted a dedication to long-term support and to know how long a particular version of Node will be supported and we finally get that because, one, we have the Node project and all of the old release lines that we can now properly do releases for and we have all the contributors from IOJS to Bear, which is amazing. When we reconciled, we had a little over 40 core contributors as well. So Node.js at its peak had seven core contributors. So we were already more than four times that. We also have 360 GitHub members and those are people that work in some working group of some kind. And I'll get to a second how that's actually representative of all of CORE and of the CORE project because we've broken so many things off of CORE into these working groups. So these are the working groups that I could remember basically that are going on right now inside of IOJS. We found this really great model for what we think can be continuous building of core competencies. So as soon as something is clearly not being well done in CORE itself by like the TSC and in this tiny little GitHub repo we go okay, let's break that off. We're going to say the responsibility for this now entirely lies in this other group of people and they don't work for the TSC. This isn't like a hierarchy. They are autonomous. They get to control their own destiny. They can build their own processes. And what that does is it turns these working groups into its own little community with its own little incentives.  That sucked. Just getting it in. And then what would happen is one person who is good at building websites would end up doing all of this work because they can deal with the process. But they are really undervalued. They are not very valued for the great work that they do on the website because the people who work on CORE are into other things. It's not their competency. They don't really understand it. So you're not going to get new contributors to show up because new contributors want to see that their skills are valued and that their opinion matters and things like that and they're trying to work inside of the structure where the incentives just aren't there. So what these really are in a way are like tiny little forks of node. We're basically taking little pieces of node forking them off into like their own community and saying, you deal with this. It's awesome. Thank you. And it's working incredibly well. I mean, some working groups are going better than others. Some are brand new. Some are like thriving. But that 360 number is really the number of contributors to node as a CORE project now. Which is so many more than we used to have or could even imagine contributing to a single project. So this has been hugely important. But we want to extend this. So part of node success and why that exponential growth curve is still happening is that node is a really good platform to build new platforms on.  So if you look at NPM and all the modules in NPM what you can pull out are these little sub-ecosystems. So these other really critical projects that enable another set of plugins or another set of modules. And the reason that the exponential growth is staying is that more and more of these start stacking on top of each other and then they have a growth curve and they level off. But when you put all of them together you get this giant exponential growth curve. So just as an example let's look at Gulp and Grunt. So these two tools essentially go after some of the same tasks. They're just for front-end tools to get your front-end tool chain knocked out. And these have been hugely successful. They have been using tons of people use these. They have a lot more engagement than a typical node project because the barrier to entry for working out front-end stuff is just a bit lower. And interestingly if you put these ecosystems like the Grunt and Gulp ecosystems next to entire programming languages they're doing pretty well. So Grunt has a couple hundred more modules for it than all of closure. That middle graphic is for Haskell. Haskell has a different kind of grad graphic. I don't know what any of that means but it's probably a crazy Haskell math or whatever but something with monads. But we have considerably more modules just than Grunt. Gulp, which is the smaller ecosystem it's about half the size of Grunt is still more modules than all of R.  Did they rip that off a GeoCities page?   But what we're noticing is that as node becomes a place for sub-platforms for sub-ecosystems those projects end up having a lot of the same problems that we had in node. They grow to a certain size and then they can't really handle it they need to encourage participation but it's too hard to get involved. And when you think about them as being basically the size of small programming languages this is a pretty serious problem. They're not really going to be able to set up their own foundation and all of their own infrastructure. So what we want to do is create an umbrella inside of the foundation for these projects where we can take a lot of what we've learned in the node projects and help grow these communities and give them a solid place to be. This isn't the official logo for the umbrella this is just the first umbrella image that came on GitHub or Google Images.  So part of this process of creating this umbrella is that we've had to look back at what's happened with node.io.js over the last six months and really start to distill down some core values. So if there's one thing that we know it's that we're not done iterating on our own processes yet. We know that we don't have a perfect process. Every working group has a slightly different process. Some of them work well. Some of them don't. We try to share that and iterate as a group. So we can't do what Apache does and what a lot of other like big foundations do where they just impose a process that says that at the end of the day you'll hit these values. Instead what we have to do is go back and go what are the core values? What do we think it means to be a successful project inside of this foundation and then evaluate how well the policies and processes that these projects implement are working towards that goal? So the first one is that we think the project should be participatory. We don't think that we're kind of done with BDFLs. We're kind of done with closed off decision making.   You're trying to be representative of the larger community. We also think the project should be transparent. Transparency isn't just about a decision being public. A decision ends up in code and the code is public. That's not good enough. You need to be able to take the decisions that led to that piece of code the discussion around a decision finally coming to it and trace that code back through that decision process. Otherwise one can never participate in it because they don't understand it, they've never seen it and also it starts to violate people's trust. They start to believe that there's some kind of cabal of people somewhere that make decisions that they're never going to be a part of. So by making things transparent you get around that and you get a lot more credibility. And finally we think the project needs to be effective. A lot of policies and processes that you put in place will make you better at achieving some kind of goal but also leave you much less effective. And also we want new innovation in process. I mean, we're still building tools that help us build all of this stuff. We're still building tools on top of GitHub because it's still adding features. We want to be able to continuously iterate on our processes and the kind of guiding principle is that iterating on them will make us more effective and that a newer, better effective policy is actually valuable and we should actually adopt it rather than just going oh no, we figured this out, we're never changing. And finally, I think as a cultural thing, we need to be nice. We need to be like a really inviting community.   And the reason you have to do that is that there's a much smaller number of people that are very nice, that are very pleasant people that have a tolerance for assholes. And to get the larger Venn Diagram of nice people, you have to eject the assholes.  And the moment that I turned this into a Venn Diagram, it became science. So now you can't even like, this is the data now. All right. And finally, I think we, you need a neutral body. At some point, you're going to reach a breaking point with not having a neutral body or institution to carry the property and setting that up is really, really difficult. I just went through this, I know exactly how hard it is. I don't want a bunch of other projects to have to go through that all over again. So we hope that we can share what we've built with a broader community and we're working on a lifecycle document and a process for bringing these projects in. And also a lot of what we've learned we've tried to just be very public about. So we write about it on our, we try to blog about it, we try to do talks like this about it so that even if you don't come into the foundation and you don't come under an umbrella, you can take a lot of what we've learned about running software projects in open source. So that's about it, but just as a nice little thing that happened today, the first release candidate of Node v4 is up which is the first converse release of all of IOJS and NodeJS. So go to that Earl and please test that. I'm just wondering, there's probably a lot of people in the Node community that they want to participate and maybe they're confident that the active participants will be welcoming, but what if they don't know how to participate or what if they're not sure what they can offer? What would your advice be? So I think that one of the things that we're trying to do with the working groups and we haven't promoted them well enough, right? Think about getting involved in Node, you go to core and then you're like just terrified, right? But we really want people to get involved in working groups first because if you just look at that list one of them is just going to appeal to your skill set, right? Like you're just going to go, I know how to do stuff like that. And we've actually already seen somebody literally come in to the website working group and then get involved in core and then move on to the TSC in the governing body within a matter of a couple months. So I think that once you're involved in a single working group it becomes a lot more accessible to jump around to other working groups eventually into core and we really think that that's a good funnel for getting people that for one thing, it's not as hard to contribute to core as you think. Like anybody can learn it if you really want to put in the time but it is kind of terrifying and part of the thing that's terrifying isn't just the code part, it's also the culture part. So with the working groups we can take the code part out, it's freaking you out and you just kind of acclimate to the culture and then when you understand the culture is not very scary then you're not you're not fearing the code part as much. That's what I'm saying about that. And we're working on the new website right now where we're going to try to promote the working groups a lot more. Awesome. There's a hardware working group that you should be in. I'm already in it.


Hi, welcome to this talk on scalable pseudo-random quantum states. My name is Amrish Mouelli, and this is joint work with V. Kaabrakersky. And this work is going to focus on the efficient generation of quantum random states. And it is a basic fact in quantum information theory that efficiently generating a truly random quantum state is impossible. This follows because if we consider the space of all NQ with quantum states, this space is infinite, but even if we discretize it to any negligible precision, then the number of points is going to be too big, is going to be super exponential, and we don't have hope of efficiently sampling quantum. And now, one known solution to this problem is aiming for a more modest goal, namely aiming to sample from a distribution such that for a bounded number of copies of the output state, it is going to be indistinguishable from the same number of copies of a truly random quantum state. And indeed this modest approach has results. One kind of strategy is called the quantum state design. This is an efficiently sampled, usually efficiently sampled distribution, where for an a priori known T number of copies, an output state, T copies of an output space of this distribution and T copies of a truly random quantum state are going to be statistically indistinguishable, which means that the trace distance is going to be negligible. And another kind of strategy, more recent, is called a pseudo random quantum state. This is again an efficiently sampled distribution such that this time for any polynomial number of copies T, the output states T copies of the output space and T copies of the truly random quantum state are going to be computationally indistinguishable. This time the indistinguishability is going to hold only against polynomial time quantum distinguishes. Now let's define exactly what are pseudo random quantum states. This notion was defined by Glu and Song for the first time in crypto 2018. So this is a quantum algorithm. The PRS generator is a quantum algorithm G. It gets two inputs. One is a parameter denoting the number of qubits in the output state. The other is a classical key. And the security guarantees the following. So for any polynomial, if we think of the output state of the generator for a classical random key, then polynomial in many copies of this state and polynomial in many copies of a truly random quantum state are going to be indistinguishable for polynomial time quantum distinguishes. And PRS generators have a few applications. Some of them are a simulation of thermalized quantum states. Another application is quantum money. And these PRS generators are known to exist based on the existence of post quantum one way functions. Now one property that is present in all PRS generators is that what we think of as the security parameter is the same number as the size of the output quantum state. Let's be more precise about this. So let's recall for a moment the security definition of a PRS generator. So what we're seeing in red is what we think of as the security parameter, right? This is the number that denotes how many copies we are going to give the adversary. We're going to let the adversary have and also the number that denotes how hard is it going to be for the adversary to distinguish for this number of copies between the output state of the PRS and the truly random quantum state. What we're seeing in blue is just the output, the size of the output states of the generator. And as we see, this is the same number. And what this essentially means from an operational point of view is that the more random the state is, the more we want to make it hard to distinguish this state from a truly random quantum state, we have to use more quantum memory. The state size grows. And the question that we are going to try and answer in this work is can we create a small highly pseudo random state? Can we make the security parameter and the state size independent of each other? So for this goal of maintaining the independence between the security parameter and the state size n, we're going to define a scalable PRS generator. So this is again an efficient quantum algorithm. This time, the security guarantee is going to be a bit different. The output state of the generator is going to be for any polynomial number of copies indistinguishable from an n qubit quantum state, but the security parameter is going to determine how many copies and also how hard it's going to be to distinguish from the same number of copies of an n qubit totally random quantum state. And a few words on previous works. So the lack of security parameter, the lack of this independence between the security parameter and the state size is something fundamental because previous PRS generators, they output a state which is essentially a uniform superposition. So the amplitude is stationary, this is just uniform, the vector, if you look at the vector that describes the quantum states, all of the absolute values are the same. This is a square root of 2 to the minus n. And the phases are going to be pseudo-random. And if we're saying that the more the hardness of distinguishing between the PRS output and the totally random quantum state only grows with the state size, it is natural to ask what happens on the opposite, on very small output sizes. For example, the smallest output size, one qubit. What is the performance for one qubit? And these kind of distributions, which are uniform superpositions with pseudo-random or even completely random phase, they actually cover only this red ring in the block sphere. And this is the reason that they are very, very easy to distinguish from a totally random one qubit state, which covers the entire block sphere. So as we understand, in order to get a scalable PRS generator, we cannot just randomize the phases, we need to also randomize the amplitudes of the states that we are out. So onto our results. So we define also explore this notion of scalability in the efficient generation of quantum random states. And we show a framework, specifically we show a framework for constructing scalable random quantum states. And more formally, we show two theorems. The first is given the existence of post-quantum one-way functions. We show that scalable PRS generators exist. In particular, we use the same computational assumptions needed for non-scalable PRS generators. And also unconditionally, we show that there exists the scalable T-design generators in depth that is improved from polynomial in N, the security parameter in T, to polynomial in N, the security parameter in log of T, for any polynomial T. So we improve the efficiency of existing T-design, scalable T-design generators. And we show the existence of scalable PRS generators. And in order to show these two theorems, we use the same paradigms as previous work, which is the first showing and what is called an asymptotically random state generator. So let's first define what is asymptotically random state. This is essentially like a pseudo-random quantum state, but where the distinguishability is statistical. So if we take the output state of an ARS, ARS is short for asymptotically random state. So for any polynomial number of copies, this state is going to be statistically distinguishable from the same number of copies of the truly random N-quad state. And the paradigm, this ARS paradigm that appears in both previous works is the following. This is how we construct both PRS generators and T-design generators. So the main technical point is constructing an efficient quantum algorithm that when it has one to more access to a random classical function F, it generates an ARS, which means that if we sample F at random, then the output of the generator is going to be statistically indistinguishable from a truly random quantum state for any polynomial number of copies. And then when we have this ARS generator, we can take F, swap it with the quantum-secure pseudo-random function PRF in order to get the PRS. And if we want to get out of this ARS generator, a T-design generator, we swap F with the 2T-wise independent function. So essentially this is the way we can view ARS generators as the center for the efficient generation of quantum random states. And this is going to be our focus in this work in the technical part. So we follow this ARS paradigm, but we construct a scalable ARS generator, a scalable ARS generator, which means that this efficient quantum algorithm now is going to get additional parameter, which is the security parameter. And this security parameter is going to determine how hard is it going to distinguish the output of the generator between a truly random quantum state and also how many copies we let the adversary have. And accordingly, our main technical lemma is going to be showing that there exists a scalable ARS generator where the trace distance between the following two distributions is going to be bounded by T over e to the lambda, where these two distributions are the following. The first is the output of the ARS generator, the scalable ARS generator, T copies of this quantum state versus T copies of a truly random n qubit state. And one important thing about this bound is that, of course, it is independent of n, which implies that only the security parameter is going to control how hard is it going to distinguish from a truly random quantum state. And we also improve the bound in terms of the dependence on T, because we get a linear T compared to a T squared from previous ones. We now describe our construction of scalable asymptotically random state generator. So to be concrete with what we want, we want a polynomial time quantum algorithm that gets n number of qubits, lambda security parameter. It gets a quantum oracle access to a classical random function f from n bits to polynomial in n and lambda number of bits. And it outputs an n qubit state psi. And the guarantee is that when f is random, T copies of this state is going to be highly distinguishable from T copies of the truly random n qubit quantum state. One thing that's going to help us with intuition is maybe the most basic fact in quantum information is that the space of n qubit quantum states corresponds to the unit sphere in complex space of two to the n dimensions. Now our approach is going to be very natural and with accordance to this effect, we're going to attempt to sample a unit vector on the sphere just in a quantum state, and the security parameter is going to only increase the density on this sphere of all n qubit quantum states. And the outline for implementing this approach is the following. So given the oracle access to this, the quantum oracle access to this classical function f, we want to transform it into oracle access to a different function that describes a spherically symmetric vector v, where we mean oracle access to the vector. This is a vector in two to the n dimensions. It has two to the n entries and for input x, it is going to output the entry that corresponds to the string x. And this vector has to be spherically symmetric if f is random. And the second part in our algorithm is going to be to efficiently generate the quantum state that corresponds to the spherically symmetric vector v. So let's start with the first part. We want oracle access to a spherically symmetric vector and we have oracle access to a random classical function f. And one thing that can solve this first problem is that if we had a classical circuit g that translates it locally, which means that g of f of x is going to be this vector v such that when f is random, doing this transformation with g on each of the coordinates of f, going to yield a spherically symmetric vector. And for this to identify what this circuit g needs to be, we recall a basic property of multivariate Gaussian distribution is that it is spherically symmetric, which means if we take a vector with many coordinates and each of the coordinates we sample from a Gaussian distribution independently, this vector is going to be spherically symmetric. It's going to a normalization of this vector is going to be a uniform unit vector. And this is, of course, a very known property of the multivariate Gaussian distribution. It is very useful for algorithms for sampling random unit vectors, because all of these coordinates are going to be can be sampled in parallel, independently of each other. And then only the norm of the vector needs to be computed. And this also can be done in parallel. And while this property is very useful for the first parallel generation of a classical unit vectors, we use it in the quantum setting to generate it efficiently. So this classical circuit g is going to be sampler circuit, the classical sampler circuit for the Gaussian distribution, which means that we're going to think about the output of F as the randomness, the random tape for a classical sampling algorithm. And this algorithm is going to be sampler for the Gaussian distribution. We denote this algorithm with S. So V, the X coordinate of our vector V is going to be S, this sampler S, applied to the randomness F of X. And one technical detail to recall is that S has to be an efficient, in particular, a polynomial size, a classical circuit. And it cannot really sample from the continuous Gaussian distribution. It has to sample from a discrete Gaussian distribution. But we're going to leave this technical detail for the full version for the paper. And in this presentation, we're going to assume that S sampled from the continuous Gaussian distribution. OK, so it seems we solved our first problem. We have oracle axis, quantum oracle axis, to a spherically symmetric vector V. And now we want to generate the quantum state that corresponds to the normalization of V. And this general task of getting oracle axis to the description of a quantum state and then generating the quantum state is we don't have efficient algorithms for this general task. But of course, we don't have the general case here. We have a restricted case where our vectors are Gaussian vectors. And we're going to attempt to find properties of the multivariate Gaussian distribution that are going to be helpful in the efficient generation of the quantum state that corresponds to V. For this task of generating the quantum state that corresponds to the vector V, we first recall a quantum algorithm for the generation of quantum states. This algorithm is called the quantum ejection sampling. It is the quantum analog of a classical ejection sampling. And the setting is as follows. So we have one quantum state alpha and we want to transform it to another quantum state beta. And additionally to having alpha, we have a classical, we have oracle axis, quantum oracle axis to a classical transformation circuit F. Now, this circuit F outputs the ratio beta over alpha times a number one over D for some number D, which is an upper bound. Now, this upper bound is an upper bound on M, where M is the maximal ratio between the coordinates, between all of the coordinates of beta and alpha. And if we have this circuit F and D is where it outputs beta over alpha times one over D, we can generate beta with probability one over D squared. So the intuition is the important part behind quantum ejection sampling. And it says that if we have a state alpha, where all of its coordinates are roughly the same as another quantum state beta, and we also know the ratios in all of the coordinates by some classical circuit F, we can generate beta with some good probability. Okay, so in our case, if we take the quantum ejection sampling to our setting, we know what is the target vector that we are aiming for, our beta is the normalized V. We want to generate a quantum state that corresponds to the normalization of V. Now, we have beta, but we don't have yet a suitable alpha. Alpha needs to be a quantum state that we know how to efficiently generate from scratch, not using a quantum ejection sampling. And even if we, in addition to alpha, we also need to know what is the circuit F that is going to output the ratio between beta and alpha times the bound one over D. Recall that we don't even have beta yet. We have only the unnormalized version of beta. We don't have the normalized V because in order to compute the norm of V, we need to know all of the coordinates of V, and this seems to take exponential time. So what properties of the Gaussian distribution are going to be useful to us for the quantum efficient generation of the state normalized? So the first property, again, these are very basic properties. We just observed that they are useful for the efficient generation of the quantum states that corresponds to Gaussian vectors. And the first property is that if we take a random Gaussian vector of 2 to the n coordinates to the n dimensions with overwhelming probability with probability 1 minus e to the minus lambda, all coordinates are bounded by a square root of n plus lambda. This is true by union bound because the probability for each of the coordinates to pass this bound, this relatively small bound, is so, so much time compared to the number of coordinates, which is 2 to the n. Now, this means this less sentence is very only on the intuitive level is that all of the amplitudes of this vector V are roughly the same when they are compared to the norm. So the differences between each pair of coordinates is relatively nothing compared to the huge norm of this vector. This means intuitively again that this vector really resembles a vector where all of the amplitudes are the same. And a vector where all of the amplitudes are the same is simply the uniform superposition. And what is fantastic about the uniform superposition is that this is a quantum state that we already know how to efficiently generate from scratch. So we're going to take alpha to be the uniform superposition, the plus to the n state. And if we take alpha to be this uniform superposition, we can take our classical transformation circuit F to be the x entry of V times 1 over square root of n plus lambda. Now, why we chose these exact parameters? So let's observe that if we look at the ratio beta over alpha, we know that beta now is the normalized V and alpha, we also know what is alpha. This is simply the uniform superposition. We know that because of the first property, all of the coordinates of V are going to be bounded by square root of n plus lambda, which means that our D is going to be square root of 2 to the n times square root of n plus lambda, all of this divided by the norm of V. And by choosing these parameters, we guarantee that the f of x is indeed 1 over D times beta over alpha. And this is all great, and all our parameters are fixed, but we recall that the successful ability of quantum ejection sampling is 1 over D squared. So essentially, in order for this probability to be noticeable, we need D to be polynomial. And this comes down to the norm of the vector V being very big, being like on the order of square root of 2 to the n. And this is where another property of the Gaussian distribution kicks in to help us is that the Gaussian vector of 2 to the n dimension has this square root of 2 to the n over 2 has this norm, at least with over 1 probability, with 1 minus e to the minus 2 to the n. And we know that now our vector with over 1 probability is going to be large enough, which means that D is going to be small enough, and the rejection sampling successful ability is going to be noticeable. And because we can regenerate alpha every time we try, we can try polynomial many times and with overwhelming probability in polynomial time, managed to successfully generate the state V, the quantum state that corresponds to V. Now, one small technical problem that I kind of hid under the rug is that this concentration bound that tells us that the vector V is going to have a large enough norm, this concentration bound kicks in only for large enough n. Right, we want our construction to work even for n equals 1. And for n equals 1, this 1 minus e to the minus 2 to the n is not large enough probability. This is just a constant probability. And our solution to this is that this concentration bound on the multivariate Gaussian distribution is so, so, so successful and even in the exponent we have 2 to the n, so this concentration kicks in already when n is at least log of lambda. And then we have one minus e to the minus lambda, which is good enough, which is overwhelming probability in the security parameter, which is what we want essentially. And in this extreme case where n is smaller than the log of the security parameter, we can just sample the entire vector because we can run in 2 to the n time, which is polynomial time in lambda, and just sample explicitly sample the entire classical description of this n qubit state and generate it inefficiently in n, but efficiently in lambda. And to conclude, this is our algorithm for the scalable ARS generator. For the regular case where lambda is bounded by 2 to the n, our first step is to transform this oracle axis to f, to oracle axis to a spherically symmetric vector, and then to a unit vector, and our second step is to iterate polynomial many times and try to do quantum rejection sampling that we know is going to be successful by some concentration properties of the multivariate Gaussian distribution and then generate the quantum state that corresponds to the spherically symmetric vector v. And for the restricted case of the security parameter being huge compared to the number of output, the size of the output state, we know that we can explicitly sample the classical, the entire classical description of the quantum state that we want to output and generate it inefficiently in the state size, but efficiently in the security parameter. And this concludes our talk. Thank you very much for listening.


Hello, everybody, and we've got some great news here. The OKD4 documentation is now live and public. And you can go to docs.okd.io and pick up the latest version. And this version is for OKD4. It's based on the OKD4.3 documentation set with some of the fixes from the OKD4.4 docs that are being worked on currently now. And we have a request that you help us fix our docs, because there are some things in it, like references to MiniShift, which is no longer something that works with OKD4. So we're looking for some feedback from the community. And we would like to share with you how to give us that feedback. So if you go over to GitHub in the OpenShift slash OpenShift dash docs and logged an issue, and in the title, wrote something like this. What we're asking people to do is in brackets, put OKD here, and then tell us what's wrong or missing. And I've invited Michael Burke, who's on the docs team, tell us a little bit about what you should be writing up for these kinds of issues and what he needs in order to make the changes and the feedback to be incorporated. So Michael, tell us a little bit about that. Hi, I think the best way to do this is just start off with a link to the page that contains the information that is wrong or missing. And describe as best as possible how you want us to address your concerns. More information you can provide to us about what you want to change and where the changes are made. And more easily, we can make that change in the documentation. And that's great. And I think what we're really aiming for is some community scrutiny on the latest docs and seeing what's missing. If there's a whole section missing or something that we've done, please also let us know. And we're aiming to try and get your eyeballs and scrutiny's on this over the next week and a half so that we can have some good updated documentation to go out with the beta release, which teasers should be out very shortly. So please, if you can help us, log in here and take a look again at the docs, which are that live up here at okd.docs.io. So thanks for your time. And thanks, Michael, for your support and your help from the documentation team to get this done.