 So this both is about handling of the home directory and configuration files in the home directory. And it's basically the fastest priority standard concept for the home directory. There were some other talking during this discussion about making it also about APIs for configuration files. So there will be a library that can handle multiple types of configuration files and convert between them with administrative deferral. But it doesn't quite fit the specification we are working for. And so that we should have to be a separate project there. So I'll start with problems and I'll show you what the current specification is at freedays.org. And the idea is that I have gathered from people for the next version of the specification and how to implement them when we can discuss that or think about something really different. So the initial problems were first of all the fastest and priority standard does not regulate at all how applications handle the data inside the home directory. Isn't that? Then the other problem that is more closer to me as a developer of a backup program is that backup applications cannot differentiate between different types of data that are stored in the user directory. There is user content, there is configuration data, there is temporary data that should not really be backend. I have a question here. What's from the point of view of a backup application, the difference between user content and user configuration? I'll try to differentiate that a bit later on. For example, if a photo and a tag for a photo are a user content then... because it's hard for me to see, why do you have to differentiate? Do you have to backup and restore it anyway? For example, the list of game, the configuration for the game, for the chat, different configuration. There was a different example. For example, for an email program there is the configuration of how you read your email, how you receive your email and the email itself. The point of restoring it separately is that you could have an email program that stopped working with the latest configuration information, but you still need the emails that you have received before. So you would restore the emails but not the configuration of the program. And you can have different backup policies for each other. The emails change very much and the configuration tends to be stable. That's a very hard point, a hard task that I see your intent. Another application of this, if we separate the configuration from everything else, is a uniform way to reset the configuration of the application, so that we know that here in this folder is everything that is configuration for this application, and if we erase that folder, we only erase the configuration, reset it to default, and our user data should be lost that way. And the discovery of a lot of files, the user directory and all of them are hidden, a lot of users even don't know that they are there. It's a hidden complexity for a user today. When I proposed this idea on my blog, people came to me and said, well, there is a free desktop work specification about that. The XDG base directory specification is currently at version 0.6 and hasn't changed since 2004. It specifies splitting the data, splitting the user home directory data into data, configuration and cache information. It has very detailed and complex information about how there could be multiple directories for user data, multiple directories for user configuration, and what priorities they all have. And also it had environment variables that allowed administrators to have the configuration information or user data outside the idea pool. And there was nothing about some directories, so there's also only a global definition of, well, the configuration information of all applications here in this directory, and nothing about how applications should share between themselves in there. And there are a couple of limitations of this specification software as well. When I talk to people that are developing this, they'll seem to be eager that this specification moved forward somehow to create maybe better versions of it that are more implementable and engage in wider implementation of them, because currently developers look at it as a very complex thing to implement. There's only a few programs that have done that. So what I think about moving on from that specification is, I wanted to see David's leading role in the community in this sense by creating and implementing the new version of this specification and moving it on into the wider community. By doing three steps, defining what we want here in this specification, second step, implement that via a hack by basically redirecting access from old config files or old data locations to new ones via the LD3 library or something similar, and then push these changes into individual packages further upstream. So what I thought about so far in this version one, there need to be three data classes. The configuration data, user data and temporary data. Use patterns, rules of operation of every class need to be defined. Folders for each class need to be defined. There should be at least a recommendation about how applications should use the subdirectories, how related applications should share these subdirectories, and also we need to clearly define migration path from either the regular situation or from the 0.6 version of the specification. There were two proposals about the main look of the folders. There could be type slash application folders or application slash type folders. The difference being that in the first option there would be one folder which contains configuration for all applications. And the same one folder containing all cache for all applications or user data for all applications. And the second option would be that configuration, cache and user data are in one folder for each individual application. And then they are put into some bigger folder there. When the first option is similar to what we have here now in the specification, 0.6 version of the spec. And the second option is more similar to how the Markov 6 is treated where every application basically is a folder with strictly defined contents. There is a set location for the binaries, a set location for the configuration, a set location for user data, for application data and similar. I myself, after a long discussion, preferred the second option actually because it allows, I haven't seen any drawbacks of the second option so far. But I will be showing some interesting side benefits of choosing this way of storing configuration and get to that just a bit later. So what I see is a configuration data, just setting some parameters on the software. The main thing is that the software should continue to work but just reset to default settings if the configuration data is removed. So nothing that the user creates should be erased or lost if you just raise the configuration data. There are border lines here in the questions. For example, is the pop3 access information to remote email? Is that a configuration thing? Because if you remove it and you cannot access the user data at a remote location until you configure it again. Action of the application slightly changes here. That should be defined in the specs by example. So programmers can refer to that. User data? Data and files that users have created or made significant contributions to creating and have not explicitly saved to another location. That for example would be the emails or the typing information from photos. Isn't safe to the photos themselves for example. And it should never be necessary to erase the user data to make the software work again. So software should not be breakable by the user data. If software is breakable there is something that is probably configuration or should be rephrased. And I think in this specification there is a place for suggestions to application writers as to how to handle different types of data. For example, that application should be extremely careful when writing user data to avoid losing it in all situations including situations like a full partition. And temporary data is less class that can be regenerated or is of temporary use like web cache or managed thumbnails. There is quite a lot of this information in the home directory. For example, the thumbnail directory can be several hundred megabytes large on a typical user home directory about several months of use. And application should be prepared that this data can be erased at any point. About the structure of folder names so if we go with the second option the structure like this can be formed where all the information of the application the only place where the application can write except a special user request would be home, some kind of folder name like library like it is in Microsoft and folder for the application name. It would store the configuration data home library application and config temporary data, home library application, TMP, cache not quite sure which to use here and they could store the user data in the rest of this folder. It is quite fine with the backup software actually because at least my backup software can have frugal expressions, makes no difference whether it is cache dot application name or application name slash cache. So it should be able to handle such a situation no additional problem. A population would be shared by many applications? It is an issue there that needs to be addressed that there are applications that are sharing information between themselves where that is information that needs to be stored. So it should probably be defined as some kind of master application that would store this configuration information. Or maybe generic names for application name for example email or mails or something like this, name slash config and there is the... Like a virtual application that is holding the problem is there will be complex and it will be hard to manage and many of the things are in the code many applications so it will be very difficult to assess. It could be the next step of consolidating similar configuration information from multiple applications. It is partially what Gconf is supposed to do. Right, I was asking how does this relate to Gconf? Gconf is a very problematic case here. Why? Because it stores the configuration of an application in a completely unrelated place to that application. So you can't really define a way to reset for example all configuration information of evolution maybe. Why not? Because it is in multiple locations even inside the Gconf. Can we manage that? Sorry, all configuration of evolution is under one specific tree and you can preset the configuration of evolution with one command line just reset everything under below this subtree. I'm not sure about the evolution, I haven't looked at it yet. It could be in one subtree. If it spread among several subtree we could consider that as a bug or something or we would need some really good explanation but even then evolution itself is registering a schema and you should be able to say look at all keys which are going to be registered by the scheme of evolution and rest at all keys introduced by the schema evolution has introduced. So in fact it's quite easy to do this with Gconf. The question of how Gconf would fit into here and even how whether configuration information from the Gconf should somehow be stored into the same directories it would need to be separate it's an interesting question to have here and I'm not quite sure of the answer because I would really like everything to be in a folder and not spread across multiple locations even if there is a map of these locations somewhere. Maybe you are thinking in backup and he's thinking in integration I wonder if you are a different person. Well Gconf is some sort of configuration database you don't have to care where the configuration actually is you have a new configuration space this Gconf tree and you think where in the Gconf tree is my configuration store and you don't care where it is on the file system in fact you can even configure it to be an elder. Yes, but the problem is that I do care where it is in the files when I try to backup it or restore it. Well, the canonical answer of the Gconf developer which I'm not would probably be what you would need to write a backup interface to Gconf database. Which would be nice. Yes, it would be pretty well answered because in that case everything is standardized except Gconf which would be a special term. You can't say the other way Gconf introduced a standard and other folks are doing something else. No, I'm not that fond of Gconf anyway I understand why I... Yes, right. I understand that point in some ways. For the beginning you could of course treat the XML file Gconf is... by default Gconf uses an XML backend for configuration data and you could treat that XML file as configuration data for a start. A solution might be to treat Gconf as one single application and integrate this single application into this scheme. Well, that could be a very, very rude hack to get it working with. I'm not quite sure if it's really a hack. The point for example is the same evolution. If we later... One of the targets of having this specification made is to have an application resetting settings simply by erasing a configuration directory. So... to have an account of Gconf files to programs like an evolution, we would have to erase evolutions to the configuration directory and the evolutions of the directory in Gconf directory. Yeah, that just shaped it for the specific case of the evolution of three of database called apps evolution and it's quite easy to say please reset everything below the subtree. I'm not quite sure if every configuration, every information of evolution is there. It could be that some parts of the configuration are shared with other programs for example outside the street. I have no idea, I have not wanted to do this specific case. Okay, let me just comment. First I don't think that it is and if it is, I perhaps consider that as a problem. Well, it could be a feature because like with example several programs share several programs share false information all the proxy server information yes I prefer the iteration of that. Well, is that a configuration of evolution? No, it influences how evolution works. Well, that's a very var definition. I think evolution is a very particular example of a very big program with a lot of things. Well, we have to consider such a big problem of the programs. Oh, yeah, I know. But maybe it's not a happy order that we look for. Maybe evolution will be the application which needs more has to be integrated to the standard. Well, anyway, what's the problem we're discussing actually here? Well, the two uses of the spec the backup in the store of everything except cash basically maybe different times of backup for configuration and for user data and an application to reset configuration Well, I think there isn't actually a problem here because everything which is stored in Gconf is in fact configuration. Yeah, that's good. There is no temporary data in Gconf. That doesn't make too much sense to put temporary data. No, does it make sense to put user data in there? Right. So no matter of that spec we could just perhaps 3Gconf indeed as an application of its own and make store its backend data for configuration as Gconf configuration and be done with it. If you want to reset a specific application well, then you would need some specific interface which knows which schema authentication is introduced in Gconf and the version data of this application which then it will reset in Gconf 3. Well, a slightly more cleaner approach like here is to have the Gconf store this particular tree of configuration just there in this directory. Well, of course you could perhaps write its based your conforming Gconf backend that should be also possible. So in the sense that you don't store it in one flat XML file but spread across your library, saturate it it should be possible as well but I don't see much point in it. It's just the problem of applications using slightly different short names for themselves but there's Thunderbird, Mozilla Thunderbird, some confusion by the application on there but that's unrelated to the main problem. The interesting part about having application type in directories is that there are other folders there that are these folders for plugins maybe you could have Firefox for example store their plugins inside that application name and maybe share a plugin name with the executable files for some plugins that are executed somehow by the software itself in the bin sub directory and configuration files for the plugins integrated into the configuration for the main software as well as having a possibility of adding something to the menu having a desktop file in the application name directory the idea behind all of this is to possibly later allow having a install applications, user installed applications that are simply unpacking this application directory into the correct place in a similar way that it is done on Macintosh the idea is that you receive from the Internet an archive you unpack it to move it or unpack it to your library and you have an installed application inside that archive there is a bin where you have the executable files there is something that adds this application to your menu the program files, config files every part of that application and once you as a user put it in your library there is a part of the menu that regenerates this application and gets added to your menu I think it would not be that hard to add this functionality once these directories are established so that third-party software can be installed by end users in an extremely simple manner then and you are aware that such a directory the last point on that slide already exists is called don't load to share applications are you? don't load to share applications if you put some of the desktop files in there for example the normal KDE desktop we respect that for example overwrite system-wide or register user-specific applications well, yeah great I was aware that there is such a thing but I wasn't aware of this for example I can show you I've installed Adobe Reader for example which is a normal desktop file which tells how you start in Adobe Reader so this already exists and is already used great well, as it is part of the home directory there should be in this specification where these files should be what is the desktop specification of the desktop right but it also needs to be here if this specification is to describe everything that applications need to do it in the home directory obviously the specification should be completely changed that's true with the top local applications it is in a different location than this application directory so the desktop file would need to be copied over to there if this can be either changed or added as an additional way the desktop files can be added so if we take this Adobe software and you simply unpack its archive into your library directory then it gets installed without any need to execute any scripts or copy any files around I think would simply simplify that significantly but oh yeah that's a way to do the desktop file specification the migration path the suggestion is that we do this in two simple steps first we do an ugly hack it uses either LD preload or some other way to hack into the system and intercept every file request and have a map from the file locations to new file locations so that every file request to an old location would actually go to a new correct location in the home directory possibly with moving the old file over while this process is being done and the additional benefit of this actually is that if we make a preloading library of rewriting file locations preferably using that allows the use of regular expressions in this it could be a very useful administrative tool for moving files that don't exist yet in this way and would allow us to do this application and in the second step we just add support for this specification is a policy requirement and in a couple of releases introduce that to the software and forward that upstream Your last slide Yeah Okay Then Thank you for your presentation I have a few remarks about that Let's start with the last one I'm not too convinced about this migration path I think the very first step of this plan should be to prove that it actually works This means to take one application one well-known application or larger applications to actually use this and implement this specification and to show the benefits of that So in the first steps you have introduce a new allocation this library directory and they show that there are benefits of it in the other application and then convince to more and more upstream to actually adopt this specification I am the maintainer of the midiplate scene and I know that scene is actually adopting this base specification for the next release 1.2 but version called 0.6 they don't know all 1.2 0 because that's I think the ratio of yours yes So there are actually upstreams which are keen on using that and before we are doing ugly heads like this I'd rather try to convince main adopters of larger application like KDE, GNOME, XFC well no the situation adopted before will create legacy applications and the next thing is this is not how Debian policy works you don't change policy in order to change things in Debian not to change things in Debian first and then adjust policy according to what's actually done this is what I am observing regarding the later changes in policy because this way this pushing changes in Debian policy first is going that lots of Debian maintainers will stream and not implement the policy and then you get terribly flameless as observed in the last years of Debian development Well, you need to discuss the policy first before implementing it of course and that's the point, no I say first implement it and then document policy because I think Debian policy should document what is common practice well the common practice is scattering things all over the place but it is not defined in Debian policy you won't find the part in Debian policy where it's outdated to scatter all your configuration in your home directory Exactly, that's what I am thinking of describing a better way of doing it Yes, but then making it required I fully agree that it should be documented but I don't agree that Debian policy is the perfect place in the first place to do it I mean, it's very fine to do it as a free desktop space or as another specification and get applications using it but I think it's a wrong way to force the maintainers to do it out in the blue because you won't get many upstreams which won't implement it either because they object or because they are not interested in interacting Well, if the maintainers get them patches that would significantly make it significantly easier for upstreams to implement it They might not want to create patches for it The major thing about free software is that people tend to be different and they tend to implement things different and they are and it's a major but it's a good point about free software because you have the choice between different systems and forcing to introduce such a major system that might just not work and we are getting to a basic problem about free software Everything might just not work and maintainers might just want to change files in other packages along the way or might just want to put executable files in the root directory or do something else like that That's why the policy exists to set the rules for the packages That's why Yes, but if we really enforce it a dead end policy we would have to enforce it in every package and we will I guess in the least like 50% of the package a stock stream would not adopt it so we will I work from upstream in a lot of cases, that's probably not what we want There is a lot of diversion from upstream in the file names in the outside the home directory Yeah We already have problems there please note because that's as a file system priority standard it's outside home directory it's inside home directory that should be not no difference in that I generally agree that's a good idea to get this implemented I just disagree about the migration path and the way we implement it Well we have to think if it's really going to work in first place The thing about this ugly hack in the beginning is that all the work of translating from the old file names to new file names is concentrated in one package Yes, which is the list of translations, yes and just by installing that package you will have a compatible system that implements this specification and then you can see I think you would never get rid of that ugly hack if you don't want to have an enormous amount of work to do I think that the ugly hack can be done in parallel with the version of the abstract but the abstract really believes in this that it should be applied by itself so the ugly hack can be made because that's not a conflict with the abstract and the abstract should be convinced that they use the COOIC standard COOIC standard is 5, the COOIC standard for the 1.0 3% here which is the top and the middle bits 0.6 is much more complicated actually it has all the provisions about forcing environmental variables and having multiple configuration directories for one user and priorities of files in those configuration directories I'm not sure it sounds like a very interesting idea but I'm not really seeing the benefits of it that is why I didn't include this in my proposal there's a lot of quite complex stuff in the 0.6 version of the specification that actually does require significant changes to the applications that's why that's why I think it is not made the right way accepted yes, only half of the program is included in that Do the upstream of your package know that it's complex component? For the execution well, they had me work with a very small library and I haven't looked at the next version because if you change the standards many times it will say he works a lot he works a lot for implementing he will want to change again the thing is that basically the only difference between this my proposal and the current regular situation in the applications is the paths where the files are stored where in the 0.6 version of the specs there is quite a lot of additional code that needs to be added to applications and I agree with him the deviant policy requirement is the step with a long number it's not step number two probably forward the step one and the policy requirement will be that that's not the problem now I think well, the policy requirement I'm thinking when through this ugly hacks or other methods we can get for every package this translation information that when you install this ugly hack package you have every configuration file migrated every user that file migrated to your location when that is complete then I think it can be moved to the packages I think that the ugly hack could be a good proof of concept of how the standard works but probably is a really bad solution because if you go to maintain it's probably don't work in every bad hash so we have to have different ugly hacks for like C and like if you put it in GLC then it would intercept older and faster related calls just like fake would for example maybe some things just make first and change directly it's an open one file it's a change that we maybe it's not open it's an open slash file or so normally they make and then change like me and open some files it would be useful for proof of concept so evolution works here it works like this without the standard and what's like this with the standard and this is the benefit but probably will not be will not really use it in reality I think so you might not find here about this LDP reload hack I'm not sure all architectures support LDP reloading at all I remember that MIPS doesn't support it it's another problem and the other thing is it doesn't work aesthetically fine with this one of the major targets for the rewrite the the proprietary applications would actually be intercepted another point which I don't see addressing this way at all when you talked about credentials a confidential information like passwords at least I think it would be a very good chance to explicitly mention that and this is a sensitive information please make sure that no other application than the application who's supposed to be able to read that the enforcement of this can be for example done by Aparmo or SCN but it would help them a lot if the specification would designate some special kind of this confidential information it would be useful for that too because can you have a policy to save the confidential information that's a really good idea manage the confidential information information to have at least the specifications that's a really good idea that's good so you don't see a special case because you said before you're not sure if that's configuration data at all because if you're really good at it then the application is usable and it won't it's correct and if a special case well then a special case that's a good surprise I would like to ask a question I think it's a really good idea I think it's necessary to have a policy to make these to collaborate with the standard then the for example well making this making a new version of the standard this may be a problem because people at the free desktop work out open it towards this the major problem is really implementing it in major software like non-kiddy, mozilla stuff if the standard is easy to implement and it's stable and discuss it by the community I think the option will be implemented with the time that doesn't really happen with the existing standard because it's complex as you said I will I think I have an example where the hack is going to break horribly for example take open SSH with open SSH why at the moment you have the configuration and confidentiality key information in the box SSH and a different configuration of the open SSH server is looking in dot SSH slash author's keys and if you are now moving rather taking it to slash library as the open SSH author's keys then you would have to adapt the configuration of the open SSH server the code that doesn't run as the user you see it's going to break the software open SSH when we are doing this library it's a criminal hack so really we have to do this in the source and I'm very interested to see how you convince open SSH upstream to adopt this specification I'm serious that's true we could back here try to convince open SSH you see the very question I'm thinking as one way of convincing people hacking the convention the convention of people is actually adding this somehow to the fastest hierarchy standard I think I think you shouldn't go the way up by making it mandatory by policy requirements I think you should go from the way from down saying look these are my problems I want to solve I want to make backup applications I want to ensure that security frameworks can more easily define access for example I don't see any reason why any application besides my SSH should touch my SSH key or my GPG key as well I don't see any reason why any other application than my GPG should be able to meet my GP and this specification if you can show that this specification is considerably helping security frameworks to enforce sensible security policies I think that's way more likely that more upstreams are going to help the specifications so you have to show that there are actual benefits from that yeah that's a very nice benefit that we are talking about both real benefits and talking about RAC and that's why I'm saying I'm not sure about the migration part first show that there are actually benefits implemented for applications that are known and open SSH that's true maybe give it to know because most of my upstreams use files in home records and probably they don't even know the standard so you need to give it to know who you are and step of the path I'm not sure that actually many people know about the standard it has been built quite quietly and put up on the free-desk border site and forgotten about but a huge call of comments will be that many developers can fill their view and they will be feel their part of that so they will be agree with the standard too that have been a policy requirement I'm seeing actually as the final push towards making a complete support yes but you can't do it before it's already widely adopted yeah but you probably don't want because policy will trick you with a large take if you try if you implement in the policy and it's not widely adopted there will be a huge amount of free-disk critical backs with free-disk validation so it will never I think we already read that migration is not so we will take a lot of effort it's like there was a doc to use a standard of migration and probably it was not really adopted at the time of and probably it was to use I don't think this is going to end in this decade no no you have to show their benefits if you really want to write a policy we would have to put it in policy probably maybe not as a requirement but as a really really short well first at least we should yeah if you go to provide a ton of mass backfiting and stuff like that and well it's going to take a lot of time we maybe should think about how we for a few seconds I think you should be sending if you want to do it like in one release the release is going to take like a couple of months and if you want to do it like in a couple of releases that's going to need a little bit harder it's going to take several years anyway I think it's going to go in like it would be a shoot for one release please and then it could be converted to a requirement for the next release and thank you thank you