I pushed an initial version of a next iteration of DSSP to Gitweb the other day. All things considering (especially the thing where I do this for fun) I am pretty satisfied with the result.
DSSP2 (standard) is and will in the foreseeable future be maintained as I use it on all my systems and obviously DSSP3 is not a substitute. I do plan though to create something equivalent to DSSP2 standard based on another iteration of DSSP (may well be DSSP3). I am not going to be rushed into it though. For now I will be working on DSSP2 as well as DSSP3 but I am not going to make any intrusive changes to DSSP2 (I guess I haven’t made any real intrusive changes to DSSP2 since version 0). DSSP2 will go into maintenance mode.
There is this one thing that bothers me more about DSSP3 than anything else. It is how I deal with filesystem identifiers. It is not consiistent with the remainder of the identifiers. In DSSP2 the various “partitions” are identified by the “partition name”. For example “dev” indentifiers are are in the “dev namespace”, files in “files”, fs in “fs” etc. The thing here is that filesystems are relatively unique in that you can only have one filesystem of each, where for example you usually have more than one file identifier or even for example have more than one config file identifier. Even when it comes to devices, as you have various classes of devices like terminals and storage and other nodes.
The way i designed it currently is that when you operate on an filesystem you end up calling a macro that is not prefixed with something that identifies filesystems. Instead the suffix identifies the identifiers as being a filesystem. Its a weird solution but I feel that its pretty elegant considering the circumstances. It should be obvious that I already decided to accept this implementation with DSSP3. Nonetheless it feels weird.
Also when you design a new policy from scratch it is kind of hard to anticipate how things are going to play out eventually. Until you fully leverage everything there can always surface aspects that you might not have foreseen. Anyway I guess I just wanted to vent my unease with the filesystem situation.
I am currently in the process of producing decent documentation for DSSP3. Writing is not one of my stronger skills and I still have some way’s to go but I do have three chapters that I am pretty happy with. Only about 13 or more to go.
I haven’t commited to DSSP2 for ten day’s but that is not only because of my work on DSSP3. Fedora has been pretty chaotic in the last few weeks as well and I decided to let this storm pass in hopes that things looked worse than they are. It looks like it my be prudent to wait some more as a recent mass-rebuilt still hasnt trickled down.
So for now its a focus on DSSP3 docs, then update Fedora/Debian and support any changes in DSSP2 for that, and then eventually decide on a way forward either with DSSP3 or maybe some other iteration. Ive also been contemplating my options for building on top a base. One of the other pain points of DSSP2 standard has also been that of “derived” domains. Things would be so much simpler if I could somehow do away with those. Seems as if this is easier said than done. I do have some ideas but I would have to sacrifice a lot in terms of niceness.
Then again, I do this for fun first and foremost. I like exploring. We’ll see. Just wanted to dump a blog about the current status.