Voting Guide for Debian Init Systems GR

There are a lot of options on the ballot for the Init Systems GR.
There have been hundreds of messages on debian-vote, and more scattered
across debian-devel, debian-project, and bugs. Reading all that is no
easy task. so I would like to summarize my understanding of the options
and what they would mean. I've tried to remove as much bias as I can,
but this is still Sam's personal opinion.



I'm focused entirely on the effects of the proposals. Several options
(D, F, and G) spend significant time outlining principles. That is
something I'm ignoring here in this post, although I acknowledge it is
really important to some.



Areas of Agreement



One of the big surprises for me in this discussion is things that are
true of all the ballot options so far. We are agreed that programs
designed to use systemd features that only work with systemd are welcome
in Debian. That's true even if there is no way for these programs to
work without systemd. Under Proposal D, this is a bug, but not a
release-critical bug.



Init Diversity Options


Several options focus on encouraging or requiring packages to support
init systems others than systemd when that is possible. These include
Proposal
E
, Proposal F,
and Proposal
A
. Under proposal E, it is a release critical bug if a program does
not work when something other than systemd is pid 1 unless that program
is designed explicitly to work with systemd and no support for running
without systemd is available. Lack of an init script alone is not
sufficient to count as designed to work exclusively with systemd.



So, under this proposal, a maintainer must integrate support for running
without systemd if it is available. They are responsible for going out
and finding this support. If the support is as simple as writing an
init script, the maintainer has an RC bug until they write the init
script. If the support is more complex, the maintainer is not
responsible for writing it. Proposal A is the same as Proposal E,
except that the bug is not release-critical. I'll go into Proposal A in
more detail after discussing Proposal D.



Proposal D is similar to Proposal E. My interpretation is that Proposal D places
somewhat less of a burden on maintainers to go out and find existing
non-systemd support. My interpretation is that the bug becomes RC when
someone contributes that support. (Or if the support is present in the
upstream but turned off in the package). Proposal D requires that
non-systemd support not have a substantial effect on systemd
installations. So where as Proposal E uses the designed exclusively for
systemd criteria, Proposal D uses the no substantial effect on systemd
systems criteria to determine whether working only with systemd is
acceptable. The discussions seemed to imply that if Gnome uses systemd
features in excess of what technologies like elogind can handle, it is
likely to meet both criteria.



Proposal D goes into a lot more detail than Proposal E. Proposal E
would likely be a long-term block on using systemd facilities like
sysusers. Proposal D specifically proposes a mechanism whereby such
facilities can be documented in policy. This mechanism is only
available if it is likely that developers of non-systemd (including
non-Linux) systems will implement the facility. After a six-to-twelve
month transition time, the facility can be used even on non-systemd
systems. So, sufficiently low effort in the non-systemd community that
it is unreasonable to expect a facility could be implemented could still
permanently block adoption of such facilities. Proposal D is definitely
about a long-term commitment to non-systemd systems even if the effort
in the non-systemd community is not as high as we'd like to adopt new
features elsewhere.



Proposal D also includes a number of guidelines for proper behavior
around these emotionally charged issues.



The only difference between Proposal E and Proposal A is the severity of
the bug when non-systemd support is not in a package. In Proposal A,
this bug is important: potentially sufficient for a stable update, but
not release critical. As a practical matter, Proposal A allows the
non-systemd community to contribute (and NMU) patches for non-systemd
support. However, it does not place an obligation on maintainers to
write this support themselves. Proposal A would permit systemd
facilities like sysusers to be used, although doing so might be a bug.
In the specific case of sysusers, someone could justify NMUing a patch
to use adduser in a maintainer script. Unlike Proposal D, Proposal A
places the burden of keeping up with systemd facilities fully on the
non-systemd community. Proposal A does not have Proposal D's
requirement that it be reasonable to expect that the non-systemd
community can implement the facility.



Systemd Options


There are two systemd options: Proposal F
and Proposal
B
. Proposal F replaces a previous Proposal C. As far as I can tell
Proposal F and C do the same thing, but Proposal F has some text
describing principles. As I said in the introduction, I'm not
discussing that here.



Under Proposal F, systemd is the only officially supported option.
Other init systems may be explored at wishlist priority. Systemd
facilities such as sysusers are encouraged, and we will use our usual
mechanisms to plan transitions from Debian facilities where appropriate.



Proposal B does not explicitly say that alternate init system work can
only be wishlist. Under Proposal B, I think it would be reasonable to
file some bugs at normal severity, but it would also be reasonable for a
maintainer to downgrade them. I don't consider that a significant
difference.



The big difference is that Proposal B commits us as a project to
reviewing integrations of technologies that are alternatives to
systemd facilities. The current example is elogind. But things like
a non-systemd implementation of sysusers, tmpfiles.d, etc, would also
qualify. The rationale is that sometimes alternatives like that touch
on core infrastructure, and even if other maintainers are doing the
work, gatekeeper review is needed. Under Proposal B, the alternate technologies would be available, but whether to use them in a specific package would be up to the maintainer. I've discussed in another, more opinionated blog post why this might be a good idea.



Proposal G


As best I can tell Proposal G is just a set of principles. so, in the context of the analysis I have set out to perform here, I think there is nothing to say.

The Case for Proposal B

