• user team:
  • creates new project with cookiecutter template
  • makes modification on their code, including on code provided by template
• meanwhile, provider team:
  • makes modifications to cookiecutter template
  • releases new template version
  • asks his users to update code brought by template using cruft
• user team then:
  • runs cruft to update template code
  • discovers a lot of code conflicts (similar to git merge conflicts)
  • often rolls back cruft update and gives up on template update

• Assume that template are one shot. Template update are not practical in the long run.
• Make sure that template are as thin as possible. They should contain minimal logic.
• Move most if not all logic in separate libraries or scripts that are owned by provider team. This way update coming from provider team can be managed like external dependencies by upgrading the version of a dependency.

1. reproduce.debian.net
2. Two new academic papers
3. Distribution work
4. On our mailing list
5. Upstream patches
6. diffoscope
7. Website updates
8. Reproducibility testing framework

reproduce.debian.net The last few months saw the introduction of reproduce.debian.net. Announced at the recent Debian MiniDebConf in Toulouse, reproduce.debian.net is an instance of rebuilderd operated by the Reproducible Builds project. Powering that is rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there. This month, however, we are pleased to announce that in addition to the existing amd64.reproduce.debian.net and i386.reproduce.debian.net architecture-specific pages, we now build for a three more architectures (for a total of five) arm64 armhf and riscv64.

Two new academic papers Giacomo Benedetti, Oreofe Solarin, Courtney Miller, Greg Tystahl, William Enck, Christian K stner, Alexandros Kapravelos, Alessio Merlo and Luca Verderame published an interesting article recently. Titled An Empirical Study on Reproducible Packaging in Open-Source Ecosystem, the abstract outlines its optimistic findings:

[We] identified that with relatively straightforward infrastructure configuration and patching of build tools, we can achieve very high rates of reproducible builds in all studied ecosystems. We conclude that if the ecosystems adopt our suggestions, the build process of published packages can be independently confirmed for nearly all packages without individual developer actions, and doing so will prevent significant future software supply chain attacks.

The entire PDF is available online to view.
In addition, Julien Malka, Stefano Zacchiroli and Th o Zimmermann of T l com Paris in-house research laboratory, the Information Processing and Communications Laboratory (LTCI) published an article asking the question: Does Functional Package Management Enable Reproducible Builds at Scale?. Answering strongly in the affirmative, the article s abstract reads as follows:

In this work, we perform the first large-scale study of bitwise reproducibility, in the context of the Nix functional package manager, rebuilding 709,816 packages from historical snapshots of the nixpkgs repository[. We] obtain very high bitwise reproducibility rates, between 69 and 91% with an upward trend, and even higher rebuildability rates, over 99%. We investigate unreproducibility causes, showing that about 15% of failures are due to embedded build dates. We release a novel dataset with all build statuses, logs, as well as full diffoscopes: recursive diffs of where unreproducible build artifacts differ.

As above, the entire PDF of the article is available to view online.

Distribution work There as been the usual work in various distributions this month, such as:

• Arch Linux developer kpcyrd has provided a status report for January 2025 related to Arch s progress towards full reproducibility. kpcyrd notes in particular progress towards to making a minimal reproducible bootable system that is, an Arch installation containing only reproducible packages.

• 10+ reviews of Debian packages were added, 11 were updated and 10 were removed this month adding to our knowledge about identified issues. A number of issue types were updated also.
• The FreeBSD Foundation announced that a planned project to deliver zero-trust builds has begun in January 2025 . Supported by the Sovereign Tech Agency, this project is centered on the various build processes, and that the primary goal of this work is to enable the entire release process to run without requiring root access, and that build artifacts build reproducibly that is, that a third party can build bit-for-bit identical artifacts. The full announcement can be found online, which includes an estimated schedule and other details.

• Finally, for openSUSE, Bernhard M. Wiedemann published another report for that distribution.

On our mailing list On our mailing list this month:

• Following-up to a substantial amount of previous work pertaining the Sphinx documentation generator, James Addison asked a question pertaining to the relationship between SOURCE_DATE_EPOCH environment variable and testing that generated a number of replies.
• Adithya Balakumar of Toshiba asked a question about whether it is possible to make ext4 filesystem images reproducible. Adithya s issue is that even the smallest amount of post-processing of the filesystem results in the modification of the Last mount and Last write timestamps.
• James Addison also investigated an interesting issue surrounding our disorderfs filesystem. In particular:

  FUSE (Filesystem in USErspace) filesystems such as disorderfs do not delete files from the underlying filesystem when they are deleted from the overlay. This can cause seemingly straightforward tests for example, cases that expect directory contents to be empty after deletion is requested for all files listed within them to fail.

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • Komikku (nocheck)
  • abseil-cpp (race)
  • dunst (date)
  • eclipse-egit (jar-mtime minor)
  • exaile (race)
  • gawk (bug)
  • gimp3 (png date)
  • intel (ASLR)
  • ioquake3 (debugsource contains date and time)
  • joker (sort)
  • libchardet
  • llama.cpp (random)
  • llama.cpp (-march=native-related issue)
  • nethack (race)
  • netrek-client-cow (date)
  • nvidia-modprobe (date)
  • nvidia-persistenced (date)
  • obs-build (toolchain bug, mis-parses changelog)
  • perl-libconfigfile (race)
  • pgvector (CPU)
  • python-Django4 (FTBFS-2038)
  • python-python-datamatrix (FTBFS)
  • qore-ssh2-module (GIGO-bug)
  • rpm (UID in cpio header from rpmbuild)
  • zig (CPU-related issue)
