Edd chumped that Apache are using DOAP on their projects site. This is very cool, and I really think that GNOME should follow their example. I've been thinking for a while about building a DOAP-based software map for GNOME, and the Apache Projects site provides a very useful starting point... Time to find the source code and try a GNOME-branded version!

Eric Dorland writes about watch files, which are a way to keep track of whether there are new upstream versions of a package. He urges everyone to add them to their packages. I don't want to do that. First, I'm also the upstream of most of my packages, so my need of them is small. When I'm not upstream, I keep track of what upstream does anyway, so I'm informed of new releases that way. I realize that watch files are not useful only for the package maintainer, but also other interested parties, but, hey, I'm lazy, so I need some incentive apart from "some people think they're cool" before I take on a duty to maintain yet another aspect related to packaging. Second, I don't think watch files belong in the package. If upstream moves to a new domain, for example, the watch file needs to be updated. If it is in the package, that needs the package needs to be updated. I'd rather see watch files kept in a central server so that the package doesn't need to be changed in this situation. This would also avoid the need of having the package maintainer co-operate. Thus, I propose that those seriously interested in watch files create a "watch.debian.net" service, which keeps watch files in a centralized location, and allows them to be maintained in a wiki-like fashion.

I spent some time yesterday putting watch files in most of my packages. Watch files have been around for a long time in Debian, but hasn't reached the exposure it perhaps deserve. They're used by uscan to check for newer upstream versions of the source. What's even more useful than running uscan is the Debian Watch Health Status pages (which are also helpfully linked from the QA developer's page, but that functionality appears to be broken at the moment) which parse the watch files as well and provide a nice web interface to look up your packages and others and see where upstream is at. Unfortunately, for this to work properly the package needs a watch file, and according to the statistics, only ¹/₃ of all packages have watch files. So here's a quick tutorial, just plop a suitably modified version of these examples into the debian/watch file in your package and you're off to the races. If you're packaging foo and the source tarballs are on ftp.foo.org your watch file will look something like this:

version=3
ftp://ftp.foo.org/pub/foo/foo-(.*)\.tar\.gz

