Gunnar Wolf: Back to Understanding Computers and Cognition


RSS
format.
Anyway I do want to write a post summing up 2022, as well as
sharing some hopes and projects I have for 2023. But I don t want to
make it too long to read. So That shall be the blog post for today!
(post caption image by Walt Stoneburner on Flickr; CC BY
2.0)
expect()
and
Result<T,E>
It will take some time to be at ease developing in
it, if I ever reach that stage!
Oh, FWIW Interested related reading. I am halfway through an
interesting article, published in March in the Communications of the
ACM magazine, titled Here We Go Again: Why
Is It Difficult for Developers to Learn Another Programming
Language? ,
that presents an interesting point we don t always consider: If I m a
proficient programmer in the X programming language and want to use
the Y programming language, learning it Should be easier for me
than for the casual bystander, or not? After all, I already have a
background in programming! But it happens that mental constructs we
build for a given language might hamper our learning of a very
different one. This article presents three interesting research
questions:
[1] Choice 5: Change SC for non-free firmware in installer, one installer [2] Choice 1: Only one installer, including non-free firmware [3] Choice 6: Change SC for non-free firmware in installer, keep both installers [4] Choice 2: Recommend installer containing non-free firmware [5] Choice 3: Allow presenting non-free installers alongside the free one [6] Choice 7: None Of The Above [7] Choice 4: Installer with non-free software is not part of DebianWhy have I voted this way? Fundamentally, my motivation for starting this vote was to ask the project for clear positive direction on a sensible way forward with non-free firmware support. Thus, I've voted all of the options that do that above NOTA. On those terms, I don't like Choice 4 here - IMHO it leaves us in the same unclear situation as before. I'd be happy for us to update the Social Contract for clarity, and I know some people would be much more comfortable if we do that explicitly here. Choice 1 was my initial personal preference as we started the GR, but since then I've been convinced that also updating the SC would be a good idea, hence Choice 5. I'd also rather have a single image / set of images produced, for the two reasons I've outlined before. It's less work for our images team to build and test all the options. But, much more importantly: I believe it's less likely to confuse new users. I appreciate that not everybody agrees with me here, and this is part of the reason why we're voting! Other Debian people have also blogged about their voting choices (Gunnar Wolf and Ian Jackson so far), and I thank them for sharing their reasoning too. For the avoidance of doubt: my goal for this vote was simply to get a clear direction on how to proceed here. Although I proposed Choice 1 (Only one installer, including non-free firmware), I also seconded several of the other ballot options. Of course I will accept the will of the project when the result is announced - I'm not going to do anything silly like throw a tantrum or quit the project over this! Finally If you're a DD and you haven't voted already, please do so - this is an important choice for the Debian project.
[6] Choice 1: Only one installer, including non-free firmware
[2] Choice 2: Recommend installer containing non-free firmware
[3] Choice 3: Allow presenting non-free installers alongside the free one
[7] Choice 4: Installer with non-free software is not part of Debian
[4] Choice 5: Change SC for non-free firmware in installer, one installer
[1] Choice 6: Change SC for non-free firmware in installer, keep both installers
[5] Choice 7: None Of The Above
[1] Choice 6: Change SC for non-free firmware in installer, keep both installers
[2] Choice 2: Recommend installer containing non-free firmware
[3] Choice 3: Allow presenting non-free installers alongside the free one
[4] Choice 5: Change SC for non-free firmware in installer, one installer
[5] Choice 7: None Of The Above
[6] Choice 1: Only one installer, including non-free firmware
[7] Choice 4: Installer with non-free software is not part of Debian
Choice 1
(even though I seconded it, this means, I think
it s very important to have this vote, and as a first proposal, it s
better than the status quo maybe it s contradictory that I prefer
it to the status quo, but ranked it below NotA. Well, more on that
when I present Choice 5
).
My least favorite option is Choice 4
, presented by Simon
Josefsson, which represents the status quo: I don t want Debian not
to have at all an installer that cannot be run on most modern hardware
with reasonably good user experience (i.e. network support or the
ability to boot at all!)
Slightly above my acceptability threshold, I ranked Choice 5
,
presented by Russ Allbery. Debian s voting and its constitution rub
each other in interesting ways, so the Project Secretary has to run
the votes as they are presented but he has interpreted Choice 1
to be incompatible with the Social Contract (as there would no longer
be a DFSG-free installer available), and if it wins, it could lead him
to having to declare the vote invalid. I don t want that to happen,
and that s why I ranked Choice 1
below None of the above
.
[update/note] Several people have asked me to back that the Secretary said so. I can refer to four mails: 2022.08.29, 2022.08.30, 2022.09.02, 2022.09.04.Other than that,
Choice 6
(proposed by Holger Levsen), Choice 2
(proposed by me) and Choice 3
(proposed by Bart Martens) are very
much similar; the main difference is that Choice 6
includes a
modification to the Social Contract expressing that:
The Debian official media may include firmware that is otherwise not
part of the Debian system to enable use of Debian with hardware that
requires such firmware.
2
and 3
to be mostly the same, being Choice 2
more verbose in explaining the reasoning than Choice 3
.
Oh! And there are always some more bits to the discussion For
example, given they hold modifications to the Social Contract, both
Choice 5
and Choice 6
need a 3:1 supermajority to be valid.
So, lets wait until the beginning of October to get the results, and
to implement the changes they will (or not?) allow. If you are a
Debian Project Member, please vote!
No HDMI support via the USB-C displayport. While I don t expect
to go to conferences or even classes in the next several months,
I hope this can be fixed before I do. It s a potential important
issue for me.
/usr/bin/wf-recorder -g '0,32 960x540' -t --muxer=v4l2 --codec=rawvideo --pixelformat=yuv420p --file=/dev/video10
/dev/video10
). You will note
I m grabbing a 960 540 rectangle, which is the top of my screen
(1920x1080) minus the Waybar. I think I ll increase it to 960 720, as
the projector to which I connect the Raspberry has a 4 3 output.
After this is sent to /dev/video10
, I tell ffmpeg
to send it via
RTP to
the fixed address of the Raspberry:
/usr/bin/ffmpeg -i /dev/video10 -an -f rtp -sdp_file /tmp/video.sdp rtp://10.0.0.100:7000/
/tmp/video.sdp
is created in the laptop itself; this file describes the stream s
metadata so it can be used from the client side. I cheated and copied
it over to the Raspberry, doing an ugly hardcode along the way:
user@raspi:~ $ cat video.sdp
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 10.0.0.100
t=0 0
a=tool:libavformat 58.76.100
m=video 7000 RTP/AVP 96
b=AS:200
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=1
user
user, and dropped the following in my user s .xsession
:
setterm -blank 0 -powersave off -powerdown 0
xset s off
xset -dpms
xset s noblank
mplayer -msglevel all=1 -fs /home/usuario/video.sdp
clever
) explained today in the
#debian-raspberrypi
channel in OFTC that it advances far better than
what I expected: It is even possible to boot a usable system under the
RPi2 family! Just There is somewhat incomplete hardware support:
For his testing, he has managed to use a xfce environment but over
the composite (NTSC) video output, as HDMI initialization support is
not there.
However, he shared with me several interesting links and videos, and I
told him I d share them there are still many issues; I do not
believe it is currently worth it to make Debian images with this
firmware.
clever
showed me that made me write this post Is the
amount of stuff you can do with the RPi s VPU (why clever
s definitions beyond
how I trust my own ) before it loads an opearting system:
raspi-firmware
)clever
we could push this firmware to experimental instead
of
unstable
, as it is not yet ready for most production
systems. However, pabs made some spot-on further
questions. And yes, it requires installing three(!) different
cross-compilers, one of which vc4-toolchain, for the
VPU is free software, but
not yet upstreamed, and hence is not available for Debian.
Anyway, the talk continued long after I had to go. I have gone a bit
over the backlog, but I have to leave now so that will be it as for
this blog post
oax
, not his
usual kbw
, which he lent me). He was also working on Manual de
Lenguaje y Tipograf a Cient fica en
Castellano, where you
can see some examples of TeX; due to a hardware crash, the book has
the rare privilege of being a direct copy of the output of the
thermal printer: It was not possible to produce a higher resolution
copy for several years But it is fun and interesting to see what we
were able to produce with in-house tools back in 1985!
So, what could he teach me so I could use the computers while he
worked? TeX, of course. No, no LaTeX (that was published in
1984). LaTeX is a set of macros developed initially by Leslie Lamport,
used to make TeX easier; TeX was developed by Donald Knuth, and if I
have this information correct, it was Knuth himself who installed and
demonstrated TeX in the Foonly computer, during a visit to UNAM.
Now, after 39 years hammering at Emacs buffers Have I grown extra
fingers? Nope. I cannot even write decent elisp
code, and can barely
read it. I do use org-mode (a lot!) and love it; I have written
basically five books, many articles and lots of presentations and
minor documents with it. But I don t read my mail or handle my git
from Emacs. I could say, I m a relatively newbie after almost four
decades.
Four decades
When we got a PC in 1986, my father got the people at the Institute to
get him memacs
(micro-emacs). There was probably a ten year period I
barely used any emacs, but always recognized it. My fingers hve
memorized a dozen or so movement commands, and a similar number of
file management commands.
And yes, Emacs and TeX are still the main tools I use day to day.
Many free projects use OpenPGP encryption or signatures for various important tasks, like defining membership, authenticating participation, asserting identity over a vote, etc. The Web-of-Trust upon which its operation is based is a model many of us hold dear, allowing for a decentralized way to assign trust to the identity of a given person. But both the Web-of-Trust model and the software that serves as a basis for the above mentioned uses are at risk due to attacks on the key distribution protocol (not on the software itself!) With this talk, I will try to bring awareness to this situation, to some possible mitigations, and present some proposals to allow for the decentralized model to continue to thrive towards the future.I am on the third semester of my PhD, trying to somehow keep a decentralized infrastructure for the OpenPGP Web of Trust viable and usable for the future. While this is still in the early stages of my PhD work (and I still don t have a solution to present), I will talk about what the main problems are and will sketch out the path I intend to develop. What is the relevance? Mainly, I think, that many free software projects use the OpenPGP Web of Trust for their identity definitions Are we anachronistic? Are we using tools unfit for this century? I don t think so. I think we are in time to fix the main sore spots for this great example of a decentralized infrastructure.
Raspberry Pi Zero 2 W
,
which you can easily see in the following photo, informs the kernel it
has 512MB RAM, and Well, really, it s an easy device tree to read,
don t be shy!
linux-source-5.15
, applied Stephan s patch,
and added the following for the DTB to be generated in the arm64 tree
as well:
--- /dev/null 2022-01-26 23:35:40.747999998 +0000
+++ arch/arm64/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts 2022-02-13 06:28:29.968429953 +0000
@@ -0,0 +1 @@
+#include "arm/bcm2837-rpi-zero-2-w.dts"
make dtbs
, and Failed, because
bcm283x-rpi-wifi-bt.dtsi is not yet in the kernel .
OK, no worries: Getting wireless to work is a later step. I commented
out the lines causing conflict (10, 33-35, 134-136), and:
root@rpi3-20220212:/usr/src/linux-source-5.15# make dtbs
DTC arch/arm64/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dtb
#debian-raspberrypi
, steev suggested me
to pull in the WiFi patch, that has also been
submitted
(but not yet accepted) for kernel inclusion. I did so, uncommented the
lines I modified, and built again. It builds correctly, and again
copied the DTB over. It still does not find the WiFi; dmesg
still
complains about a missing bit of firmware (failed to load
brcm/brcmfmac43430b0-sdio.raspberrypi,model-zero-2-w.bin
). Steev
pointed out it can be downloaded from RPi Distro s GitHub
page,
but I called it a night and didn t pursue it any further ;-)
So I understand this post is still a far cry from saying our
images properly boot under a RPi 0 2 W ,
but we will get there
This is a program visualization tool aimed at concurrent programs and related issues. The tool itself is mostly language agnostic, and relies on Storm to compile the provided code and provide basic debug information. The generated code is then inspected and instrumented to provide an experience similar to a basic debugger. The tool emphasizes a visual representation of the object hierarchy that is manipulated by the executed program to make it easy to understand how it looks. In particular, a visual representation is beneficial over a text representation since it makes it easier to find shared data that might need to be synchronized in a concurrent program. As mentioned, the tool is aimed at concurrent programs. Therefore, it allows spawning multiple threads running the same program to see if that affects the program s execution (this is mostly interesting if global variables are used). Furthermore, any spawned threads also appear in the tool, and the user may control them independently to explore possible race conditions or other synchronization errors. If enabled from the menu bar, the tool keeps track of reads and writes to the data structure in order to highlight basic race conditions in addition to deadlocks.
pthread
implementation, an own thread model is used; i.e. thread
creation is handled via int thread_id = thread_name(funcname,
¶ms)
instead of the more complex
pthread_create()
function (including details such as the thread object being passed as
by reference as a parameter)
All in all, while I have not yet taken full advantage of this tool in
my teaching, it has helped me show somewhat hard to grasp concepts
such as:
progvis-examples
package to get
started. You will find some dozens of sample programs in
/usr/share/doc/progvis-examples/examples
; playing with them will
help you better understand the tool and be able to better write your
own programs.
raspi.debian.net
, in April 2020,
I had been hosting it in my Dreamhost webspace.
Over two years ago yes, before I finished setting it up in Dreamhost
Steve McIntyre approached me and invited me to host the images under
the Debian cdimages user group. I told him I d first just get the
setup running, and later I would approach him for finalizing the
setup.
debian-arm@lists.debian.org
finished with me stating I would be moving the hosting to Debian
infrastructure
soon.
Well It took me a bit over a month to get this sorted out, together
with several days of half-broken links, but it is finally done:
raspi.debian.net is a CNAME for
ftp.acc.umu.se
, which is the same system that hosts
cdimage.debian.org.
And, of course it is also reachable as
https://cdimage.debian.org/cdimage/unofficial/raspi/
looks more official, but is less memorable
Thanks a lot to Steve for the nudging, and to maswan to help
finalizing the setup.
What next? Well, the images are being built on my server. I d love to
move the builder over to Debian machines as well. When? How? That s
still in the air.
We live in an era where human to human interactions are more and more often mediated by technology. This, of course, means everything leaves a digital trail, a trail that can follow and us relentlessly. Privacy is recognized, however, as a human right although one that is under growing threats. Anonymity is the best tool to secure it. Throughout history, clear steps have been taken legally, technically and technologically to defend it. Various studies point out this is not only a known issue for the network's users, but that a large majority has searched for alternatives to protect their communications' privacy. This book stems from a colloquium held by *Laboratorio de Investigaci n y Desarrollo de Software Libre* (LIDSOL) of Facultad de Ingenier a, UNAM, towards the end of 2018, where we invited experts from disciplines so far apart as law and systems development, psychology and economics, to contribute with their experiences to a transdisciplinary vision.If this interests you, you can get the book at our institutional repository. Oh, and What about the birds? In Spanish (Mexican only?), we have a saying, hay p jaros en el alambre , meaning watch your words, as uninvited people might be listening, as birds resting over the wires over which phone calls used to be made (back in the day where wiretapping was that easy). I found the design proposed by our editor ingenious and very fitting for our topic!
debian-installer
i3
, as it s
fundamental for me to work happily.
Of course, the computer has quirks, more than I d expect from a
regular x86 system, but well within what I expected to achieve during
my first day with it. The issues I have most noted are:
/usr/local/bin/install-dtbs.py
/usr/lib/linux-image-5.12.19-custom/ /boot/efi/dtb
. And this should
remain handy, as I ll have to do so for every new kernel I install
(hint, hint: It should be called from /etc/kernel/postinst.d or
something like that. I should check and propose a patch!)
/etc/roundcube/config.inc.php
:
$config['max_recipients'] = 10
/index.php
and there is quite a bit of
parsing to do to understand the actions done. When sending a mail, of
course, it is done using the POST
HTTP verb, and the URI-specified
variables include _task=mail&_unlock=loading<message_id>
(of course,
with changing message IDs).
After some poking here and there, I faced to SpiderLabs
ModSecurity Only
that I am not yet well versed in writing rules for it. But after quite
a bit of reading, poking, breaking I was able to come up with the
following rules:
# How often does the limit counter expire ratelimit_client=60,
# every 60 seconds
SecRule REQUEST_LINE "@rx POST.*_task=mail&_unlock" id:10,phase:2,nolog,pass,setuid:% tx.ua_hash ,setvar:user.ratelimit_client=+1,expirevar:user.ratelimit_client=60
# How many requests do we allow in the specified time period?
# @gt 3, 3 requests
SecRule user:ratelimit_client "@gt 2" chain,id:100009,phase:2,deny,status:429,setenv:RATELIMITED,log,msg:RATE-LIMITED
SecRule REQUEST_LINE "@rx POST.*_task=mail&_unlock"
_task=mail&_unlock
fragment in the
URL. It increments tht ratelimit_client
user variable, but expires
it after 60 seconds.
The first line verifies whether the above specified variable (do note
that it s user:
instead of user.
) is greater than 2. If so, it
sets the deny
action, HTTP return status of 429 (Too Many
Requests
), and logs the reason why this request was denied
(rate-limited).
And Given the way Roundcube works, this even works transparently!
If a user hits the limit, the mail sending component will just wait
and, after a while, time out. Then, the user can click Send
again. If legitimate users are too productive and try to send over
three mails in a minute, they won t lose any of it; spammers will
(hopefully!) find it unbearably slow and give up.
Logging is quite informative; I will probably later restrict it to
show fewer parts (even if just for privacy sake, as it logs the full
request!) For a complex permissions framework such as mod_security,
having information such as the following is most welcome in order to
find a possibly misbehaving rule:
--76659f4b-H--
Message: Access denied with code 429 (phase 2). Pattern match "POST.*_task=mail&_unlock" at REQUEST_LINE. [file "/etc/modsecurity/rate_limit_sender.conf"] [line "20"] [id "100009"] [msg "RATELIMITED BOT"]
Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [client 192.168.1.48] ModSecurity: Access denied with code 429 (phase 2). Pattern match "POST.*_task=mail&_unlock" at REQUEST_LINE. [file "/etc/modsecurity/rate_limit_sender.conf"] [line "20"] [id "100009"] [msg "RATELIMITED BOT"] [hostname "my.server.mx"] [uri "/roundcube/"] [unique_id "YMzJLR9jVDMGsG@18kB1qAAAAAY"]
Action: Intercepted (phase 2)
Stopwatch: 1624033581838813 1204 (- - -)
Stopwatch2: 1624033581838813 1204; combined=352, p1=29, p2=140, p3=0, p4=0, p5=94, sr=81, sw=89, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/).
Server: Apache
WebApp-Info: "default" "-" ""
Engine-Mode: "ENABLED"
Next.