• Chris Lamb:
  • #1092251 filed against kmetronome.
  • #1092917 filed against rust-xh.
  • #1093198 filed against parser.
  • #1093199 filed against parser.
  • #1093201 filed against rsync.
  • #1094611 filed against wasistlos.
• Egbert Eich:
  • apptainer (randomness)
  • spack (core-count and date)
• Valentin Lefebvre:
  • uki-tool (toolchain)
• Marvin Friedrich:
  • cargo-packaging/rusty_v8 (upstream toolchain bugfix)
• James Addison:
  • #1092870 filed against binutils.
• Pol Dellaiera:
  • PHP Ecosystem: composer/composer#12090 which was then gracefully fixed by Jordi Boggiano at composer/composer#12263.

diffoscope diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 285, 286 and 287 to Debian:

• Security fixes:
  • Validate the --css command-line argument to prevent a potential Cross-site scripting (XSS) attack. Thanks to Daniel Schmidt from SRLabs for the report. [ ]
  • Prevent XML entity expansion attacks. Thanks to Florian Wilkens from SRLabs for the report.. [ ][ ]
  • Print a warning if we have disabled XML comparisons due to a potentially vulnerable version of pyexpat. [ ]
• Bug fixes:
  • Correctly identify changes to only the line-endings of files; don t mark them as Ordering differences only. [ ]
  • When passing files on the command line, don t call specialize( ) before we ve checked that the files are identical or not. [ ]
  • Do not exit with a traceback if paths are inaccessible, either directly, via symbolic links or within a directory. [ ]
  • Don t cause a traceback if cbfstool extraction failed.. [ ]
  • Use the surrogateescape mechanism to avoid a UnicodeDecodeError and crash when any decoding zipinfo output that is not UTF-8 compliant. [ ]
• Testsuite improvements:
  • Don t mangle newlines when opening test fixtures; we want them untouched. [ ]
  • Move to assert_diff in test_text.py. [ ]
• Misc improvements:
  • Drop unused subprocess imports. [ ][ ]
  • Drop an unused function in iso9600.py. [ ]
  • Inline a call and check of Config().force_details; no need for an additional variable in this particular method. [ ]
  • Remove an unnecessary return value from the Difference.check_for_ordering_differences method. [ ]
  • Remove unused logging facility from a few comparators. [ ]
  • Update copyright years. [ ][ ]

In addition, fridtjof added support for the ASAR .tar-like archive format. [ ][ ][ ][ ] and lastly, Vagrant Cascadian updated diffoscope in GNU Guix to version 285 [ ][ ] and 286 [ ][ ].
strip-nondeterminism is our sister tool to remove specific non-deterministic results from a completed build. This month version 1.14.1-1 was uploaded to Debian unstable by Chris Lamb, making the following the changes:

• Clarify the --verbose and non --verbose output of bin/strip-nondeterminism so we don t imply we are normalizing files that we are not. [ ]
• Bump Standards-Version to 4.7.0. [ ]

Website updates There were a large number of improvements made to our website this month, including:

• Arnout Engelen:
  • Update the link to NixOS reproducibility-related issue template on the NixOS-specific contribute page [ ] and remove an outdated link. [ ]
• Holger Levsen:
  • Check, deduplicate, update and generally cleanup a number of presentations linked on our Talks & Resources page. [ ][ ][ ][ ]
• James Addison:
  • Add some file permissions hints and guidance on the Archive metadata page. [ ]
• Michael R. Crusoe:
  • Add an R example to the SOURCE_DATE_EPOCH documentation. [ ]
  • Update the website s README to make the setup command copy & paste friendly. [ ]

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In January, a number of changes were made by Holger Levsen, including:

• reproduce.debian.net-related:
  • Add support for rebuilding the armhf architecture. [ ][ ]
  • Add support for rebuilding the arm64 architecture. [ ][ ][ ][ ]
  • Add support for rebuilding the riscv64 architecture. [ ][ ]
  • Move the i386 builder to the osuosl5 node. [ ][ ][ ][ ]
  • Don t run our rebuilders on a public port. [ ][ ]
  • Add database backups on all builders and add links. [ ][ ]
  • Rework and dramatically improve the statistics collection and generation. [ ][ ][ ][ ][ ][ ]
  • Add contact info to the main page [ ], thumbnails [ ] as well as the new, missing architectures. [ ]
  • Move the amd64 worker to the osuosl4 and node. [ ]
  • Run the underlying debrebuild script under nice. [ ]
  • Try to use TMPDIR when calling debrebuild. [ ][ ]