Some things to note: the version line is just there to allow for future enhancements without breaking backwards compatibility. For the location specifier, the last part after the final / is a regular expression (notice the .'s are escaped). The pattern inside the parentheses is what gets parsed as the upstream version number. For HTTP the syntax is almost identical:

version=3
http://www.foo.org/files/foo-(.*)\.tar\.gz

This snippet will download http://www.foo.org/files/ and look for href's corresponding to the rest of the pattern. For projects hosted on Sourceforge, there's a handy syntax for that, and uscan will take care of figuring out its annoying mirror system. If it's project bar, and the source is called libbar:

version=3
http://sf.net/bar/libbar-(.*)\.tar\.gz

There are many more details in the uscan man page. I think it would be great if more maintainers put watch files in their packages. It's one of those touches that really sets Debian apart from the rest.

Sometimes there is a need to take a slice of a GtkTreeModel, for example if you have a tree of data and want to show a particular layer of it in a GtkIconView. GtkIconView widgets will only work on list models so there needs to be a way of taking a slice of a tree model and presenting it as a list model. I hereby present OwlTreeModelSlice. The tree view on the left is a GtkTreeStore. The icon view on the right is displaying a OwlTreeModelSlice, that has been told to use the Applications node as the root. There are a few methods left to implement, and I need to get someone masterful in tree model fu to review the code, but hopefully I'll be releasing the source shortly. NP: Motion, The Cinematic Orchestra

I uploaded last night Mono 1.1.9.1, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9 to Debian/Unstable and debian.meebey.net. mono-tools for Debian/Unstable is now in the NEW queue though, so it will take some days before it hits the Debian archive. Gnunit and the famous monodoc-browser package is part of mono-tools now.
Warning about Gtk# 2.3.91, it breaks ABI means all Gtk# 2 applications must be recompiled against Gtk# 2.3.91 in order to work again, for example f-spot and muine. MonoDevelop 0.7 is already recompiled and uploaded too, f-spot and muine will follow tonight. The package dependencies will force a removal of f-spot and muine when Gtk# 2 will be upgraded, so nothing will break silently. Thanks to Eduard Bloch (aka Zomb) and Ingo Saitz (aka Salz) for sponsoring the uploads of the packages to the Debian archive.

I was baking waffles today, using my not-so-secret recepy. I needed about fifteen of them, and murphy helped me let it take far longer than initially expected. I had already made some errors in creating the dough (though nothing that I couldn't fix), and when I had eventually finished it and was halfway through baking those waffles, my waffle iron broke down. Which wasn't totally unexpected, given how this is a waffle iron that was part of the inheritance of an aunt of my dad's who had died even before I was born, which must have been approximately fourty years ago. Still, it had me sitting there with a broken waffle iron, a promise that I'd be baking waffles for a fundraising activity, and only half the number of waffles that I needed. I had found myself a slight little problem. So, I went to a local shop, had a look at the waffle irons that they had for sale, and chose one that looked OK to me. I hadn't taken a close look at the box, but the saleswoman had shown me the device and it looked well suited for my needs. Once home, I showed it to my brother. Who promptly exclaimed that 'it is the same as the old one'. At first, I wanted to protest; but on close examination of the picture on the box, I had to agree that he was right! They had restyled the one inside the box—given it a different colour, and used a temperature dial with a more modern look—but it was, indeed, the same model. And this redesign must have happened fairly recently; the illustratory pictures in the user manual still show the 'old' style design, which is identical to the old waffle iron, modulo approximately fourty years of technical evolution. In fact, the single most drastic change between the old device and the pictures in the manual of the new one would seem to be the fact that the company producing these devices changed names in the mean time. They also appear to be having a website, which contains pictures of yet another design of the same appliance. I was baffled. I mean, sure, home appliances are not computers, and I could imagine how a waffle iron, designed five years ago, would still be in sale today. But after that long? What I haven't checked yet, for lack of time, is whether the irons of the old device would fit in the new device. I'll do that tomorrow, because the old device had a 4x6 "Brussels waffles" iron, whereas the new only came with a double 4x7 "Home-made waffles" iron, and an iron for six heart-shaped biscuit waffles. If that would fit, then that would save me an expense of 32 euros—I love baking Brussels waffles, so any waffle iron I use needs to be able to do those. Even if it can only do so one waffle at a time. The ability to use the iron of that 40-year-old thing in the new device would be... great.

This is another example why I'm proud of Debian. I sometimes have the impression, that some distributions try to package stuff with as little effort as possible. Debian however has to support tons of different architectures, build daemons and pbuilder that mostly ensure you've got the build dependencies complete, tons of users of unstable and testing that will send you bug reports when you don't have the runtime dependencies right and so on. We have a really good quality assurance. On the very first day my selinux-basics package entered unstable, I already received feedback about the udev integration. So you might ask me, why I think this is really different from other distributions. There are of course distributions which have similar properties, but I think Debian has the biggest crowd. And Ubuntu is so closely tied to Debian that these things aren't that separable. Most Ubuntu packages are largely unmodified Debian packages. And changes done by Ubuntu - which for example tracks Gnome closer than Debian - will often be fed back into Debian again. For example fakeroot, or pbuilder are further examples on Debians best practises to do quality ensurance. Sane software shouldn't require real root privileges for building. The current Debian Vote on the GFDL is another example. I'm confident it will boil down to "Debian refuses the GFDL, because it contains too many restrictions for our users". Debian cares much for it's users. And the users of our users. And the users of our users of our users. ;-) As a whole, not just the majority which will probably never even consider changing a GFDL-licensed document. Of course, people are frequently annoyed by e.g. Debian not having the latest X.org betas in unstable, so they could try out Xgl, Aiglx and this other eye candy. Sorry about that, but I do think that the X task force knows how to set its priorities right, and you could probably just get these beta version from Ubuntu and run them on your Debian. Or build your own packages and offer them to others who want to try it, too. Or wait, like I do quite often (for example for ekiga, which is stuck in the NEW queue currently). It doesn't really hurt much to not have the newest, fancies toys. In fact, you are likely to be more productive when you don't care for these things.

Last week my new mobile phone, a Sony Ericsson K750i arrived. After using it a few days, I really like it. Especially the usb cable, which makes it possible to access the memory stick in the phone via usb-storage, and which charges the battery when connected. The quality of the integrated 2 megapixel camera could be better, here is an example.

Today I went to see the doctor for the first time in the US. I went for a few different reasons, there was a mole on my back that Sarah was worried about having changed, my wrist still hurts from that bike crash a few months ago, and I thought I'd see if I could get a 'flu shot. The first thing that's different is when you make the appointment, the receptionist asks why. I wouldn't necessarily feel comfortable explaining what ails me to a receptionist from the comfort of my office cubicle shared with three other people within earshot. Besides, it's between me and my doctor. I was a bit taken aback by this level of questioning, just to make an appointment, and hid behind a "general checkup". The second thing is each doctor seems to have their own personal nurse to do the pre-consultation blood-pressure taking and examination room setup. The third thing is the prescription seems to go straight from the doctor to the dispensing pharmacy of your choice. Pretty cool. So today I had my "general checkup". Hoo boy. Let's just say an hour later, I was feeling very poked, prodded, and squeezed, and emerged with a tetanus booster, a blood test, and an order for an x-ray. I certainly felt like I got my ten dollars' worth.

One year ago, I uploaded shadow 4.0.3-31 with "New maintainer" in the changelog. During this year, the shadow maitenance team has been built with Alexander Gattin, Christine Spang, Martin Quinson and last but definitely not least Tomasz Kloczko, the upstream author and Nicolas Fran ois, the best non DD ever. In one year, this wonderful team built 35 releases, closed 214 bugs (according to the changelog), cleaned out the BTS which had about 300 opened issues at that time. There are now 35 opened bugs, 24 being fixed in upstream's CVS, 3 tagged "wontfix" and 1 fixed in experimental. In short, there is no reported issue that hasn't received attention. It took us six months before being able to resynchronize the Debian version of login and passwd with upstream. After achieving it and after dozens of exchanges with upstream, the size of the diff.gz file went down from over 1.5MB to about 120kb in the next release. Upstream changelog is now full of patches and rewards to Debian. We used 26 cheese names for naming releases in a tradition established after a famous Cheese Party held at Debconf 5. Be prepared for the Debconf 6 Cheese Party! I see this work as a good example of revival work for an essential package and good collaboration with upstream. I probably have my part in this, trying to keep the communication, sometimes making decisions and always revive work on forgotten issues. But, definitely, I have to deserve a special mention to Nicolas. He's definitely the one who understand the whole code and when he didn't knew, he just learned. Without him, we would never have been able to achieve this. Please, just give him direct DAM approval if he ever applies as a NM...:-) Again, happy birthday to the new shadow....

Greenpeace has asked companies to minimize the usage of toxic substances (English article) in computers and other electronic devices at this year's Cebit. Hewlett Packard, LGE, Motorola, Nokia, Samsung, Sony and Sony Ericsson have assured Greenpeace to reduce toxic substances in their products in the nearer future. However, many other companies have ignored Greenpeace so far. For example: Acer, Apple, Dell, Fujitsu-Siemens, IBM, Lenovo, Panasonic, Siemens and Toshiba. I'm listing the names of these companies here in the hope to increase public pressure on them a bit ;-) Although I'm not a member of Greenpeace (yet?), I do support the ideas and work of Greenpeace, and especially the above E-waste article made me think. We're all using more and more computers, PDAs and other gadgets — especially the geeks among us. I think we all should (at least to a certain degree) care about how this affects the environment. I have fired up a search engine and looked for some hints about what you can do as a computer geek in order to help save the environment — guess what... there's a HOWTO for that, the Linux Ecology-HOWTO! (I'm beginning to think that there's no topic out there anymore, which hasn't been covered in a HOWTO by some Linux geek ;-) (via netzpolitik.org)