This is my personal opinion, not that of the project leader. Tomorrow,
I'll write an essay trying to discuss the various options in with as
little bias as I can manage (although even that will be Sam's opinion).
Several people have asked me why I included Proposal B.
This is my answer.


While I was talking to people about systemd and init systems, people
seemed to inherently assume that being uncomfortable with systemd meant
that you were in favor of sysvinit, or at least init-script based
solutions. At least, people who were heavily involved in the issue made
that assumption. That didn't resonate with me.


Several concerns commonly raised with systemd resonate with me:


  1. It combines a bunch of things in one project; as an example how you
    start daemons ends up being tied to how you configure the network.

  2. This combination seems like it might reduce innovation at least
    outside of the systemd ecosystem, because interfaces are coupled.

  3. It is Linux specific


Of these, the biggest concern for me is the idea that systemd might
stifle innovation by becoming one point of control.


And yet, in my opinion, systemd is vastly superior to the current
alternatives. I'd far rather be writing service units than init
scripts. They are more declarative. Dependencies that I care about are
easier to express. There are better security isolation facilities. In
non-Debian work I've found that I depend heavily on systemd because it
is easier and more pleasurable to code to than the alternatives.
Declarative syntax for managing users is useful. I haven't personally
seen the huge joy of socket activation, but if I were writing somewhat
different things, perhaps I would. Given
the options today, I would pick systemd hands down and not look back.


But what about tomorrow? For me, one of the great things about Debian
has been that it's possible to integrate new technologies and to try
things out. Debian has been the OS where I and many others could try
out new technologies and figure out what it was like to fully integrate
them into the operating system. Systemd is the best we've got now, but
I'm reluctant to step away from Debian as a platform for innovation and
experimentation.


Yet I don't think focusing on sysvinit or other init-script based
solutions actually has anything to do with the kind of innovation I'm
talking about. I understand that for people who value sysvinit (or
something like runit) above systemd, that work is valuable. My
experience is that for my needs, systemd is a better fit. I wanted a
proposal that allowed us to maintain Debian as a platform for innovation
without focusing on the legacy of init scripts. I think that if there
is going to be something that some day replaces systemd, it will support
service units (or a significant subset) not init scripts. I suspect it
will have a way to handle socket activation and so on. And I cannot
imagine a future systemd replacement that does not have advanced
security isolation features.


How it Works


Proposal B is a systemd focused proposal. It's very similar to Proposal F.
The text is different, but the implications of both proposals are
similar. Maintainers can use whatever systemd facilities they choose.
Init scripts are not required. For most maintainers, even thinking
about alternate init systems or future experiments is something entirely
optional. That's true under both proposal F and Proposal B.


Where they differ is in how much support the project gives to
experiments involving alternate init systems. Under Proposal F, that's
entirely optional at each member's discretion. My experience is that's
not sufficient for Debian to remain a community for innovation. My
experience is that key maintainers and teams maintaining central
infrastructure or packages often need to work with people who are trying
to integrate new features. The difference between Proposal B and F is
that under Proposal B, we commit to making that happen for technologies
that are important in exploring alternatives to systemd.


Obviously, no member of our community is obligated to do work. In
practice this commitment might mean working to find new volunteers to
help out key packages or teams and do this work. Sadly, there are areas
where the history of interaction has not been so good; behavior on
multiple sides of discussions has not lived up to our standards. In
addition to making sure we have the necessary volunteers for key
packages and teams,
part of meeting this commitment may involve working with people who
want to explore alternatives to systemd to find advocates who foster a
climate where we can be excellent to each other.


The Risks


There are some real risks with Proposal B. The biggest is that we'll
spend time working on integrations and nothing innovative will come out
of it. A possible outcome is that we spend a lot of time integrating
elogind and similar technologies, but they end up not being useful
because packages start depending on service units and socket
activations. Unless something new comes along, we may waste our
effort. Yet we've often been willing to spend effort to enable people
to try things. For me, this proposal is about reaffirming that aspect
of Debian.


In the worst case, it's possible that we decrease the quality of our
systemd integration leaving room for something else, spend significant
emotional energy, and do not end up with interesting innovation.
I think it's much more likely that if there is no interesting
innovation, Proposal B will slowly morph into Proposal F.


Why did You Do this?


In the beginning of this post, I talked about how I personally
considered the concerns about systemd separate than the desire to keep
init-script based systems running. That view is uncommon among people
who have been spending a lot of time on this issue. In general people
who are spending a lot of time on init systems seem to be fairly
divided. If you are trying to get work done today, you are probably
either fully using systemd or using one of the existing init-script
based alternatives.


However, my concern resonated with developers I talk to who spend less
time involved in the issue. Not people who were going to go research
things enough to write a proposal. But people who weren't sure that
systemd was the way and the light of the future, but found it had a lot
of great things going for it.


I was one of the few people who was taking the time to really understand
the issues but who was somewhat flexible. I didn't even know how I was
going to rank the options on my ballot until this morning. Yes, I've
been systemd leaning in some ways, but I also very much see the
arguments in favor of enabling people to keep other init systems
working. I'd be happy with most of the options on this ballot winning.
So, I tried to listen and see if there were ways of splitting
disagreement that wouldn't work for the people most committed to one
position, but might appeal to people who are less involved.


Why are you Writing This Post?


I think it's dangerous for someone who is project leader to speak a
personal opinion, especially on a controversial issue. However, I've
heard people struggling with some of the issues I discuss here in our
community. What I say may give people another way of looking at
things. I do think I have a valuable prospective because I have spent a
lot of time thinking about the issues but have not been as intimately
involved as others who have spent similar time. I think my need to act
as a facilitator at least for this GR is over. And after spending a day
considering, I think it's more beneficial to specifically ask the
project to think about Debian as a community for experimentation than to
say nothing.

Free as in Sausage Making: Inside the Debian Project

Recently, we’ve been having some discussion around the use of non-free software and services in doing our Debian work. In judging consensus surrounding a discussion of Git packaging, I said that we do not have a consensus to forbid the use of non-free services like Github. I stand behind that consensus call. Ian Jackson, who initially thought that I misread the consensus later agreed with my call.


I have been debating whether it would be wise for me as project leader to say more on the issue. Ultimately I have decided to share my thoughts. Yes, some of this is my personal opinion. Yet I think my thoughts resonate with things said on the mailing list; by sharing my thoughts I may help facilitate the discussion.


We are bound together by the Social Contract. Anyone is welcome to contribute to Debian so long as they follow the Social Contract, the DFSG, and the rest of our community standards. The Social Contract talks about what we will build (a free operating system called Debian). Besides SC #3 (we will not hide problems), the contract says very little about how we will build Debian.


What matters is what you do, not what you believe. You don’t even need to believe in free software to be part of Debian, so long as you’re busy writing or contributing to free software. Whether it’s because you believe in user freedom or because your large company has chosen Debian for entirely pragmatic reasons, your free software contributions are welcome.


I think that is one of our core strengths. We’re an incredibly diverse community. When we try to tie something else to what it means to be Debian beyond the quality of that free operating system we produce, judged by how it meets the needs of our users, we risk diminishing Debian. Our diversity serves the free software community well. We have always balanced pragmatic concerns against freedom. We didn’t ignore binary blobs and non-free firmware in the kernel, but we took the time to make sure we balanced our users’ needs for functional systems against their needs for freedom. By being so diverse, we have helped build a product that is useful both to people who care about freedom and other issues. Debian has been pragmatic enough that our product is wildly popular. We care enough about freedom and do the hard work of finding workable solutions that many issues of software freedom have become mainstream concerns with viable solutions.


Debian has always taken a pragmatic approach to its own infrastructure and to how Debian is developed. The Social Contract requires that the resulting operating system be 100% free software. But that has never been true of the Debian Project nor of our developers.



  • At the time the Social contract was adopted, uploading a package to Debian involved signing it with the non-free PGP version 2.6.3. It was years later that GnuPG became commonly used.

  • Debian developers of the day didn’t use non-free tools to sign the Social Contract. They didn’t digitally sign it at all. Yet their discussions used the non-free Qmail because people running the Debian infrastructure decided that was the best solution for the project’s mailing lists.


“That was then,” you say.



  • Today, some parts of security.debian.org redirect to security-cdn.debian.org, a non-free web service

  • Our recommended mirror (deb.debian.org) is backed by multiple non-free CDN web services.

  • Some day we may be using more non-free services. If trends in email handling continue, we may find that we need to use some non-free service to get the email we send accepted by major email providers. I know of no such plan in Debian today, but I know other organizations have faced similar choices.


Yet these choices to use non-free software and non-free services in the production of Debian have real costs. Many members of our community prefer to use free software. When we make these choices, we can make it harder for people to contribute to Debian. When we decline to use free software we may also be missing out on an opportunity to improve the free software community or to improve Debian itself. Ian eloquently describes the frustrations those who wish to use only free software face when faced with choices to use non-free services.


As alternatives to non-free software or services have become available, we as a project have consistently moved toward free options.


Normally, we let those doing the work within Debian choose whether non-free services or software are sufficiently better than the free alternatives that we will use them in our work. There is a strong desire to prefer free software and self-hosted infrastructure when that can meet our needs.


For individual maintainers, this generally means that you can choose the tools you want to do your Debian work. The resulting contributions to Debian must themselves be free. But if you want to go write all your Debian packaging in Visual Studio on Windows, we’re not going to stop you, although many of us will think your choices are unusual.


And my take is that if you want to store Debian packages on Github, you can do that too. But if you do that, you will be making it harder for many Debian contributors to contribute to your packages. As Ian discussed, even if you listen to the BTS, you will create two classes of contributors: those who are comfortable with your tools and those who are not. Perhaps you’ve considered this already. Perhaps you value making things easier for yourself or for interacting with an upstream community on Github over making it easier for contributors who want to use only free tools. Traditionally in Debian, we’ve decided that the people doing the work generally get to make that decision. Some day perhaps we’ll decide that all Debian packaging needs to be done in a VCS hosted on Debian infrastructure. And if we make that decision, we will almost certainly choose a free service to host. We’re not ready to make that change today.


So, what can you do if you want to use only free tools?



  • You could take Ian’s original approach and attempt to mandate project policy. Yet each time we mandate such policy, we will drive people and their contributions away. When the community as a whole evaluates such efforts we’ll need to ask ourselves whether the restriction is worth what we will lose. Sometimes it is. But unsurprisingly in my mind, Debian often finds a balance on these issues.


  • You could work to understand why people use Github or other non-free tools. As you take the time to understand and value the needs of those who use non-free services, you could ask them to understand and value your needs. If you identify gaps in what free software and services offer, work to fix those gaps.


  • Specifically in this instance, I think that setting up easy ways to bidirectionally mirror things between Github and services like Salsa could really help.



Conclusions



  1. We have come together to make a free operating system. Everything else is up for debate. When we shut down that debate—when we decide there is one right answer—we risk diluting our focus and diminishing ourselves.

  2. We and the entire free software community win through the Debian Project’s diversity.

  3. Freedom within the Debian Project has never been simple. Throughout our entire history we’ve used non-free bits in the sausage making, even though the result consists (and can be built from) entirely free bits.

  4. This complexity and diversity is part of what allows us to advocate for software freedom more successfully. Over time, we have replaced non-free software that we use with free alternatives, but those decisions are nuanced and ever-changing.

AH/DAM/DPL Meet Up

All the members of the Antiharassment team met with the Debian Account Managers and the DPL in that other Cambridge— the one with proper behaviour, not the one where pounds are weight and not money.

I was nervous. I was not part of decision making earlier this year around code of conduct issues. I was worried that my concerns would be taken as insensitive judgment applied by someone who wasn’t there.

I was worried about whether I would find my values aligned with the others. I care about treating people with respect. I also care about freedom of expression. I value a lot of feminist principles and fighting oppression. Yet I’m happy with my masculinity. I acknowledge my privilege and have some understanding of the inequities in the world. Yet I find some arguments based on privilege problematic and find almost all uses of the phrase “check your privilege” to be dismissive and to deny any attempt at building empathy and understanding.

And Joerg was there. He can be amazingly compassionate and helpful. He can also be gruff at times. He values brevity, which I’m not good at. I was bracing myself for a sharp, brief, gruff rebuke delivered in response to my feedback. I know there would be something compassionate under such a rebuke, but it might take work to find.

The meeting was hard; we were talking about emotionally intense issues. But it was also wonderful. We made huge progress. This blog is not about reporting that progress.

Like the other Debian meetings I’ve been at, I felt like I was part of something wonderful. We sat around and described the problems we were working on. They were social not technical. We brainstormed solutions, talked about what worked, what didn’t work. We disagreed. We listened to each other. We made progress.

Listening to the discussions on debian-private in December and January, it sounded like DAM and Antiharassment thought they had it all together. I got a note asking if I had any suggestions for how things could have been done better. I kind of felt like they were being polite and asking since I had offered support.

Yet I know now that they were struggling as much as any of us struggle with a thorny RC bug that crosses multiple teams and packages. The account managers tried to invent suspensions in response to what was going on. They wanted to take a stand against bullying and disrespectful behavior. But they didn’t want to drive away contributors; they wanted to find a way to let people know that a real problem required immediate attention. Existing tools were inadequate. So they invented account suspensions. It was buggy. And when your social problem solving tools are buggy, people get hurt.

But I didn’t find myself facing off against that mythical group of people sure in their own actions I had half imagined. I found myself sitting around a table with members of my community, more alike than different. They had insecurities just like I do. They doubted themselves. I’m sure there was some extent to which they felt it was the project against them in December and January. But they also felt some of that pain that raged across debian-private. They didn’t think they had the answers, and they wanted to work with all of us to find them.

I found a group of people who genuinely care about openness and expressing dissenting views. The triggers for action were about how views were expressed not about those views. The biggest way to get under DAM’s skin and get them started thinking about whether there is a membership issue appears to be declining to engage constructively when someone wants to talk to you about a problem. In contrast, even if something has gone horribly wrong trying to engage constructively is likely to get you the support of all of us around that table in finding a way to meet your needs as well as the greater project.

Fear over language didn’t get in our way. People sometimes made errors about using someone’s preferred pronouns. It wasn’t a big deal: when they noticed they corrected themselves, acknowledged that they cared about the issue and went on with life. There was cursing sometimes and some really strong feelings.

There was even a sex joke. Someone talked about sucking and someone else intentionally misinterpreted it in a sexual context. But people payed attention to the boundaries of others. I couldn’t have gotten away with telling that joke: I didn’t know the people well enough to know their boundaries. It is not that I’m worried I’ll offend. It is that I actively want to respect the others around me. One way I can do that is to understand their boundaries and respect them.

One joke did cross a line. With a series of looks and semi-verbal communication, we realized that was probably a bit too far for that group while we were meeting. The person telling the joke acknowledged and we moved on.

I was reassured that we all care about the balance that allows Debian to work. We bring the same dedication to creating the universal operating system that we do to building our community. With sufficient practice we’ll be really good at the community work. I’m excited!

Questioning and Finding Purpose

This is copied over from my spiritual blog. I'm nervous doing that, especially at a point when I'm more vulnerable than usual in the Debian community. Still, this is who I am, and I want to be proud of that rather than hide it. And Debian and the free software community are about far more than just the programs we write. So hear goes:

The Libreplanet opening keynote had me in tears. It was a talk by Dr. Tarek Loubani. He described his work as an emergency physician in Gaza and how 3d printers and open hardware are helping save lives.


They didn't have enough stethoscopes; that was one of the critical needs. So, they imported a 3d printer, used that to print another 3d printer, and then began iterative designs of 3d-printable stethoscopes. By the time they were done, they had a device that performed as well or better than than a commercially available model. What was amazing is that the residents of Gaza could print their own; this didn't introduce dependencies on some external organization. Instead, open/free hardware was used to help give people a sense of dignity, control of some part of their lives, and the ability to better save those who depended on them.


Even more basic supplies were unavailable. The lack of tourniquets caused the death of some significant fraction of casualties in the 2014 war. The same solution—3d-printed tourniquets had an even more dramatic result.


Dr. Loubani talked about how he felt powerless to change the world around him. He talked about how he felt like an insignificant ant.


By this point I was feeling my own sense of hopelessness and insignificance. In the face of someone saving lives like that, I felt like I was only playing at changing the world. What is helping teach love and connection when we face that level of violence? Claming that sexual freedom is worth fighting for seems like a joke in the worst possible taste in the face of what he is doing. I felt like an imposter.


Then he went on to talk about how we are all ants, but it is the combination of all our insignificant actions that eventually change the world. He talked about how the violence he sees is an intimate act: he talked about the connection between a sniper and their victim. We die one at a time; we can work to make things better one at a time.


He never othered or judged those committing violence. Not as he talked about his fellow doctor and friend who was shot, radioed that he could not breathe, and eventually died pinned down by gunfire so that no one could rescue him. Not as he talked about how he himself was shot. Not as he helped the audience connect with grief-stricken family members facing the death of their loved ones. He never withdrew compassion.


To me I heard hope that what I try to teach can matter; it can connect. If he can face that violence and take a stand against it while still maintaining compassion, then this stuff I believe actually can work. Facing the world and making real changes without giving up compassion and empathy seems more possible: I’ve seen it done.


Somewhere in this talk, I regained a connection with my own value. People like him are helping save people. However, the violence will continue until we have the love, empathy and compassion to understand and connect with each other and find better options. In my own way I’m doing that. Every time I help someone see a different way of looking at things, I make it easier for them to start with empathy first rather than fear.


Everything I’ve written about sex is still true. That journey can bring us closer to accepting ourselves, stepping past fear and shame. Once we accept our own desires and our own need, we’re in a better position to meet in the Strength of Love and advocate for our own needs while offering compassion to others. Once we know what we can find when we have empathy and connection, we can learn to strive for it.


So I will find joy in being my own little ant. Insignificant and divine: take your pick as it’s all the same in the end.


Bringing that Round to Debian


Debian is back in the center of my compassion work. I'm running for Debian project Leader (DPL). I served on the Debian Technical Committee for over a year, hoping to help bring understanding of diverse positions to our technical dispute resolution process. That ended up being the wrong place. Everyone seems to believe that the DPL is currently at the center of most of the work of helping people connect. I hope to fix that: more than one person should be driving that work.


After the keynote I found myself sitting between Micky Metts and Henry Poole. Micky asked me what I did that I loved. “Ah, she’s not expecting this answer,” I thought to myself as I talked about my spiritual work and how it overlaps with my Debian work. It turns out that she was delighted by the answer and we had a great time chatting about self empowerment. I’m looking forward to her keynote later today.


Then Henry asked how I was going to accomplish bringing empathy into Debian. I talked about my hopes and dreams and went through some of the specifics I’ve discussed in my platform and what I’ve had success with so far. He talked about similarities and overlaps with work his company does and how he works to teach people about free software.


Especially after that keynote it was joyful to sit between two luminaries and be able to share hopes for empathy, compassion and connection. I felt like I had found validation and energy again.

Dreaming of a Job to Promote Love, Empathy and sexual Freedom

Debianhas always been filled with people who want to make the world a better place. We consider the social implications of our actions. Many are involved in work that focuses on changing the world. I’ been hesitant to think too closely about how that applies to me: I fear being powerless to bring about the world in which I would like to live.

Recently though, I've been taking the time to dream. One day my wife came home and told another story of how she’d helped a client reduce their pain and regain mobility. I was envious. Every day she advances her calling and brings happiness into the world, typically by reducing physical suffering. What would it be like for me to find a job where I helped advance my calling and create a world where love could be more celebrated. That seems such a far cry from writing code and working on software design every day. But if I don’t articulate what I want, I'll never find it.

I’ve been working to start this journey by acknowledging the ways in which I already bring love into the world. One of the most important lessons of Venus’s path is that to bring love into the world, you have to start by leading a life of love. At work I do this by being part of a strong team. We’re there helping each other grow, whether it is people trying entirely new jobs or struggling to challenge each other and do the best work we can. We have each other’s back when things outside of work mean we're not at our best. We pitch in together when the big deadlines approach.

I do not shove my personal life or my love and spirituality work in people’s faces, but I do not hide it. I'm there as a symbol and reminder that different is OK. Because I am open people have turned to me in some unusual situations and I have been able to invite compassion and connection into how people thought about challenges they faced.

This is the most basic—most critical love work. In doing this I’m already succeeding at bringing love into the world. Sometimes it is hard to believe that. Recently I have been daring to dream of a job in which the technology I created also helped bring love into the world.

I'd love to find a company that's approaching the world in a love-positive, sex-positive manner. And of course they need to have IT challenges big enough to hire someone who is world class at networking, security and cloud architecture. While I'd be willing to take a pay cut for the right job, I'd still need to be making a US senior engineer's salary.

Actually saying that is really hard. I feel vulnerable because I’m being honest about what I want. Also, it feels like I’m asking for the impossible.

Yet, the day after I started talking about this on Facebook, OkCupid posted a job for a senior engineer. That particular job would require moving to New York, something I want to avoid. Still, it was reassuring as a reminder that asking for what you want is the first step.

I doubt that will be the only such job. It's reasonable to assume that as we embrace new technologies like blockchains and continue to appreciate what the evolving web platform standards have to offer, there will be new opportunities. Yes, a lot of the adult-focused industries are filled with corruption and companies that use those who they touch. However, there's also room for approaching intimacy in a way that celebrates desire, connection, and all the facets of love.

And yes, I do think sexuality and desire are an important part of how I’d like to promote love. With platforms like Facebook, Amazon and Google, it's easier than ever for people to express themselves, to connect, and if they are willing to give up privacy, to try and reach out and create. Yet all of these platforms have increasingly restrictive rules about adult content. Sometimes it’s not even intentional censorship. My first post about this topic on Facebook was marked as spam probably because some friends suggested some businesses that I might want to look at. Those businesses were adult-focused and apparently even positive discussion of such businesses is now enough to trigger a presumption of spam.

If we aren't careful, we're going to push sex further out of our view and add to an ever-higher wall of shame and fear. Those who wish to abuse and hurt will find their spaces, but if we aren't careful to create spaces where sex can be celebrated alongside love, those seedier corners of the Internet will be all that explores sexuality. Because I'm willing to face the challenge of exploring sexuality in a positive, open way, I think I should: few enough people are.

I have no idea what this sort of work might look like. Perhaps someone will take on the real challenge of creating content platforms that are more decentralized and that let people choose how they want content filtered. Perhaps technology can be used to improve the safety of sex workers or eventually to fight shame associated with sex work. Several people have pointed out the value of cloud platforms in allowing people to host whatever service they would choose. Right now I’m at the stage of asking for what I want. I know I will learn from the exploration and grow stronger by understanding what is possible. And if it turns out that filling my every day life with love is the answer I get, then I’ll take joy in that. Another one of the important Venus lessons is celebrating desires even when they cannot be achieved.

Shaving the DJ Software Yak

I'm getting married this June. (For the Debian folks, the Ghillie shirt and vest just arrived to go with the kilt. My thanks go out to the lunch table at Debconf that made that suggestion. formal Scottish dress would not have fit, but I wanted something to go with the kilt.)
Music and dance have been an important part of my spiritual journey. Dance has also been an import part of the best weddings I attended. So I wanted dance to be a special part of our celebration. I put together a play list for my 40th birthday; it was special and helped set the mood for the event. Unfortunately, as I started looking at what I wanted to play for the wedding, I realized I needed to do better. Some of the songs were too long. Some of them really felt like they needed a transition. I wanted a continuous mix not a play list.
I'm blind. I certainly could use two turn tables and a mixer--or at least I could learn how to do so. However, I'm a kid of the electronic generation, and that's not my style. So, I started looking at DJ software. With one exception, everything I found was too visual for me to use.
I've used Nama before to put together a mashup. It seemed like Nama offered almost everything I needed. Unfortunately, there were a couple of problems. Nama would not be a great fit for a live mix: you cannot add tracks or effects into the chain without restarting the engine. I didn't strictly need live production for this project, but I wanted to look at that long-term. At the time of my analysis, I thought that Nama didn't support tempo-scaling tracks. For that reason, I decided I was going to have to write my own software. Later I learned that you can adjust the sample rate on a track import, which is more or less good enough for tempo scaling. By that point I already had working code.
I wanted a command line interface. I wanted BPM and key detection; it looked like Mixxx was open-source software with good support for that. Based on my previous work, I chose Csound as the realtime sound backend.

Where I got


I'm proud of what I came up with. I managed to stay focused on my art rather than falling into the trap of focusing too much on the software. I got something that allows me to quickly explore the music I want to mix, but also managed to accomplish my goal and come up with a mix that I'm really happy with. As a result, at the current time, my software is probably only useful to me. However, it is available under the GPL V3. If anyone else would be interested in hacking on it, I'd be happy to spend some time documenting and working with them.
Here's a basic description of the approach.

  • You are editing a timeline that stores the transformations necessary to turn the input tracks into the output mix.
  • There are 10 mixer stereo channels that will be mixed down into a master output.
  • there are a unlimited number of input tracks. Each track is associated with a given mixer channel. Tracks are placed on the timeline at a given start point (starting from a given cue point in the track) and run for a given length. During this time, the track is mixed into the mixer channel. Associated with each track is a gain (volume) that controls how the track is mixed into the mixer channel. Volumes are constant per track.
  • Between the mixer channel and the master is a volume fader and an effect chain.
  • Effects are written in Csound code. Being able to easily write Csound effects is one of the things that made me more interested in writing my own than in looking at adding better tempo scaling/BPM detection to Nama.
  • Associated with each effect are three sliders that give inputs to the effect. Changing the number of mixer channels and effect sliders is an easy code change. However it'd be somewhat tricky to be able to change that dynamically during a performance. Effects also get an arbitrary number of constant parameters.
  • Sliders and volume faders can be manipulated on the timeline. You can ask for a linear change from the current value to a target over a given duration starting at some point. So I can ask for the amplitude to move from 0 to 127 at the point where I want to mix in a track say across 2 seconds. You express slider manipulation in terms of the global timeline. However it is stored relative to the start of the track. That is, if you have a track fade out at a particular musical phrase, the fade out will stay with that phrase even if you move the cue point of the track or move where the track starts on the timeline. This is not what you want all the time, but my experience with Nama (which does it using global time) suggests that I at least save a lot of time with this approach.
  • There is a global effect chain between the output of the final mixer and the master output. This allows you to apply distortion, equalization or compression to the mix as a whole. The sliders for effects on this effect chain are against global time not a specific track.
  • There's a hard-coded compressor on the final output. I'm lazy and I needed it before I had effect chains.

There's some preliminary support for a MIDI controller I was given, but I realized that coding that wasn't actually going to save me time, so I left it. This was a really fun project. I managed to tell a story for my wedding that is really important for me to tell. I learned a lot about what goes into putting together a mix. It's amazing how many decisions go into even simple things like a pan slider. It was also great that there is free software for me to build on top of. I got to focus on the part of the problem I wanted to solve. I was able to reuse components for the realtime sound work and for analysis like BPM detection.

Tools of Love

From my spiritual blog

I have been quiet lately. My life has been filled with gentle happiness, work, and less gentle wedding planning. How do you write about quiet happiness without sounding like the least contemplative aspects of Facebook? How do I share this part of the journey in a way that others can learn from? I was offering thanks the other day and was reminded of one of my early experiences at Fires of Venus. Someone was talking about how they were there working to do the spiritual work they needed in order to achieve their dream of opening a restaurant. I'll admit that when I thought of going to a multi-day retreat focused on spiritual connection to love, opening a restaurant had not been at the forefront of my mind. And yet, this was their dream, and surely dreams are the stuff of love. As they continued, they talked about finding self love deep enough to have the confidence to believe in dreams.



As I recalled this experience, I offered thanks for all the tools I've found to use as a lover. Every time I approach something with joy and awe, I gain new insight into the beauty of the world around us. In my work within the IETF I saw the beauty of the digital world we're working to create. Standing on sacred land, I can find the joy and love of nature and the moment.



I can share the joy I find and offer it to others. I've been mentoring someone at work. They're at a point where they're appreciating some of the great mysteries of computing like “Reflections on Trusting Trust” or two's compliment arithmetic. I’ve had the pleasure of watching their moments of discovery and also helping them understand the complex history in how we’ve built the digital world we have. Each moment of delight reinforces the idea that we live in a world where we expect to find this beauty and connect with it. Each experience reinforces the idea that we live in a world filled with things to love.



And so, I’ve turned even my experiences as a programmer into tools for teaching love and joy. I’ve been learning another new tool lately. I’ve been putting together the dance mix for my wedding. Between that and a project last year, I’ve learned a lot about music. I will never be a professional DJ or song producer. However, I have always found joy in music and dance, and I absolutely can be good enough to share that with my friends. I can be good enough to let music and rhythm be tools I use to tell stories and share joy. In learning skills and improving my ability with music, I better appreciate the music I hear.



The same is true with writing: both my work here and my fiction. I’m busy enough with other things that I am unlikely to even attempt writing as my livelihood. Even so, I have more tools for sharing the love I find and helping people find the love and joy in their world.



These are all just tools. Words and song won’t suddenly bring us all together any more than physical affection and our bodies. However, words, song, and the joy we find in each other and in the world we build can help us find connection and empathy. We can learn to see the love that is there between us. All these tools can help us be vulnerable and open together. And that—the changes we work within ourselves using these tools—can bring us to a path of love. And so how do I write about happiness? I give thanks for the things it allows me to explore. I find value in growing and trying new things. In my best moments, each seems a lens through which I can grow as a lover as I walk Venus’s path.


How Can Debian Turn Disagreement into Something that Makes us Stronger

Recently, when asked to engage with the Debian Technical Committee, a maintainer chose to orphan their package rather than discuss the issue brought before the committee. In another decision earlier this year, a maintainer orphaned their package indicating a lack of respect for the approach being taken and the process. Unfortunately, this joins an ever longer set of issues where people walk away from the TC process disheartened and upset.

For me personally the situations where maintainers walked away from the process were hard. People I respect and admire were telling me that they were unwilling to participate in our dispute resolution process. In one case the maintainer explicitly did not respect a process I had been heavily involved in. As someone who values understanding and build a team, I feel disappointed and hurt thinking about this.

Unfortunately, I don't feel much better when I consider several of the other issues brought before the TC. In a number of cases, the process has concluded, but it feels like a pyrrhic victory. We have an answer, but often we never reached an understanding of one of the key stakeholder's positions. People are sufficiently disappointed or frustrated that they reduce their involvement. That is, the answer is not one they can live with. Sometimes, I'm not even sure that answering the question was worth the cost.

My initial suspicion as I begin to consider issues that have come before the TC in the last few years is that as a necessary consequence of how the TC operates, we will drive a significant chunk of those who come to us away from our community. I will not be part of that. If I end up eventually agreeing with this suspicion, I will either work to improve the TC process or find a different way to contribute to the project that is more aligned with my goals.


Our Community is More Important than Technical Correctness

I firmly believe that Debian's strength is its community. Distributions, upstreams, free-software advocates, corporate interests, and everything in between work together. Because we are working on a concrete product,we actually have to understand how our needs conflict and compliment each other. Also, like any organization, our ability to get things done is dependent on our contributors and the time we all put in.

I cannot think of anything more harmful we can do than drive away a constructive contributor. Technical quality is important: many of us will eventually go away if quality drops too much. However, Debian itself can be improved incrementally. Yes, new people do join Debian. However, it takes a lot of new people to make up for a situation where everyone involved is frustrated, and some leave and tell their friends to stay away from Debian.

When a Disagreement Reaches the TC

When a disagreement reaches the TC, we know a few things. First, people have not have not been able to resolve it on their own. Second, the disagreement is important enough to at least one of the parties to ask for outside help.

If the TC were to simply announce a decision, it is very likely that at least one party would feel frustrated and disappointed. If the decision is important to someone it almost always means that they care about the outcome. If previous efforts have not reached agreement then there is an outcome that is undesired. While it's possible under the constitution that two parties could bring an issue to the TC mutually where the dynamics could be different, this does not happen in practice.

When we "lose"

When a decision making process decides to select one of my undesired outcomes, I have strong negative feelings. First, there is the technical result itself. Because of an adverse decision it is generally harder for me to do my technical work, or some ethical position or group I care about is disadvantaged. However, the strongest feelings are related to needs about my place in the community, not a direct response to the technical decision. I worry about whether issues I care about will be valued in the future; I would likely feel weary or scared thinking of contributing in an environment where issues that matter to me aren't going to be considered. I tend to feel frustrated if my position was not adequately considered this time around.

Often, the strongest feelings do not stem from how I am impacted by the decision itself. Thus, if my more general needs are addressed, I will feel a lot better about not having my preferred outcome selected. Confidence that my position was understood is the single biggest factor in being able to accept the result. If the community took the time to understand me, then I have confidence that I am valued. I can advocate for change and be part of the ongoing discussion. If I understand the other positions then I can understand that the position was not arbitrary. Understanding the other positions is also a prerequisite to seeing how things I value were considered, especially when the tradeoff did not ultimately favor these values.

My conversations with others about their experience with conflict suggest my feelings and needs are common.


However, the TC focuses almost exclusively on the technical matter before it. I don't think the TC has done a good job of actually understanding maintainers or the people bringing issues to us. Especially when we're fairly sure we understand what the ultimate decision will be, we focus on getting to that decision. Of course part of actually understanding someone is considering what they have to say. Even when you have high confidence in an outcome, if you want someone to feel understood, you do have to listen at a point where you can consider what they bring forward.

Frustration of Being Questioned



On the other side, it's frustrating to have your decisions questioned. Reviewing a decision takes time. Even if the TC agrees with a maintainer, asking that maintainer to sit through a long process can create frustrations as deep as any I discussed in the previous section.

So the process is doubly bad for maintainers. Someone can bring up an issue which requires precious time. Then if the TC decides against the maintainer, we have all the problems I discussed previously.

I acknowledge this. A good process must respect the maintainer's time. However, it must respect the community members who disagree with maintainers. Everyone who brings an issue to the TC is a developer. They have contributed significantly to our community and are part of our team. Yes, we need to protect the process against abuse. But in a very real sense if we aren't willing to consider an issue and we aren't willing to engage with someone, understand why they think the issue should be considered, and work until they understand why we made our decision, we are saying we do not respect them enough to take that time. We should expect that to drive people away.

I wonder if the solution here involves a two phase process. During the first phase we work with someone bringing an issue to us until we understand it. We either engage the maintainer at that point, spend the time to help the person bringing an issue to us understand why we are not engaging the maintainer, or have decided the issue is abusive of the processs/misdirected. For this to work maintainers would have to trust us enough to actually be willing to sit back and not spend a lot of their time.

Sam, It's Just Personalities



One criticism I've heard as I discuss this is that a lot of the negative feelings surround interpersonal conflict and are personality conflicts. Yes, personalities matter. Yes, we’re still healing from the Systemd discussion.

However, as a community, I think we need to figure out how we respect the inevitable personality conflicts. I can think of one or two developers I'm still upset with years after an issue. It happens. Perhaps if I were a maintainer when one of these developers raised a concern with my packages, I could ask that someone else be a primary advocate for an issue. Similarly, if a developer wanted to address an issue with me as a maintainer but would prefer not to deal with me, perhaps we could figure out some way that we could see if someone else shared the concern.

Dropping a Package is Sometimes an Answer



My concerns were sparked by instances where a maintainer dropped a package rather than interact with the TC. Sometimes that can be a healthy step in a transition. At Debconf this year, Enrico Zini gave a talk on consent culture in Debian. One of the key points of his talk is that we can find over time that what we're being asked to do in Debian is no longer consistent with our boundaries. If it isn’t helping us move forward—if it isn’t fun—then it is likely time to stop.

In that sense, approaching disagreement can be a great time to take stock and ask whether we still enjoy maintaining a package. If we don’t, then stepping aside and letting others take it on can be a great way that we and they can be happier. I don’t really think that’s what happened in these instances though. Based on comments made to me, this sounded more like a lack of faith in being treated well or in our ability as a committee.

Even so, Enrico’s talk applies in a number of ways here. He suggests that the approach we should take when someone is done and steps away is to thank then. I couldn’t agree more. From the depth of my heart I offer thanks: “Thank you for taking care of yourself and stepping away when it is no longer fun. Thank you for all the effort you have put into these packages. I hope to work with you on great things in the future.”
  • Current Mood
    sad sad
  • Tags