• buildinfos.debian.net-related:
  • Stop creating buildinfo-pool_$ suite _$ arch .list files. [ ]
  • Temporarily disable automatic updates of pool links. [ ]
• FreeBSD-related:
  • Fix the sudoers to actually permit builds. [ ]
  • Disable debug output for FreeBSD rebuilding jobs. [ ]
  • Upgrade to FreeBSD 14.2 [ ] and document that bmake was installed on the underlying FreeBSD virtual machine image [ ].
• Misc:
  • Update the real year to 2025. [ ]
  • Don t try to install a Debian bookworm kernel from backports on the infom08 node which is running Debian trixie. [ ]
  • Don t warn about system updates for systems running Debian testing. [ ]
  • Fix a typo in the ZOMBIES definition. [ ][ ]

In addition:

• Ed Maste modified the FreeBSD build system to the clean the object directory before commencing a build. [ ]
• Gioele Barabucci updated the rebuilder stats to first add a category for network errors [ ] as well as to categorise failures without a diffoscope log [ ].
• Jessica Clarke also made some FreeBSD-related changes, including:
  • Ensuring we clean up the object directory for second build as well. [ ][ ]
  • Updating the sudoers for the relevant rm -rf command. [ ]
  • Update the cleanup_tmpdirs method to to match other removals. [ ]
• Jochen Sprickerhof:
  • Fix logic for old files saved on buildinfos.debian.net. [ ]
  • Rework and simplify the generation of statistics linked from reproduce.debian.net. [ ][ ][ ][ ]
• Roland Clobus:
  • Update the reproducible_debstrap job to call Debian s debootstrap with the full path [ ] and to use eatmydata as well [ ][ ].
  • Make some changes to deduce the CPU load in the debian_live_build job. [ ]

Lastly, both Holger Levsen [ ] and Vagrant Cascadian [ ] performed some node maintenance.
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org
• Twitter: @ReproBuilds

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Passively lit coding

Personal history Looking back at my own old blog entries I find one from 10 years ago describing how I bought a Kobo eBook reader with the intent of using it as an external monitor for my laptop. It seems that I got a proof-of-concept setup working, using VNC, but it was tedious to set up, and I never actually used that. I subsequently noticed that the eBook reader is rather useful to read eBooks, and it has been in heavy use for that every since. Four years ago I gave this old idea another shot and bought an Onyx BOOX Max Lumi. This is an A4-sized tablet running Android and had the very promising feature of an HDMI input. So hopefully I d attach it to my laptop and it just works . Turns out that this never worked as well as I hoped: Even if I set the resolution to exactly the tablet s screen s resolution I got blurry output, and it also drained the battery a lot, so I gave up on this. I subsequently noticed that the tablet is rather useful to take notes, and it has been in sporadic use for that. Going off on this tangent: I later learned that the HDMI input of this device appears to the system like a camera input, and I don t have to use Boox s monitor app but could other apps like FreeDCam as well. This somehow managed to fix the resolution issues, but the setup still wasn t as convenient to be used regularly. I also played around with pure terminal approaches, e.g. SSH ing into a system, but since my usual workflow was never purely text-based (I was at least used to using a window manager instead of a terminal multiplexer like screen or tmux) that never led anywhere either.

VSCode, working remotely Since these attempts I have started a new job working on the Lean theorem prover, and working on or with Lean basically means using VSCode. (There is a very good neovim plugin as well, but I m using VSCode nevertheless, if only to make sure I am dogfooding our default user experience). My colleagues have said good things about using VSCode with the remote SSH extension to work on a beefy machine, so I gave this a try now as well, and while it s not a complete game changer for me, it does make certain tasks (rebuilding everything after a switching branches, running the test suite) very convenient. And it s a bit spooky to run these work loads without the laptop s fan spinning up. In this setup, the workspace is remote, but VSCode still runs locally. But it made me wonder about my old goal of being able to work reasonably efficient on my eInk tablet. Can I replicate this setup there? VSCode itself doesn t run on Android directly. There are project that run a Linux chroot or in termux on the Android system, and then you can VNC to connect to it (e.g. on Andronix) but that did not seem promising. It seemed fiddly, and I probably should take it easy on the tablet s system.

code-server, running remotely A more promising option is code-server. This is a fork of VSCode (actually of VSCodium) that runs completely on the remote machine, and the client machine just needs a browser. I set that up this weekend and found that I was able to do a little bit of work reasonably.