Thanks to the one who posted this little hint some weeks ago The ControlMaster? feature recently provided by ssh is really helpful. (If you are on Darwin, you need to install openssh through DarwinPorts first.) It's quite easy to enable it. Consider the following snipplet for ~/.ssh/config:

ControlMaster? auto
ControlPath? ~/.ssh/ssh_control_%h_%p_%r

It creates a control channel for a server connection upon the first connect. It is persistent as long as the first SSH process is running. It will block after the logout though if there are still childs connected to the master process. If that annoys you, just open some SSH masters which pre-authenticate into the background by using ssh -M -fn. What do you gain from that? Well, consider you have a SSH connection open to some host and want to scp something. You won't have to go through any authentication again and the copy process starts immediately because it is multiplexed over the connection which already exists. The same counts if you want to start a second shell to that host with the same username. I use ssh-agent for authentication (gpg-agent probably soon to come...), but sometimes the negotiation just needs quite a long time, so this snipplet is a serious SSH improvement for me.

Since Joey Hess posted a short conversation we had on IRC today about the role of the DPL, I thought it's a good time to express some of my thoughts. Basically, I think that most people have a bad understanding of which tasks are really involved in being DPL (e.g. much more purely administrative crap that nobody else wants to do) and that they're quite naive about what the DPL can achieve, at least in the current climate. Let's just look at the current discussions on the -vote list. It's this time of the year when everyone pretends that its Christmas, expresses their feelings of what's wrong with Debian and where Santa Claus^W^Wthe candidates reassure them that everything will be fine. "Will you fix NM? Fix or replace ftp-master? etc." "Oh, sure I will, all of that (and more)." Honestly, would you elect someone if they told you they won't or can't? The strange thing is that the same questions get asked every year, and yet people don't get the hint and look for other solutions. I'm not overly happy with any of the candidates this year, and I was seriously considering running again, not next year but possibly later. However, this Christmas wankfest reminded me again why that may not be such a good idea after all. I remember how much time I spent answering questions on -vote myself, and while I'm all for transparency, many of the questions were just a waste of time. This year, the questions were relatively sane in the beginning but now it's just a waste of time most questions are posed in a way that it's clear what kind of answer people want to hear. I spent hours and hours answering questions, but at some point I thought "cannot we just stop talking for hours about what I'd do if elected and actually start doing all that stuff?". That would have been so much more productive. Instead of asking the DPL what they'll do to solve All The Problems In Debian, why don't you ask yourself what you can do to improve the situation? There's a bottleneck with the DAM, you say. Right, the chances that you'll be added as DAM are relatively small. But have you ever considered helping the DAM and to make their life easier? How about signing up as an Application Manager and producing such good reports that it'll be a piece of cake for the DAM to approve people based on your reports? Right, it won't fix the bottleneck, but it will make the situation so much better. Instead of bitching about the security team, why don't you prepare a package, write the text for the DSA and get everything ready in a way that a DSA member can simply take your work, recompile the package and issue the advisory? Now I'm sure some people will say that they've tried that and failed. Yes, not every upload for DSA will be accepted as it is, but how hard have you tried? And people always complain about the cabal and how hard it is to join teams. And while I agree that this is partly true, there are so many counter examples too. Look at me as an example. In 2.5 years, I became the most productive Application Manager, joined (and took over) the NM Front Desk, became a "senior" Quality Assurance member, and got elected as project leader. Am I special? No, in no way I just put in a lot of effort. Look at Jeroen van Wolffelaar, who joined at the end of 2004, and who is involved in QA (especially MIA) and lintian, is the co-author of the new packages.d.o code and an ftp assistant. Andi Barth (who got an account in January 2004) has done important QA work (bts2ldap), is a maintainer of the developers reference and a release manager. So it's not possible to join a team, you say? Maybe you're just not trying hard enough (and the right way!). (Hint: "make me a DAM/ftp-master/whatever" doesn't work as well as "how can I make your job easier?"). What I'm trying to say is that people should stop believing that the DPL will fix everything and that they should actually help out themselves. If we all work together and put effort into the areas that need work we might actually achieve something. People have been asking for a strong leader and this urge got stronger over the last few years. But, face it, we currently don't have a culture which accepts a strong leader. Joey Hess mentioned that he wants to see a DPL who pushes technical changes. I did that too, to some degree (mostly in private since that works much better than on a mailing list where a big flamewar is guaranteed). For example, I kindly asked Joey to lower the priority of the non-free question so it would not get asked in a default installation. And he did because Joey is a reasonable guy. (He also told me that me making this request made it easier for him to justify.) However, unfortunately, not everyone is like Joey. And what are you going to do if a maintainer refuses to listen, as many do? I mean, seriously, what can you do? Some are increasingly talking about the good old times of Bruce Perens who would tell people what to do and make decisions. The urge for a strong leader increased over the last years. I think that's partly a reason why Branden got elected last year people expected him to completely shake things up. I haven't talked to him and I wasn't part of the leadership team, so I don't really know what happened, but from what (little) I've heard, it seems that he tried, quickly realized just how rigid some of the structures are and gave up. You have to see things in a historical perspective (and I can only recommend that people who have access to the debian-private archives take the time to read through them). There's a reason we have had "weak" leaders since Bruce. While now a large number of people think that Bruce was the best thing since sliced bread, lots of people were really pissed off back then with him commanding people around. And what was the result? A constitution that would ensure that no leader would ever have such power again. And that's what we're currently stuck with. I think that one of the biggest problems Debian is currently facing is the inability to make decisions. There are so many endless, completely futile (and repetitive) discussions going on. We need someone who comes in, tells people to shut up and makes a decision on behalf of the project. A decision people will follow, even if they personally disagree with it. But seriously, do you think our culture would currently accept such a leader? I can tell you from experience that even people who have been asking for a "strong" leader won't actually follow a leader who tells them to take a certain course of action. We really need to fix this problem, and the problem is in our culture. And since our culture is defined by who we are, you should start with yourself first. Start by asking yourself a few questions. Do you think before posting something to our lists, and ask yourself twice whether it really adds value to the discussion? If there's an area that is problematic, will you try to help out? If asked to do something you're not particularly interested in but which is good for the project will you do it? And most importantly, will you contribute to make our culture something that is fun? The project leader is important, but don't wait for them to fix all of our problems. If there's a problem, try to figure out a way how you can solve it!

<tbm> got a minute. I'm wondering about your latest blog
<joeyh> the one I committed 2 minutes ago or the pervious one?
<tbm> the dpl one
<joeyh> ok, sure
<tbm> what does it mean to focus on technical things? I focused on organizational things, but mostly in a way so that other people can do their technical work without having to worry.
<joeyh> I basically think that part of the whole dpl-as-figurehead problem is that we have stopped trusting our DPLs to lead the project toard large technical changes to Debian (software)
<tbm> that's right, but I think the majority doesn't want that anyway. Like Ted T'so, who said he wanted a "strong leader" but when I asked him to lead the kernel team he said he'd prefer to maintain a kernel in non-free than a crippled one in main.
<tbm> funny asking for a strong leader but then ignorning the leader
<tbm> but yeah, it seems we disagree about the role of the dpl; I see it more as organizational/secretarial so other people can do their technical work
<joeyh> right, which is why I'm focusing on it to the exclusion of all the other stuff the DPL should do, to try to counterbalance that majority as best I can
<tbm> like getting you a laptop for d-i for example
<tbm> okay
<joeyh> look at Shuttleworth. He's provided strong technical directions to Ubunutu. Occasionally incorrect, arguably often iffy, but it's done a lot for them
<tbm> oh, I see. Right. What I think Debian needs is someone to say which way to go when one of our discussions/flamewars don't end in consensus, which they recently never do
<tbm> but somehow I doubt most DDs would care what the dpl said anyway.
<joeyh> we need a DPL to make decisions like "Debian will ship a Gnome desktop by defualt in the sarge release", and who can get the whole project behind that. Otherwise it leaves people like me having to work around the projet's inability to make the decision under the radar
<tbm> they got so used to "quiet" dpls
<tbm> yeah, I agree with you on this.
<tbm> okay, thanks for clarifying
<joeyh> do you mind if I post this on my blog?
<tbm> no

