Three moments from earlier this week..
Sprawled under a tree after three hours of hiking with a heavy,
water-filled pack, I look past my feet at six ranges of mountains behind
mountains behind flowers.
From my campsite, I can see the rest of the path of the Appalachian Trail
across the Roan balds, to Big Hump mountain. It seems close enough to
touch, but not this trip. Good to have a goal.
Near sunset, land and sky merge as the mist moves in.
pytest.xfail over assert False.0.023-1 was uploaded by Chris Lamb:
* Support Android .apk files with the JAR normalizer.
* handlers/png.pm: Drop unused Archive::Zip import
* Remove hyphen from non-determinism and non-deterministic.
* javaproperties.pm: Match more styles of .properties and loosen filename matching.
* Improve tests:
- Make fixture runner generic to all normalizer types.
- Replace (single) pearregistry test with a fixture.
- Set a canonical time for fixture tests.
- Add gzip testcase fixture.
- Replace t/javadoc.t with fixture
- Replace t/ar.t with a fixture.
- t/javaproperties: move pom.properties and version.properties tests to fixtures
- t/fixtures.t: move to using subtests
- t/fixtures.t: Explicitly test that we can find a normalizer
- t/fixtures.t: Don't run normalizer if we didn't find one.
0.023-2 uploaded by Mattia Rizzolo to allow stderr in autopkgtest.
disorderfs development
#debian-qa IRC channel, to discuss current issues with the setup and to start the work of migrating jenkins.debian.net to jenkins.debian.org. The next meeting will take place on September 28th 2016 at 19 UTC.
Misc.
This week's edition was written by Chris Lamb and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.
During this year s ESSLLI (European Summer School in Logic, Language and Information) I was teaching a course on Algebraic Specification and Verification with CafeOBJ. Now that the course is over I can relax a bit and enjoy the beauty of the surrounding North Tyrol.
For those who couldn t attend the ESSLLI or the course, here are the course materials:
.buildinfo feature. This project is a part of Reproducible Builds effort
Mentor and Co-Mentor
#debian-reproducible.https://tests.reproducible-builds.org/debian/reproducible.html. Based on the work done, I came up with specification called Hide Profile for allowing diffoscope to hide different profiles.
Link to the specification:
Later, I started to work on wish-list feature bug #826711.
Links to commits:
Ignoring .buildinfo file while comparing .changes files use case.
Hide Profiles Specification.Coding Period make diffoscope better and enhance ignoring capabilities of diffoscope.exsting bugs.
$ LD=afl-gcc CC=afl-gcc AFL_HARDEN=1 make VARIANT=debug test
afl-cc 2.32b by <lcamtuf@google.com>
afl-cc 2.32b by <lcamtuf@google.com>
COMPILE: src/libnsbmp.c
afl-cc 2.32b by <lcamtuf@google.com>
afl-as 2.32b by <lcamtuf@google.com>
[+] Instrumented 751 locations (64-bit, hardened mode, ratio 100%).
AR: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/libnsbmp.a
COMPILE: test/decode_bmp.c
afl-cc 2.32b by <lcamtuf@google.com>
afl-as 2.32b by <lcamtuf@google.com>
[+] Instrumented 52 locations (64-bit, hardened mode, ratio 100%).
LINK: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp
afl-cc 2.32b by <lcamtuf@google.com>
COMPILE: test/decode_ico.c
afl-cc 2.32b by <lcamtuf@google.com>
afl-as 2.32b by <lcamtuf@google.com>
[+] Instrumented 65 locations (64-bit, hardened mode, ratio 100%).
LINK: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_ico
afl-cc 2.32b by <lcamtuf@google.com>
Test bitmap decode
Tests:606 Pass:606 Error:0
Test icon decode
Tests:392 Pass:392 Error:0
TEST: Testing complete
afl-fuzz -i test/bmp -o findings_dir -- ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null
$ afl-whatsup sync_dir/
Summary stats
=============
Fuzzers alive : 19
Total run time : 5 days, 12 hours
Total execs : 214 million
Cumulative speed : 8317 execs/sec
Pending paths : 0 faves, 542 total
Pending per fuzzer : 0 faves, 28 total (on average)
Crashes found : 554 locally unique
if ((width <= 0) (height == 0))
return BMP_DATA_ERROR;
if (height < 0)
bmp->reversed = true;
height = -height;
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 a 2012 paper by Fons Adriaensen;
GStreamer does well, something else. It fails pretty badly in a number of
cases; see e.g. this 2015 master's thesis
that tries to patch it up. However, let's ignore this part of the problem
for now and focus on the resampling.
So let's look at the case where we've determined we have a signal and need to
play it 0.01% faster (or slower); in a real situation, this number would vary
a bit (clocks are not even consistently wrong). This means that at some point,
we want to output sample number 3000 and that corresponds to input sample
number 3000.3, ie., we need to figure out what's between two input samples.
As with so many other things, there's a way to do this that's simple, obvious
and wrong, namely linear interpolation.
The basis of linear interpolation is to look at the two neighboring samples
and weigh them according to the position we want. If we need sample 3000.3,
we calculate y = 0.7 x3000 + 0.3 x3001 (don't switch
the two coefficients!), or, if we want to save one multiplication and get
better numerical behavior, we can use the equivalent
y = x3000 + 0.3 (x3001 - x3000).
And if we need sample 5000.5, we take y = 0.5 x5000 + 0.5 x5001. And after a while, we'll be back on integer samples; output sample
10001 corresponds to x10000 exactly.
By now, I guess it should be obvious what's going on: We're creating a filter!
Linear interpolation will inevitably result in high frequencies being
dampened; and even worse, we are creating a time-varying filter, which means
that the amount of dampening will vary over time. This manifests itself as
a kind of high-frequency flutter , where the amount of flutter depends on
the relative resampling frequencies. There's also cubic resampling (which
can mean any of several different algorithms), but it only really reduces
the problem, it doesn't really solve it.
The proper way of interpolating depends a lot on exactly what you want
(e.g., whether you intend to change the rate quickly or not);
this paper
lays out a bunch of them, and was the paper that originally made me understand
why linear interpolation is so bad. Nageru outsources this problem to
zita-resampler,
again by Fons Adriaensen; it yields extremely high-quality resampling
under controlled delay, through a relatively common technique known as
polyphase filters.
Unfortunately, doing this kind of calculations takes CPU. Not a lot of CPU,
but Nageru runs in rather CPU-challenged environments (ultraportable laptops
where the GPU wants most of the TDP, and the CPU has to go down to the
lowest frequency), and it is moving in a direction where it needs to resample
many more channels (more on the later), so every bit of CPU helps. So I coded
up an SSE optimization of the inner loop for a particular common case
(stereo signals) and sent it in for upstream inclusion. (It made the
code 2.7 times as fast without any structural changes or reducing precision,
which is pretty much what you can expect from SSE.)
Unfortunately, after a productive discussion, suddenly upstream went silent.
I tried pinging, pinging again, and after half a year pinging again, but to
no avail. I filed the patch in Debian's BTS,
but the maintainer understandably is reluctant to carry a delta against upstream.
I also can't embed a copy; Debian policy would dictate that I build against
the system's zita-resampler. I could work around it by
rewriting zita-resampler until it looks nothing like the original, which
might be a good idea anyway if I wanted to squeeze out the last drops of speed;
there are AVX optimizations to be had in addition to SSE, and the structure
as-is isn't ideal for SSE optimizations (although some of the changes I have
in mind would have to be offset against increased L1 cache footprint,
so careful benchmarking would be needed). But in a sense, it feels like just
working around a policy that's there for good reason. So like I said, I'm
in a bit of a bind. Maybe I should just buy a faster laptop.
Oh, and how does GStreamer solve this? Well, it doesn't use linear interpolation.
It does something even worse it uses nearest neighbor. Gah.
Update: I was asked to clarify that this is about the audio resampling done
by the GStreamer audio sink to sync signals, not in the audioresample element, which solves
a related but different problem (static sample rate conversion).
The audioresample element supports a number of different resampling methods;
I haven't evaluated them.
This is something that is specified clearly on the Nginx manual, but it s nice to have it as a quick reference.
The access_log and error_log directives on Nginx are on separate modules (HTTP Log and Core modules respectively) and they don t behave the same way when all you want is to disable all logging on your server (in our case, we serve a gazillion static files and perform a lot of reverse proxying and we re not interested on tracking that). It s a common misconception that you can set error_log to off, because that s how you disable access_log (if you do that, the server will still log to the file $nginx_path/off). Instead, you have to set error_log to log to the always mighty black hole /dev/null using the highest level for logging (which triggers the fewest events), crit:
http
server
# ...
access_log off;
error_log /dev/null crit;
# ...
#...
error_log on the root of the configuration and access_log within your http block and make sure you don t override that on any of the inner blocks. And you re good to go.
Geo::PostalCode is a great Perl module. It lets you find surrounding postal areas (zip codes) around a given an amount of miles (radius), calculate distance between them, among other nice features. Sadly, I couldn t get it to work with updated data and because the file its Berkely DB installer was producing was not being recognized by its parser, which bases off on DB_File. Since I was able to find working data for the source of zip codes, I ended up hacking the module and producing a version with no Berkeley DB support.
So basically, and taken from the POD:
RATIONALE BEHIND NO BERKELEY DB$ sudo cpanm Geo::PostalCode::NoDB now!
On a busy day at work, I couldn t get Geo::PostalCode to work with newer data (the data source TJMATHER points to is no longer available), so the tests shipped with his module pass, but trying to use real data no longer seems to work. DB_File marked the Geo::PostalCode::InstallDB output file as invalid type or format. If you don t run into that issue by not wanting to use this module, please drop me a note! I would love to learn how other people made it work.
So, in order to get my shit done, I decided to create this module. Loading the whole data into memory from the class constructor has been proven to be enough for massive usage (citation needed) on a Dancer application where this module is instantiated only once.
Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian.
Debian Android
A book that goes further behind the walls that surround North Korea than anything else I have seen. Suki Kim managed to squeeze herself, American-Korean, into a English teaching job at the Pyongyang University of Science and Technology, and reports her experiences during two visits there.
Most of us in the connected world are well aware about the incredibly backwardness of North Korea, and the harsh living conditions despite the praise that is bombarded onto us through the official channels. But reading about the incredibly underdeveloped students at PUST, Pyongyang University of Science and Technology, the elite of the country, who never heard about the most basic techniques, is still surprising.
Time there seemed to pass differently. When you are shut off from the world, every day is exactly the same as the one before. This sameness has a way of wearing down your soul until you become nothing but a breathing, toiling, consuming thing that awakes to the sun and sleeps at the dawning of the dark.Another very disturbing part of this book are the short but intensive looks into the country side, when excursions or shopping trips were scheduled. They lay open a barren land, with Gulag like working conditions and permanent shortage of proper food. I have been aware about the situation in North Korea, but reading about it from a very special perspective gave me the shivers.
UsePAM yes ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactiveThis forces all authentication to pass two verification methods in ssh: publickey and keyboard-interactive. All users will have to supply a public key and then also pass keyboard-interactive auth. Normally keyboard-interactive auth prompts for a password, but we can change /etc/pam.d/sshd on this. I added this line at the very top of /etc/pam.d/sshd:
auth [success=done new_authtok_reqd=done ignore=ignore default=bad] pam_google_authenticator.soThis basically makes Google Authenticator both necessary and sufficient for keyboard-interactive in ssh. That is, whenever the system wants to use keyboard-interactive, rather than prompt for a password, it instead prompts for a token. Note that any user that has not set up google-authenticator already will be completely unable to ssh into their account. Enhancement 1, variant 2: Allowing automated processes to root On many of my systems, I have ~root/.ssh/authorized_keys set up to permit certain systems to run locked-down commands for things like backups. These are automated commands, and the above configuration will break them because I m not going to be typing in codes at 3AM. If you are very restrictive about what you put in root s authorized_keys, you can exempt the root user from the 2FA requirement in ssh by adding this to sshd_config:
Match User root AuthenticationMethods publickeyThis says that the only way to access the root account via ssh is to use the authorized_keys file, and no 2FA will be required in this scenario. Enhancement 1, variant 2: Allowing non-pubkey auth On some multiuser systems, some users may still want to use password auth rather than publickey auth. There are a few ways we can support that:
AuthenticationMethods publickey,keyboard-interactive keyboard-interactiveThis means that to authenticate, you need to pass either publickey and then keyboard-interactive auth, or just keyboard-interactive auth. Then in /etc/pam.d/sshd, you put this:
auth required pam_google_authenticator.soAs a sub-variant for option 1, you can add nullok to here to permit auth from people that do not have a Google Authenticator configuration. Or for option 2, change required to sufficient . You should not add nullok in combination with sufficient, because that could let people without a Google Authenticator config authenticate completely without a password at all. Enhancement 2: Configuring su A lot of other tutorials stop with ssh (and maybe gdm) but forget about the other ways we authenticate or change users on a system. su and sudo are the two most important ones. If your root password is compromised, you don t want anybody to be able to su to that account without having to supply a token. So you can set up google-authenticator for root. Then, edit /etc/pam.d/su and insert this line after the pam_rootok.so line:
auth required pam_google_authenticator.so nullokThe reason you put this after pam_rootok.so is because you want to be able to su from root to any account without having to input a token. We add nullok to the end of this, because you may want to su to accounts that don t have tokens. Just make sure to configure tokens for the root account first. Enhancement 3: Configuring sudo This one is similar to su, but a little different. This lets you, say, secure the root password for sudo. Normally, you might sudo from your user account to root (if so configured). You might have sudo configured to require you to enter in your own password (rather than root s), or to just permit you to do whatever you want as root without a password. Our first step, as always, is to configure PAM. What we do here depends on your desired behavior: do you want to require someone to supply both a password and a token, or just a token, or require a token? If you want to require a token, put this at the top of /etc/pam.d/sudo:
auth [success=done new_authtok_reqd=done ignore=ignore default=bad] pam_google_authenticator.soIf you want to require a token and a password, change the bracketed string to required , and if you want a token or a password, change it to sufficient . As before, if you want to permit people without a configured token to proceed, add nullok , but do not use that with sufficient or the bracketed example here. Now here comes the fun part. By default, if a user is required to supply a password to sudo, they are required to supply their own password. That does not help us here, because a user logged in to the system can read the ~/.google_authenticator file and easily then supply tokens for themselves. What you want to do is require them to supply root s password. Here s how I set that up in sudoers:
Defaults:jgoerzen rootpw jgoerzen ALL=(ALL) ALLSo now, with the combination of this and the PAM configuration above, I can sudo to the root user without knowing its password but only if I can supply root s token. Pretty slick, eh? Further reading In addition to the basic tutorials referenced above, consider:
For a few years I did not attempt any serious task on the Amazon cloud. It
took me a bit of time to get back my automatisms and adapt myself to the
changes. In particular, the cheapest instances, t2.nano, are only
accessible via virtual private clouds (VPC), and it was a bit difficult for
me to find how to create a simple one. Perhaps this is because all AWS
accounts created after March 18, 2013, automatically have a default VPC, and
everybody else who needed their own simple VPC have created it a long time
ago already. In the end, this was not complicated at all. This is probably
why I could not find a tutorial.
In brief, one needs first to create a VPC. If it is just for spawning an
instance from time to time, the IP range does not matter much. Default VPCs
are using 172.31.0.0/16, so let's do the same.
CIDR_BLOCK=172.31.0.0/16
aws ec2 create-vpc --cidr-block $CIDR_BLOCK
VPC. The same pattern will be repeated for each
command creating something. One can also find the VPC's identifier with the
command aws ec2 describe-vpcs.
VPC=vpc-XXXXXXXX
SUBNET. In order that the instances receive a public IP
address like in default VPCs and like in the usual behaviour of the VPC-less
Cloud, one needs to set the attribute MapPublicIpOnLaunch.
aws ec2 create-subnet --vpc-id $VPC --cidr-block $CIDR_BLOCK
SUBNET=subnet-XXXXXXXX
aws ec2 modify-subnet-attribute --subnet-id $SUBNET --map-public-ip-on-launch
GATEWAY) and attach it to
the VPC.
aws ec2 create-internet-gateway
GATEWAY=igw-XXXXXXXX
aws ec2 attach-internet-gateway --internet-gateway-id $GATEWAY --vpc-id $VPC
describe-route-tables. Then, create a default route to
the gateway.
aws ec2 describe-route-tables
ROUTETABLE=rtb-XXXXXXXX
aws ec2 create-route --route-table-id $ROUTETABLE --destination-cidr-block 0.0.0.0/0 --gateway-id $GATEWAY
aws ec2 describe-security-groups
SECURITY_GROUP=sg-XXXXXXXX
aws ec2 authorize-security-group-ingress --group-id $SECURITY_GROUP --protocol tcp --port 22 --cidr 0.0.0.0/0
This is a repost and update of my retirement letter sent privately to Debian last month, July 10, 2016. At that time I received many notes of appreciation and good wishes which I treasure. Now, I d like to say goodbye to the broader Debian community and, as well, indicate which of the cleanup items have since been addressed in strikethrough style and with annotations. Also, I d like to stay in touch with many of you, so I have added some comments oriented towards those of you who are interested in doing that after the letter.
When in 1995, on a tip from a friend, I installed Debian on my 386 at work and was enthralled with the results, I could not have foreseen that two years later, friends I had made on channel #debian would nudge me to become a Debian developer. Nor when that happened did I have any idea that twenty years later, I d consider Debian to be like family, the greatest free software community in the world, and would still be promoting it and helping people with it whenever I could. Debian quietly, unexpectedly became a part of what defines me. My priorities in life have changed over that time, though. I have shifted my attention to things that are more important to me in life, such as my family, my health and well-being physically and spiritually, and bringing all I can to bear on the task of preserving our local wilderness areas and trails. In the latter area, I m now bringing all of what Debian has helped shaped me to be to the table, launching some ambitious projects I hope will bear fruit in the coming years, and make a measurable contribution to help us hang onto our precious natural preserves where I live. Unfortunately, as I ve poured more time and energy into these things, I ve increasingly not been giving my packages the care they need. Nor do I have any roles or goals now for any of the Debian projects I was previously involved in. So, after much careful deliberation, and as much as it pains me to say it, it s time to retire as a Debian developer. It has been a great privilege to work with you, and to meet many of you in New York at Debconf 10. I plan to be around online, and will continue to take an interest in Debian, lending a hand when I can. Thanks for all of the fun times, for all that I ve learned, and for the privilege to make awesome things with you. I ll treasure this forever. So much for the soppy bits.Now, business. These things remain to clean up upon my departure, and I d appreciate help from QA, and anyone else who can lend a hand. My packages are effectively orphaned, but I haven t the time to do any of the cleanup myself, so please speak up if you can help.
There are also some Alioth projects / lists that are defunct that I ll need to talk to the Alioth admins about cleaning up in the coming days. One of these is <debian-eeepc-devel@lists.alioth.debian.org> and since it is still listed as the maintainer of eeepc-acpi-scripts, that needs to be sorted out before the list can be closed. Thanks again, and see you around!
- Debian Jr.
- O: junior-doc. The junior-doc package has been awaiting an overhaul by whoever revives the project since I gave it up years ago. I m still listed as maintainer and that should be changed to Debian Junior Maintainers <debianjr-maintainers@lists.alioth.debian.org> if they want it. Otherwise, it is orphaned.
I should also be dropped from Uploaders from debian-junior, the metapackages source.Fixed in git.- Tux Paint. This is a very special package that deserves to go to someone who will love it and care for it well. There are three source packages in all:
- O: tuxpaint
- O: tuxpaint-config
- O: tuxpaint-stamps
- O: xletters. This is a cute little typing practice game and needs a new maintainer.
XPilot is co-maintained by Phil Brooke <pjb@debian.org>, so he should replace me as Maintainer.Phil said he ll pick up xpilot-ng and will also look at xpilot-extra.
xpilot-ngO: xpilot-extra (recently removed from testing due to my neglect, and not co-maintained by Phil; it s unclear if anyone really uses this anymore)- GTypist is co-maintained by Daniel Leidert <dleidert@debian.org> and should replace me as Maintainer.
My ruby packages. A group of packages that I brought into Debian as dependencies of taskwarrior-web, which I never completed. Maybe they ll be useful in and of themselves, and maybe not. In any case, they are maintained by pkg-ruby-extras-maintainers, but I m the sole developer in Uploaders and should be removed:Fixed in git.
ruby-blockenspielruby-parseconfigruby-rack-flash3ruby-simple-navigationruby-sinatra-simple-navigationruby-term-ansicolorruby-versionomyDebian Live stuff: I am listed in Uploaders for live-manual(fixed in git)and debian-installer-launcher(fixed in git)and need to be removed.- O: eeepc-acpi-scripts. The defunct Debian EeePC project has just this one package. Recently, the mailing list was asked about its status, and it was recently NMU d. To my knowledge, nobody from the original team remains to take care of it, so it needs a new maintainer. I should be removed from Uploaders, and since the Debian Eee PC Team no longer exists, it should be removed as maintainer. It is effectively orphaned unless someone speaks up.
Ben
User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup. User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.Most of the use cases mentioned here are achievable with Containers today. The big difference UML provides in, is with a separate kernel. UML is an implementation of Linux as an architecture of Linux itself. It supports x86 and x86_64 architecture. And given that it is the port of the kernel, you can do many of the tests and experiments of the regular kernel, safely inside a confined UML environment. As with other virtualization implementations, the limitation comes in if you are working on physical hardware. With its re-entry in Debian, I wanted to revive my local setup. First is the packaging structure and the second is its integration with current standard tools
rrs@learner:~/tidBits (master)$ cat /etc/systemd/network/tap.netdev [NetDev] Name=tap0 Kind=tap [TAP] Group=uml-net User=uml-net 2016-08-01 / 15:41:40 rrs@learner:~/tidBits (master)$ cat /etc/systemd/network/tap.network [Match] Name=tap0 [Network] DHCPServer=yes IPForward=yes IPMasquerade=yes Address=172.16.20.2 LLMNR=yes MulticastDNS=yes DNS=172.16.20.1 2016-08-01 / 15:41:43
systemd allows for defining user/group ownership in its file. With this setup, and uml-utilities running, one can simply fire a UML instance as below:
rrs@learner:~/rrs-home/Community/Packaging/user-mode-linux (master)$ linux ubd0=~/rrs-home/NoTrack/uml.img eth0=daemon mem=1024M rw
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Adding 23609344 bytes to physical memory to account for exec-shield gap
Linux version 4.6.3 (root@chutzpah) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #2 Sat Jul 16 16:22:22 UTC 2016
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 263721
Kernel command line: ubd0=/home/rrs/rrs-home/NoTrack/uml.img eth0=daemon mem=1024M rw root=98:0
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1020852K/1071632K available (4803K kernel code, 1207K rwdata, 1340K rodata, 157K init, 217K bss, 50780K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:15
.....snipped.......
root@uml:~# cat /proc/cpuinfo
processor : 0
vendor_id : User Mode Linux
model name : UML
mode : skas
host : Linux learner 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
bogomips : 6048.97
root@uml:~# ping www.debian.org
PING www.debian.org (130.89.148.14) 56(84) bytes of data.
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_seq=1 ttl=46 time=372 ms
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_seq=2 ttl=46 time=395 ms
64 bytes from klecker4.snt.utwente.nl (130.89.148.14): icmp_seq=3 ttl=46 time=315 ms
^C
--- www.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 315.550/361.064/395.440/33.556 ms
And here are some (incomplete and non-conclusive) performance numbers
root@uml:~# dd if=/dev/zero of=foo.img bs=1M count=2500 conv=fsync 2500+0 records in 2500+0 records out 2621440000 bytes (2.6 GB, 2.4 GiB) copied, 39.4876 s, 66.4 MB/s vs rrs@learner:/var/tmp/Debian-Build/Result$ dd if=/dev/zero of=foo.img bs=1M count=2500 conv=fsync 2500+0 records in 2500+0 records out 2621440000 bytes (2.6 GB, 2.4 GiB) copied, 41.2126 s, 63.6 MB/s 2016-08-01 / 15:59:15
Talks have been finished, and as a special present to the participants, Pavneet has organized an excursion that probably was one of the best I ever had. First we visited the Toronto Reference Library where we were treated to a delicious collection of rare books (not to mention all the other books and architecture), and then a trip through the Ismaili Centre Toronto and the Aga Khan Museum.
During the ceremony, Pavneet also announced the winners of the TUG 2016 fountain pen auction. These pens have a long history/travel behind them, see details on the linked page, and were presented to the special guests of the conference. Two remaining pens were auctioned with funds going to the TUG. The first one was handed over to Steve Grathwohl, and to my utter surprise the second one to myself. So now I am a happy owner of a TUG 2016 fountain pen. What a special feature!
Just one more detail about these pens: They are traditional style, so without ink capsules, but one needs to insert the ink with a syringe. I guess I need to stack up a bit at home, and more importantly, train my really ugly hand-writing, otherwise it would be a shame to use this exquisite tool.
We returned to the harbor around 10pm, and back to the hotel, where there was much greeting and thanking, as many people will return the following day.
I have a long overdue blog entry about what happened in recent times. People that follow my tweets did catch some things. Most noteworthy there was the Trans*Inter*Congress in Munich at the start of May. It was an absolute blast. I met so many nice and great people, talked and experienced so many great things there that I'm still having a great motivational push from it every time I think back. It was also the time when I realized that I in fact do have body dysphoria even though I thought I'm fine with my body in general: Being tall is a huge issue for me. Realizing that I have a huge issue (yes, pun intended) with my length was quite relieving, even though it doesn't make it go away. It's something that makes passing and transitioning for me harder. I'm well aware that there are tall women, and that there are dedicated shops for lengthy women, but that's not the only thing that I have trouble with. What bothers me most is what people read into tall people: that they are always someone they can lean on for comfort, that tall people are always considered to be self confident and standing up for themselves (another pun, I know ... my bad).
And while I'm fine with people coming to me for leaning on to, I rarely get the chance to do so myself. And people don't even consider it. When I was there in Munich, talking with another great (... pun?) trans woman who was as tall as me I finally had the possibility to just rest my head on her shoulder and finally feel the comfort I need just as much as everyone else out there, too. Probably that's also the reason why I'm so touchy and do go Free Hugging as often as possible. But being tall also means that you are usually only the big spoon when cuddling up. Having a small mental breakdown because of realizing that didn't change the feeling directly but definitely helped with looking for what I could change to fix that for myself.
Then, at the end of may, the movie FtWTF - female to what the fuck came to cinema. It's a documentary about six people who got assigned female at birth. And it's absolutely charming, and has great food for thoughts in it. If you ever get the chance to watch it you definitely should.
And then came debconf16 in Capetown. The flight to there was canceled and we had to get rebooked. The first offer was to go through Dubai, and gladly a colleague did point out to the person behind the desk that that wouldn't be safe for myself and thus out of scope. In the end we managed to get to Capetown quite nice, and even though it was winter when the sun was shining it was quite nice. Besides the cold nights that is. Or being stuck on the way up to table mountain because a colleague had cramps in his lags and we had to call mountain rescue. Gladly the night was clear, and when the mountain rescue finally got us to top and it was night already we had one of the nicest views from up there most people probably never will experience.
And then ... I got invited to a trans meetup in Capetown. I was both excited and nervous about it, what to expect there. But it was simply great. The group there was simply outstandingly great. The host gave update information on progress on clinical support within south Africa, from what I took with me is that there is only one clinic there for SRS which manages only two people a year which is simply ... yuck. Guess you can guess how many years (yes, decades) the waiting line is ... I was blown away though by the diversity of the group, on so many levels, most notably on the age spectrum. It was a charm to meet you all there! If you ever stop by in Capetown and you are part of the LGBTIQ community, make sure you get in contact with the Triangle Project.
But, about the real reason to write this entry: I was approached at Debconf by at least two people who asked me what I thought about creating an LGBTIQA+ group within Debian, and if I'd like to push for that. Actually I think it would be a good idea to have some sort of exchange between people on the queer spectrum (and I hope I don't offend anyone with just saying queer for LGBTIQA+ people). Given that I'm quite outspoken people approach me every now and then so I'm aware that there is a fair amount of people that would fall into that category. On the other hand some of them wouldn't want to have it publicly known because it shouldn't matter and isn't really the business of others.
So I'm uncertain. If we follow that path I guess something that is closed or at least offers the possibility to have a closed communication would be needed to not out someone by just joining in the discussion. It's was easier with Debian Women where it was (somewhat) clear that male participants are allies supporting the cause and not considered being women themselves, but often enough (mostly cis hetero male) people are afraid to join a dedicated LGBTIQA+ group because they have the fear of having their identity judged. These things should be considered before creating such a place so that people can feel comfortable when joining and know what to expect beforehand.
For the time being I created #debian-diversity on irc.debian.org to discuss how to move forward. Please bear in mind that even the channel name is up for discussion. Acronyms might not be the way to go in my opinion, just read back up the discussion that lead to the Diversity Statement of Debian where the original approach was to start listing groups for inclusiveness but it was quickly clear that it can get outdated too easily.
I am willing to be part of that effort, but right now I have some personal things to deal which eat up a fair amount of my time. My kid starts school in September (yes, it's that long already, time flies ...). And it looks like I'll have to move a second time in the near future: I'll have to leave my current flat by the end of the year and the Que[e]rbau I'm moving into won't be ready by that time to host me yet ... F*ck. :(
Next.