Access With code-server one has to decide how to expose it safely enough. I decided against the tunnel-over-SSH option, as I expected that to be somewhat tedious to set up (both initially and for each session) on the android system, and I liked the idea of being able to use any device to work in my environment. I also decided against the more involved reverse proxy behind proper hostname with SSL setups, because they involve a few extra steps, and some of them I cannot do as I do not have root access on the shared beefy machine I wanted to use. That left me with the option of using a code-server s built-in support for self-signed certificates and a password:

$ cat .config/code-server/config.yaml
bind-addr: 1.2.3.4:8080
auth: password
password: xxxxxxxxxxxxxxxxxxxxxxxx
cert: true

With trust-on-first-use this seems reasonably secure. Update: I noticed that the browsers would forget that I trust this self-signed cert after restarting the browser, and also that I cannot install the page (as a Progressive Web App) unless it has a valid certificate. But since I don t have superuser access to that machine, I can t just follow the official recommendation of using a reverse proxy on port 80 or 431 with automatic certificates. Instead, I pointed a hostname that I control to that machine, obtained a certificate manually on my laptop (using acme.sh) and copied the files over, so the configuration now reads as follows:

bind-addr: 1.2.3.4:3933
auth: password
password: xxxxxxxxxxxxxxxxxxxxxxxx
cert: .acme.sh/foobar.nomeata.de_ecc/foobar.nomeata.de.cer
cert-key: .acme.sh/foobar.nomeata.de_ecc/foobar.nomeata.de.key

(This is getting very specific to my particular needs and constraints, so I ll spare you the details.)

Service To keep code-server running I created a systemd service that s managed by my user s systemd instance:

~ $ cat ~/.config/systemd/user/code-server.service
[Unit]
Description=code-server
After=network-online.target
[Service]
Environment=PATH=/home/joachim/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
ExecStart=/nix/var/nix/profiles/default/bin/nix run nixpkgs#code-server
[Install]
WantedBy=default.target