Something in apt-cacher did always suck... I adopted the package short before the Sarge release and tried to make it work better. At that time the package was not in the best state, too many changes have done without big design (or any design?) in mind. I made some changes on the cache structure to make it easier maintainable, introduced a basic signaling mechanism and consistency checks, so it should not get stuck or deliver wrong data any longer. However, there was the one big flaw, and Bug 354925 brought it to daylight. Storing all files in a flat directory was a very cheap way to merge multiple mirror contents and allow users choosing just any valid mirror. But it had also some costs: file collisions on identical names, happening more often since Ubuntu's is out there. The more I looked trough the code to find a good solution, the more I realized a need for a complete overhaul of the internal structure. For example, the simpliest change would be just putting the files into a nested directory structure. Great. But you will have duplicated files everywhere. They can still be re-unified using hardlinks, but that should be done offline since lookups with checksummng cause too much delay. And there was still the problem with persistent connections and forks, LWP does not allow connection reusing in forked clients so you get too many server connections. And the logging has been done synchronously and required flock'ing. Acceptable and not very memory-expensive but causes delays on filesystems with some load. So, the final software architecture for apt-cacher that I came up can be described with few characteristics:

• using perl threads (separate threads for logging, connection dispatcher, connection handlers, download agents)
• not spawning too many threads, putting agent threads into a pool of available threads. That would even reuse the connection if the next apt-get client tries to access the same server
• no direct access via CGI or stdin/stdout (inetd) anymore. Instead, connection can be done via Unix Domain Sockets, so small wrappers will provide access to the daemon. That should be even more efficient.
• the problem with file duplicates will be solved with sqlite3 - apt-cacher will extract the data from Packages/Sources/Index files and track the paths/filesizes/checksums. When a client requests a file and a stored one (with the same size/basename/checksum) exits, it will be returned instead.
• the bunch of "header", "complete" and "notify" files will disappear too. They just eat space and inodes and are not needed anymore. The header files will be replaced with self-generated ones, using file data from the database. .complete and .notify existed basically for IPC and storage of origin download path and will be replaced with internal thread communication and directory path.
• integration of pdiff files - if the package index files are processesed in a background thread anyway, the more fresh pdiff files can be used to rebuild the index files in an efficient way. Trigering this rebuild action periodicaly would also allow old apt-get clients to use the benefits of the patch transport.

