• Goals of the Debian git transition project
  • Achievements so far, and current status
• Core engineering principle
  • Correspondence between dsc and git
  • Patches-applied vs patches-unapplied
  • Consequences, some of which are annoying
• Distributing the source code as git
  • Tracking the relevant git data, when changes are made in the legacy Archive
  • Why *.dgit.debian.org is not Salsa
• Roadmap
  • In progress
  • Future Technology
• Mindshare and adoption - please help!
  • A rant about publishing the source code
  • Documentation
• Personnel
  • Thanks

0. Everyone who interacts with Debian source code should be able to do so entirely in git.

1. All examination and edits to the source should be performed via normal git operations.
2. Source code should be transferred and exchanged as git data, not tarballs. git should be the canonical form everywhere.
3. Upstream git histories should be re-published, traceably, as part of formal git releases published by Debian.
4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.

• It is familiar to, and doesn t trick, outsiders to Debian. Debian insiders radically underestimate how weird patches-unapplied is. Even expert software developers can get very confused or even accidentally build binaries without security patches!
• Making changes can be done with just normal git commands, eg git commit. Many Debian insiders working with patches-unapplied are still using quilt(1), a footgun-rich contraption for working with patch files!
• When developing, one can make changes to upstream code, and to Debian packaging, together, without ceremony. There is no need to switch back and forth between patch queue and packaging branches (as with gbp pq), no need to commit patch files, etc. One can always edit every file and commit it with git commit.

• It is dependable, both in terms of reliability and security.
• It is append-only: once something is pushed, it is permanently recorded.
• Its access control is precisely that of the Debian Archive.
• Its ref namespace is standardised and corresponds to Debian releases.
• Pushes are authorised by PGP signatures, not ssh keys, so traceable.

• Ian Jackson. Author and maintainer of dgit and git-debrebase. Co-creator of tag2upload. Original author of dpkg-source, and inventor in 1996 of Debian Source Packages. Alumnus of the Debian Technical Committee.
• Sean Whitton. Co-creator of the tag2upload system; author and maintainer of git-debpush. Co-maintainer of dgit. Debian Policy co-Editor. Former Chair of the Debian Technical Committee.

• Maintainers of src:dgit
• tag2upload Delegates; operators of the tag2upload service.
• service operators of the git depository *.dgit.debian.org.

• By email: Ian Jackson ijackson@chiark.greenend.org.uk; Sean Whitton spwhitton@spwhitton.name; git-debpush@packages.d.o.
• By filing bugs in the Debian Bug System against src:dgit.
• On OFTC IRC, as Diziet and spwhitton.

What is a trailing stop-loss order? What if you could buy stocks to benefit from their value increasing without having to worry about a potential crash? All modern online stock brokers have a feature called stop-loss, where you can enter a price at which your stocks automatically get sold if they drop down to that price. A trailing stop-loss order is similar, but instead of a fixed price, you enter a margin (e.g. 10%). If the stock price rises, the stop-loss price will trail upwards by that margin. For example, if you buy a share at 100 euros and it has risen to 110 euros, you can set a 10% trailing stop-loss order which automatically sells it if the price drops 10% from the peak of 110 euros, at 99 euros. Thus, no matter what happens, you only lost 1 euro. And if the stock price continues to rise to 150 euros, the trailing stop-loss would automatically readjust to 150 euros minus 10%, which is 135 euros (150-15=135). If the price dropped to 135 euros, you would lock in a gain of 35 euros, which is not the peak price of 150 euros, but still better than whatever the price fell down to as a result of a large crash. In the simple case above, it obviously makes sense in theory, but it might not make sense in practice. Prices constantly oscillate, so you don t want a margin that is too small, otherwise you exit too early. Conversely, having a large margin may result in too large a drawdown before exiting. If markets crash rapidly, it might be that nobody buys your stocks at the stop-loss price, and shares have to be sold at an even lower price. Also, what will you do once the position is sold? The reason you invested in the stock market was to avoid holding cash, so would you buy the same stock back when the crash bottoms? But how will you know when the bottom has been reached?