(I am using nix as a package manager on a Debian system there, hence the additional PATH and complex ExecStart. If you have a more conventional setup then you do not have to worry about Environment and can likely use ExecStart=code-server. For this to survive me logging out I had to ask the system administrator to run loginctl enable-linger joachim, so that systemd allows my jobs to linger.

Git credentials The next issue to be solved was how to access the git repositories. The work is all on public repositories, but I still need a way to push my work. With the classic VSCode-SSH-remote setup from my laptop, this is no problem: My local SSH key is forwarded using the SSH agent, so I can seamlessly use that on the other side. But with code-server there is no SSH key involved. I could create a new SSH key and store it on the server. That did not seem appealing, though, because SSH keys on Github always have full access. It wouldn t be horrible, but I still wondered if I can do better. I thought of creating fine-grained personal access tokens that only me to push code to specific repositories, and nothing else, and just store them permanently on the remote server. Still a neat and convenient option, but creating PATs for our org requires approval and I didn t want to bother anyone on the weekend. So I am experimenting with Github s git-credential-manager now. I have configured it to use git s credential cache with an elevated timeout, so that once I log in, I don t have to again for one workday.

$ nix-env -iA nixpkgs.git-credential-manager
$ git-credential-manager configure
$ git config --global credential.credentialStore cache
$ git config --global credential.cacheOptions "--timeout 36000"

To login, I have to https://github.com/login/device on an authenticated device (e.g. my phone) and enter a 8-character code. Not too shabby in terms of security. I only wish that webpage would not require me to press Tab after each character This still grants rather broad permissions to the code-server, but at least only temporarily

Android setup On the client side I could now open https://host.example.com:8080 in Firefox on my eInk Android tablet, click through the warning about self-signed certificates, log in with the fixed password mentioned above, and start working! I switched to a theme that supposedly is eInk-optimized (eInk by Mufanza). It s not perfect (e.g. git diffs are unhelpful because it is not possible to distinguish deleted from added lines), but it s a start. There are more eInk themes on the official Visual Studio Marketplace, but because code-server is a fork it cannot use that marketplace, and for example this theme isn t on Open-VSX. For some reason the F11 key doesn t work, but going fullscreen is crucial, because screen estate is scarce in this setup. I can go fullscreen using VSCode s command palette (Ctrl-P) and invoking the command there, but Firefox often jumps out of the fullscreen mode, which is annoying. I still have to pay attention to when that s happening; maybe its the Esc key, which I am of course using a lot due to me using vim bindings. A more annoying problem was that on my Boox tablet, sometimes the on-screen keyboard would pop up, which is seriously annoying! It took me a while to track this down: The Boox has two virtual keyboards installed: The usual Google ASOP keyboard, and the Onyx Keyboard. The former is clever enough to stay hidden when there is a physical keyboard attached, but the latter isn t. Moreover, pressing Shift-Ctrl on the physical keyboard rotates through the virtual keyboards. Now, VSCode has many keyboard shortcuts that require Shift-Ctrl (especially on an eInk device, where you really want to avoid using the mouse). And the limited settings exposed by the Boox Android system do not allow you configure that or disable the Onyx keyboard! To solve this, I had to install the KISS Launcher, which would allow me to see more Android settings, and in particular allow me to disable the Onyx keyboard. So this is fixed. I was hoping to improve the experience even more by opening the web page as a Progressive Web App (PWA), as described in the code-server FAQ. Unfortunately, that did not work. Firefox on Android did not recognize the site as a PWA (even though it recognizes a PWA test page). And I couldn t use Chrome either because (unlike Firefox) it would not consider a site with a self-signed certificate as a secure context, and then code-server does not work fully. Maybe this is just some bug that gets fixed in later versions. Now that I use a proper certificate, I can use it as a Progressive Web App, and with Firefox on Android this starts the app in full-screen mode (no system bars, no location bar). The F11 key still does t work, and using the command palette to enter fullscreen does nothing visible, but then Esc leaves that fullscreen mode and I suddenly have the system bars again. But maybe if I just don t do that I get the full screen experience. We ll see. I did not work enough with this yet to assess how much the smaller screen estate, the lack of colors and the slower refresh rate will bother me. I probably need to hide Lean s InfoView more often, and maybe use the Error Lens extension, to avoid having to split my screen vertically. I also cannot easily work on a park bench this way, with a tablet and a separate external keyboard. I d need at least a table, or some additional piece of hardware that turns tablet + keyboard into some laptop-like structure that I can put on my, well, lap. There are cases for Onyx products that include a keyboard, and maybe they work on the lap, but they don t have the Trackpoint that I have on my ThinkPad TrackPoint Keyboard II, and how can you live without that?

Conclusion After this initial setup chances are good that entering and using this environment is convenient enough for me to actually use it; we will see when it gets warmer. A few bits could be better. In particular logging in and authenticating GitHub access could be both more convenient and more safe I could imagine that when I open the page I confirm that on my phone (maybe with a fingerprint), and that temporarily grants access to the code-server and to specific GitHub repositories only. Is that easily possible?

Intelligence as an emergent property of Reinforcement Learning (RL)Reinforcement Learning (RL) has been successfully used in the past by Google&aposs DeepMind team to build highly intelligent and specialized systems where intelligence is observed as an emergent property through rewards-based training approach that yielded achievements like AlphaGo (see my post on it here - AlphaGo: a journey to machine intuition).DeepMind went on to build a series of Alpha* projects that achieved many notable feats using RL:

• AlphaGo, defeated the world champion Lee Seedol in the game of Go
• AlphaZero, a generalized system that learned to play games such as Chess, Shogi and Go without human input
• AlphaStar, achieved high performance in the complex real-time strategy game StarCraft II.
• AlphaFold, a tool for predicting protein structures which significantly advanced computational biology.
• AlphaCode, a model designed to generate computer programs, performing competitively in coding challenges.
• AlphaDev, a system developed to discover novel algorithms, notably optimizing sorting algorithms beyond human-derived methods.

All of these systems achieved mastery in its own area through self-training/self-play and by optimizing and maximizing the cumulative reward over time by interacting with its environment where intelligence was observed as an emergent property of the system.

The RL feedback loop

RL mimics the process through which a baby would learn to walk, through trial, error and first principles.

R1 model training pipelineAt a technical level, DeepSeek-R1 leverages a combination of Reinforcement Learning (RL) and Supervised Fine-Tuning (SFT) for its training pipeline:

DeepSeek-R1 Model Training Pipeline

Using RL and DeepSeek-v3, an interim reasoning model was built, called DeepSeek-R1-Zero, purely based on RL without relying on SFT, which demonstrated superior reasoning capabilities that matched the performance of OpenAI&aposs o1 in certain benchmarks such as AIME 2024.The model was however affected by poor readability and language-mixing and is only an interim-reasoning model built on RL principles and self-evolution.DeepSeek-R1-Zero was then used to generate SFT data, which was combined with supervised data from DeepSeek-v3 to re-train the DeepSeek-v3-Base model.The new DeepSeek-v3-Base model then underwent additional RL with prompts and scenarios to come up with the DeepSeek-R1 model.The R1-model was then used to distill a number of smaller open source models such as Llama-8b, Qwen-7b, 14b which outperformed bigger models by a large margin, effectively making the smaller models more accessible and usable.

Key contributions of DeepSeek-R1

1. RL without the need for SFT for emergent reasoning capabilities

R1 was the first open research project to validate the efficacy of RL directly on the base model without relying on SFT as a first step, which resulted in the model developing advanced reasoning capabilities purely through self-reflection and self-verification.Although, it did degrade in its language capabilities during the process, its Chain-of-Thought (CoT) capabilities for solving complex problems was later used for further RL on the DeepSeek-v3-Base model which became R1. This is a significant contribution back to the research community.The below analysis of DeepSeek-R1-Zero and OpenAI o1-0912 shows that it is viable to attain robust reasoning capabilities purely through RL alone, which can be further augmented with other techniques to deliver even better reasoning performance.

Source: https://github.com/deepseek-ai/DeepSeek-R1

Its quite interesting, that the application of RL gives rise to seemingly human capabilities of "reflection", and arriving at "aha" moments, causing it to pause, ponder and focus on a specific aspect of the problem, resulting in emergent capabilities to problem-solve as humans do.

2. Model distillation

DeepSeek-R1 also demonstrated that larger models can be distilled into smaller models which makes advanced capabilities accessible to resource-constrained environments, such as your laptop. While its not possible to run a 671b model on a stock laptop, you can still run a distilled 14b model that is distilled from the larger model which still performs better than most publicly available models out there. This enables intelligence to be brought closer to the edge, to allow faster inference at the point of experience (such as on a smartphone, or on a Raspberry Pi), which paves way for more use cases and possibilities for innovation.

Source: https://github.com/deepseek-ai/DeepSeek-R1

Distilled models are very different to R1, which is a massive model with a completely different model architecture than the distilled variants, and so are not directly comparable in terms of capability, but are instead built to be more smaller and efficient for more constrained environments. This technique of being able to distill a larger model&aposs capabilities down to a smaller model for portability, accessibility, speed, and cost will bring about a lot of possibilities for applying artificial intelligence in places where it would have otherwise not been possible. This is another key contribution of this technology from DeepSeek, which I believe has even further potential for democratization and accessibility of AI.

Why is this moment so significant?DeepSeek-R1 was a pivotal contribution in many ways.

1. The contributions to the state-of-the-art and the open research helps move the field forward where everybody benefits, not just a few highly funded AI labs building the next billion dollar model.
2. Open-sourcing and making the model freely available follows an asymmetric strategy to the prevailing closed nature of much of the model-sphere of the larger players. DeepSeek should be commended for making their contributions free and open.
3. It reminds us that its not just a one-horse race, and it incentivizes competition, which has already resulted in OpenAI o3-mini a cost-effective reasoning model which now shows the Chain-of-Thought reasoning. Competition is a good thing.
4. We stand at the cusp of an explosion of small-models that are hyper-specialized, and optimized for a specific use case that can be trained and deployed cheaply for solving problems at the edge. It raises a lot of exciting possibilities and is why DeepSeek-R1 is one of the most pivotal moments of tech history.

Truly exciting times. What will you build?

• Fix crash when switching bitween some fractional scales (MR)
• Make layer surface code more flexible and fade in system modal dialogs (MR)
• Auto close quick setting status pages (MR)
• Cleanup and undraft the captive portal (MR). If this lands we have another 2y old MR out of the way.
• Brush up monitor scaling quick setting originally submitted by Adam Honse (MR)
• Fix modem interface regression introduced by the rework for cell broadcast (MR)
• Fill background with primary color (MR), also ensures fallback
• Release Phosh 0.44.1 (MR)
• Don't forget to update background on dark uri changes (MR) when background can't be loaded
• Fix crash in mpris widget (MR)
• Reduce restyling on state changes (MR)
• Dev Doc updates (MR)
• Drop long unused widget (MR)
• Improve Wi-Fi portal notification handling (MR)
• Support sound capability on the notification server (MR)
• Use systemd-cat to launch session (MR)

• layer-surface: Don't arrange surfaces / set focus on finalize (MR
• Update to wlroots 0.18.2 and some cleanups (MR)
• Run scan-build in CI and fix detected issues (MR)
• Simplify XWayland handling in PhocDesktop (MR)
• Handle xdg's suspended surface state (in phone mode) (MR)
• Invalidate layer shell list less often and take opacity into account for visibility check (MR)
• Unbreak touch point debugging / deduplicate code (MR)
• Release Phoc 0.44.1 (MR)
• Fix initial alpha == 0.0 (MR)
• Fix leak in output-shield and allow to set easing function (MR)
• Smoothen mode/scale/orientation changes (MR)
• Fix thumbnail rendering of floating windows (MR)
• Fix damage tracking debugging (MR)
• Allow to toggle some debugging flags at runtime (MR)
• Fix subsurface damage tracking regression caused by the wlroots 0.18.x switch (MR)
• Catch up with wlroots 0.19.x again (MR)
• Backport the sensible bits of the 0.19.x branch to main to smoothen the next upgrade (MR)
• Fix touch drag (MR) - basically the wlroots patch from below.
• Make PhocViewChild less of a snow flake (MR)
• Fix popup reposition damage (MR)
• Draft: Deduplicate the View and LayerSurface subsurface/popup handling (MR). Needs 625 to land first.
• popup: Try harder to find a suitable output (MR)

• Let long press on shift toggle CapsLock (MR)
• Add minimal GObject for application (MR). Lets merge the bits of the 1y old MR that still apply.
• Unbrush 2y old MR to get rid of more globals (MR)
• Update Unicode data, thanks GTK devs! (MR)

• Use GTK 4.17's portal avoidance (MR)

• Bring back weekly snapshots by switching to a faster runner
• Use xz compression (MR)

• Use Authorization header: (MR)

• Ship example greetd config (MR)

• Update libphosh-rs (MR)
• Update phoc to new git snapshot (MR)
• Upload phosh 0.44.1)
• Backport touch fix (MR)

