 Dette sesjon skal være en generelt update på staten av Dora Verkstationen, og også hva vi har gjort så farlig. Det er vort å nøte til, at jeg tenkte at min sesjon var skadet for et halvt år, men jeg vet ikke om det er 50 minutter. Så jeg vil tøye til å spille på de slikene litt, så jeg kan gå til dem. Min namen er Christian Schallert. Jeg er manager for Desktop at Red Hat. Så dette talet vil faktisk cover everything we did since we sort of launched the Dora Verkstation effort five years ago, and sort of what our next steps are. I the first start we'll talk a little bit about our goals, and then of course how we've progressed so far in terms of achieving those goals, and then what the next steps are. So, what is our goal, is actually correct here. For the Dora Verkstation, we had an explicit goal of targeting developers, and that is still true. Our plan forward is still targeting developers, but I think we have sort of widened the definition of it. So we include things like Gisadmin, graphic artist, and I would say sort of makers in general. Anyone who uses their computer for creating content is sort of part of our target audience. While I guess sort of, let's say a productivity worker, or someone who's just using it for email and so on, is of course more than welcome, but they're not like someone we prioritize in terms of choosing over development priorities going forward. So, progress so far. So these slides I actually was planning to rush through when I have half an hour, but I will talk a little bit more on each item since we have more time. I think we have quite a few major achievements that we achieved the last five years. I guess most of you know the Linux Vendor firmware service, was the thing we kicked off to make sure that people actually could install and get firmware on their laptops, or on any basically Linux system. I mean, before we had the Vendor firmware service, for the most part you could not actually update your firmware at all on most laptops, or at best you could download some kind of thing that would start on special DOS session to install your firmware for you. And I think today we are, we're not on par with Windows, but I think we're getting quite close. I mean, we have all the major vendors, Dell, HP, Lenovo signed up, and they're also getting more and more of their hardware partners to add up. So for instance, I think just yesterday I saw a post from Richard Hughes talking about how Lenovo had started on updating Thunderbolt firmware updates, for instance for the Thunderbolt controller, I think, for example. All in all, I think this has been one of our big achievements that we know have succeeded in getting so much firmware created, and more and more people are coming aboard continuously. And also some of the smaller things are starting to appear, like I was talking to Richard Hughes actually, and he was mentioning that Intel, for instance, is starting to upload firmware updates for their prototype hardware. So when you get sort of sample hardware from Intel for new architectures, you will actually be able to get firmware updates for them through the firmware service. Another thing that we worked on as part of this, and actually to go back a little bit. So, you know, as I said, we started focusing on developers, and we sort of did actually quite a few surveys and went out and asked people, like, what are your main concerns with Linux as a development platform, or as a, and you know, the thing that came back to us very, very often was like hardware support. The things didn't work correctly, or that, you know, the botany laptop, and most things worked, but there was one or two things that was broken. So a lot of initial effort over these last few years has been on improving hardware support. But I think as we go through these things, remember that, you know, the things we focused on was actually targeting developers, even though of course a lot of them are quite generic in their thing. And of course, Thunderbolt support was only since it came, and there is a lot of hardware support. There was basically no Thunderbolt support at all in Linux when it started out. And we've been working on this project called Bolt to make sure that we handle this kind of, you know, security levels and so on for Thunderbolt. And this is a project we still keep pushing forward to make sure we add functionality for supporting more and more things. Another thing we have been working on, and this is maybe not so visible from the community, but it's having better relationships with the hardware vendors, especially like the laptop vendors themselves. Because to some degree it doesn't scale, or that might really work if we own the problem of making sure hardware works. Because what happens then is that let's say Lenovo ships a new laptop, which has a new piece of hardware in it that nobody else has been using before. And at that point you will have a situation where, you know, Linux will have a period of time where it's simplest to support it. And of course we will then struggle with having to maybe try and reverse engineer that hardware to make it work. So we've been pushing very hard on our hardware partners to say that, you know, you need to hire people and you need to own the problem. So that they plan, so A, that they push their suppliers and that they plan to make sure, you know, that there's upstream support for their hardware in time for a new hardware to ship. And also that they let us know so that we are able to make sure that, you know, we bring it into Fedora or Elford at a good time. And I think we've been quite successful there. I mean, of course I've had their own effort for some time as part of the Reproduct Sputnik and, you know, the Express 13 and so on. So they are probably the furthest along with making sure that they plan Linux hardware support. I know that for instance Lenovo know is also ramping up quite heavily their efforts to make sure that they can properly plan hardware support for the laptop to Linux. Wayland is another big effort that, you know, we successfully brought in. You know, when we started contributing to Wayland it was mostly an Intel project at that point. I think it was a general agreement that, you know, Wayland was the way forward. And it had advantages over X in terms of improved security and so on. But it was still far from ready for disapuse. And at the same time, at that point, Ubuntu was trying to basically fork into doing MIR and doing their own proprietary setup. But I think we succeeded in A, of course making Wayland a reality. And then of course MIR ended up falling by the wayside. So I think we have succeeded there in making sure Wayland had a future standard for Linux desktop graphics. Flatpacks is another effort that has gone far and I will talk a bit about also what we are doing going forward. Because, you know, it solves quite a few problems. First of all, you know, I think we had a talk today from Facebook for instance and also from Matthew talking about like, you know, too fast or too slow. Turning things into flatpacks will help us, you know, eliminate clear between operating system and applications so that we don't and so easily have the situations that you constantly have no that you operate update your OS and then application break because it depends on an older library or something. So by, you know, making everything into this containerized this applications, we will be able to have applications and always move at different paces. We don't constantly, you know, trigger break hazards or having applications fight over which version a certain library should be at. Very clearly developer targeting we did was that of course spending time over last few years adding improvements to the GNOME terminal and trying to make sure that it works really well. And things like, you know, you get these notifications now when the job is finished. So if you have like a big compiler running in a terminal you don't know it manually go back and check it instead you will get notified saying, hey, you know, your job has completed. GNOME software is another piece where we invested a lot of time and effort. I mean, it does, of course, the firmware updates that I mentioned earlier. It does nice and easy graphical updates of the whole operating system. I think it also has made huge strides in just making applications discoverable and easy to install. And of course it also supports multiple packaging technologies like RPMs and Debs and flat packs. Another thing, and this goes back to this hardware supporting we spent quite a bit of time some years ago making sure. We got a great HCI high DPI support and you know Fedora Workstation got a lot of good press actually over that. I mean we were the first distribution to have good high DPI support over the box. And of course at this point there are still a few applications that are still lagging a little behind in terms of adopting high DPI. But all in all I think we are in a good place and I think it was a good example where we were managed to get on it quite early so it didn't end up being this thing that you know you got your high DPI hardware but it took you a year or two before you could actually start using the functionality under Linux. LibInput is maybe not something you actually see today but as part of our valent transition we also decided to split out the input support in X into this thing called LibInput and also rewrite it a bit to make it better and more scalable. So we have seen a lot of improvements through the input stack now due to that and it also helped us you know consolidate a few things that used to be separate things like you know you had a separate input library for various things and there are all no centralized into LibInput. Another big achievement I felt that we achieved was of course solving the problem that had been for years where you had the conflict between Mesa and the open GL stack there and then Vida driver which meant that you know depending on which package got updated the latest had things over writing each other and conflicting. On a more of course a polished front the recent thing for Dora 30 got this thing called flicker free boot where you know don't see your screen sort of flickering and then you know resetting itself as it goes through the different stages during boot instead you sort of have a clear steady path. On one level this seems like a small thing but once again based on the service we found like people one of the things that often gave people impression of Dora and Linux in general was it that it felt unpolished so this is also why we sort of greenlit Hans de Gøde to work on doing this. We put a lot of effort into integrating Qt into Dora Workstation because you know Dora Workstation is based on GNOME but there's a lot of applications out there using Qt so we spent time making sure we had teaming and that supported Qt to make it look like the rest of desktop but we also created a thing called Qt GNOME platform it makes sure that when you change things like when you switch to the dark team or if you enable accessibility or change your desktop font that it applies not just for GNOME GTK but also to your Qt applications. Another thing that we used to get dinged for a lot was the lack of codecs and of course there was a lot of legal challenges around that but we spent quite a lot of time over the last years making sure that we cleared a lot of these codecs still in use for including, to be able to include them on disk. So I think we have in terms of other codecs we have all the major ones now supported and we also got impact to video recently cleared so we can support for instance if you have old files from DVDs and so on that you still have around. For H264 we made an agreement with Cisco some years ago to ship this thing that I have called Open H264. The problem with that was that it only supported the low complexity format of H264 which is useful for videoconferencing but it's not what you want to use when you have like a playback of a H264 video file in a Matroska file for instance. So what we did there was that we actually pulled money from Red Hat, Cisco, Endless to pay Centricular which is consulting company to basically make sure we got support for these more higher profiles into H264 and that actually became available only I think some months ago but that means we also finally have a full featured Open H264 decoder available for for the users out of the box. There's still some things that you might want to try to do there going forward. I mean it's all software decoder at the moment and of course it would be nice for instance get take advantage of GPUs but that's what we have but at least we can play back things now. Yes, we also spent time improving battery life. I mean it was also the recurring thing we got a lot of feedback from is that people for instance who had been using Linux for a while and ended up for instance switching to Max. The common reason we often got quoted was that like well I just wanted a laptop that had long battery life. So we spent quite a bit of time improving that having general conversations with the vendors to make sure that they start taking ownership of ensuring that their laptops have good battery life and I thank you for your reference and look at things like the XPS 13. The battery life is absolutely competitive with comparable windows or Apple systems. When you use Linux on it. We had a Google Drive support that was also something we got feedback from a lot of users for that they needed. I least said that here is done because many times it has been available for some years already in Fedora but we are actually going to take another look at that now and see if we can improve performance actually a little bit because especially for large files it's a little slow the way it currently works. And then also we put in some work to make sure that Fedora works better as a guest in a virtual box because we know that there are quite a few developers out there who are on windows or Apple systems who rely on virtual box for getting access to a Linux system. So next steps. So another effort actually kicked off recently is that we have started so Red Hat has a quite close relationship with the University of Boston at Boston University and also quite a few universities in Bernal in Czechia. So we have started trying to use that relationship to basically try to tailor our solution a bit towards computer science students. So we are now doing user interviews and surveys and so on on some of these students with the goal of basically starting to have a feedback loop so that when we do improvements and changes in Fedora we will sort of instantly get feedback from them and I guess they also at least the two universities we are currently working with are quite different in the sense that at Boston University a lot of the students there are Mac users so we sort of get feedback from people coming from Mac to try Fedora while in Bernal I think it's more of a mix of either people already on Linux or Windows so we sort of get a different kind of feedback from them and we can use them to contrast and see of course what they haven't come in and where there are different things people are looking for. So in terms of major things going forward I think over the flagship effort at the moment is this thing called Fedora Toolbox and unfortunately the talk about that happens now at the same time as my talk and this is already available today in Fedora as I call it prototype here but it's basically like a first implementation and the goal of Toolbox is to just make using pet containers as easy as possible Toolbox is basically built on top of a lot of these other tools that we have available like Podman and so on but it tries to help you make it that easy to the setup a new pet container and log into it and know that you are in it because like let's say you have 20 terminals open we are just trying to make sure that you for instance know for sure okay I'm in this container now or I know I'm on the host and I just make you know give you visual cues for instance telling you where you are and also just make it easier to find the image you want is the goal of this project or plans for instance that currently it's where you have ease access to a Fedora image we also want to make an image available or it's called UBI the universal base image that is a rail based container so that if you want to do development for deployment on rail then you can pull in this and then develop towards it and we are also working with the team inside Red Hat working on AI ML to make a special container available easily that will provide all the tools to do AI ML development like TensorFlow and so on so at the moment as I said it's available and you can do some testing with it it's currently basically a big shell script but we plan on writing it in Go and once that's done then we'll start extending the functionality of it but of course we hope people will start using it already and start providing us feedback because as I said our goal is to make this the best way to work and part of our motivation for doing it was of course that if you run on an immutable system like Silver Blue or CoreOS then you don't have the ability to just install random packages or at least not easily install random packages on the whole system but instead you should work inside your pet container but but in some sense we want to go further than that too because our goal is to make using pet containers so comfortable that you actually want to do that even on a normal Fedora system because the advantage of a pet container is that you can set up your environment exactly like you want it without risking breaking your whole system so like let's say you for whatever reason need for instance a newer or older version of Relip C you can install it in your pet container and it doesn't affect anything but the pet container but if you try to do that on your whole system you may be asking for trouble another effort that's also been done for a while but we are going to start pushing harder is Fleet Commander Oliver is actually here he just finished a new version that has support for using Active Directory because up to this point we require you to have free API available to set up Fleet Commander however we got a lot of feedback from both people in the Fedora community and reddit customers that you know due to Windows being the predominant desktop in the company overall and they did have Active Directory setup so we added support for Active Directory now directly so we do expect a lot of people who have been waiting for this to deploy it and what Fleet Commander does is that it allows you to configure your desktop session on a per user basis centrally and you can create groups because based on your directory server so if you have like different teams inside Active Directory you can assign different profiles to each of them and I think when you saw the Facebook talk today they talked about for instance how they used these Chef scripts to change the screensaver settings and yes it is possible to use Chef for that but it's also if you look at the screen it's not obvious I think for someone who doesn't spend a lot of time with living systems how to do it while using Fleet Commander it sort of will be a purely graphical environment where you can click click through the desktop UI and set the settings you want and then just save that as a profile and then deploy it to the user so you want to have that profile Fleet Commander is also not a replacement for things like for instance like satellite or Ansible but I think it always stays like a compliment to specifically deal with the complexities of configuring a desktop session while you still need to rely on these other tools for if you want to have controlled rollout of packages and these kind of things which is not part of the area of expertise or goal even for Fleet Commander to try to do or that may have the ability to do On our to-do list there is to improve support for Firefox because we know that of course most people use Firefox or a lot of our red desk customers use Firefox because it's a one browser that we can ship out to the box with always the goal there is for Fleet Commander to be able to set things like default bookmarks and so on automatically centrally so that if you want to add a new bookmark to your new travel expense application and you can just deploy that through Fleet Commander and it will show up wherever it wants to bookmark automatically another thing you can use Fleet Commander for is that if you need to deploy a new VPN setting that's another thing we support there where you can say that we are removing the VPN server address so I don't want to deploy this to every user that they automatically get the new settings for VPN so I think this will Fleet Commander will be a very powerful tool for Fedora too because it actually gives us a good story for people who want to do this for the big scale deployments of Fedora and need to have certain things managed and of course when you end up trying it and deploying it, please give us feedback for features you want to add it because that's definitely also a big part of our next step there to figure out what are the gaps people feel they have compared to for instance similar tools for Windows and Mac. Flatback Ecosystem. So I talk about course Flatbacks has been I think a major project that we succeeded in doing and what we're looking at there now is to start trying to build out the ecosystem. We have a runtime in the works based on the universal base image and what it will give us is that we will finally have a runtime available for ISV to target that sort of LTS runtime. The goal eventually will be that the life the supported lifetime of the UBI runtime will be the same as the release you can expect it to be around for around 10 years and still get secured updates during that period. So for a lot of vendors who are interested in having a Linux version you know, interested in necessarily chasing fast moving distributions like Fedora currently is they can instead target this UBI runtime and they will have a platform that is going to be stable for years to come and then they can also just switch to the next UBI version once they're ready. We're also I guess from the red side working on figuring out how to do hosting of Flatback containers we're currently looking at both the Red Hat Container Catalog and also this Quay.io for possible places to host this so the goal also once again is for a lot of these ISVs you want to basically be able to provide them a place to upload their Flatback and it becomes available to users across well first of all of course Rail and Fedora but also any other distribution that wants to support Flatbacks We have also spent a lot of time making sure you can build Flatbacks in Fedora from over RPM the RPM content there Over the latest content is that we managed to get over 60 Flatbacks built from Fedora RPMs and we actually have an interaction at the moment focusing on that effort so we expect that by the end of the summer we will have significantly grown that number so that means if you are experienced Fedora Packager you can hopefully quite easily get into making sure that your application is built to the Flatback and becomes available to people across Fedora, Rail and of course any other Flatback using distribution available Fedora Silveblu Mattje mentioned that in his talk this morning This is an effort that of course is trying to use some of these same principles that are behind CoreOS and apply them for desktop use having an immutable OS image and of course the big advantage of that for here is that you basically get hassle for upgrades because I think for anyone used Fedora or any current distribution problem especially if you bring in third party packages into your system when you do an upgrade things easily go wrong but on top of that I think you also have seen in the past that you sometimes get problems because a lot of these packages have script that tries to manually edit text files and so on and sometimes especially if you have modified the text file locally things go wrong during the upgrade and then you suddenly have a system in a uncertain state which is also of course painful for anyone to support you on because they don't necessarily understand or know exactly what went wrong and what the current state of your system is but by replying on these immutable OS images that means that when we go from version to version we just do one upgrade politically centrally and we verify that at work and then we push that out to everyone just to work for everyone to go from version to other and even in a case where something went wrong let's say for instance there has been a regression in the kernel that means that driver doesn't work properly and more for your specific system thanks to using OS 3 in here we can actually do OS rollbacks too so that you figure out that hey actually you know this update breaks my system and then you roll back while a bug and once your bug is resolved then you can of course update to the latest version which should hopefully and once again work for you and we're currently focusing on closing functionality gaps with sort of a normal for door install because once again we want this to be a positive experience, right? We don't want to have people feel that you know they in order to get the advantages of having immutable OS images and so on they on the flip side get trapped so that's why for instance we have the toolbox for making sure you have a good development experience but we're also spending a lot of time making sure we deal with things like how do we get the driver installed in these kind of setups how do we deal with third party printer drivers and these kind of things so at the moment of course Silver Blue is a separate download and we'll probably remain some for some more time but you know eventually we hope to sort of say that the workstation is Silver Blue but that's further on the road and we sort of feel that yes we are confident now that Silver Blue is ready for mainstream use another feature that we will try to be focusing on for a bit now is high dynamic range for those who know it it's basically standard for having better color representation on screens it's becoming quite popular on high end TVs which we also see that a lot of laptops and computer systems are starting to have HDR capable monitors NVIDIA and Intel and so on are looking at this from their end the overall goal here is to provide a technical leadership to ensure that we get a unified solution that works across every vendor system but it also means that you know even once we have the hardware support in place we do expect that there will be plumbing needed up to stack all the way into the desktop shell to make sure that we correctly support HDR systems Pipewire is another effort that we are pushing forward the overall vision for that project is to make Linux the first class operating system for component creators as a side or in some sense the initial target for us there and where it's already deployed is of course handling video capture and screen sharing in Fedora the reason for that for that being a priority for us to resolve was that first of all with Wayland it does provide better security I guess a lot of you probably have been to talk in the past where you talk about how easy it is to basically do keyboard capture under X but with Wayland it has in some sense improved that but it also made things like dealing with video sharing and screen sharing a lot harder to do so we basically made sure we could bring in Pipewire to provide an API and a way to do that and we've been working over the last year making sure that the browsers have support for Pipewire to basically for instance when you run things like BlueJeans or Google video Google Hangouts to the video calls that you can then under also on Wayland get that working and you know you have video capture and screen sharing and at the same time of course on the application side where we are trying to move to flat packs we needed a system to enable people to get you know secure access to the video device from inside the sandbox flat pack so Pipewire also you know answers that question for us and provides a way to securely do that and also have multiple applications sharing on video device there without getting necessarily access to each other's content so that's already deployed but our next step that we're trying to focus on is bringing in a jack compatibility layer to flat packs which I think in terms of like you know the pro audio community has for a very long time been almost like a separate sub community within the Linux community but our goal is to basically make them first class citizens and make sure that you know you don't need to install and configure jack and figure out how it interacts or interoperates with pulse audio instead Pipewire provides a jack API that's API compatible with jack and so at least in theory every jack application should just work I think in practice when I was testing this I did discover that quite a few jack applications due to the way the jack has been working so far there's a lot of weird things like you know they try to search for a jack binary in a specific binary binary location and then auto start it and then connect it and so on and of course if you do that sort of things that doesn't work but if they just implement and try to talk to a jack server running on system then Pipewire should work perfectly as a drop in replacement our final step which probably is some time out still is to also be a replacement for pulse audio at the moment the way it's going to be working is that pulse audio will probably be talking to Pipewire so the current pulse audio application will be all this operative to Pipewire and we're going to handle it that way but eventually we won't be able to shut down the separate pulse audio daemon and just have one Pipewire daemon handling video, handling pulse audio use cases and handling the jack use cases yeah, one thing this also wants a bit of smaller future but we've also been looking at making sure we have a mirrorcast support so that's available for testing today in Fedora but it's a separate little test application we hope to sort of merge it into the desktop proper but I did notice that the TV set the hotel room here actually do have mirrorcast support so if you want to test it tonight you can just download the mirrorcast test application and try it in your room tonight ok, so I think that was what I meant to cover, as I said when I wrote the slides I expected to spend half an hour and I only realized half an hour ago that they had 50 minutes so I hope there's some questions here so of course we and my team don't necessarily have resources to support every possible option out there so I think what I'm expecting to be the outcome here is that once we iron out quality kinks and the challenges of doing an image based operating system with silver blue and gnome of course as part of that process we will resolve a lot of quality nor operating system level issues so that eventually for instance the KDESIG to be able to take over and eventually may produce you know a version of silver blue but basically the same kind of system with KDG on top I think due to the nature of systems you won't be able to install another desktop on silver blue so you will have to then install a different image and use that instead that said of course being image based systems I do expect that you might get to a point that if there are multiple images available switch between them might be really easy because they will probably be parallel installable and you can say that you can actually boot into any image now or exit the image now instead and they still share the same object and so on afterwards I don't think it will be from the login manager I think it will more be from the u5 boot manual but of course our focus at the moment is simply getting the silver blue image to a level where we expect people who are using workstation play to want to use it so call it extended future use cases like alternative desktops or other more major if I think this is not something we currently have any complete transport because we are full engaged just trying to make the service of the boot mainstream and usable with the full choices we already made No, we don't I think I have been discussing with Matthew Millie a few times whether it would be nice to actually get that so we could sort of see for instance how the transition is going The challenge we have there as Matthew mentioned in his talk is that by default we are trying to respect people's privacy as much as possible but that of course comes at a price of not really knowing what they are doing either which is good from a privacy perspective it's harder for us to then make good decisions based on having such data available so we will hopefully in the future come up with good ways to add more metering to the system so we can sort of figure out at this point 99% are using valent maybe that's a good time to start deprecating the X version or for that matter if you know that hey you still see that 70% are on X so we can obviously not deprecate it no kind of trade offs but at the moment we don't really have that data as far as I know from some weeks in philosophy the current plan is for the next fedora release to have it all to the box yes that should actually doable so if you want to have an aquarium or something behind you as a talk that should be absolutely possible to do as a filter in pipe wire similar i guess what phase time I think have that functionality right but yeah it's a pipe wire have the architecture to allow you to you know even if the application doesn't necessarily support it to actually say hey bring in this filter for me and give me a neutral background or an aquarium or whatever it should be that you would like to have there any other questions yes that is the plan I mean we have a talk actually about tomorrow alright yes we have a well it is I would say like this it is a definite our goal and we want to see it happen as soon as possible but as I mentioned on the slides here I mean we don't want to commit to a certain time for doing that before we are 100% certain that we have crossed off all the boxes that needs to be there because we don't want to sort of go after until the world you know switch now you know this is a new default and then you know 60% of people come running back to us saying that hey you know Skype doesn't work or you know whatever is the particular thing that sort of then makes the system not useful for them so we are trying to to sort of organically grow syllabi at the moment by having an alternative download and then once we this is also back to the question about metrics I think we are hoping to eventually be able to also get to metrics so once we see that a lot of people are on syllabi already and that we have been able to address at least the issues we are aware of then of course that would be the time we say that okay so let's for Dora33 as an example let's make syllabi over sort of default and then of course still keep the RPM version there but switch to default but at the moment I think we're still we're still not certain we're there or I guess we're certain that we're not there today to make that switch so we want to be certain we do that because I think you know in the past I think a good example there was the original rollout of pulse audio I guess in many ways it wasn't really ready for prime time when it was rolled out and it basically lost years of bad feelings towards it afterwards and we want to avoid that and I think when we did the transition to Wayland I mean on one level we wanted to do that a lot sooner than we actually did in Fedora but at the same time we were very clear right that we don't want to start saying in Fedora now is Wayland and then have nobody be able to use it in a functional way and I think at least based on what I feel reception was when we eventually did switch to default and the general comments that I see on various news sites and so on when people discuss it is that we succeeded in making the switch at the right time not that everything was perfect but at least it wasn't like everything was broken either you know, can often be a problem so that's the approach we take with Civil Blue 2 is that we're going to switch Fedora over or Fedora Workstation over to it once it's ready but not before now I think I have a feeling that in terms of like you probably would at least want to do re-install at some point just to get rid of the old system lying there because at some point you probably don't want to use it but I think also due to the way it works one thing we have been discussing but there's no concrete plans of doing is trying to maybe have some sort of application or tool for extracting some of your configuration and then being able to restore that configuration once you re-installed that's your Civil Blue system that would probably be a very limited thing if you end up doing it at some point like maybe preserve if you have some custom macro images or things like that and some configuration data but there's not going to be I don't think we will get to a point where we can sort of guarantee that everything on your old Fedora system some will make over it because especially the home directory could probably be left untouched so any configuration has stored there we might be able to reuse but if your instance then changes to slash ETC there's no way we can preserve those especially if it's sort of in stuff outside of desktop so I think the only question is we don't currently have any concrete plans for providing any tooling there apart from reinstalling and then re-configuring for bigger installations like for your not personal system and of course Fleet Commander could actually provide that where as long as you know all this configuration is under Fleet Commander it will then re-apply it once you switch to Civil Blue any other questions thanks a lot everyone I hope it was useful there's a Civil Blue talk tomorrow and I recommend going to that there was also a toolbox talk happening at the same time as this one so I recommend people to check out the video because as I said that sort of over flagship effort going forward thank you