Backtesting stock market strategies with Python, YFinance, Pandas and Lightweight Charts I am not a professional investor, and nobody should take investment advice from me. However, I know what backtesting is and how to leverage open source software. So, I wrote a Python script to test if the trading strategy of using trailing stop-loss orders with specific margin values would have worked for a particular stock. First you need to have data. YFinance is a handy Python library that can be used to download the historic price data for any stock ticker on Yahoo.com. Then you need to manipulate the data. Pandas is the Python data analysis library with advanced data structures for working with relational or labeled data. Finally, to visualize the results, I used Lightweight Charts, which is a fast, interactive library for rendering financial charts, allowing you to plot the stock price, the trailing stop-loss line, and the points where trades would have occurred. I really like how the zoom is implemented in Lightweight Charts, which makes drilling into the data points feel effortless. The full solution is not polished enough to be published for others to use, but you can piece together your own by reusing some of the key snippets. To avoid re-downloading the same data repeatedly, I implemented a small caching wrapper that saves the data locally (as Parquet files):

python Copy

CACHE_DIR.mkdir(parents=True, exist_ok=True) end_date = datetime.today().strftime("%Y-%m-%d") cache_file = CACHE_DIR / f" TICKER - START_DATE -- end_date .parquet" if cache_file.is_file(): dataframe = pandas.read_parquet(cache_file) print(f"Loaded price data from cache: cache_file ") else: dataframe = yfinance.download( TICKER, start=START_DATE, end=end_date, progress=False, auto_adjust=False ) dataframe.to_parquet(cache_file) print(f"Fetched new price data from Yahoo Finance and cached to: cache_file ")

CACHE_DIR.mkdir(parents=True, exist_ok=True)
end_date = datetime.today().strftime("%Y-%m-%d")
cache_file = CACHE_DIR / f" TICKER - START_DATE -- end_date .parquet"

if cache_file.is_file():
 dataframe = pandas.read_parquet(cache_file)
 print(f"Loaded price data from cache:  cache_file ")
else:
 dataframe = yfinance.download(
 TICKER,
 start=START_DATE,
 end=end_date,
 progress=False,
 auto_adjust=False
 )

 dataframe.to_parquet(cache_file)
 print(f"Fetched new price data from Yahoo Finance and cached to:  cache_file ")

The dataframe is a Pandas object with a powerful API. For example, to print a snippet from the beginning and the end of the dataframe to see what the data looks like, you can use:

python Copy

print("First 5 rows of the raw data:") print(df.head()) print("Last 5 rows of the raw data:") print(df.tail())

print("First 5 rows of the raw data:")
print(df.head())
print("Last 5 rows of the raw data:")
print(df.tail())

Example output:

Copy

First 5 rows of the raw data Price Adj Close Close High Low Open Volume Ticker BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA Date 2014-01-02 29.956285 55.540001 56.910000 55.349998 56.700001 316552 2014-01-03 30.031801 55.680000 55.990002 55.290001 55.580002 210044 2014-01-06 30.080338 55.770000 56.230000 55.529999 55.560001 185142 2014-01-07 30.943321 57.369999 57.619999 55.790001 55.880001 370397 2014-01-08 31.385597 58.189999 59.209999 57.750000 57.790001 489940 Last 5 rows of the raw data Price Adj Close Close High Low Open Volume Ticker BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA Date 2025-12-11 78.669998 78.669998 78.919998 76.900002 76.919998 357918 2025-12-12 78.089996 78.089996 80.269997 78.089996 79.470001 280477 2025-12-15 79.080002 79.080002 79.449997 78.559998 78.559998 233852 2025-12-16 78.860001 78.860001 79.980003 78.809998 79.430000 283057 2025-12-17 80.080002 80.080002 80.150002 79.080002 79.199997 262818

First 5 rows of the raw data
Price Adj Close Close High Low Open Volume
Ticker BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA
Date
2014-01-02 29.956285 55.540001 56.910000 55.349998 56.700001 316552
2014-01-03 30.031801 55.680000 55.990002 55.290001 55.580002 210044
2014-01-06 30.080338 55.770000 56.230000 55.529999 55.560001 185142
2014-01-07 30.943321 57.369999 57.619999 55.790001 55.880001 370397
2014-01-08 31.385597 58.189999 59.209999 57.750000 57.790001 489940
Last 5 rows of the raw data
Price Adj Close Close High Low Open Volume
Ticker BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA BNP.PA
Date
2025-12-11 78.669998 78.669998 78.919998 76.900002 76.919998 357918
2025-12-12 78.089996 78.089996 80.269997 78.089996 79.470001 280477
2025-12-15 79.080002 79.080002 79.449997 78.559998 78.559998 233852
2025-12-16 78.860001 78.860001 79.980003 78.809998 79.430000 283057
2025-12-17 80.080002 80.080002 80.150002 79.080002 79.199997 262818

Adding new columns to the dataframe is easy. For example, I used a custom function to calculate the Relative Strength Index (RSI). To add a new column RSI with a value for every row based on the price from that row, only one line of code is needed, without custom loops:

python Copy

df["RSI"] = compute_rsi(df["price"], period=14)

df["RSI"] = compute_rsi(df["price"], period=14)

After manipulating the data, the series can be converted into an array structure and printed as JSON into a placeholder in an HTML template:

python Copy

baseline_series = [ "time": ts, "value": val for ts, val in df_plot[["timestamp", BASELINE_LABEL]].itertuples(index=False) ] baseline_json = json.dumps(baseline_series) template = jinja2.Template("template.html") rendered_html = template.render( title=title, heading=heading, description=description_html, ... baseline_json=baseline_json, ... ) with open("report.html", "w", encoding="utf-8") as f: f.write(rendered_html) print("Report generated!")

 baseline_series = [
  "time": ts, "value": val 
 for ts, val in df_plot[["timestamp", BASELINE_LABEL]].itertuples(index=False)
 ]

 baseline_json = json.dumps(baseline_series)
 template = jinja2.Template("template.html")
 rendered_html = template.render(
 title=title,
 heading=heading,
 description=description_html,
 ...
 baseline_json=baseline_json,
 ...
 )

 with open("report.html", "w", encoding="utf-8") as f:
 f.write(rendered_html)
 print("Report generated!")

In the HTML template, the marker variable in Jinja syntax gets replaced with the actual JSON:

html Copy

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title> title </title> ... </head> <body> <h1> heading </h1> <div id="chart"></div> <script> // Ensure the DOM is ready before we initialise the chart document.addEventListener('DOMContentLoaded', () => // Parse the JSON data passed from Python const baselineData = baseline_json safe ; const strategyData = strategy_json safe ; const markersData = markers_json safe ; // Create the chart const chart = LightweightCharts.createChart(document.getElementById('chart'), width: document.getElementById('chart').clientWidth, height: 500, layout: background: color: "#222" , textColor: "#ccc" , grid: vertLines: color: "#555" , horzLines: color: "#555" ); // Add baseline series const baselineSeries = chart.addLineSeries( title: ' baseline_label ', lastValueVisible: false, priceLineVisible: false, priceLineWidth: 1 ); baselineSeries.setData(baselineData); baselineSeries.priceScale().applyOptions( entireTextOnly: true ); // Add strategy series const strategySeries = chart.addLineSeries( title: ' strategy_label ', lastValueVisible: false, priceLineVisible: false, color: '#FF6D00' ); strategySeries.setData(strategyData); // Add buy/sell markers to the strategy series strategySeries.setMarkers(markersData); // Fit the chart to show the full data range (full zoom) chart.timeScale().fitContent(); ) </script> </body> </html>

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="UTF-8">
 <title>  title  </title>
 ...
</head>
<body>
 <h1>  heading  </h1>
 <div id="chart"></div>
 <script>
 // Ensure the DOM is ready before we initialise the chart
 document.addEventListener('DOMContentLoaded', () =>  
 // Parse the JSON data passed from Python
 const baselineData =   baseline_json   safe  ;
 const strategyData =   strategy_json   safe  ;
 const markersData =   markers_json   safe  ;

 // Create the chart
 const chart = LightweightCharts.createChart(document.getElementById('chart'),  
 width: document.getElementById('chart').clientWidth,
 height: 500,
 layout:  
 background:   color: "#222"  ,
 textColor: "#ccc"
  ,
 grid:  
 vertLines:   color: "#555"  ,
 horzLines:   color: "#555"  
  
  );

 // Add baseline series
 const baselineSeries = chart.addLineSeries( 
 title: '  baseline_label  ',
 lastValueVisible: false,
 priceLineVisible: false,
 priceLineWidth: 1
  );
 baselineSeries.setData(baselineData);

 baselineSeries.priceScale().applyOptions( 
 entireTextOnly: true
  );

 // Add strategy series
 const strategySeries = chart.addLineSeries( 
 title: '  strategy_label  ',
 lastValueVisible: false,
 priceLineVisible: false,
 color: '#FF6D00'
  );
 strategySeries.setData(strategyData);

 // Add buy/sell markers to the strategy series
 strategySeries.setMarkers(markersData);

 // Fit the chart to show the full data range (full zoom)
 chart.timeScale().fitContent();
  )
 </script>
</body>
</html>

There are also Python libraries built specifically for backtesting investment strategies, such as Backtrader and Zipline, but they do not seem to be actively maintained, and probably have too many features and complexity compared to what I needed for doing this simple test. The screenshot below shows an example of backtesting a strategy on the Waste Management Inc stock from January 2015 to December 2025. The baseline Buy and hold scenario is shown as the blue line and it fully tracks the stock price, while the orange line shows how the strategy would have performed, with markers for the sells and buys along the way.

Results I experimented with multiple strategies and tested them with various parameters, but I don t think I found a strategy that was consistently and clearly better than just buy-and-hold. It basically boils down to the fact that I was not able to find any way to calculate when the crash has bottomed based on historical data. You can only know in hindsight that the price has stopped dropping and is on a steady path to recovery, but at that point it is already too late to buy in. In my testing, most strategies underperformed buy-and-hold because they sold when the crash started, but bought back after it recovered at a slightly higher price. In particular when using narrow margins and selling on a 3-6% drawdown the strategy performed very badly, as those small dips tend to recover in a few days. Essentially, the strategy was repeating the pattern of selling 100 stocks at a 6% discount, then being able to buy back only 94 shares the next day, then again selling 94 shares at a 6% discount, and only being able to buy back maybe 90 shares after recovery, and so forth, never catching up to the buy-and-hold. The strategy worked better in large market crashes as they tended to last longer, and there were higher chances of buying back the shares while the price was still low. For example, in the 2020 crash selling at a 20% drawdown was a good strategy, as the stock I tested dropped nearly 50% and remained low for several weeks; thus, the strategy bought back the stocks while the price was still low and had not yet started to climb significantly. But that was just a lucky incident, as the delta between the trailing stop-loss margin of 20% and total crash of 50% was large enough. If the crash had been only 25%, the strategy would have missed the rebound and ended up buying back the stocks at a slightly higher price. Also, note that the simulation assumes that the trade itself is too small to affect the price formation. We should keep in mind that in reality, if many people have stop-loss orders in place, a large price drop would trigger all of them, creating a flood of sell orders, which in turn would affect the price and drive it lower even faster and deeper. Luckily, it seems that stop-loss orders are generally not a good strategy, and we don t need to fear that too many people will be using them.

Conclusion Even though using a trailing stop-loss strategy does not seem to help in getting consistently higher returns based on my backtesting, I would still say it is useful in protecting from the downside of stock investing. It can act as a kind of insurance policy to considerably decrease the chances of losing big while increasing the chances of losing a little bit. If you are risk-averse, which I think I probably am, this tradeoff can make sense. I d rather miss out on an initial 50% loss and an overall 3% gain on recovery than have to sit through weeks or months with a 50% loss before the price recovers to prior levels. Most notably, the trailing stop-loss strategy works best if used only once. If it is repeated multiple times, the small losses in gains will compound into big losses overall. Thus, I think I might actually put this automation in place at least on the stocks in my portfolio that have had the highest gains. If they keep going up, I will ride along, but once the crash happens, I will be out of those particular stocks permanently. Do you have a favorite open source investment tool or are you aware of any strategy that actually works? Comment below!

Changes in version 0.0.17 (2025-12-18)

• Added new funtion reorderMicrobenchmarkResults with alias rmr
• Use tolower on email argument to checkCRANStatus
• Added new function cranORCIDs bootstrapped from two emails by Kurt Hornik
• Switched to using Authors@R in DESCRIPTION and added ORCIDs where available
• Switched to r-ci action with included bootstrap step; updated updated the checkout action (twice); added (commented-out) log accessor
• Removed googleFinanceData as the (unofficial) API access point no longer works
• Removed muteTweeters because the API was turned off

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.

We have distribution-wide CI in unstable, but there s only one of it and it s shared between all of us. As a result it s very possible to get into tangles when multiple people are working on related things at the same time, and we only avoid that as much as we do by careful coordination such as transition bugs. Experimental helps, but again, there s only one of it and setting up another one is far from trivial. So, what we want is a system where you can run experiments on possible Debian changes at a large scale without a high setup cost and without fear of breaking things for other people. And then, if it all works, push the whole lot into Debian.

$ dput -O debusine_workspace=developers-cjwatson-pylint \
       -O debusine_workflow=publish-to-sid-pylint \
       debusine.debian.net foo.changes

Changes in RcppArmadillo version 15.2.3-1 (2025-12-16)

• Upgraded to Armadillo release 15.2.3 (Medium Roast Deluxe)
  • Faster .resize() for vectors
  • Faster repcube()

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.

# simple-ppa.conf
[CORE]
SignWith = 2906D748B7551BC8
ExportDir = /srv/www/simple-ppa
MailFrom: Simple-PPA <admin@simple-ppa.debian.net>
Codenames = sid forky trixie trixie-backports bookworm bookworm-backports
AlsoAllow = forky: unstable
            trixie: unstable
            bookworm: unstable
[simple-ppa-dev]
Label = Simple-PPA's self-hosted development repository
# ckk's key
Uploaders = allow * by key E76004C5CEF0C94C+
[ckk]
Label = Christian Kastner at Simple-PPA
Uploaders = allow * by key E76004C5CEF0C94C+

Why? Debian developers typically put most of their effort towards maintaining the main Debian archive. However, it s often useful to have other places to work, for various reasons:

• Developers working on a set of packages might need to check that changes to several of them all work properly together on a real system.
• Somebody fixing a bug might need to ask affected users to test the fix before uploading it to Debian.
• Some projects are difficult to package in a way that meets Debian policy, or are too niche to include in Debian, but it s still useful to distribute them in a packaged form.
• For some packages, it s useful to provide multiple upstream versions for multiple Debian releases, even though Debian itself would normally want to keep that to a minimum.

The Ubuntu ecosystem has had PPAs for a long time to meet these sorts of needs, but people working directly on Debian have had to make do with putting things together themselves using something like reprepro or aptly. Discussions about this have been happening for long enough that people started referring to PPAs for Debian as bikesheds , and users often find themselves trying to use Ubuntu PPAs on Debian systems and hoping that dependencies will be compatible enough for things to more or less work. This clearly isn t ideal, and solving it is one of Freexian s objectives for Debusine. Developers publishing packages to Debusine repositories can take advantage of all Debusine s existing facilities, including a battery of QA tests and regression tracking (coming soon). Repositories are signed using per-repository keys held in Debusine s signing service, and uploads to repositories are built against the current contents of that repository as well as the corresponding base Debian release. All repositories include automatic built-in snapshot capabilities.

Who can use this service? We ve set up debusine.debian.net to allow using repositories. All Debian Developers and Debian Maintainers can log in there and publish packages to it. The resulting repositories are public by default. debusine.debian.net only allows packages with licences that allow distribution by Debian, and it is intended primarily for work that could reasonably end up in Debian; Freexian reserves the right to remove repositories from it.

How can I use it? If you are a Debian contributor, we d be very excited to have you try this out, especially if you give us feedback. We have published instructions for developers on using this. Since this is a beta service, you can expect things to change, but we ll maintain compatibility where we can. If you re interested in using this in a commercial setting, please contact Freexian to discuss what we can do for you.

This post is an unpublished review for Unique security and privacy threats of large language models a comprehensive survey

No devices found on the network

DEBUG (MainThread) [homeassistant.components.govee_light_local.config_flow] Starting discovery with IP 192.168.42.2
DEBUG (MainThread) [homeassistant.components.govee_light_local.config_flow] No devices found with IP 192.168.42.2

    strategy:
      matrix:
        include:
          -   name: container, os: ubuntu-latest, container: rocker/r2u4ci  
          -   name: r-devel,   os: ubuntu-latest, container: rocker/drd  
          -   name: macos,     os: macos-latest  
          -   name: ubuntu,    os: ubuntu-latest  

    runs-on: $  matrix.os  
    container: $  matrix.container  

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 now sponsor me at GitHub.

• [DLA 4381-1] net-snmp security update to fix two CVEs related to denial of service.
• [DLA 4382-1] libsdl2 security update to fix one CVE related to a memory leak and a denial of service.
• [DLA 4380-1] cups-filters security update to fix three CVEs related to out of bounds read or writes or a heap buffer overflow.
• [ELA-1586-1] cups-filters security update to fix three CVEs in Buster and Stretch, related to out of bounds read or writes or a heap buffer overflow.
• [libcupsfilters] upload to unstable to fix two CVEs
• [cups-filters] upload to unstable to fix three CVEs
• [cups] upload to unstable to fix two CVEs
• [rlottie] upload to unstable to finally fix three CVEs
• [rplay] upload to unstable to finally fix one CVE
• [#1121342] trixie-pu bug for libcupsfilters to fix two CVEs in Trixie.
• [#1121391] trixie-pu bug for cups-filter to fix three CVEs in Trixie.
• [#1121392] bookworm-pu bug for cups-filter to fix three CVEs in Bookworm.
• [#112433] trixie-pu bug for rlottie to finally fix three CVEs in Trixie.
• [#112437] bookworm-pu bug for rlottie to finally fix three CVEs in Bookworm.

• lprng to unstable.
• cpdb-backend-cups to unstable.
• cpdb-libs to unstable.
• ippsample to unstable.
• cups-filters to unstable.

• siril to unstable (sponsored upload).
• supernovas to unstable (sponsored upload).

• openzwave-controlpanel to unstable.
• pywws to unstable.

• osmo-tetra to unstable.
• libgsm to unstable.
• osmo-tetra to unstable.

• cpptest to unstable.
• npd6 to unstable.
• ptunnel to unstable.
• ptunnel-ng to unstable.
• dateutils to unstable.
• apcupsd to unstable.
• puppet-modules-cirrax-gitolite to unstable.
• visam to unstable.
• apcupsd to unstable.

Searching more efficiently The first use case that worked for me was search. Instead of searching on a traditional search engine and then ending up on Stack Overflow, I could get the answer I was looking for directly in an AI side-window in my editor. Of course, that's bad news for Stack Overflow. I was however skeptical from the beginning since LLMs make mistakes, sometimes they making up function signatures or APIs that don't exist. Therefore I got into the habit of going to the official standard library documentation to double-check suggestions. For example, if the LLM suggests using strings.SplitN, I verify the function signature and behaviour carefully before using it. Basically, "don't trust and do verify." I stuck to the standard library in my project, but if an LLM recommends third-party dependencies for you, make sure they exist and that Socket doesn't flag them as malicious. Research has found that 5-20% of packages suggested by LLMs don't actually exist, making this a real attack vector (dubbed "slopsquatting").

Autocomplete is too distracting A step I took early on was to disable AI autocomplete in my editor. When learning a new language, you need to develop muscle memory for the syntax. Also, Go is no Java. There's not that much boilerplate to write in general. I found it quite distracting to see some almost correct code replace my thinking about the next step. I can see how one could go faster with these suggestions, but being a developer is not just about cranking out lines of code as fast as possible, it's also about constantly learning new things (and retaining them).

Asking about idiomatic code One of the most useful prompts when learning a new language is "Is this the most idiomatic way to do this in Go?". Large language models are good at recognizing patterns and can point out when you're writing code that works but doesn't follow the conventions of the language. This is especially valuable early on when you don't yet have a feel for what "good" code looks like in that language. It's usually pretty easy (at least for an experience developer) to tell when the LLM suggestion is actually counter productive or wrong. If it increases complexity or is harder to read/decode, it's probably not a good idea to do it.

Reviews One way a new dev gets better is through code review. If you have access to a friend who's an expert in the language you're learning, then you can definitely gain a lot by asking for feedback on your code. If you don't have access to such a valuable resource, or as a first step before you consult your friend, I found that AI-assisted code reviews can be useful:

1. Get the model to write the review prompt for you. Describe what you want reviewed and let it generate a detailed prompt.
2. Feed that prompt to multiple models. They each have different answers and will detect different problems.
3. Be prepared to ignore 50% of what they recommend. Some suggestions will be stylistic preferences, others will be wrong, or irrelevant.

The value is in the other 50%: the suggestions that make you think about your code differently or catch genuine problems. Similarly for security reviews:

• A lot of what they flag will need to be ignored (false positives, or things that don't apply to your threat model).
• Some of it may highlight areas for improvement that you hadn't considered.
• Occasionally, they will point out real vulnerabilities.

But always keep in mind that AI chatbots are trained to be people-pleasers and often feel the need to suggest something when nothing was needed

An unexpected benefit One side effect of using AI assistants was that having them write the scaffolding for unit tests motivated me to increase my code coverage. Trimming unnecessary test cases and adding missing ones is pretty quick when the grunt work is already done, and I ended up testing more of my code (being a personal project written in my own time) than I might have otherwise.

Learning In the end, I continue to believe in the value of learning from quality books (I find reading paper-based most effective). In addition, I like to create Anki questions for common mistakes or things I find I have to look up often. Remembering something will always be faster than asking an AI tool. So my experience this year tells me that LLMs can supplement traditional time-tested learning techniques, but I don't believe it obsoletes them. P.S. I experimented with getting an LLM to ghost-write this post for me from an outline (+ a detailed style guide) and I ended up having to rewrite at least 75% of it. It was largely a waste of time.

Code The Go standard library includes a module to read and write ZIP archives. It contains a function that turns a ZIP archive into an io/fs.FS structure that can replace embed.FS in most contexts.¹

package embed
import (
  "archive/zip"
  "bytes"
  _ "embed"
  "fmt"
  "io/fs"
  "sync"
)
//go:embed data/embed.zip
var embeddedZip []byte
var dataOnce = sync.OnceValue(func() *zip.Reader  
  r, err := zip.NewReader(bytes.NewReader(embeddedZip), int64(len(embeddedZip)))
  if err != nil  
    panic(fmt.Sprintf("cannot read embedded archive: %s", err))
   
  return r
 )
func Data() fs.FS  
  return dataOnce()
 

We can build the embed.zip archive with a rule in a Makefile. We specify the files to embed as dependencies to ensure changes are detected.

common/embed/data/embed.zip: console/data/frontend console/data/docs
common/embed/data/embed.zip: orchestrator/clickhouse/data/protocols.csv 
common/embed/data/embed.zip: orchestrator/clickhouse/data/icmp.csv
common/embed/data/embed.zip: orchestrator/clickhouse/data/asns.csv
common/embed/data/embed.zip:
    mkdir -p common/embed/data && zip --quiet --recurse-paths --filesync $@ $^

The automatic variable $@ is the rule target, while $^ expands to all the dependencies, modified or not.

Space gain Akvorado, a flow collector written in Go, embeds several static assets:

• CSV files to translate port numbers, protocols or AS numbers, and
• HTML, CSS, JS, and image files for the web interface, and
• the documentation.

Breakdown of the space used by each component before (left) and after (right) the introduction of embed.zip.

Embedding these assets into a ZIP archive reduced the size of the Akvorado executable by more than 4 MiB:

$ unzip -p common/embed/data/embed.zip   wc -c   numfmt --to=iec
7.3M
$ ll common/embed/data/embed.zip
-rw-r--r-- 1 bernat users 2.9M Dec  7 17:17 common/embed/data/embed.zip

Performance loss Reading from a compressed archive is not as fast as reading a flat file. A simple benchmark shows it is more than 4 slower. It also allocates some memory.²

goos: linux
goarch: amd64
pkg: akvorado/common/embed
cpu: AMD Ryzen 5 5600X 6-Core Processor
BenchmarkData/compressed-12     2262   526553 ns/op   610 B/op   10 allocs/op
BenchmarkData/uncompressed-12   9482   123175 ns/op     0 B/op    0 allocs/op

Each access to an asset requires a decompression step, as seen in this flame graph:

🖼 Flame graph when reading data from embed.zip compared to reading data directly

CPU flame graph comparing the time spent on CPU when reading data from embed.zip (left) versus reading data directly (right). Because the Go testing framework executes the benchmark for uncompressed data 4 times more often, it uses the same horizontal space as the benchmark for compressed data. The graph is interactive.

While a ZIP archive has an index to quickly find the requested file, seeking inside a compressed file is currently not possible.³ Therefore, the files from a compressed archive do not implement the io.ReaderAt or io.Seeker interfaces, unlike directly embedded files. This prevents some features, like serving partial files or detecting MIME types when serving files over HTTP.

---

For Akvorado, this is an acceptable compromise to save a few mebibytes from an executable of almost 100 MiB. Next week, I will continue this futile adventure by explaining how I prevented Go from disabling dead code elimination!

---

1. You can safely read multiple files concurrently. However, it does not implement ReadDir() and ReadFile() methods.
2. You could keep frequently accessed assets in memory. This reduces CPU usage and trades cached memory for resident memory.
3. SOZip is a profile that enables fast random access in a compressed file. However, Go s archive/zip module does not support it.

registry.gitlab.com/debdistutils/guix/container:latest
registry.gitlab.com/debdistutils/guix/container:slim
registry.gitlab.com/debdistutils/guix/container:extra
registry.gitlab.com/debdistutils/guix/container:gash

jas@kaka:~$ podman run -it --privileged --entrypoint=/bin/sh registry.gitlab.com/debdistutils/guix/container:latest
sh-5.2# env HOME=/ guix describe # https://issues.guix.gnu.org/74949
  guix 21ce6b3
    repository URL: https://git.guix.gnu.org/guix.git
    branch: master
    commit: 21ce6b392ace4c4d22543abc41bd7c22596cd6d2
sh-5.2# 

cp -rL /gnu/store/*profile/etc/* /etc/
echo 'root:x:0:0:root:/:/bin/sh' > /etc/passwd
echo 'root:x:0:' > /etc/group
groupadd --system guixbuild
for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild -d /var/empty -s $(command -v nologin) -c "Guix build user $i" --system guixbuilder$i; done
env LANG=C.UTF-8 guix-daemon --build-users-group=guixbuild &
guix archive --authorize < /share/guix/ci.guix.gnu.org.pub
guix archive --authorize < /share/guix/bordeaux.guix.gnu.org.pub
guix install hello
GUIX_PROFILE="/var/guix/profiles/per-user/root/guix-profile"
. "$GUIX_PROFILE/etc/profile"
hello

test-amd64-latest-wget-configure-make-libksba:
  image: registry.gitlab.com/debdistutils/guix/container:latest
  before_script:
  - cp -rL /gnu/store/*profile/etc/* /etc/
  - echo 'root:x:0:0:root:/:/bin/sh' > /etc/passwd
  - echo 'root:x:0:' > /etc/group
  - groupadd --system guixbuild
  - for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild -d /var/empty -s $(command -v nologin) -c "Guix build user $i" --system guixbuilder$i; done
  - export HOME=/
  - env LANG=C.UTF-8 guix-daemon --build-users-group=guixbuild &
  - guix archive --authorize < /share/guix/ci.guix.gnu.org.pub
  - guix archive --authorize < /share/guix/bordeaux.guix.gnu.org.pub
  - guix describe
  - guix install libgpg-error
  - GUIX_PROFILE="//.guix-profile"
  - . "$GUIX_PROFILE/etc/profile"
  script:
  - wget https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.6.7.tar.bz2
  - tar xfa libksba-1.6.7.tar.bz2
  - cd libksba-1.6.7
  - ./configure
  - make V=1
  - make check VERBOSE=t V=1

• aioftp
• basemap (fixing Cython 3.1 compatibility)
• billiard
• black
• django-phonenumber-field
• flask-security
• flufl.i18n
• langtable
• mariadb-connector-python
• peewee (fixing Cython 3.1 compatibility)
• pydantic
• pydantic-core
• pydantic-settings
• pylsqpack
• pymongo
• pymssql
• pyodbc
• python-auditwheel (contributed follow-up fix upstream)
• python-avro
• python-bleach
• python-btrees
• python-certifi
• python-charset-normalizer
• python-colorlog
• python-django-channels
• python-django-constance
• python-django-contact-form
• python-django-hashids
• python-djvulibre (fixing Cython 3.1 compatibility)
• python-evalidate
• python-legacy-cgi
• python-openstep-plist (fixing Cython 3.1 compatibility)
• python-pytest-run-parallel
• python-pytokens
• python-tblib
• python-webargs
• pyupgrade
• sqlfluff
• trove-classifiers
• ttconv
• wcwidth
• zope.hookable
• zope.i18nmessageid (removing run-time dependency on setuptools)
• zope.interface
• zope.proxy
• zope.security (removing run-time dependency on setuptools)
• zope.sqlalchemy

• kivy
• mypy
• pytest-mypy-testing (contributed upstream)
• python-cytoolz
• python-discord
• python-ncls, fixing some failures in pyranges
• pyxdg
• traitlets
• twine

• pmix: B-D on python3-all-dev, but not built for all supported Python3 versions
• python-certifi: Package not compatible with multiarch

• cdebconf: Move to /usr/lib/apt/apt-extracttemplates
• devscripts: Restore dpkg-dev dependency
• groff: Missing information about some utilities in the contrib directory

• base-passwd: French translation (merged and uploaded)
• cdebconf: Consider using the standard dh sequence in d/rules (merged and uploaded)
• cdebconf: Multiple select is not right aligned in Hebrew (patch fails to build; asked reporter for an update)
• cdebconf: Allow building without libglib2.0-dev (merged and uploaded)
• pydantic-core (merged and uploaded)
• pymongo (sponsored adoption by Aryan Karamtoth)
• python-maturin: Add missing build dependencies (merged and uploaded)