Re: Q: top three things you would like to change if that was easy?
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.
Reply to: