I have 2 very useful shell scripts related to resizing consoles. The first is imaginatively called resize and just configures the terminal to be the requested size, neatly resizing an xterm or gnome-terminal:
The other is a bit more complicated and useful when connecting to a host via a serial console, or when driving a qemu VM with -display none -nographic and all output coming over a serial console on stdio. It figures out the size of the terminal it s running in and correctly sets the local settings to match so you can take full advantage of a larger terminal than the default 80x24:
Generally I source this with . fix-term or the TERM export doesn t get applied. Both of these exist in various places around the net (and there s a resize binary shipped along with xterm) but I always forget the exact terms to find it again when I need it. So this post is mostly intended to serve as future reference next time I don t have them handy.
There was no new activity in Debian project funding in the two existing projects. However, there was a survey run with hundreds of Debian Developers and Debian contributors. The survey results are being collated and we will use the anonymized data to further develop the Freexian project funding initiative.
We are preparing to more broadly announce additional support for Debian 8 Jessie and Debian 9 Stretch. Now, Debian 8 can be supported until June 2025 and Debian 9 until June 2027. More information on ELTS support is available.
Learn more about the rationale behind this initiative in this article.
Debian LTS contributors
In March, 11 contributors were paid to work on Debian LTS, their reports are available below. If you re interested in participating in the LTS or ELTS teams, we welcome participation from the Debian community. Simply get in touch with Jeremiah or Rapha l if you are if you are interested in participating.
Utkarsh Gupta did 57.75h out of 59.5h assigned, carrying over 1.75 hours.
Evolution of the situation
In March we released 42 DLAs.
The security tracker currently lists 81 packages with a known CVE and the dla-needed.txt file has 52 packages needing an update.
We re glad to welcome a few new sponsors such as lectricit de France (Gold sponsor), Telecats BV and Soliton Systems.
Thanks to our sponsors
Sponsors that joined recently are in bold.
If you intend to apply for a
DebConf22 bursary and/or
submit an event proposal and have not yet
done so, please proceed as soon as possible!
Bursary applications for DebConf22 will be accepted until May 1st at 23:59 UTC.
Applications submitted after this deadline will not be considered.
You can apply for a bursary when you register
for the conference.
Remember that giving a talk or organising an event is considered towards your bursary;
if you have a submission to make, submit it even if it is only sketched-out.
You will be able to detail it later. DebCamp plans can be entered in the usual
Sprints page at the Debian wiki.
Please make sure to double-check your accommodation choices (dates and venue).
Details about accommodation arrangements can be found on the
accommodation page.
Event proposals will be accepted until May 1st at 23:59 UTC too.
Events are not limited to traditional presentations or informal sessions (BoFs):
we welcome submissions of tutorials, performances, art installations, debates,
or any other format of event that you think would be of interest to the Debian
community.
Regular sessions may either be 20 or 45 minutes long (including time for
questions), other kinds of sessions (workshops, demos, lightning talks, and so
on) could have different durations. Please choose the most suitable duration for
your event and explain any special requests. You can submit it
here.
The the 23rd edition of DebConf will take place
from July 17th to 24th, 2022 at the
Innovation and Training Park (ITP) in Prizren,
Kosovo, and will be preceded by DebCamp, from July 10th to 16th.
See you in Prizren!
After two long years of COVID hiatus, local Debian events in Montreal are back!
Last Sunday, nine of us met at Koumbit to work on Debian (and other stuff!),
chat and socialise.
Even though these events aren't always the most productive, it was super fun
and definitely helps keeping me motivated to work on Debian in my spare time.
Many thanks to Debian for providing us a budget to rent the venue for the day
and for the pizzas! Here are a few pictures I took during the event:
If everything goes according to plan, our next meeting should be sometime in
June. If you are interested, the best way to stay in touch is either to
subscribe to our mailing list or to join our IRC channel
(#debian-quebec on OFTC). Events are also posted on Quebec's Agenda du
libre.
The diffoscope maintainers are pleased to announce the release of diffoscope
version 211. This version includes the following changes:
[ Mattia Rizzolo ]
* Drop mplayer from the Build-Depends, it was add likely by accident and it's
not needed.
* Disable gnumeric tests in Debian because it's not currently available.
The Language Server Protocol (LSP) is a neat mechanism that
provides a common interface to what used to be language-specific
lookup mechanisms (like, say, running a Python interpreter in the
background to find function definitions).
There is also ctags shipped with UNIX since forever, but that
doesn't support looking backwards ("who uses this function"),
linting, or refactoring. In short, LSP rocks, and how do I use it
right now in my editor of choice (Emacs, in my case) and OS (Debian)
please?
(use-package lsp-mode
:commands (lsp lsp-deferred)
:hook ((python-mode go-mode) . lsp-deferred)
:demand t
:init
(setq lsp-keymap-prefix "C-c l")
;; TODO: https://emacs-lsp.github.io/lsp-mode/page/performance/
;; also note re "native compilation": <+varemara> it's the
;; difference between lsp-mode being usable or not, for me
:config
(setq lsp-auto-configure t))
(use-package lsp-ui
:config
(setq lsp-ui-flycheck-enable t)
(add-to-list 'lsp-ui-doc-frame-parameters '(no-accept-focus . t))
(define-key lsp-ui-mode-map [remap xref-find-definitions] #'lsp-ui-peek-find-definitions)
(define-key lsp-ui-mode-map [remap xref-find-references] #'lsp-ui-peek-find-references))
Note: this configuration might have changed since I wrote this, see
my init.el configuration for the most recent config.
The main reason for choosing lsp-mode over eglot is that it's in
Debian (and eglot is not). (Apparently, eglot has more chance of being
upstreamed, "when it's done", but I guess I'll cross that bridge when
I get there.)
I already had lsp-mode partially setup in Emacs so I only had to do
this small tweak to switch and change the prefix key
(because s-l or mod is used by my window
manager). I also had to pin LSP packages to bookworm here so that
it properly detects pylsp (the older version in Debian bullseye only
supports pyls, not packaged in Debian).
This won't do anything by itself: Emacs will need something to talk
with to provide the magic. Those are called "servers" and are
basically different programs, for each programming language, that
provide the magic.
Servers setup
The Emacs package provides a way (M-x lsp-install-server)
to install some of them, but I prefer to manage those tools through
Debian packages if possible, just like lsp-mode itself. Those are
the servers I currently know of in Debian:
package
languages
ccls
C, C++, ObjectiveC
clangd
C, C++, ObjectiveC
elpa-lsp-haskell
Haskell
fortran-language-server
Fortran
gopls
Golang
python3-pyls
Python
There might be more such packages, but those are surprisingly hard to
find. I found a few with apt search "Language Server Protocol", but
that didn't find ccls, for example, because that just said "Language
Server" in the description (which also found a few more pyls plugins,
e.g. black support).
Note that the Python packages, in particular, need to be upgraded to
their bookworm releases to work properly (here). It seems like
there's some interoperability problems there that I haven't quite
figured out yet. See also my Puppet configuration for LSP.
Finally, note that I have now completely switched away from Elpy
to pyls, and I'm quite happy with the results. lsp-mode feels slower
than elpy but I haven't done any of the performance tuning
and this will improve even more with native compilation. And
lsp-mode is much more powerful. I particularly like the "rename
symbol" functionality, which ... mostly works.
Remaining work
Puppet and Ruby
I still have to figure how to actually use this: I mostly spend my
time in Puppet these days, there is no server listed in the Emacs
lsp-mode language list, but there is one listed over at the
upstream language list, the puppet-editor-services
server.
But it's not packaged in Debian, and seems somewhat... involved. It
could still be a good productivity boost. The Voxpupuli team have
vim install instructions which also suggest installing
solargraph, the Ruby language server, also not packaged in
Debian.
Bash
I guess I do a bit of shell scripting from time to time nowadays, even
though I don't like it. So the bash-language-server may prove
useful as well.
Other languages
Here are more language servers available:
I've been using sbuild for a while to build my Debian packages,
mainly because it's what is used by the Debian autobuilders, but
also because it's pretty powerful and efficient. Configuring it just
right, however, can be a challenge. In my quick Debian development
guide, I had a few pointers on how to
configure sbuild with the normal schroot setup, but today I finished
a qemu based configuration.
Why
I want to use qemu mainly because it provides better isolation than a
chroot. I sponsor packages sometimes and while I typically audit
the source code before building, it still feels like the extra
protection shouldn't hurt.
I also like the idea of unifying my existing virtual machine setup
with my build setup. My current VM is kind of all over the place:
libvirt, vagrant, GNOME Boxes, etc?). I've been slowly
converging over libvirt however, and most solutions I use right now
rely on qemu under the hood, certainly not chroots...
I could also have decided to go with containers like LXC, LXD, Docker
(with conbuilder, whalebuilder, docker-buildpackage),
systemd-nspawn (with debspawn), unshare (with schroot
--chroot-mode=unshare), or whatever: I didn't feel those offer the
level of isolation that is provided by qemu.
The main downside of this approach is that it is (obviously) slower
than native builds. But on modern hardware, that cost should be
minimal.
Then to make this used by default, add this to ~/.sbuildrc:
# run autopkgtest inside the schroot
$run_autopkgtest = 1;
# tell sbuild to use autopkgtest as a chroot
$chroot_mode = 'autopkgtest';
# tell autopkgtest to use qemu
$autopkgtest_virt_server = 'qemu';
# tell autopkgtest-virt-qemu the path to the image
# use --debug there to show what autopkgtest is doing
$autopkgtest_virt_server_options = [ '--', '/srv/sbuild/qemu/%r-%a.img' ];
# tell plain autopkgtest to use qemu, and the right image
$autopkgtest_opts = [ '--', 'qemu', '/srv/sbuild/qemu/%r-%a.img' ];
# no need to cleanup the chroot after build, we run in a completely clean VM
$purge_build_deps = 'never';
# no need for sudo
$autopkgtest_root_args = '';
Note that the above will use the default autopkgtest (1GB, one core)
and qemu (128MB, one core) configuration, which might be a little low
on resources. You probably want to be explicit about this, with
something like this:
# extra parameters to pass to qemu
# --enable-kvm is not necessary, detected on the fly by autopkgtest
my @_qemu_options = ['--ram-size=4096', '--cpus=2'];
# tell autopkgtest-virt-qemu the path to the image
# use --debug there to show what autopkgtest is doing
$autopkgtest_virt_server_options = [ @_qemu_options, '--', '/srv/sbuild/qemu/%r-%a.img' ];
$autopkgtest_opts = [ '--', 'qemu', @qemu_options, '/srv/sbuild/qemu/%r-%a.img'];
This configuration will:
create a virtual machine image in /srv/sbuild/qemu for
unstable
tell sbuild to use that image to create a temporary VM to build
the packages
tell sbuild to run autopkgtest (which should really be
default)
tell autopkgtest to use qemu for builds and for tests
Note that the VM created by sbuild-qemu-create have an unlocked root
account with an empty password.
Other useful tasks
enter the VM to make test, changes will be discarded (thanks Nick
Brown for the sbuild-qemu-boot tip!):
You might also need parameters like --ram-size if you customized
it above.
And yes, this is all quite complicated and could be streamlined a
little, but that's what you get when you have years of legacy and just
want to get stuff done. It seems to me autopkgtest-virt-qemu should
have a magic flag starts a shell for you, but it doesn't look like
that's a thing. When that program starts, it just
says ok and sits there.
Maybe because the authors consider the above to be simple enough (see
also bug #911977 for a discussion of this problem).
Live access to a running test
When autopkgtest starts a VM, it uses this funky qemu commandline:
... which is a typical qemu commandline, I'm sorry to say. That
gives us a VM with those settings (paths are relative to a temporary
directory, /tmp/autopkgtest-qemu.w1mlh54b/ in the above example):
the shared/ directory is, well, shared with the VM
port 10022 is forward to the VM's port 22, presumably for SSH,
but not SSH server is started by default
the ttyS1 and ttyS2 UNIX sockets are mapped to the first two
serial ports (use nc -U to talk with those)
the monitor UNIX socket is a qemu control socket (see the QEMU
monitor documentation, also nc -U)
In other words, it's possible to access the VM with:
nc -U /tmp/autopkgtest-qemu.w1mlh54b/ttyS2
The nc socket interface is ... not great, but it works well
enough. And you can probably fire up an SSHd to get a better shell if
you feel like it.
Nitty-gritty details no one cares about
Fixing hang in sbuild cleanup
I'm having a hard time making heads or tails of this, but please bear
with me.
In sbuild + schroot, there's this notion that we don't really need
to cleanup after ourselves inside the schroot, as the schroot will
just be delted anyways. This behavior seems to be handled by the
internal "Session Purged" parameter.
At least in lib/Sbuild/Build.pm, we can see this:
my $is_cloned_session = (defined ($session->get('Session Purged')) &&
$session->get('Session Purged') == 1) ? 1 : 0;
[...]
if ($is_cloned_session)
$self->log("Not cleaning session: cloned chroot in use\n");
else
if ($purge_build_deps)
# Removing dependencies
$resolver->uninstall_deps();
else
$self->log("Not removing build depends: as requested\n");
... which is ... a little confusing to me. $info is:
my $info = $self->get('Chroots')->get_info($schroot_session);
... so I presume that depends on whether the schroot was correctly
cleaned up? I stopped digging there...
ChrootUnshare.pm is way more explicit:
$self->set('Session Purged', 1);
I wonder if we should do something like this with the autopkgtest
backend. I guess people might technically use it with something else
than qemu, but qemu is the typical use case of the autopkgtest
backend, in my experience. Or at least certainly with things that
cleanup after themselves. Right?
For some reason, before I added this line to my configuration:
$purge_build_deps = 'never';
... the "Cleanup" step would just completely hang. It was quite
bizarre.
Disgression on the diversity of VM-like things
There are a lot of different virtualization solutions one can use
(e.g. Xen, KVM, Docker or Virtualbox). I have also
found libguestfs to be useful to operate on virtual images in
various ways. Libvirt and Vagrant are also useful wrappers on
top of the above systems.
There are particularly a lot of different tools which use Docker,
Virtual machines or some sort of isolation stronger than chroot to
build packages. Here are some of the alternatives I am aware of:
Take, for example, Whalebuilder, which uses Docker to build
packages instead of pbuilder or sbuild. Docker provides more
isolation than a simple chroot: in whalebuilder, packages are
built without network access and inside a virtualized
environment. Keep in mind there are limitations to Docker's security
and that pbuilder and sbuilddo build under a different user
which will limit the security issues with building untrusted
packages.
On the upside, some of things are being fixed: whalebuilder is now
an official Debian package (whalebuilder) and has added
the feature of passing custom arguments to dpkg-buildpackage.
None of those solutions (except the autopkgtest/qemu backend) are
implemented as a sbuild plugin, which would greatly reduce their
complexity.
I was previously using Qemu directly to run virtual machines, and
had to create VMs by hand with various tools. This didn't work so well
so I switched to using Vagrant as a de-facto standard to build
development environment machines, but I'm returning to Qemu because it
uses a similar backend as KVM and can be used to host longer-running
virtual machines through libvirt.
The great thing now is that autopkgtest has good support for qemuandsbuild has bridged the gap and can use it as a build
backend. I originally had found those bugs in that setup, but all of
them are now fixed:
#911977: sbuild: how do we correctly guess the VM name in autopkgtest?
#911979: sbuild: fails on chown in autopkgtest-qemu backend
#911963: autopkgtest qemu build fails with proxy_cmd: parameter not set
#911981: autopkgtest: qemu server warns about missing CPU features
So we have unification! It's possible to run your virtual machines
and Debian builds using a single VM image backend storage, which is
no small feat, in my humble opinion. See the sbuild-qemu blog post
for the annoucement
Now I just need to figure out how to merge Vagrant, GNOME Boxes, and
libvirt together, which should be a matter of placing images in the
right place... right? See also hosting.
pbuilder vs sbuild
I was previously using pbuilder and switched in 2017 to sbuild.
AskUbuntu.com has a good comparative between pbuilder and sbuild
that shows they are pretty similar. The big advantage of sbuild is
that it is the tool in use on the buildds and it's written in Perl
instead of shell.
My concerns about switching were POLA (I'm used to pbuilder), the fact
that pbuilder runs as a separate user (works with sbuild as well now,
if the _apt user is present), and setting up COW semantics in sbuild
(can't just plug cowbuilder there, need to configure overlayfs or
aufs, which was non-trivial in Debian jessie).
Ubuntu folks, again, have moredocumentation there. Debian
also has extensive documentation, especially about how to
configure overlays.
I was ultimately convinced by stapelberg's post on the topic which
shows how much simpler sbuild really is...
Who
Thanks lavamind for the introduction to the sbuild-qemu package.
This is the fourth book of the Malloreon, the sequel series to
the Belgariad. Eddings as usual helpfully
summarizes the plot of previous books (the one thing about his writing
that I wish more authors would copy), this time by having various
important people around the world briefed on current events. That said,
you don't want to start reading here (although you might wish you could).
This is such a weird book.
One could argue that not much happens in the Belgariad other than map
exploration and collecting a party, but the party collection involves
meddling in local problems to extract each new party member. It's a bit
of a random sequence of events, but things clearly happen. The Malloreon
starts off with a similar structure, including an explicit task to create
a new party of adventurers to save the world, but most of the party is
already gathered at the start of the series since they carry over from the
previous series. There is a ton of map exploration, but it's within the
territory of the bad guys from the previous series. Rather than local
meddling and acquiring new characters, the story is therefore chasing
Zandramas (the big bad of the series) and books of prophecy.
This could still be an effective plot trigger but for another decision of
Eddings that becomes obvious in Demon Lord
of Karanda (the third book): the second continent of this world, unlike
the
Kingdoms
of Hats world-building of the Belgariad, is mostly uniform. There are
large cities, tons of commercial activity, and a fairly effective and
well-run empire, with only a little local variation. In some ways it's a
welcome break from Eddings's previous characterization by stereotype, but
there isn't much in the way of local happenings for the characters to get
entangled in.
Even more oddly, this continental empire, which the previous series set up
as the mysterious and evil adversaries of the west akin to Sauron's domain
in Lord of the Rings, is not mysterious to some of the party at
all. Silk, the Drasnian spy who is a major character in both series, has
apparently been running a vast trading empire in Mallorea. Not only has
he been there before, he has houses and factors and local employees in
every major city and keeps being distracted from the plot by his cutthroat
capitalist business shenanigans. It's as if the characters ventured into
the heart of the evil empire and found themselves in the entirely normal
city next door, complete with restaurant recommendations from one of their
traveling companions.
I think this is an intentional subversion of the normal fantasy plot by
Eddings, and I kind of like it. We have met the evil empire, and they're
more normal than most of the good guys, and both unaware and entirely
uninterested in being the evil empire. But in terms of dramatic plot
structure, it is such an odd choice. Combined with the heroes
being so absurdly powerful that they have no reason to take most dangers
seriously (and indeed do not), it makes this book remarkably anticlimactic
and weirdly lacking in drama.
And yet I kind of enjoyed reading it? It's oddly quiet and comfortable
reading. Nothing bad happens, nor seems very likely to happen. The
primary plot tension is Belgarath trying to figure out the plot of the
series by tracking down prophecies in which the plot is written down with
all of the dramatic tension of an irritated rare book collector. In the
middle of the plot, the characters take a detour to investigate an
alchemist who is apparently immortal, featuring a university on Melcena
that could have come straight out of a Discworld novel, because
investigating people who spontaneously discover magic is of arguably equal
importance to saving the world. Given how much the plot is both on rails
and clearly willing to wait for the protagonists to catch up, it's hard to
argue with them. It felt like a side quest in a video game.
I continue to find the way that Eddings uses prophecy in this series to be
highly amusing, although there aren't nearly enough moments of the
prophecy giving Garion stage direction. The basic concept of two
competing prophecies that are active characters in the world attempting to
create their own sequence of events is one that would support a better
series than this one. It's a shame that Zandramas, the main villain, is
rather uninteresting despite being female in a highly sexist society,
highly competent, a different type of shapeshifter (I won't say more to
avoid spoilers for earlier books), and the anchor of the other prophecy.
It's good material, but Eddings uses it very poorly, on top of making the
weird decision to have her talk like an extra in a Shakespeare play.
This book was astonishingly pointless. I think the only significant plot
advancement besides map movement is picking up a new party member (who was
rather predictable), and the plot is so completely on rails that the
characters are commenting about the brand of railroad ties that Eddings
used. Ce'Nedra continues to be spectacularly irritating. It's not, by
any stretch of the imagination, a good book, and yet for some reason I
enjoyed it more than the other books of the series so far. Chalk one up
for brain candy when one is in the right mood, I guess.
Followed by The Seeress of Kell, the epic (?) conclusion.
Rating: 6 out of 10
Windows 10 added a new PIN login method, which is an optional login method instead of an Internet based password through Microsoft or a Domain password through Active Directory. Here is a web page explaining some of the technology (don t watch the YouTube video) [1]. There are three issues here, whether a PIN is any good in concept, whether the specifics of how it works are any good, and whether we can copy any useful ideas for Linux.
Is a PIN Any Good?
A PIN in concept is a shorter password. I think that less secure methods of screen unlocking (fingerprint, face unlock, and a PIN) can be reasonably used in less hostile environments. For example if you go to the bathroom or to get a drink in a relatively secure environment like a typical home or office you don t need to enter a long password afterwards. Having a short password that works for short time periods of screen locking and a long password for longer times could be a viable option.
It could also be an option to allow short passwords when the device is in a certain area (determined by GPS or Wifi connection). Android devices have in the past had options to disable passwords when at home.
Is the Windows 10 PIN Any Good?
The Windows 10 PIN is based on TPM security which can provide real benefits, but this is more of a failure of Windows local passwords in not using the TPM than a benefit for the PIN. When you login to a Windows 10 system you will be given a choice of PIN or the configured password (local password or AD password).
As a general rule providing a user a choice of ways to login is bad for security as an attacker can use whichever option is least secure.
The configuration options for Windows 10 allow either group policy in AD or the registry to determine whether PIN login is allowed but doesn t have any control over when the PIN can be used which seems like a major limitation to me.
The claim that the PIN is more secure than a password would only make sense if it was a viable option to disable the local password or AD domain password and only use the PIN. That s unreasonably difficult for home users and usually impossible for people on machines with corporate management.
Ideas For Linux
I think it would be good to have separate options for short term and long term screen locks. This could be implemented by having a screen locking program use two different PAM configurations for unlocking after short term and long term lock periods.
Having local passwords based on the TPM might be useful. But if you have the root filesystem encrypted via the TPM using systemd-cryptoenroll it probably doesn t gain you a lot. One benefit of the TPM is limiting the number of incorrect attempts at guessing the password in hardware, the default is allowing 32 wrong attempts and then one every 10 minutes. Trying to do that in software would allow 32 guesses and then a hardware reset which could average at something like 32 guesses per minute instead of 32 guesses per 320 minutes. Maybe something like fail2ban could help with this (a similar algorithm but for password authentication guesses instead of network access).
Having a local login method to use when there is no Internet access and network authentication can t work could be useful. But if the local login method is easier then an attacker could disrupt Internet access to force a less secure login method.
Is there a good federated authentication system for Linux? Something to provide comparable functionality to AD but with distributed operation as a possibility?
At the end of March, the source code to StackRox was released,
following the 2021 acquisition by Red Hat. StackRox is a Kubernetes security
tool which is now badged as Red Hat Advanced Cluster Security (RHACS),
offering features such as vulnerability management, validating cluster
configurations against CIS benchmarks, and some runtime behaviour analysis. In
fact, it s such a diverse range of features that I have trouble getting my head
round it from the product page or even the documentation.
Source code is available via the StackRox organisation on GitHub,
and the most obviously interesting repositories seem to be:
stackrox/scanner, the vulnerability
scanner, also in Go. From a first glance at the go.mod file, it does not seem
to share much code with Clair, which is
interesting.
stackrox/collector, the runtime
analysis component, in C++ but also with hooks into the kernel.
My initial curiosity has been around the collector , to better understand what
runtime behaviour the tool can actually pick up. I was intrigued to find that
the actual kernel component is a patched version of Falco s kernel module/eBPF probes;
a few features are disabled compared to Falco, e.g. page faults and signal events.
There s a list of supported syscalls in
driver/syscall_table.c,
which seems to have drifted slightly or be slightly behind the upstream Falco
version? In particular I note the absence of io_uring, but given RHACS is
mainly deployed on Linux 4.18 at the moment (RHEL 8) this is probably a
non-issue. (But relevant if anyone were to run it on newer kernels.)
That s as far as I ve got for now. Red Hat are making great efforts to reach
out to the community; there s a Slack channel,
and office hours recordings,
and a community hub to explore further. It s
great to see new free software projects created through acquisition in this
way - I m not sure I remember seeing a comparable example.
Back in April 2021 I introduced a simple text-based adventure game, The Lighthouse of Doom, which I'd written in Z80 assembly language for CP/M systems.
As it was recently the 40th Anniversary of the ZX Spectrum 48k, the first computer I had, and the reason I got into programming in the first place, it crossed my mind that it might be possible to port my game from CP/M to the ZX Spectrum.
To recap my game is a simple text-based adventure game, which you can complete in fifteen minutes, or less, with a bunch of Paw Patrol easter-eggs.
You enter simple commands such as "up", "down", "take rug", etc etc.
You receive text-based replies "You can't see a telephone to use here!".
My code is largely table-based, having structures that cover objects, locations, and similar state-things. Most of the code involves working with those objects, with only a few small platform-specific routines being necessary:
Clearing the screen.
Pausing for "a short while".
Reading a line of input from the user.
Sending a $-terminated string to the console.
etc.
My feeling was that I could replace the use of those CP/M functions with something custom, and I'd have done the 99% of the work. Of course the devil is always in the details.
Let's start. To begin with I'm lucky in that I'm using the pasmo assembler which is capable of outputting .TAP files, which can be loaded into ZX Spectrum emulators.
I'm not going to walk through all the code here, because that is available within the project repository, but here's a very brief getting-started guide which demonstrates writing some code on a Linux host, and generating a TAP file which can be loaded into your favourite emulator. As I needed similar routines I started working out how to read keyboard input, clear the screen, and output messages which is what the following sample will demonstrate..
First of all you'll need to install the dependencies, specifically the assembler and an emulator to run the thing:
# apt install pasmo spectemu-x11
Now we'll create a simple assembly-language file, to test things out - save the following as hello.z80:
; Code starts here
org 32768
; clear the screen
call cls
; output some text
ld de, instructions ; DE points to the text string
ld bc, instructions_end-instructions ; BC contains the length
call 8252
; wait for a key
ld hl,0x5c08 ; LASTK
ld a,255
ld (hl),a
wkey:
cp (hl) ; wait for the value to change
jr z, wkey
; get the key and save it
ld a,(HL)
push af
; clear the screen
call cls
; show a second message
ld de, you_pressed
ld bc, you_pressed_end-you_pressed
call 8252
;; Output the ASCII character in A
ld a,2
call 0x1601
pop af
call 0x0010
; loop forever. simple demo is simple
endless:
jr endless
cls:
ld a,2
call 0x1601 ; ROM_OPEN_CHANNEL
call 0x0DAF ; ROM_CLS
ret
instructions:
defb 'Please press a key to continue!'
instructions_end:
you_pressed:
defb 'You pressed:'
you_pressed_end:
end 32768
Now you can assemble that into a TAP file like so:
$ pasmo --tapbas hello.z80 hello.tap
The final step is to load it in the emulator:
$ xspect -quick-load -load-immed -tap hello.tap
The reason I specifically chose that emulator was because it allows easily loading of a TAP file, without waiting for the tape to play, and without the use of any menus. (If you can tell me how to make FUSE auto-start like that, I'd love to hear!)
I wrote a small number of "CP/M emulation functions" allowing me to clear the screen, pause, prompt for input, and output text, which will work via the primitives available within the standard ZX Spectrum ROM. Then I reworked the game a little to cope with the different screen resolution (though only minimally, some of the text still breaks lines in unfortunate spots):
The end result is reasonably playable, even if it isn't quite as nice as the CP/M version (largely because of the unfortunate word-wrapping, and smaller console-area). So now my repository contains a .TAP file which can be loaded into your emulator of choice, available from the releases list.
Here's a brief teaser of what you can expect:
Outstanding bugs? Well the line-input is a bit horrid, and unfortunately this was written for CP/M accessed over a terminal - so I'd assumed a "standard" 80x25 resolution, which means that line/word-wrapping is broken in places.
That said it didn't take me too long to make the port, and it was kinda fun.
The Reproducible Builds project relies on several projects, supporters
and sponsors for financial support, but they are
also valued as ambassadors who spread the word about our project and the work
that we do.
This is the fourth instalment in a series featuring the projects, companies
and individuals who support the Reproducible Builds project. If you are a
supporter of the Reproducible Builds project (of whatever size) and would like
to be featured here, please let get in touch with us at
contact@reproducible-builds.org.
We started this series by
featuring the Civil Infrastructure Platform
project and followed this up with a
post about the Ford Foundation
as well as a recent one about ARDC. However,
today, we ll be talking with Meder Kydyraliev of the
Google Open Source Security Team (GOSST).
Chris Lamb: Hi Meder, thanks for taking the time to talk to us today. So, for
someone who has not heard of the Google Open Source Security Team (GOSST)
before, could you tell us what your team is about?
Meder: Of course. The Google Open Source Security Team (or GOSST ) was created
in 2020 to work with the open source community at large, with the goal of
making the open source software that everyone relies on more secure.
Chris: What kinds of activities is the GOSST involved in?
Meder: The range of initiatives that the team is involved in recognizes the
diversity of the ecosystem and unique challenges that projects face on their
security journey. For example, our sponsorship of sos.dev
ensures that developers are rewarded for security improvements to open source
projects, whilst the long term work on improving
Linux kernel security
tackles specific kernel-related vulnerability classes.
Many of the projects GOSST is involved with aim to make it easier for
developers to improve security through automated assessment
(Scorecards and
Allstar) and vulnerability discovery tools
(OSS-Fuzz, ClusterFuzzLite,
FuzzIntrospector), in addition to
contributing to infrastructure to make adopting certain best practices
easier. Two great examples of best practice efforts are
Sigstore for artifact signing and
OSV for automated vulnerability management.
Chris: The usage of open source software has exploded in the last decade, but
supply-chain hygiene and best practices has seemingly not kept up. How does
GOSST see this issue and what approaches is it taking to ensure that past and
future systems are resilient?
Meder: Every open source ecosystem is a complex environment and that awareness
informs our approaches in this space. There are, of course, no silver
bullets , and long-lasting and material supply-chain improvements requires
infrastructure and tools that will make lives of open source developers easier,
all whilst improving the state of the wider software supply chain.
As part of a broader effort, we created the Supply-chain Levels for Software Artifacts
framework that has been used internally at Google to protect
production workloads. This framework describes the best practices for source
code and binary artifact integrity, and we are engaging with the community on
its refinement and adoption. Here, package managers (such as PyPI, Maven
Central, Debian, etc.) are an essential link in the software supply chain due
to their near-universal adoption; users do not download and compile their own
software anymore. GOSST is starting to work with package managers to explore
ways to collaborate together on improving the state of the supply chain and
helping package maintainers and application developers do better all with the
understanding that many open source projects are developed in spare time as a
hobby!
Solutions like this,
which are the result of collaboration between GOSST and GitHub,
are very encouraging as they demonstrate a way to materially strengthen
software supply chain security with readily available tools, while also
improving development workflows.
For GOSST, the problem of supply chain security also covers vulnerability
management and solutions to make it easier for everyone to discover known
vulnerabilities in open source packages in a scalable and automated way. This
has been difficult in the past due to lack of consistently
high-quality data in an easily-consumable format. To address this, we re working
on infrastructure (OSV.dev) to make vulnerability data more easily accessible
as well as a widely adopted and automation friendly data format.
Chris: How does the Reproducible Builds effort help GOSST achieve its goals?
Meder: Build reproducibility has a lot of attributes that are attractive as
part of generally good build hygiene . As an example, hermeticity, one of
requirements to meet SLSA level 4,
makes it much easier to reason about the dependencies of a piece of software.
This is an enormous benefit during vulnerability or supply chain incident
response.
On a higher level, however, we always think about reproducibility from the
viewpoint of a user and the threats that reproducibility protects them from.
Here, a lot of progress has been made, of course, but a lot of work remains to
make reproducibility part of everyone s software consumption practices.
Chris: So if someone wanted to know more about GOSST or follow the team s
work, where might they go to look?
Meder: We post regular updates on Google s Security Blog
and on the Linux hardening mailing list.
We also welcome community participation in the projects we work on! See any of
the projects linked above or OpenSSF s GitHub projects page
for a list of efforts you can contribute to directly if you want to get
involved in strengthening the open source ecosystem.
Chris: Thanks for taking the time to talk to us today.
Meder: No problem. :)
For more information about the Reproducible Builds project, please see our website at
reproducible-builds.org. If you are interested in
ensuring the ongoing security of the software that underpins our civilisation
and wish to sponsor the Reproducible Builds project, please reach out to the
project by emailing
contact@reproducible-builds.org.
It is now widely known that Ubuntu 22.04 LTS (Jammy Jellyfish) ships Firefox as a snap, but some people (like me) may prefer installing it from .deb packages to retain control over upgrades or to keep extensions working.
Luckily there is still a PPA serving firefox (and thunderbird) debs at https://launchpad.net/~mozillateam/+archive/ubuntu/ppa maintained by the Mozilla Team. (Thank you!)
You can block the Ubuntu archive s version that just pulls in the snap by pinning it:
I ve currently got Covid, I believe I caught it on the 11th of April (my first flight since the pandemic started) with a runny nose on the 13th and a positive RAT on the evening of the 14th. I got an official PCR test on the 16th with a positive result returned on the 17th. I think I didn t infect anyone else (yay)! Now I seem mostly OK but still have a lack of energy, sometimes I suddenly feel tired after 20 minutes of computer work.
The progression of the disease was very different to previous cold/flu diseases that I have had. What I expect is to start with a cough or runny nose, escalate with more of that, have a day or two of utter misery with congestion, joint pain, headache, etc, then have it suddenly decrease overnight. For Covid I had a runny nose for a couple of days which went away then I got congestion in my throat with serious coughing such that I became unable to speak. Then the coughing went away and I had a really bad headache for a day with almost no other symptoms. Then the headache went away and I was coughing a bit the next day. The symptoms seemed to be moving around my body.
I got a new job and they wanted me to fly to the head office to meet the team, I apparently got it on the plane a day before starting work. I ve discussed this with a manager and stated my plan to drive instead of fly in future. It s only a 7 hour drive and it s not worth risking the disease to save 3-4 hours travel time, or even the 5 hours travel I d have saved if the airports were working normally (apparently a lot of airport staff are off sick so there s delays). Given the flight delays and the fact that I was advised to arrive extra early at the airport I ended up taking almost 7 hours for the entire trip!
7 hours driving is a bit of effort, but sitting in an airport waiting for a delayed flight while surrounded by diseased people isn t fun either.
My attempt to travel to the UK by train last year didn t go quite as well as I expected. As I mentioned in that blog post, the NightJet to Brussels was cancelled, forcing me to fly instead. This disappointed me so much that I actually unpublished the blog post minutes after it was originally put online. The timing was nearly perfect: I type make publish and I get an email from BB saying they don t know if my train is going to run. Of course it didn t, as Deutsche Bahn workers went ahead with their strike. The blog post sat in the drafts for more than half a year until yesterday, when I finally updated and published it.
The reason I have finally published it is that I m going to the UK by train once again. Now, unless railways decide to hold a strike again, fully by train both ways. Very expensive, especially compared to the price of Ryanair flights to my destination. Unfortunately, even though Eurostar added more daily services, they re still not cheap, especially on a shorter notice. This seems to apply to the BB s NightJet even more: I tried many routes between Vienna and London, and the cheapest still seemed to be the connection through Brussels.
While researching the prices of the tickets, it seems all booking systems decided to stop co-operating. The Trainline refused to let me look up any trains at all, even with all tracking and advertisement allowed, SNCF kepts showing me overly generic errors (Sorry, an error has occurred.), while the GWR booking system kept crashing with a 500 Internal Server Error for about two hours.
Trainline, GWR and SNCF kept crashing
Eventually, having spent a lot of time and money, I ve booked my trains to, within and back from England. This time, Cambridge is among the destinations.
The complete route
Date
Station
Arrival
Departure
Train
26.4
Bratislava hl.st.
18:37
REX 2529
Wien Hbf
19:44
20:13
NJ 40490
27.4
Bruxelles-Midi
9:54
15:56
EST 9145
London St Pancras
17:01
17:43
ThamesLink
Cambridge
18:43
I m not sure about it yet, but I may end up taking an earlier train from Bratislava just to ensure there s enough time for the change in Vienna; similarly, I m not sure how much time I will be spending at St Pancras, so I may take one of the later trains.
P.S. The maps in this and other posts were created using uMap; the map data come from OpenStreetMap. The train route visualisation was generated with help of signal.eu.org.
My first self-designed functional 3D print is a replacement
battery cover for a LED fake-candle that my daughter uses
as a night-light.
I measured the original cover (we have three of the candles)
using a newly-purchased micrometer and tried to re-create it
in OpenSCAD. I skipped the screw-hole that is for securing
the cover as we don't use that.
I sliced it using Cura and printed it using PETG on our
office 3D printer, a Ender 3. Print time was about an hour.
To my amazement, my first take fits snugly!
I've uploaded the OpenSCAD source here: batterycover.scad. It's covered
under the terms of Creative Commons Attribution-ShareAlike 4.0 International
(CC BY-SA 4.0).
This post was written in August 2021. Just as I was going to publish it, I received an email from BB stating that due to a railway strike in Germany my night train would be cancelled. Since the rest of the trip has already been booked well in advance, I had to take a plane to Charleroi and a bus to Brussels to catch my Eurostar. Ultimately, I ended up publishing it in April 2022, just as I m about to leave for a fully train-powered trip to the UK once again.
Before the pandemic started, I planned to use the last months of my then-expiring UK visa and go to England by train. I ve completed two train long journeys by that time already, to Brussels and to Belarus and Ukraine, but this would be something quite different, as I wanted to have multiple stops on my way, use night trains where it made sense, and to go through the Channel Tunnel.
The Channel Tunnel fascinated me since my childhood; I first read about it in the Soviet Science and Life magazine () when I was seven. I ve never had the chance to use it though, since to board any train going though it I d first need to get to France, Belgium or the Netherlands, making it significantly more expensive than the cheap 30 Ryanair flights to Stansted.
As the coronavirus spread across the world, all of my travel plans along with plans for a sabbatical had to be cancelled. During 2020, I only managed to go on two weekend trips to Prague and Budapest, followed by a two-weeks holiday on Crete (we returned just a couple of weeks before the infection numbers rose and lockdowns started). I do realise that a lot of people couldn t even have this much because the situation in their countries was much worse we were lucky to have had at least some travel.
Fast forward to August 2021, I m fully vaccinated, I once again have a UK visa for five years, and the UK finally recognises the EU vaccination passports yay! I can finally go to Devon to see my mother and sister again. By train, of course.
Compared to my original plan, this journey will be different: about the same or even more expensive than I originally planned, but shorter and with fewer stops on the way. My original plan would be to take multiple trains from Bratislava to France or Belgium and complete this segment of the trip in about three days, enjoying my stay in a couple of cities on the way. Instead, I m taking a direct NightJet from Vienna to Brussels, not stopping anywhere on the way.
Train route from Bratislava to Brussels
Since I was booking my trip just two weeks ahead, the price of the ticket is not that I hoped for, but much higher: 109 for the ticket itself and 60 for the berth (advance bookings could be about twice as cheap).
Next, to London! Eurostar is still on a very much reduced schedule, running one train only from Amsterdam through Brussels and Lille to London each day. This means, of course, higher ticket prices (I paid about 100 for the ticket) and longer waiting time in Brussels my sleeper arrives about 10 am, but the Eurostar train is scheduled to depart at 3 pm.
Train route from Brussels to London
The train makes a stop in Lille, which I initially suspected to be risky as at the time when I booked my tickets, as at the time France was on the amber plus list for the UK, requiring a quarantine upon arrival. However, Eurostar announced that they will assign travellers from Lille to a different carriage to avoid other passengers having to go to quarantine, but recently France was taken off the amber plus list.
The train fare system in the UK is something I don t quite understand, as sometimes split tickets are cheaper, sometimes they re expensive, sometimes prices for the same service at different times can be vastly different, off-peak tickets don t say what exactly off-peak means (very few people in the UK are asked were able to tell me when exactly off-peak hours are). Curiously, transfers between train stations using London Underground services can be included into railway tickets, but some last mile connection like Exeter to Honiton cannot (but this used to be possible). Both GWR.com and TrainLine refused to sell me a single ticket from London to Honiton through Exeter, insisting I split the ticket at Exeter St Davids or take the slower South Western train to Honiton via Salisbury and Yeovil. I ended up buying a 57 ticket from Paddington to Exeter St Davids with the first segment being the London Underground from St Pancras, and a separate 7.70 ticket to Honiton.
Change of trains in LondonChange of trains in Exeter
Date
Station
Arrival
Departure
Train
12.8
Bratislava-Petr alka
18:15
REX 7756
Wien Hbf
19:15
19:53
NJ 50490
13.8
Bruxelles-Midi
9:55
15:06
EST 9145
London St Pancras
16:03
16:34
TfL
London Paddington
16:49
17:04
GWR 59231
Exeter St Davids
19:19
19:25
SWR 52706
Honiton
19:54
Unfortunately, due to the price of the tickets, I m taking a 15 Ryanair flight back
Update after the journey
Since I flew to Charleroi instead of comfortably sleeping in a night train, I had to put up with inconveniences of airports, including cumbersome connections to the nearby cities. The only reasonable way of getting from Charleroi to Brussels is an overcrowded bus which takes almost an hour to arrive. I used to take this bus when I tried to save money on my way to FOSDEM, and I must admit it s not something I missed.
Boarding the Eurostar train went fine, my vaccination passport and Covid test wasn t really checked, just glanced at. The waiting room was a bit of a disappointment, with bars closed and vending machines broken. Since it was underground, I couldn t even see the trains until the very last moment when we were finally allowed on the platform. The train itself, while comfortable, disappointed me with the bistro carriage: standing only, instant coffee, poor selection of food and drinks. I m glad I bought some food at Carrefour at the Midi station!
When I arrived in Exeter, I soon found out why the system refused to sell me a through ticket: 6 minutes is not enough to change trains at Exeter St Davids! Or, it might have been if I took the right footbridge but I took the one which led into a very talkative (and slow!) lift. I ended up running to the train just as it closed the doors and departed, leaving me tin Exeter for an hour until. I used this chance and walked to Exeter Central, and had a pint in a conveniently located pub around the corner.
P.S. The maps in this and other posts were created using uMap; the map data come from OpenStreetMap. The train route visualisation was generated with help of the Raildar.fr OSRM instance.
In response to my post about Android phones without Google Play [1] I received an email recommending Joplin for notes on Android [2].
Joplin supports storing notes on a number of protocols including Nextcloud and WebDAV. I setup WebDAV because it s easiest, here is Digital Ocean instructions for WebDAV on Apache [3]. That basically works. One problem for my use case is that the Joplin client doesn t support accounts on multiple servers and the only released way of sharing notes between accounts is using the paid Joplin Cloud service.
There is a Joplin Server in beta which allows sharing notes but that is designed to run in Docker and is written in TypeScript so it was too much pain to setup. One mitigating factor is that there are Notebooks which are collections of notes. So if multiple people who trust each other share an account they can have Notebooks for personal notes and a Notebook for shared notes.
There is also a Snap install of the client for Debian [4]. Snap isn t my favourite way of doing things but packaging JavaScript programs will probably be painful so I ll do it if I continue using Joplin.
Finally, TIL, what can all be the reason for systemd services to hang indefinitely. The internet is flooded with numerous reports on this topic but no clear answers. So no more uselessly marked workarounds like: systemctl daemon-reload and systemctl-daemon-reexec for this scenario.
The scene would be something along the lines of:
The snapper-timeline service is important to me and it not running for months is a complete failure. Disappointingly, commands like systemctl --failed do not report of this oddity. The overall system status is reported to be fine, which is completely incorrect.
Thankfully, a kind soul s comment gave the hint. The problem is that you could be having certain services in Activating status, which thus blocks all other services; quietly. So much for the unnecessary fun.
Looking further, in my case, it was:
That was it. I knew the systemd-timesyncd service, in the past, had given me enough headaches. And so was it this time, just quietly doing it all again.
rrs@priyasi:~$ systemctl status systemd-time-wait-sync.service
systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset>
Active: activating (start) since Fri 2022-04-22 13:14:25 IST; 1min 38s ago
Docs: man:systemd-time-wait-sync.service(8) Main PID: 11090(systemd-time-wa) Tasks: 1(limit: 37051) Memory: 836.0K
CPU: 7ms
CGroup: /system.slice/systemd-time-wait-sync.service
11090 /lib/systemd/systemd-time-wait-sync
Apr 22 13:14:25 priyasi systemd[1]: Starting Wait Until Kernel Time Synchronized...
Apr 22 13:14:25 priyasi systemd-time-wait-sync[11090]: adjtime state 5 status 40 time Fri 2022->
13:16 => 3
Dear LazyWeb, anybody knows of why the systemd-time-wait-sync service would hang indefinitely? I ve had identical setups on many machines, in the same network, where others don t exhibit this problem.
The TimeoutStartSec=infinity is definitely an attribute that shouldn t be shipped in any system services. There are use cases for it but that should be left for local admins to explicitly decide. Hanging for infinity is not a desired behavior for a system service.
In figuring all this out, today I learnt the handy systemctl list-jobs command, which will give the list of active running/blocked/waiting jobs.
There has been a
flurry of activity on the Debian mailing lists ever since Steve
McIntyre raised the issue of including non-free firmware as part of
official Debian installation images.
Firstly I should point out that I am in complete agreement with Steve s proposal to include non-free firmware as part of an installation image. Likewise I think that we should have a separate archive section for firmware. Because without doing so it will soon become almost impossible to install onto any new hardware. However, as always the issue is more nuanced than a first glance would suggest.
Lets start by
defining what is firmware?
Firmware is any
software that runs outside the orchestration of the operating system.
Typically firmware will be executed on a processor(s) separate from
the processor(s) running the OS, but this does not need to be the
case.
As Debian we
are content that our systems can operate using fully free and open
source software and firmware. We can install our OS without needing
any non-free firmware.
This is an illusion!
Each and every PC
platform contains non-free firmware
It may be possible to run free firmware on some Graphics controllers, Wi-Fi chip-sets, or Ethernet cards and we can (and perhaps should) choose to spend our money on systems where this is the case. When installing a new system we might still be forced to hold our nose and install with non-free firmware on the peripheral before we are able to upgrade it to FLOSS firmware later if this is exists or is even possible to do so. However after the installation we are running a full FLOSS system in terms of software and firmware.
We all (almost
without exception) are running propitiatory firmware whether we like
it or not.
Even after carefully selecting graphics and network hardware with FLOSS firmware options we still haven t escaped from non-free-firmware. Other peripherals contain firmware too each keyboard, disk (SSDs and Spinning rust). Even your USB memory stick that you use to contain the Debian installation image contains a microcontroller and hence also contains firmware that runs on it.
Much of this
firmware can not even be updated.
Some can be
updated, but is stored in FLASH ROM and the hardware vendor has
defeated all programming methods (possibly circumnavigated with a
hardware mod).
Some of it can
be updated but requires external device programmers (and often the
programming connections are a series of test points dotted around
the board and not on a header in order to make programming as
difficult as possible).
Sometimes the
firmware can be updated from within the host operating system (i.e.
Debian)
Sometimes, as
Steve pointed out in his post, the hardware vendor has enough
firmware on a peripheral to perform basic functions perhaps
enough to install the OS, but requires additional firmware to enable
specific feature (i.e. higher screen resolutions, hardware
accelerated functions etc.)
Finally some
vendors don t even bother with any non-volatile storage beyond a
basic boot loader and firmware must be loaded before the device can
be used in any mode.
What about the motherboard? If we are lucky we might be able to run a FLOSS implementation of the UEFI subsystem (edk2/tianocore for example), indeed the non AMD64/i386 platforms based around ARM, MIPS architectures are often the most free when it comes to firmware.
What about the microcode on the processor? Personally I wasn t aware that that this was updatable firmware until the Spectre and Meltdown classes of vulnerabilities arose a few years back.
So back to Debian
images including non-free firmware.
This is specifically to address the last two use cases mentioned above, i.e. where firmware needs to be loaded to achieve a minimum functioning of a device. Although it could also include motherboard support, and microcode as well.
As far as I can tell
the proposal exists for several reasons:
#1 Because some freely distributable firmware is required for
more and more devices, in order to install Debian, or because whilst
Debian can be installed a desktop environment can not be started or
fully function
#2 Because frankly it is less work to produce, test and maintain fewer installation images As someone who performs tests on our images, this clearly gets my vote :-)
and perhaps most important of all..
#3 Because our least experienced users, and new users will download an official image and give up if things don t just work TM
Steve s proposal
option 5 would address theses issues and I fully support it.
I would love to see
separate repositories for firmware and firmware-none free.
Additionally to accompany firmware non-free I would like to have
information on what the firmware actually does. Can I run my
hardware without it, what function(s) are limited without the
firmware, better yet is there a FLOSS equivalent that I can load
instead? Is this something that we can present in Debian installer?
I would love not to require non-free firmware, but if I can t,
I would love if DI would enable a user to make an informed choice as
to what, if any, firmware is installed.
Should we be
requesting (requiring?) this information for any non-free firmware
image that we carry in the archive?
Finally lets
consider firmware in the wider general case, not just the case where
we need to load firmware from within Debian each and every boot.
Personally I am
annoyed whenever a hardware manufacturer has gone out of their way to
prevent firmware updates. Lets face it software contains bugs, and
we can assume that the software making up a firmware image will as
well.
Critical (security)
vulnerabilities found in firmware, especially if this runs on the
same processor(s) as the OS can impact on the wider system, not just
the device itself. This will mean that, without updatable firmware,
the hardware itself should be withdrawn from use whilst it would
otherwise still function. By preventing firmware updates vendors are
forcing early obsolescence in the hardware they sell, perhaps good
for their bottom line, but certainly no good for users or the
environment.
Here I can practice
what I preach. As an Electronic Engineer / Systems architect I have
been beating the drum for In System Updatable firmware for ALL
programmable devices in a system, be it a simple peripheral or a
deeply embedded system. I can honestly say that over the last 20
years (yes I have been banging this particular drum for that long) I
have had 100% success in arguing this case commercially. Having
device programmers in R&D departments is one thing, but that is
additional cost for production, and field service. Needing custom
programming headers or even a bed of nails fixture to connect your
target device to a programmer is more trouble than it is worth.
Finally, the ability to update firmware in the field means that you
can launch your product on schedule, make a sale and ship to a
customer even if the first thing that you need to do is download an
update. Offering that to any project manager will make you very
popular indeed.
So what if this
firmware is non-free? As long as the firmware resides in
non-volatile media without needing the OS to interact with it, we as
a project don t need to carry it in our archives. And we as
principled individuals can vote with our feet and wallets by choosing
to purchase devices that have free firmware.
But where that isn t
an option, I ll take updatable but non-free firmware over non-free
firmware that can not be updated any day of the week.
Sure, the
manufacture can choose to no longer support the firmware, and it is
shocking how soon this happens often in the consumer market, the
manufacture has withdrawn support for a product before it even
reaches the end user (In which case we should boycott that
manufacture in future until they either change their ways of go
bust). But again if firmware can be updated in system that
would at least allow the possibility of open firmware to arise.
Indeed the only commercial case I have seen to argue against
updatable firmware has been either for DRM, in which case good
lets get rid of both, or for RF licence compliance, and even then it
is tenuous because in this case the manufacture wants ISP for its own
use right up until a device is shipped out the door, typically
achived by blowing one time programmable fuse links .
I have 2 very useful shell scripts related to resizing consoles. The first is imaginatively called 
If you intend to apply for a
After two long years of COVID hiatus, local Debian events in Montreal are back!
Last Sunday, nine of us met at 
If everything goes according to plan, our next meeting should be sometime in
June. If you are interested, the best way to stay in touch is either to
Back in April 2021 I introduced 
Trainline, GWR and SNCF kept crashing
The complete route
Train route from Bratislava to Brussels
Train route from Brussels to London
Change of trains in London
Change of trains in Exeter
Finally, TIL, what can all be the reason for systemd services to hang indefinitely. The internet is flooded with numerous reports on this topic but no clear answers. So no more uselessly marked workarounds like: 
There has been a
flurry of activity on the Debian mailing lists ever since Steve
McIntyre raised the issue of including non-free firmware as part of
official Debian installation images.
Firstly I should point out that I am in complete agreement with Steve s proposal to include non-free firmware as part of an installation image. Likewise I think that we should have a separate archive section for firmware. Because without doing so it will soon become almost impossible to install onto any new hardware. However, as always the issue is more nuanced than a first glance would suggest.
Lets start by
defining what is firmware?
Firmware is any
software that runs outside the orchestration of the operating system.
Typically firmware will be executed on a processor(s) separate from
the processor(s) running the OS, but this does not need to be the
case.
As Debian we
are content that our systems can operate using fully free and open
source software and firmware. We can install our OS without needing
any non-free firmware.
This is an illusion!
Each and every PC
platform contains non-free firmware
It may be possible to run free firmware on some Graphics controllers, Wi-Fi chip-sets, or Ethernet cards and we can (and perhaps should) choose to spend our money on systems where this is the case. When installing a new system we might still be forced to hold our nose and install with non-free firmware on the peripheral before we are able to upgrade it to FLOSS firmware later if this is exists or is even possible to do so. However after the installation we are running a full FLOSS system in terms of software and firmware.
We all (almost
without exception) are running propitiatory firmware whether we like
it or not.
Even after carefully selecting graphics and network hardware with FLOSS firmware options we still haven t escaped from non-free-firmware. Other peripherals contain firmware too each keyboard, disk (SSDs and Spinning rust). Even your USB memory stick that you use to contain the Debian installation image contains a microcontroller and hence also contains firmware that runs on it.