Gunnar Wolf: Talking about the Debian keyring in Investigaciones Nucleares, UNAM
For the readers of my blog that happen to be in Mexico City, I was invited to give a talk at Instituto de Ciencias Nucleares, Ciudad Universitaria, UNAM.
I will be at Auditorio Marcos Moshinsky, on August 26 starting at 13:00. Auditorio Marcos Moshinsky is where we met for the early (~1996-1997) Mexico Linux User Group meetings. And... Wow. I'm amazed to realize it's been twenty years that I arrived there, young and innocent, the newest of what looked like a sect obsessed with world domination and a penguin fetish.
| Attachment | Size |
|---|---|
| llavero_chico.png | 220.84 KB |
| llavero_orig.png | 1.64 MB |
Like 
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
Tonight 
When it rains in Tucson, people are able to take an unusually carefree
attitude towards it. Although the storm is dramatic, and the amount of
water means that the streets turn to rivers, everyone knows that it
will be over in a few hours and the heat will return (and indeed,
that s why drain provision is so paltry).
In other words, despite the arresting thunderclaps, the weather is not
threatening. By contrast, when there is a storm in Britain, one feels
a faint primordial fear that one won t be able to find shelter
after the storm, in the cold and sodden woods and fields. Here, that
threat just isn t present. I think that s what makes us feel so free
to move around in the rain.
I rode my bike back from the gym in my $5 plastic shoes. The rain
hitting my body was cold, but the water splashing up my legs and feet
was warm thanks of the surface of the road except for one area where
the road was steep enough that the running water had already taken
away all lingering heat.
I was assigned another 14.7 hours of work by Freexian's Debian LTS
initiative and carried over 1 from last month. I worked a total of
15 hours, carrying over a fraction of an hour.
I spent another week in the Front Desk role and triaged various new
CVEs for wheezy.
I spent the remainder of the time working on the next Linux stable
updates (3.2.82 and Debian 3.2.81-2), but didn't release them - that
will be done in the next few days.
Happy Independence Day to all. I had been looking forward to this day so I can use to share with my brothers and sisters what little I know about TOR . Independence means so many things to many people. For me, it means having freedom, valuing it and using it to benefit not just to ourselves but to people at large. And for that to happen, at least on the web, it has to rise above censorship if we are to get there at all. I am 40 years old, and if I can t read whatever I want to read without asking the state-military-Corporate trinity than be damned with that. Debconf was instrumental as I was able to understand and share many of the privacy concerns that we all have. This blog post is partly a tribute to being part of a community and being part of Debconf16.
So, in that search for privacy couple of years ago, I came across TOR . TOR stands for The Onion Router project. Explaining tor is simple. Let us take the standard way in which we approach the website using a browser or any other means.
a. We type out a site name, say debian.org in the URL/URI bar .
There are various motivations for doing that. For myself, I m just a private person and do not need or want that any other person/s or even the State should be looking over my shoulder as to what I m doing. And the argument that we need to spy on citizens because Terrorists are there doesn t hold water over me. There are many ways in which they can pass messages even without tor or web. The Government-Corporate-Military just get more powerful if and when they know what common people think, do, eat etc.
So the question is how does you install tor if you a private sort of person . If you are on a Debian machine, you are one step closer to doing that.
So the first thing that you need to do is install the following
A while back, I found myself in need of some TLS certificates set up and issued for a testing environment.
I remembered there was some code for issuing TLS certs in Docker, so I yanked some of that code and made a sensable CLI API over it.
Thus was born 
At some point back when the dinosaurs roamed the Earth and I was in
high school, I borrowed my first digital signal processing book from a friend.
I later went on to an engineering education and master's thesis about DSP,
but the very basics of DSP never stop to fascinate me. Today, I wanted to
write something about one of them and how it affects audio processing in
Nageru (and finally, how Debian's policies put me in a bit of a bind on
this issue).
DSP texts tend to obscure profound truths with large amounts of maths,
so I'll try to present a somewhat less general result that doesn't require
going into the mathematical details. That rule is:
Adding a signal to weighted, delayed copies of itself is a filtering operation.
(It's simple, but ignoring it will have sinister effects, as we'll see later.)
Let's see exactly what that means with a motivating example. Let's say that
I have a signal where I want to get rid of (or rather, reduce) high frequencies.
The simplest way I can think of is to add every neighboring sample; that is,
set yn = xn + xn-1. For each sample, we
add the previous sample, ie., the signal as it was one sample ago.
(We ignore what happens at the edges; the common
convention is to assume signals extend out to infinity with zeros.)
What effect will this have? We can figure it out with some trigonometry,
but let's just demonstrate it by plotting instead: We assume 48 kHz sample rate
(which means that our one-sample delay is 20.83 s) and a 22 kHz
note (definitely treble!), and plot the signal with one-sample delay
(the x axis is sample number):
As you can see, the resulting signal is a new signal of the same frequency
(which is always true; linear filtering can never create new frequencies,
just boost or dampen existing ones), but with much lower amplitude.
The signal and the delayed version of it end up cancelling each other mostly
out. Also note that there signal has changed phase; the resulting signal
has been a bit delayed compared to the original.
Now let's look at a 50 Hz signal (turn on your bass face). We need to zoom out a bit to see
full 50 Hz cycles:
The original signal and the delayed one overlap almost exactly! For a lower
frequency, the one-sample delay means almost nothing (since the waveform is
varying so slowly), and thus, in this case, the resulting signal is amplified,
not dampened. (The signal has changed phase here, too actually exactly as much
in terms of real time but we don't really see it, because we've zoomed out.)
Real signals are not pure sines, but they can be seen as sums of many sines
(another fundamental DSP result), and since filtering is a linear operation,
it affects those sines independently. In other words, we now have a very
simple filter that will amplify low frequencies and dampen high frequencies
(and delay the entire signal a little bit). We can do this for all
frequencies from 0 to 24000 Hz; let's ask Octave to do it for us:
(Of course, in a real filter, we'd probably multiply the result with 0.5
to leave the bass untouched instead of boosting it, but it doesn't really
change anything. A real filter would have a lot more coefficients, though,
and they wouldn't all be the same!)
Let's now turn to a problem that will at first seem different: Combining
audio from multiple different time sources. For instance, when mixing video,
you could have input from two different cameras or sounds card and would want
to combine them (say, a source playing music and then some audience sound
from a camera). However, unless you are lucky enough to have a professional-grade setup
where everything runs off the same clock (and separate clock source cables
run to every device), they won't be in sync; sample clocks are good, but they are
not perfect, and they have e.g. some temperature variance. Say we have really
good clocks and they only differ by 0.01%; this means that after an hour of
streaming, we have 360 ms delay, completely ruining lip sync!
This means we'll need to resample at least one of the sources to match the
other; that is, play one of them faster or slower than it came in originally.
There are two problems here: How do you determine how much to resample
the signals, and how do we resample them?
The former is a difficult problem in its own right; about every algorithm
not backed in solid control theory
is doomed to fail in one way or another, and when they fail, it's extremely
annoying to listen to. Nageru follows 
One criminally-unknown new UNIX tool is 
There s a 
Please note that the environment it runs on is deployment . The backend server it uses is the great Starman, also by the great Miyagawa.
Now, if you add or change dependencies on Makefile.PL, next time you push, those will get updated.
Very cool, right? :)
(Some) people seem to be anxious to know what I m doing next, and my answer is, go mind your own fucking business. However, life is short and I would love to do any of the following:
