Hi. I've been struggling with this question for the reasons I outlined in my response to Zac. As I mentioned, I am not comfortable helping people choose the DPL based on their personal beliefs outside of the scope of what the DPL is actually responsible for. I think asking what problems the DPL sees/what areas they would focus attention on is very important and I think between my platform and some of the discussions here I've answered that.
I realized that there's another aspect beyond the DPL's personal technical beliefs that is important to choosing a DPL and I'll take your question in that spirit. I assume you're asking me to use three magic wishes to demonstrate that I can come up with some vision--that I can think about something cool and exciting to focus on. I want to stress that these are not where I will spend my time as DPL. I don't actually have magic wishes; I can't just make progress in these areas. I'd be delighted if Debian made even small progress in these three areas, and happy to help, but read my other messages for my focus as a DPL. This is about showing that yes I can believe in the future and think about it. 1) I wish for good approaches to mobile devices. Everything from generating good initial images--turning packages into a firmware image that can be loaded onto a device and then later doing incremental small fast updates. But also finding hardware partnerships and actually getting Debian onto mobile devices and fixing the parts of our stack that don't work well in that environment. I am familiar with some of the past challenges in this space and realize it's hard, but I think our lack of an answer in the mobile space hurts us. 2) I wish for us to find ways to combine hardware security and openness. Mobile devices and chromebooks actually provide advantages when they lock down the system. Apple especially has done some nice things with their full device encryption. Mostly you have to give that up to get any sort of user freedom. Solving this for real would require partnerships with hardware vendors. But I think we should think about how to leverage secure boot and other image signing mechanisms to provide device integrity while letting our users rather than some big company control the keys to their devices. Steps along the way involve making it easier to replace the platform key on your device and to manage that. Integrity protecting more of the system than just the kernel and modules. For environments where it is important being able to actually sign and integrity protect an entire OS image. All while still letting the authorized user replace as much of the software as they like. Extra bonus points are awarded when we solve the problem of how to initially trust your device. Also part of this is how to distribute the work of setting up security policies (selinux, apparmor, other MAC policies)across our maintainers. Once you get your system booted you want to use modern mechanisms to protect both integrity and confidentiality of data. Maintainers of a given package are probably in the best position to understand its security profile. And yet writing a centralized security policy is easier to get secure. Apparmor obviously does a better job of letting us distribute the work of writing security policy than selinux, but I think there's stuff to improve across the board. Is this a huge problem today? Perhaps not. However, I'm hearing government and other regulated circles start talking more and more about guaranteeing integrity of systems and looking at supply chain issues. I haven't yet seen a coherent argument actually mounted against a particular acquisition that would disqualify free software because of these integrity issues. I'm fairly sure that I just haven't seen it and as more people connect the dots, this will be an increasingly powerful argument against using free software in some circles. And it shouldn't be: free software should be more trusted not less. I hope we do the work to make that true. 3) OK, I'm being selfish here, but I wish for Debian with great accessibility. I really want a Debian based system with a good, talking touch screen interface that works well with our screen readers. It frustrates me that I find myself going to a tablet or phone because I actually get to use the touch screen layout and for a lot of applications and websites that's faster than traditional screen reader controls. As a blind user, I never thought I'd want a touch screen interface, but with the right accessibility it's really cool. Of course while we're at it, we'll make Debian accessible for everyone no matter what their disability and demonstrate how free software can be an ideal platform for inclusion. I do want to call out the great efforts of our accessibility team and to stress that I'm basically not involved in that effort. It's amazing to me that our accessibility is good enough I really don't have to think about it. I can go focus on what I'm good at, and something that is absolutely critical to my life gets handled by a great group of developers. Upgrading to buster, I faced two minor problems and then things just continued to work! 3.5) While I'm hear I want to call attention to one critical accessibility issue that we've made no progress on. Throughout my entire time in Debian, super cow powers have been denied to me, all entirely because I'm blind. It's true, I've been using Debian since the days of buzz and have never once received the blessing of the great moo. In the beginning it wasn't so bad. Like everyone I shared in the machinations of dselect. I too could hit plus and try and predict what would happen next as a series of ever more complex screens greeted me. Sometimes I even understood what was going on. I looked forward to apt. It was going to be a command line. It had to be accessible. And then one day I found that everyone else was exposed to super cow powers. But I and a small number of others were denied. At first, I thought that the right approach would be to add ALSA support to Apt. This is clearly wrong though. We need access to moo even when talking to servers. And besides we would not want to disrupt the sacred cow aesthetic. So, perhaps we need to add a way to embed sounds in our terminal emulators. We'd need to be careful though: we don't want to make the mistake of the web and the great blink tag. Then I realized there's only one solution. In policy we will mandate a mechanism for sending general MIDI as part of the terminal protocol required to implement the /user/bin/x-terminal-emulator alternative. And of course the mandatory Debian sound font for rendering this MIDI will be focused on accessibility of super cow powers. Naturally we'll have to patch the kernel and the Linux console driver. This is of course one area where HURD will demonstrate its superiority, because we can just call out to a MIDI engine rather than embedding one in the kernel. And yes, I admit it. The true reason I'm running for DPL is this: to once and for all have the power necessary to gain access to moo. P.S. While I think I'd be a great DPL I warn you that sometimes it takes me a day or so to finish up an email and get it out.