• Make it work with Python 3.13, sigh (MR)
• Typo fixes (MR)
• Release 0.9.37 (MR)
• Run codespell in CI (MR)

• Suspend video stream when toplevel is suspende (MR) - saves battery
• Release 0.3.1 (MR)

• Allow events to override the sound feedback with custom sounds (MR). Allows desktop/mobile shells like phosh to honour application prefs for notifications.

• Propose notch/cuttout support protocol MR)

• Allow to access opacity boolean (MR)
• Unbreak drag and drop via touch (MR)

• udev regression affecting gmobile (Bug). Many thanks to Yu Watanabe for providing the fix so quickly

• phosh: Uninstall action (MR) - merged
• phosh: Add home-enabled property (MR) - merged
• phosh: Emergency prefs dialog improvements (MR) - merged
• phosh: Bump gtk versions in ui file (MR - merged
• phosh: Show week number (MR) - merged
• phosh: compile schemas for plugins (MR) - merged
• phosh: Reduce API surface (MR)
• phosh: Use AdwEntryRow (MR) - merged
• phosh-osk-stub: Il layout additions (MR) - merged
• phosh-mobile-settings: Use 'meson setup' in CI (MR) - merged
• phosh-tour autostart (MR)
• livi flatpak update (MR) - merged
• debian: phosh: Recommend kbd (MR) - merged
• iio-sensor-proxy libssc support (MR)
• git-buildpackage: Spelling fixes (MR) - merged
• git-buildpackage: DEP spelling consistency (MR) - merged
• git-buildpackage: Add branch layout diagram (MR) - merged

• Ananthu C V (weepingclown)
• Andrea Pappacoda (tachi)
• Athos Coimbra Ribeiro (athos)
• Gioele Barabucci (gioele)
• Jongmin Kim (jmkim)
• Shengqi Chen (harry)
• Frans Spiesschaert (frans)

• Tianyu Chen
• Emmanuel FARHI
• Nicolas Schodet

Evander was elf and I was human. We weren't the same. I had magic. He had the magic I'd unconsciously locked into his augmentations. We were different and in love. Speaking of our differences could be a trigger. I peeked at him, worried. My customary confidence had taken a hit. "We're different," he answered my unspoken question. "And we work anyway. We'll work to make us work."

1. Read and re-read the Debian Policy, the Developer s Reference and the git-buildpackage manual Anyone learning Debian packaging and aspiring to become a Debian maintainer is likely to wade through a lot of documentation, only to realize that much of it is outdated or sometimes outright incorrect. Therefore, it is important to learn right from the start which sources are the most reliable and truly worth reading and re-reading. I recommend these documents, in order of importance:

• The Debian Policy Manual: Describes the structure of the operating system, the package archive, and requirements for packages to be included in the Debian archive.
• The Developer s Reference: A collection of best practices and process descriptions Debian packagers are expected to follow while interacting with one another.
• The git-buildpackage man pages: While the Policy focuses on the end result and is intentionally void of practical instructions on creating or maintaining Debian packages, the Developer s Reference goes into greater detail. However, it too lacks step-by-step instructions. For the exact commands, consult the man pages of git-buildpackage and its subcommands (e.g., gbp clone, gbp import-orig, gbp pq, gbp dch, gbp push). See also my post on Debian source package git branch and tags for an easy to understand diagrams.

2. Make reading man pages a habit In addition to the above, try to make a habit of checking out the man page of every new tool you use to ensure you are using it as intended. The best place to read accurate and up-to-date documentation is manpages.debian.org. The manual pages are maintained alongside the tools by their developers, ensuring greater accuracy than any third-party documentation. If you are using a tool in the way the tool author documented, you can be confident you are doing the right thing, even if it wasn t explicitly mentioned in some third-party guide about Debian packaging best practices.

3. Read and write emails While members of the Debian community have many channels of communication, the mailing lists are by far the most prominent. Asking questions on the appropriate list is a good way to get current advice from other people doing Debian packaging. Staying subscribed to lists of interest is also a good way to read about new developments as they happen. Note that every post is public and archived permanently, so the discussions on the mailing lists also form a body of documentation that can later be searched and referred to. Regularly writing short and well-structured emails on the mailing lists is great practice for improving technical communication skills a useful ability in general. For Debian specifically, being active on mailing lists helps build a reputation that can later attract collaborators and supporters for more complex initiatives.

4. Create and use an OpenPGP key Related to reputation and identity, OpenPGP keys play a central role in the Debian community. OpenPGP is used to various degrees to sign git commits and tags, sign and encrypt email, and most importantly to sign Debian packages so their origin can be verified. The process of becoming a Debian Maintainer and eventually a Debian Developer culminates in getting your OpenPGP key included in the Debian keyring, which is used to control who can upload packages into the Debian archive. The earlier you create a key and start using it to gain reputation for that specific key that is used to sign your work, the better. Note that due to a recent schism in the OpenPGP standards working group, it is safest to create an OpenPGP key using GnuPG version 2.2.x (not 2.4.x), or using Sequoia-PGP.

5. Integrate Salsa CI in all work One reason Debian remains popular, even 30 years after its inception, is due to its culture of maintaining high standards. For a newcomer, learning all the quality assurance tools such as Lintian, Piuparts, Adequate, various build variations, and reproducible builds may be overwhelming. However, these tasks are easier to manage thanks to Salsa CI, the continuous integration pipeline in Debian that runs tests on every commit at salsa.debian.org. The earlier you activate Salsa CI in the package repository you are working on, the faster you will achieve high quality in your package with fewer missteps. You can also further customize a package specific salsa-ci.yml to have more testing coverage.

6. Fork on Salsa and use draft Merge Requests to solicit feedback All modern Debian packages are hosted on salsa.debian.org. If you want to make a change to any package, it is easy to fork, make an initial attempt at the change, and publish it as a draft Merge Request (MR) on Salsa to solicit feedback. People might have surprising reasons to object to the change you propose, or they might need time to get used to the idea before agreeing to it. Also, some people might object to a vague idea out of suspicion but agree once they see the exact implementation. There may also be a surprising number of people supporting your idea, and if there is an MR, they have a place to show their support at. Don t expect every Merge Request to be accepted. However, proposing an idea as running code in an MR is far more effective than raising the idea on a mailing list or in a bug report. Get into the habit of publishing plenty of merge requests to solicit feedback and drive discussions toward consensus.

7. Use git rebase frequently Linear git history is much easier to read. The ease of reading git log and git blame output is vital in Debian, where packages often have updates from multiple people spanning many years even decades. Debian packagers likely spend more time than the average software developer reading git history. Make sure you master git commands such as gitk --all, git citool --amend, git commit -a --fixup <commit id>, git rebase -i --autosquash <target branch>, git cherry-pick <commit id 1> <id 2> <id 3>, and git pull --rebase. If rebasing is not done on your initiative, rest assured others will ask you to do it. Thus, if the commands above are familiar, rebasing will be quick and easy for you.

8. Reviews: give some, get some In open source, the larger a project becomes, the more it attracts contributions, and the bottleneck for its growth isn t how much code developers can create but how much code submissions can be properly reviewed. At the time of writing, the main Salsa group Debian has over 800 open merge requests pending reviews and approvals. Feel free to read and comment on any merge request you find. You don t have to be a subject matter expert to provide valuable feedback. Even if you don t have specific feedback, your comment as another human acknowledging that you read the MR and found no issues is viewed positively by the author. Besides, if you spend enough time reviewing MRs in a specific domain, you will eventually become an expert in it. Code reviews are not just about providing feedback to the submitter; they are also great learning opportunities for the reviewer. As a rule of thumb, you should review at least twice as many merge requests as you submit yourself.

9. Improve Debian by improving upstream It is common that while packaging software for Debian, bugs are uncovered and patched in Debian. Do not forget to submit the fixes upstream, and add a Forwarded field to the file in debian/patches! As the person building and packaging something in Debian, you automatically become an authority on that software, and the upstream is likely glad to receive your improvements. While submitting patches upstream is a bit of work initially, getting improvements merged upstream eventually saves time for everyone and makes packaging in Debian easier, as there will be fewer patches to maintain with each new upstream release.

10. Don t hold any habits too firmly Last but not least: Once people learn a specific way of working, they tend to stick to it for decades. Learning how to create and maintain Debian packages requires significant effort, and people tend to stop learning once they feel they ve reached a sufficient level. This tendency to get stuck in a local optimum is understandable and natural, but try to resist it. It is likely that better techniques will evolve over time, so stay humble and re-evaluate your beliefs and practices every few years. Mastering these habits takes time, but each small step brings you closer to making a meaningful impact on Debian. By staying curious, collaborative, and adaptable, you can ensure your contributions stand the test of time just like Debian itself. Good luck on your journey toward becoming a Debian Maintainer!

• A backward compatible deployment setup
• Migration of static text content pages
• Migration of dynamic pages (Incorporating existing perl scripts)
• Redirection for contents moved permanently (301)

...
aliases:
  - /index.fr.html
...