 All right. So, well, this is changing the default system show. Well, I am Rafael Geyser and Lucas Kly. And so, why do we want to change the BNSH? Of course, we don't want to just make a change because we had that in this random idea. We want benefits. And what are these kind of benefits? It is not just about speed, like some people say. It is not just about making the boot process faster or reducing the memory footprint. We actually want a better shell. One of the benefits, of course, is the speed. But it also is a stricter. And the memory footprint is smaller than bash and most of the other shells. The fact that it is stricter is helpful for, for example, for the embedded ports because they actually don't use bash, nor dash. For example, Mdebian uses Busybox SH, which is even more stricter than dash. So, about changing the shell. I've been working on filing bug reports. We'll fix bashisms and demo something about bashisms. I've reported over 800 reports and 800 have been fixed. And there are about 120 that need to be fixed. And of course, there are some other bashisms that are hidden on the source code of C executables, Perl scripts, Python scripts that use a system call. So, how do we detect them? There are a set of tools that can be used to detect those bashisms and other problems that will affect our users. One of the tools is check bashisms from the script package. And another tool is Lintian, which at the moment only checks the maintainer scripts for bashisms. But there are plans to extend these checks to every make file and every VNSH script shipped on the source and binary packages. There are, of course, other ways to detect them by making the change and rebuilding the archive and also testing these solid packages with few parts. So, if they didn't fail and now they fail, well, there's something wrong with it. And of course, you also have the option of users reporting those bashisms that we didn't detect. So, well, check bashisms. It's more like this. This is on the rules of a package. And, well, so it supports VNSH scripts and even make files. Of course, the make file support is not as well supported as VNSH on the pure scripts mode. But we are still improving it. So, how do we plan to make the change? We don't want to just divert the VNSH same link, but we actually want to ship the VNSH file on the package itself. By doing it this way, we are guaranteeing that the file, the VNSH same link won't be gone at some random point because of some unknown reason. Because, currently, bash is providing the file. And now, bash is also going to provide the file. And the idea is to make bash the shell interpreter, the VNSH, so that bash can go away if it is not used or just keep it for interactive. And, well, of course, since it is becoming the default shell, we need to make it essential and required. Why? Because there's no, I mean, the default shell cannot be just optional or extra or whatever. Because otherwise, it wouldn't make sense and it wouldn't be the default shell. So, what does it represent? The change? Well, the change requires people to stop thinking that VNSH is always bash, which is an assumption that has occurred on Linux systems for a while. And, well, you can actually have a choice now. I mean, they're not just a stock on bash. Because, well, people used to make this assumption that VNSH is always bash and write VNSH scripts with bash systems. But now, since you are working on it, well, most of those bash systems are gone. And you can actually have a choice and use whatever policy complaint shell you want. So, there are some people who don't want bash. So, for those, here are some options. One of the options is to DPHG reconfigure bash, which basically will display the depth conf prompt, if not already displayed. And we'd like to choose whether you want bash as VNSH or not. Another way to have a different VNSH is by installing the shell you want and use DPHG and divert on it. There are some people who usually just remove the same link and manually change it. And that's not actually the right way to do it. Because it might break some systems and as a matter of fact, on the top grades, it should warn about that. And, well, if you also change your default VNSH, don't forget to look at the default user shells. Some other people also wanted to, we're wondering why we need to make dash essential. And, well, like I said, the default shell must be essential. Packages don't have, and don't need to depend on it. Otherwise, it will end, I mean, you cannot have some, a default component without it being something essential or being something from the very core. And there are, of course, some hacks around that can be used, like having a package called the shell and depending on bash, having an or dependency on bash or dash. But even if that could actually work, it is very likely that at some point it will break. Either during a default strap or during the upgrades. It is not, well, it is not an atomic operation. So there might be a chance that it will break. So about having two shells. And as a matter of fact, there are more than two shells on Debian, even on default installations, because the RAM file system has a, and the init rd file system, has a, uses Busybox. So for those complaining about get another extra shell, there are already more than two. And, well, with dash it will be the third that will be actually required. And, well, we want dash for being a sage. We don't want to make dash the default interactive shell. That's not our goal. And, for example, by making dash the default being a sage, they can take out and they can, at some point, a user will be able to remove the bash and use something else as the interactive in shell without having bash on the system. Well, I actually expected some people to bring up some complaints. So if you have any complaint, wait a moment. That's what it is about. So, some people weren't concerned about a choice, about having a choice, about being able to decide what shell they wanted on their system. So just to clarify, users can still decide what shell they want on their system. What shell they want to be in a sage to be similar to. And you could actually use a structure shell, now that we are working on fixing bash systems. And this structure shell should also be able to work now. I mean, if I, by making this change, people will actually be able to use other shells. They are having more freedom than before. Because before they could change this shell and it might break because of bash systems and not many people would care. Well, some people were wondering about the dependency from bash to dash. Well, bash depending on dash. And the thing is that new essential packages are not, are only pulled in by another essential package or by another package. I mean, for example, APT wants to automatically install the new essential package just because it is marked as essential. This will be actually a problem, for example, on mixed systems. For example, if you have APT using unstable and stable, for example, if a package used to be essential on a stable and it no longer is on stable, it will be a, it will be a problem if APT automatically installs new essential packages. So, about the users. Well, there's a depth prompt and upgrades. And so that people who don't want to, who don't want dash as they're being a sage and can use, during the upgrade process, they can select no, they don't want that as being a sage and that's it. I mean, it's as simple as that. The depth prompt defaults to yes. So, the non-interactive upgrades still get a dash and also on the installation. Yes, and during the installation, also during the installation process, I mean during the install, if you use the expert mode, you will see the depth prompt about whether you want dash as being a sage or not. Some people were also wondering what to do about massive upgrades. For example, if you maintain over 400 servers and you don't want dash on those 400 servers, how to easily prevent dash from becoming their being a sage. Well, you can always proceed the depth prompt. And, but you should always take and be careful because some of the installations used to have been a sage as the default interactive shell, I mean login shell of some of the users. If people are starting to have some questions like, what if I have grown jobs that use bashes, what if I have custom local scripts that use a business sage on the assumption that it always points to dash. Well, there are some choices which are fixing the bashes, changing the shebang. Also don't expect that being a sage is always bad when writing new scripts. You can always change the default being a sage by using the pkg reconfigure. And there's also a command, a program called switch and switch sage, which basically, well, it only works on Linux, but it allows the user to run, for example, some proprietary software that has bashes and that you cannot modify. It allows you to run it with a business sage as a bash, even though on the real system the business sage is dash or whatever system you want. And no one to make the change. Many people were complaining because some proprietary software broke and well, this is a way to work around that problem, even if you want business sage to be something other than bash. And of course, if the login shell defaults to business sage, you can also use user mode to change it. Well, some extra points. Dash is very small. I mean, the size shouldn't be a concern at all. And even though it is one more essential package, we are actually making and forcing people to be more policy compliant, because, well, dash doesn't implement all the features that bash does. So it is a bit stricter to what policy company requires. It also provides more freedom because, well, now people should not rely at all. They have no excuse to use bashes and some business sage scripts. So you can actually choose whatever shell you want. Well, you should be able to choose whatever shell you want and use it. I mean, you should not be, you should not longer have concerns about bashes and some other stuff. About squeezy. Well, dash isn't new. It's been on Debian for a long while. Before it was called dash, well, at some point it was renamed from hash to dash. And actually the code is pretty old. It comes from NetBSD. Well, many people have been using dash as business sage. We have all of our Ubuntu users and even Debian users. So many, well, many Debian users have been using dash as their business sage without much problem. And if we already have a great number of people using dash as business sage, we have slightly more people using some other shell like, well, key ssh and others. Well, we have already fixed a lot of bugs. So that should not be a concern regarding the change for squeezy. And well, even if we make the change now, we are still going to continue working on it, ensuring that the system won't break and it will be a smooth change as possible. Well, regarding the dependency from dash to dash and the priority, like I said, it is necessary. And essential packages must be able to work even if not configured. So that's also part of the priority and essential part. And also because extracted doesn't mean unpacked on Debian structure. So we have a lot of problems because, well, there's a long story behind that. So if people have any brief question, I mean, go ahead. My question is about which is the shell used in the build daemon machines? Well, the shell will also be changed to dash. But it hasn't been changed yet. No, not yet. No, the build machines will follow whenever they are upgraded. I mean, on the build machines themselves, that should happen until they are upgraded to the next stable release. But the cheer will follow the change as long as the new batch package is upgraded. That's important. That's the key factor, I think, to choose the packages for LinkedIn and everything. It's the key factor to select the shell, I think. Well, LinkedIn doesn't have much to do with it. But, well, yes, I've also been working on bashesims, trying to find bashesims on Debian rules files. And Lucas Nussbaum also helped by rebuilding the archive with dash as been a sage. I'm Aurelien. I just a short comment about the auto builders. It's also dash is also one of the reasons why we switch from GLIPC to EGLIPC. Because with dash or another shell as a default shell and also as a user shell, it doesn't build, the test doesn't run. And according to upstream, bashes is the only same shell usable on the system. Sorry? Yes, bashes is still essential. And it won't be dropped from essential in a while. I mean, that's, some people actually want to drop bashes from essential, but the work hasn't started yet. So that shouldn't be a concern either. But it's not going any worse any time soon. Do you receive a bug report? Are they positive in general? Do you have any statistics? Sorry, could you please repeat the question? The reaction of the maintainer who received a bug about a bashes is normally positive? Well, does he usually welcome the bug report? Or he maybe thinks, I don't want that to be essential or something like? Well, regarding fixing bashes, maintainers have been very positive in that sense. And there have been a couple of people who are not very keen on that. So they, all they did was keep the, change the shebang to bash instead of actually fixing the bashes. That's okay also. I mean, that's not a problem. I mean, they having a bashesm on a BNSH script is incorrect. And if you want to use bash, then change the shebang or otherwise fix the bashesm. The first line of the shell script are aware that later they will have to add dependency on bash. Sorry. Are they really aware? But bash is still essential. So currently they don't have... Yes, but it's essential now in the future. It might not be. Yeah, but that's not a problem at the moment. That's not a problem at the moment. No. No, whoever starts working on getting bash out of essential will take care of that. But at the moment this is not actually related to the change. If they change the shebang line to bin bash, it's easy to detect later. It's more hard to detect when they have been SH and actually want to be at bash because they use some features of it. There's no problem to detect scripts that use bin bash in the shebang line. Yes, it is always easier to go from bin bash to BNSH. I mean, it is easier to detect that a script requires bash if the script uses bash on the shebang. So, any other question? Yes. I'm Rafael Martinez from Spain. Is it okay? So, I'm a bash user. I don't know anything about bash. But what I'm missing in a shell environment is some primitives of build commands to synchronize and to communicate process because from the very early times, for example, the C cell from 1970, the only ways to communicate process in a restricted way between father and child is the pipe. And the only way to synchronize process is the weight command. What I'm searching because I'm programming at the application level, it's just a common as synchronization primitive like semaphore or a condition variable as the processing interface for process communication. You know, you can read the process, the P3 interface and you have more primitives to synchronize and you are missing in the cell. Is it possible to design a new shell with not so restricted capability to synchronize process? I think it's unrelated to the switch of the default shell. The user shell can still be whatever. So, if you have a shell that supports these things, you can still use that. There is no problem. Stand up. Okay, right. I'd just like to say this is marvelous. Well done. Thank you very much. We've been waiting for this for years and it's brilliant. We can just get Pasha out of essential for next time round. That would be even better. Well, I'm actually not a... Well, a lot of people have been working on this for years. So, I'm just the one who is trying to push this change. So, many more people should be thanked. And is there any other question? Somebody, no questions via IRC or something? So, when are we making the change? Now. Well, the package is now uploaded. So, successfully uploaded. So, well, I would like to thank, like I said, to those who originally started working on it. Because, well, a lot of work has been happening on this topic for years. I mean, for ages, I could say, and maybe. Well, those who have been working recently on it and those who use Dash because those are also the reason why we are changing. And, well, also special thanks to the Dash and Dash maintainers because they were okay with the changes, with making the change. And even though we are an immune Dash, the maintainer agreed to make the change before. He's currently on back, but he agreed to make the change. Well, you will see a complaint. We have emails to prove it. Yes, as a matter of fact. I'm not sure. Well, I would also like to thank Debian as a project, as a community because change mostly depends on Debian. I mean, it wouldn't make sense if there were no community and no people behind it, behind Debian. So, thank you all. Some claps. And did you notice the Bashisans, by the way? Somebody? There are two Bashisans. Yes, and the second one? No, the second one, no. Well, check Bashisans these. So, here they are. The first one, the double brackets. And the second one is... Missing dollar. Yes, well, not just the missing dollar, because if you just add the missing dollar, nothing in the variable won't be changed. I mean, you have to change it. See, equals, sign out the dollar sign and the rest. So, well, that's it. Thank you. And let's get ready for the next change. And thank you.