But first I need to get past my exams period :-( And I hope the final implementation will not become a memory monster, I didn't have the impression that Perl threads are really memory-efficient in the few first tests.

Rapha l, I have to disagree with you on the voting process. Voting something below NOTA is not a punishment for the proposer that should be exercised only in extreme cases, but rather a way to express that you find this option unacceptable (for example, as I find the "GFDL is free" and "GFDL without Invariant Sections is free" options in the GFDL vote). Contrary to popular belief, this does have an effect on the outcome, specifically if there is a cycle

1. A > B
2. B > NOTA
3. NOTA > A

When two of those are in the result set before the "sequential dropping" step, the weakest of the three is dropped. If that is "A > B", then B wins. If it is "NOTA > A", then A wins. Thus, it is vital that people communicate adequately what they find unacceptable; it's not about "my way or the highway" if I only find a single option acceptable, but rather a valid opinion. Vote early, vote often!

If you've been reading my blog through my website, rather than through any of the places where I'm syndicated, You'll have noticed that I've recently created a new CSS stylesheet (which I've called "plain", even though it isn't empty) and made it the default. The reason for this change is that my previous default, the "hackergochi" CSS, was a bit of an angry fruit salad, and also required much of the browser to render it properly (firefox couldn't scroll it very smoothly, for example). This one doesn't change much colors (though it does change a few of them), and apart from placing the menu and having it stand out, there isn't much that it changes. This will make my website work more efficiently, though not necessarily faster. The new CSS also doesn't waste as much screen real estate, which I think is a plus. Only it doesn't look very good. But then, I'm not a graphical guy.

Karl Fogel's Producing open source software: how to run a successful free software project covers many of the important aspects of free software projects, and concentrates on the parts that are different from, say, traditional in-house development projects. The book covers technical aspects like mailing lists, bug trackers, version control systems, and other infrastructure necessary for a project to survive. It also covers more social aspects, such as how to deal with flames, forking, or how to employ developers for free software projects. The book is written well, and is a light, fairly quick read. Those of us who have participated in free software for a long time can find the book as a nice summary of things that have been learned over the years. Those newer to free software development may find many new things to learn. Most of us will find something to think about. Despite the level of detail Fogel gets into, the book obviously only scratches the surface. Free software development is such a vast new territory that it is not realistic for one book to cover all of it. For example, this book does not cover conferences and other face-to-face meetings, which are important for keeping the community of free software developers alive. With the caveat that it doesn't make further volumes on this topic unnecessary, Fogel's book really is worth the time it takes to read it. Recommended.

As this year is going to be the year of computer science (or rather, Informatics) in Germany, and most of the money for it has already been spent (it all went to some PR agency AFAIK), some students are planning to organise a bit of a roadshow that will demonstrate simple topics to interested audiences. For example, we are going to show different sorting algorithms by ordering ten volunteers standing in a row by their first names, and talk a bit about complexity here, and I'm trying to rehash my crypto talk into something with more theory that is still less dry than it is currently (probably with a bigger focus on PKI).