Feeds

Dear Readers,

Welcome to the final edition of the Volume 2 of our weekly newsletter, "Editor's Pick". Over the past year, our newsletter has gradually evolved alongside the developments and achievements of TDT. While the newsletter's objective—published every Monday—remains unchanged, it continues to spotlight the most important stories from the past week. However, the presentation of these stories has undergone a few adjustments.

The TDT newsletter is divided into two sections: the introductory segment and the stories from the past week. Initially, the introduction often took on a philosophical tone, exploring ideas not directly related to open source or Drupal but rather sharing deeply personal reflections from the author. These musings were then tied back to the Drupal ecosystem, often focusing on something notable from the week. However, a challenge arose as the number of important stories increased—once even reaching 30 in a single issue. To address this, we introduced a cap, limiting the newsletter to a maximum of 16 key stories each week.

Earlier this year, we also revised the introduction’s format. Instead of philosophical musings, we began focusing on significant updates in the Drupal and open-source communities, paired with subjective analysis. This shift proved effective, steering us in the right direction. Despite capping the story count at 16, the newsletter sometimes felt overly dense. To make it more reader-friendly, we refined the format further by including bullet points after a brief editorial introduction. This approach, inspired in part by 'TheWeeklyDrop' by Bob Kepford, has brought us closer to a concise yet comprehensive format.

As 2024 comes to a close, anticipation is growing for the full launch of Drupal CMS v1, scheduled for January 15, 2025. At The DropTimes, we’re excited to keep you informed about every development along the way.

With that let's move on to the important stories from the past week

DRUPAL CMS

• Inside the Media Management Track of Drupal CMS
• Canberra to Host Drupal CMS Release Party
• The Countdown to Drupal CMS: A New Era Begins on January 15, 2025
• Drupal CMS Release Party in Nagoya: Celebrate the Future of Web Development

EVENT

• Innoraft's Experience at DrupalCon Singapore 2024: A Recap
• Drupal Enthusiasts Gear Up for Jaipur Meetup in January 2025
• Cambridge to Host Inaugural DrupalCamp England in March 2025

DISCOVER DRUPAL

• Drupal Scheduler Module Simplifies Automated Content Management
• Views Data Export: Sprint 1 Achieves 60% Reduction in Open Issues

ORGANIZATION NEWS

• Drupal4Gov Earns Nonprofit Status: Empowering Government Through Open Source
• ANNAI Inc. Announces Drupal 7 Extended Support in Collaboration with amazee.io
• Drupal Advent Calendar 2024 Features The Drop Times
• Get a Sneak Peek: 1xINTERNET Offers Hands-On Drupal CMS Demo Ahead of Release

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.

To get timely updates, follow us on LinkedIn, Twitter and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you, 
Sincerely 
Alka Elizabeth 
Sub-editor, The DropTimes.

With 2024 ending, we'd like to summarize the last twelve months at Droptica. It has been a year of dynamic changes, both in the Drupal ecosystem and our services. We're excited to share with you our achievements, innovations, and future plans that will allow us to support client projects even better. Find out what improvements we've made so far and how they can affect your operations. Also, discover what opportunities are opening up for us in the year ahead.

At DrupalCon Asia in Singapore a few weeks ago, I delivered my traditional State of Drupal keynote. This event marked DrupalCon's return to Asia after an eight-year hiatus, with the last one being DrupalCon Mumbai in 2016.

It was so fun to reconnect with the Drupal community across Asia and feel the passion and enthusiasm for Drupal. The positive energy was so contagious that three weeks later, I still feel inspired by it.

If you missed the keynote, you can watch the video below, or download my slides (196 MB).

I talked about the significant progress we've made on Drupal CMS (code name Drupal Starshot) since DrupalCon Barcelona just a few months ago.

Our vision for Drupal CMS is clear: to set the standard for no-code website building. My updates highlighted how Drupal CMS empowers digital marketers and content creators to design sophisticated digital experiences while preserving Drupal's power and flexibility.

For more background on Drupal CMS, I recommend reading our three-year strategy document. We're about a quarter of the way through, time-wise, and as you'll see from my keynote, we're making very fast progress.

A slide from my recent DrupalCon Singapore State of Drupal keynote showcasing key contributors to Drupal CMS. This slide showcases how we recognize and celebrate Makers in our community, encouraging active participation in the project.

Below are some of the key improvements I showcased in my keynote, highlighted in short video segments. These videos demonstrate just 7 recipes, but we have nearly 20 in development.

Watching these demos, it will become very clear how much time and effort Drupal CMS can save for both beginners and experienced developers. Manually assembling these features would take weeks for a Drupal expert and months for a novice. These recipes pack a wealth of expertise and best practices. What once took a Drupal expert weeks can now be done by a novice in hours.

AI support in Drupal

We're integrating AI agents into Drupal to assist with complex site-building tasks, going far beyond just content creation. Users can choose to have AI complete tasks automatically or provide step-by-step guidance, helping them learn Drupal as they go.

Search

We're including enhanced search functionality that includes autocomplete and faceted search, delivering enterprise-grade functionality out-of-the-box.

Privacy

With increasing global privacy regulations, marketers need robust compliance solutions, yet very few content management systems offer this out-of-the-box. I demonstrated how Drupal CMS will offer a user-centric approach to privacy and consent management, making compliance easier and more effective.

Media management

Our improved media management tools now include features like focal point control and image style presets, enabling editors to handle visual content efficiently while maintaining accessibility standards.

Accessibility tools

Our accessibility tools provide real-time feedback during content creation, helping identify and resolve potential issues that could affect the user experience for visually-impaired visitors.

Analytics

Analytics integration streamlines the setup of Google Analytics and Tag Manager, something that 75% of all marketers use.

Experience Builder

Drupal's new Experience Builder will bring a massive improvement in visual page building. It combines drag-and-drop simplicity with an enterprise-grade component architecture. It looks fantastic, and I'm really excited for it!

Conclusion Drupal CMS has been a catalyst for innovation and collaboration, driving strong growth in organizational credits. Development of Drupal CMS began in 2024, and we expect a significant increase in contributions this year. Credits have tripled from 2019 to 2024, demonstrating our growing success in driving strategic innovation in Drupal.

In addition to our progress on Drupal CMS, the product, we've made real strides in other areas, such as marketing, modernizing Drupal.org, and improving documentation – all important parts of the Drupal Starshot initiative.

Overall, I'm incredibly proud of the progress we've made. So much so that we've released our first release candidate at DrupalCon Singapore, which you can try today by following my installation instructions for Drupal CMS.

While we still have a lot of work left, we are on track for the official release on January 15, 2025! To mark the occasion, we're inviting the Drupal community to organize release parties around the world. Whether you want to host your own event or join a party near you, you can find all the details and sign-up links for Drupal CMS release parties. I'll be celebrating from Boston and hope to drop in on other parties via Zoom!

Finally, I want to extend my heartfelt thanks to everyone who has contributed to Drupal CMS and DrupalCon Singapore. Your hard work and dedication have made this possible. Thank you!

Review: House in Hiding, by Jenny Schwartz

Series: Uncertain Sanctuary #2 Publisher: Jenny Schwartz Copyright: October 2020 Printing: September 2024 ASIN: B0DBX6GP8Z Format: Kindle Pages: 196

House in Hiding is the second book of a self-published space fantasy trilogy that started with The House That Walked Between Worlds. I read it as part of the Uncertain Sanctuary omnibus, which is reflected in the sidebar metadata.

At the end of the previous book, Kira had gathered a motley crew for her house and discovered that she had drawn the attention of some rather significant galactic powers. Now, with the help of her new (hopefully) friends, she has to decide what role she's going to play in the galaxy.

Or she can dither a lot, ruminate repeatedly on the same topics, and flail about randomly. That's also an option.

This is slightly unfair. By the second half of the book, the series plot is beginning to cohere around two major problems: what is happening to the magic flows in the universe, and who killed Kira's parents. But apparently there was a limit on my enjoyment for the chaos in Kira's chaotic decisiveness I praised in my review of the last book, and I hit that limit around the middle of this book. I am interested in the questions of ethics, responsibility, and public image that this series is raising. I'm just not convinced that Schwartz is going to provide satisfying answers.

One thing I do appreciate about this book is that it acknowledges that politics exist and that taking powerful people at face value is a bad idea. You would think that this would be a low bar, and yet it's depressing how many fantasy novels signal the trustworthiness of a character via some variation of "I looked into his eyes and shook his hand," or at least expect readers to be surprised by the inevitable betrayals. Schwartz does not make that mistake; after getting a call from a powerful player in galactic politics, the characters take apart everything that was said while assuming it could be attempted manipulation, which is the correct initial response.

My problem comes after that. I like reading about competent characters with a plan, and these are absurdly powerful but very naive characters with no plan. This is realistic for the situation Kira has been thrust into, but it's not that entertaining to read about.

I think the root of my problem is that there are some fundamental storytelling problems here that Schwartz is struggling to fix. The basic theory of story says that you need a protagonist, a setting, a conflict, and a plot. Schwartz has a good protagonist, one great supporting character and several adequate ones, and an enjoyably weird setting. I think she's working her way up to having a plot, although usually it's best for the plot to show up before the middle book of the series. What she doesn't have is a meaningful conflict. It's not entirely clear to either the reader or to Kira why Kira cares about what's happening.

You would not think this would be a problem given that Kira's parents were murdered before the start of the first book. That's a classic conflict that's driven more books than I think anyone could count. It's not what Kira has cared about up to this point, however; she got away from Earth and has shown no sign of wanting to go back or identify the people who killed her parents, perhaps because she mostly blames herself. Instead, she's stumbling across other problems in the universe that other people would like her to care about. She occasionally feels like she ought to care about them because they involve her new friends or because she wants to be a good person, but they have very little dramatic oomph. "I'm a sorcerer and vaguely want the universe to be a better place" turns out to not work that well as a source of dramatic tension.

This lack of conflict is somewhat fascinating because it's so different than most fantasy novels. If Schwartz were more aware of how oddly disconnected her protagonist is from the story conflict, I think there could be a thoughtful, if odd, psychological novel in here about one's ethical responsibilities if one suddenly had vast power and no strong attachments to the world. Kira does gesture occasionally in that direction, but there's no real meat to her musings. Instead, her lack of motivation is solved through one of the hoariest tropes in fiction: children in danger.

I really want to like this series, and I still love the House, but this book was not good. The romance that I was delighted to not be subjected to in the first book appears to be starting (sigh), the political maneuvering that happens here is only mildly interesting and not believably competent, and the book concludes in Kira making an egregiously and blatantly stupid mistake that should have resulted in one of her friends asking her what the hell she was doing. Some setup happens, and it seems likely that the final book will have a clear conflict and plot, but this middle book was a disappointing mess.

These books are fast to read and lightly entertaining between other things, and the House still has me invested enough in this universe that I'll read the last book in the omnibus. Be warned, though, that the middle book is more a collection of anecdotes than a story, and there's only so much of Kira showing off her power I can take without a conflict and a plot.

Followed by The House That Fought.

Rating: 5 out of 10

We used to have a Mono package. It was introduced on August 8 2016 by commit 763b3d50b6249b43fceda51445bbeb1f5f5fd7d0, at Mono version 4.4.1.0, but it was later discovered in April of 2022 that the release tarball that it was built from included prebuilt binaries. Further research revealed that these binaries were not optional. Due to this, a decision was made to remove the Mono package, carried out on September 1, 2022.

We now once again have a Mono package, due to a patch series I submitted on November 29, which after some revisions was committed on December 22. This patch series introduced a full, 17-mono-package sequence that takes us from a mono-1.2.6 built fully from source to mono-6.12.0 built fully from source, using only packages that already have full bootstrap paths. I make no promise that this is the shortest or most optimal path, but it exists and I have verified it works.

As I've spent what is probably an unreasonable amount of time working toward this, I thought I'd share some of my thoughts, experiences, and commentary. Sorry in advance if it gets a bit rambly or lecture-ish.

Prologue

I started down this road because someone I'm working on a project with decided to depend on a C# package that requires C# 12.0 features, and my personal Mono package based on the tarball releases (which include bootstrap binaries) only went up to C# 7.0. This meant that the C# package in question de facto required strictly Microsoft's (er, I mean, "the .NET foundation"'s) .NET implementation — hereafter referred to as "dotnet" — and a very recent version no less. The bootstrapping story with dotnet is very bad; even beginning to untangle it would probably require a relatively modern C# compiler, and something that at least sort of understands MSBuild. And there's not much point to "bootstrapping" dotnet from something that isn't bootstrapped itself. So I figured I may as well start with Mono.

History

While Mono is today probably the most well-known alternative to Microsoft's .NET offerings, it is not the only one. Indeed, in the early 2000s there were at least 2 competing free software implementations: Mono, and DotGNU's Portable.NET (abbreviated pnet). They differed in goals, licenses, and methods: Portable.NET was a GNU project concerned with, among other things, limiting the ability of Microsoft to impose vendor lock-in via its proprietary .NET implementation and software patents. As a GNU project, it used the GPL for its runtime and compiler, and the GPL with a linking exception for its standard library, pnetlib. Mono, on the other hand, used a mix of many copyleft and permissive licenses: X11 for the standard library, GPL for the compiler (later dual-licensed to add an X11 option), and LGPL for the runtime, with GPL and LGPL code also offered "under commercial terms for when the GPL and the LGPL are not suitable". In 2016 after its acquisition by Microsoft, the runtime was relicensed to use the Expat (MIT) license.

But perhaps most importantly to us, while Mono opted to write its C# compiler, mcs, in... C#, Portable.NET's runtime and C# compiler were both written in C. Portable.NET along with the entire DotGNU project (except for LibJIT) was decommissioned in 2012, but the source is still available, and it still works fine (with a few modifications for compatibility with newer versions of its dependencies). In September of 2022, Adam Faiz submitted patches to package pnet and pnetlib, along with one of their dependencies named treecc. These packages were based on the last release of Portable.NET, version 0.8.0, released in 2007. I initially used these packages as the basis for my bootstrap efforts, and even managed to get mono-1.2.6 built using them, but later discovered that using a more recent version from git made it much easier. For example, while pnet-0.8.0 can do pointer arithmetic inside unsafe code blocks, it doesn't support the += or -= operators specifically, which requires lots of patching (after all, who would use x = x + y when you could do x += y?). There are many other similar improvements in the git version, so for this patch series I've decided to go with pnet-git.

The start

After building mono-1.2.6, I tried a few later versions, and the third or fourth one would always fail with errors about missing methods. It turns out that the reason for this is that, contrary to what their marketing suggests, C# and Java are not "write once, run everywhere". This is because their compilers rely on the details of the libraries that the program will be run with at compile-time. This is used, for example, to do overload resolution. Suppose, for example, that a certain implementation of the == operator is present in version 1.0 of a library, and then in version 2.0 of a library a more specific implementation is introduced. Now code that is compiled against version 2.0 may instead automatically reference the more-specific implementation, as is in accordance with the rules of C#. But when it is run with version 1.0, it will fail because that implementation doesn't exist. In my case, for some reason the initial mcs and core libraries being built to compile the rest of Mono were being compiled against a 2.0 library and then run with a 1.0 library. It turns out that this was because mcs uses mono's code for producing assemblies (.NET dlls and exes), and mono decides which version to put in an assembly it writes based on "which runtime version" is being used, and that version is decided at startup based on... the version that was put in the assembly it is running. So for example, mono-1.9.1 would produce 2.0 assemblies because mono-1.2.6 produced 2.0 assemblies because pnet produced 2.0 assemblies. So I modified Mono's runtime in mono-1.9.1 to allow for this version to be overridden via environment variable, and set it to v1.1.4322, and things went a lot more smoothly after that.

From there on it was mostly the usual trial-and-error process of identifying where things had bitrotted. I made sure to unvendor libgc wherever possible, though eventually by mono-4.9.0 they explicitly dropped support in their configure script for using any libgc other than what was bundled, so at that point I switched to using their homebrewed sgen garbage collector.

A concerning development

Once I got to mono-2.11.4, though, things took a turn for the interesting: Mono started using git submodules, and the (recursive? #t) clones were all failing. It turns out that this is because their submodules reference github.com using the git:// protocol.

This is notable for a few reasons.

First, GitHub dropped support for the git:// protocol in 2021, so recursive clones won't work now. This means I have to explicitly list out every submodule, its commit, and its sha256 hash, for every Mono version until they switched to using http or https. mono-2.11.4 has only 4 submodules, but that doesn't last for long: by mono-4.9.0 it has 14 submodules. A significant portion of these patches is just listing these submodules and their hashes. It's a bit annoying.

The more concerning reason, though, is why GitHub dropped support for the git:// protocol: it is unencrypted and unauthenticated. This is mitigated somewhat by the use of sha-1 hashes to identify commits in the referenced submodules, putting a significant computational burden on anyone who would try to alter what was fetched corresponding to a given submodule. Significantly more risky, though, is the process of updating submodules that use git:// URLs. It is quite unlikely that a developer is going to independently clone one of the submodules over https, navigate to a desirable commit, copy the sha-1 hash, and manually update the submodule reference's commit. They're far more likely to run cd submodule; git pull; cd ..; git add submodule; git commit ... or an equivalent.

Of course, any changes a network man-in-the-middle might try to make here would still be reflected in the commit history, so even if a developer did that, they or any of their fellow committers could spot anything strange or malicious and point it out. Also, the changes couldn't be propagated to others trying to pull them who weren't on a network path containing the MITM because the potentially-malicious commit wouldn't be present in the real submodule's repository. So the transparency of git clearly showing changes to text files, combined with the fact that surely no git hosting platform would just allow arbitrary entities to make whatever commits they want accessible under any arbitrary repository URL, rather mitigate this security issue.

This usage of git:// URLs lasted all the way until September 28, 2021, when GitHub's removal of support for it forced the developers to change them to https.

Meanwhile, in reality

On November 28, 2016, Mono added a submodule named roslyn-binaries. Unsurprisingly, it included binary blobs for Microsoft's Roslyn compiler (which I believe had been open-sourced shortly prior). From here on, Mono's build system would default to using these binaries for building on little-endian systems (though another compiler could be specified with the --with-csc configure flag). I happen to know that it is extremely unlikely that many Mono developers used this configure flag. I know this because the 5.0 series is an absolute pain in the neck to build from source, because they consistently depend on new C# features before they implement them.

To go on a brief tangent: does anyone remember back when youtube-dl was temporarily taken down from GitHub due to the RIAA's DMCA request? Many were unhappy about that. One such unhappy person made news when they made the full contents of youtube-dl's repository available to access through the DMCA request repository. It turns out that there are many actions that one can take on GitHub that will make arbitrary commits available under arbitrary repository URLs.

So, in reality, for the span of time from November 28, 2016 to September 28, 2021, anybody sitting on the network path between GitHub and any Mono developer updating the roslyn-binaries submodule could decide on any arbitrary new commit to be used. Of course, merely inspecting the diff for the commit will reveal nothing of use, because the contents are binary blobs. And not only are these blobs those of a compiler, they are the blobs of a compiler that is sure to be used to compile another compiler, which will then be redistributed as an opaque, non-bootstrappable binary blob to be used for compiling other compilers.

You would be hard-pressed to find a more fertile breeding ground for Ken Thompson / Trusting Trust attacks. If every agent of the NSA (and whatever other agencies, including those of other countries, had access to the appropriate network traffic) somehow failed to capitalize on 6 years of opportunity to compromise an entire software ecosystem using only a basic MITM of unencrypted traffic, they deserve to be sacked. Whether such an attack actually occurred or not, this is a case study in carelessness and why bootstrappability is so important; discovering all this made me quite worried about having used a Mono version built from blobs previously, and has convinced me that, as time-wasting and tedious as this project has been, it is nevertheless probably an important one.

Another note on roslyn-binaries

If you're going to write a self-hosting compiler, the least you can do is keep it self-hosting. Deciding to write a self-hosting compiler is a valid choice, of course, with its own merits and demerits, but there is something bitterly poetic about Mono starting out requiring specifically Microsoft's C# compiler in order to build (Mono did its initial bootstrapping using Microsoft's proprietary csc), achieving independence through self-hosting, being acquired by Microsoft, and thereafter coming crawling back to Microsoft's C# compiler once more before eventually dying.

The funny thing is that it's not even necessary. The dependencies on new C# features are all in Mono's standard library (which increasingly borrowed code from Microsoft's corefx library), not in Mono's compiler.

More binary submodules?

Even before roslyn-binaries, there was binary-reference-assemblies, which contained prebuilt "reference" blobs for the various versions of the standard libraries. These exist, I assume, precisely because of the library incompatibility problems regarding overloading that I mentioned earlier. While later versions of Mono included sources and a build system for producing these reference binaries, mono-4.9.0 and earlier did not. Mono's build system still demanded something to install, though, so I told it to use the real standard library of the input Mono version. When I did get to a Mono version that at least claimed to support regenerating the reference binaries, I found that it didn't work with mcs due to differences in which libraries had to be referenced, so I had to patch it to add a bunch of references determined through trial and error.

The xunit-binaries submodule was also added sometime before mono-5.1.0. This dependency makes it impossible to run the full test suite without binary blobs. Presumably for this reason, Debian elects to only run tests within the mono/mini/ and mono/tests/ subdirectories. For my part, I've disabled all tests except for those of mono-6.12.0, the final version, limited to the two aforementioned subdirectories. This is because it would take extra time for the builds, because several of the tests depend on binary blobs bundled into the Mono repository itself (which my thorough cleaning of all dlls and exes from the sources removes), because a large chunk of the tests depend on binary blobs in xunit-binaries in later versions, and because "expect some test failures" is part of the Mono documentation and I don't have the time to figure out for the Mono developers every reason why each of 17 versions of their test suite is broken.

The long march through the 5.0s

The 5.0 series was when Microsoft acquired Mono, and it shows. You'll notice I needed to introduce pre- packages for various versions because in several cases a tagged release could not build the following tagged release. For that matter, they couldn't build the pre- package either, but it at least took fewer patches to get them working. The reason for this is that Mono added a dependency on Microsoft's corefx library source code, and it usually started using C# features well before mcs was able to compile them. Because of this, despite taking 8 versions to get from 1.2.6 to 4.9.0, it took another 8 versions to get through the 5.0 series, and 5 of them required nontrivial patching to massage the source into a form compilable by mcs.

The final stretch

Eventually I realized that the dependencies on new features were all coming from corefx, not from Mono's compiler. Consequently, the only reason for this particular bootstrap-hostile ordering of builds is that it happened to be the order the Mono devs committed things. So I just cherry-picked every commit I could find touching mcs/mcs (magit was quite useful for this) and applied it to 5.10.0 to produce what is essentially the 6.12.0 compiler, then used it to jump straight to building 6.12.0.

Use of this technique earlier on in the bootstrap process may be of interest to anyone looking to shorten the chain of packages.

The finishing touches

My initial goal was to package dotnet, and I had tried to progress toward that from mono-4.9.0 for a period, but with no success. During that time, though, I did encounter a bug in Mono's xbuild condition parser, which I wrote a patch for, and included in mono-6.12.0.

I also discovered that xbuild would wrongly complain about missing references even when the proper assemblies were in MONO_PATH or MONO_GAC_PREFIX, because xbuild would erroneously only consider the path /gnu/store/...mono-6.12.0/lib/mono/gac when looking for global assembly caches, completely ignoring MONO_GAC_PREFIX. So I wrote a patch to fix that, and included it in mono-6.12.0.

Having witnessed how much nicer it is to package things that use rpath / runpath than things that use environment variables (like python) and therefore require constant wrapping of executables and use of propagated-inputs, I devised a patch that would extend Mono's per-assembly config files to support a <runpath> element. For example, if you have a file /tmp/dir2/test2.exe, and there is also a file /tmp/dir2/test2.exe.config, and its contents are

<?xml version="1.0" encoding="utf-8"?> <configuration> <runpath path="/tmp/dir1"/> </configuration>

and it references test1.dll, it will first look for it at /tmp/dir1/test1.dll. Note that, of course, test1.dll still needs to be accessible to the compiler at compile-time through MONO_PATH or an explicitly-specified path passed on the mcs command line.

It is my hope that this feature will be of use to anybody interested in developing a build system.

Future work

Mono had several difficult points in bootstrapping and packaging, but at the end of the day it still met the basic description of a software package: well-defined environment-supplied inputs and sources, a user-supplied install prefix, and files installed under that prefix.

The dotnet world is an entirely different beast. The first step of most build systems I have encountered from that realm is downloading an entire toolchain, among other dependencies, as a binary blob. They heavily depend on the exact packages they specify being available exactly where they say to install them. There is no "install", there are no "install directories" to my knowledge. A build that doesn't contact nuget.org is an aberration. I am at a loss how to build these things, much less package them. I badly need help.

There are also some portability issues with the current bootstrap path. While Portable.NET can fall back to an interpreter written in C where LibJIT isn't supported, old versions of Mono have no such capability. Strictly speaking, there is some bitrotted code for an interpreter that used to work, but has stopped working by mono-1.2.6. It was left unmaintained until it was eventually removed in 2014, only to be revived in 2017. This poses a dilemma for anybody wanting to bootstrap Mono on a platform that wasn't supported by mono-1.2.6's JIT compiler. There are a number of possible ways to try resolving this, ranging from backporting the new interpreter, to fixing up the old one for every version prior to the new interpreter, to forward-porting the old compiler and class libraries to the new interpreter, etc.

The most interesting option, though, in my opinion, would be to port mcs to Portable.NET. This would achieve the intended portability, while also allowing individual builds to be much faster since we're only building mcs, not the runtime and class library each time. It would also allow us to make much bigger version jumps, since, as we discovered earlier, many of the new C# feature dependencies in Mono come from the class library rather than the compiler. Such a shortened bootstrap could also make the bootstrap path more appealing for other distributions to use instead of binaries.

Closing thoughts

"You wish now that our places had been exchanged. That I had died, and DotGNU had lived?"

"... Yes. I wish that."

Maintenance of Mono was recently transferred over to WineHQ. With that announcement this statement was placed at https://www.mono-project.com:

"We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us."

I would like to clarify that, according to Miguel de Icaza himself, DotGNU "started working on the system about the same time". According to this DotGNU newsletter, Portable.NET began "in January 2001". While it's unclear exactly when Portable.NET reached various milestones, and the significance of the various milestones varies somewhat (for example, Mono probably does not care that Portable.NET also includes a Java and C compiler), I think that there is cause to dispute the claim that Mono was "the first" .NET implementation on Linux.

On a related note, if we haven't looked at the possibility of using Portable.NET in the Java bootstrap process, it may be worth visiting at some point.

Thank you to the DotGNU project, for the .NET implementation that made this bootstrap possible, Adam Faiz, for the initial packaging of it that let me jump straight in, the Mono project, for... Mono, and you, for your time.

This post leverages support for Atari Hard Disk Interface Partition (AHDI) partition tables in the Linux kernel, activated by default in Debian, and in the parted partition editor.

Accessing the content of a partition using a user mounted loop device

This is the easiest procedure and should be tried to first. Depending if your Linux kernel has support for AHDI partition tables, and the size of the FAT system on the partition, this procedure might not work. In that case, try the procedure using mtools further below.

Attach a disk image called hd80mb.image to a loop device:

$ udisksctl loop-setup --file hd80mb.image Mapped file hd80mb.image as /dev/loop0

Notice how the kernel detected the partition table:

$ dmesg | grep loop0 [160892.151941] loop0: detected capacity change from 0 to 164138 [160892.171061] loop0: AHDI p1 p2 p3 p4

Inspect the block devices created for each partition:

$ lsblk | grep loop0

If the partitions are not already mounted by udisks2 under /media/, mount them manually:

$ sudo mount /dev/loop0p1 /mnt/ $ ls /mnt/ SHDRIVER.SYS

When you are finished copying data, unmount the partition, and detach the loop device.

$ sudo umount /mnt $ udisksctl loop-delete --block-device /dev/loop0 Accessing the content of a partition using mtools and parted

This procedure uses the mtools package and the support for the AHDI partition scheme in the parted partition editor.

Display the partition table, with partitions offsets in bytes:

$ parted st_mint-1.5.img -- unit B print ... Partition Table: atari Disk Flags: Number Start End Size Type File system Flags 1 1024B 133170175B 133169152B primary boot 2 133170176B 266339327B 133169152B primary 3 266339328B 399508479B 133169152B primary 4 399508480B 532676607B 133168128B primary

Set some Atari-friendly mtools options:

$ export MTOOLS_SKIP_CHECK=1 $ export MTOOLS_NO_VFAT=1

List the content of the partition, passing as parameter the offset in bytes of the partition: For instance here we are interested in the second partition, and the parted output above indicates that this partition starts at byte offset 133170176 in the disk image.

$ mdir -s -i st_mint-1.5.img@@133170176 Volume in drive : has no label Directory for ::/ demodata 2024-08-27 11:43 1 file 0 bytes Directory for ::/demodata

We can also use the command mcopy with a similar syntax to copy data from and to the disk image. For instance we copy a file named file.zip to the root directory of the second partition:

$ mcopy -s -i st_mint-1.5.img@@133170176 file.zip :: Recompiling mtools to access large partitions

With disk images having large AHDI partitions (well considered large in 1992 …), you might encounter the error

mdir -s -i cecile-falcon-singlepart-1GB.img@@1024 init: sector size too big Cannot initialize '::'

This error is caused by the non-standard large logical sectors that the TOS uses for large FAT partitions (see the Atari Hard Disk Filesystem reference on page 41, TOS partitions size)

We can inspect the logical sector size using fsck tools:

$ udiskctl loop-setup --file cecile-falcon-singlepart-1GB.img $ sudo fsck.fat -Anv /dev/loop0p1 fsck.fat 4.2 (2021-01-31) ... Media byte 0xf8 (hard disk) 16384 bytes per logical sector

To access the partition, you need to patch mtools, so that it supports a logical sector size of 16384 bytes. For this you need to change the MAX_SECTOR macro from 8192 to 16384 in msdos.h in the mtools distribution and recompile. A rebuilt mtools is then able to access the partition:

$ /usr/local/bin/mdir -s -i cecile-falcon-singlepart-1GB.img@@1024 Volume in drive : has no label Directory for ::/ CECILE SYS 8462 1998-03-27 22:42 NEWDESK INF 804 2024-09-09 9:23 2 files 9 266 bytes 1 072 463 872 bytes free

The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.2 "Punkadiddle"!

2024 was the year that finally introduced a Qt5/KF5 based Amarok 3 release in April, and it was followed by a number of 3.x bugfix and feature releases. Now, to conclude 2024, it is time for Amarok 3.2.0. The most interesting change is probably the ability to build the same codebase on both Qt5 and Qt6. Qt5/KF5 is still the recommended, tested configuration, for now. Qt6 version should be usable, but in addition to any unknown issues, there are a number of known issues documented in README.

Additionally, 3.2.0 includes e.g. collection filtering and Ampache related features and fixes, oldest resolved feature request being from 2013. Multiple long-standing crash bug reports have been closed lately, and probable fixes for various issues observed in crash report data have been introduced. Amarok 3.2.0 should thus feature slightly improved stability. Some 3.2.x bugfix releases are to be expected in 2025, before the focus shifts to preparations for an "Amarok 4".

Changes since 3.1.1 CHANGES:

• Building an experimental Qt6/KF6 Amarok version is now possible
• Allow filtering collection by lack of tag / empty tag (BR 325317)

CHANGES:

• Amarok now depends on KDE Frameworks 5.108
• Show current track context applet by default

BUGFIXES:

• Probably fix occasional crashes when filtering collection (BR 492406)
• Probably fix occasional crashes when clearing CompondProgressBars
• Fix context view applets on Qt6/KF6
• Fix Ampache login on server version 5.0.0 and later (BR 496581)
• Fix crash if Ampache login is redirected (BR 396590)

The git repository statistics between 3.1.0 and 3.2.0 are as follows:

l10n daemon script: 68 commits, +41987, -35275
Tuomas Nurmi: 46 commits, +723, -4854
Raresh Rus: 3 commits, +41, -53
Ian Abbott: 1 commit, +17, -3
Heiko Becker: 1 commit, +0, -3

Getting Amarok

In addition to source code, Amarok is available for installation from many distributions' package repositories, which are likely to get updated to 3.2.0 soon, as well as the flatpak available on flathub.

Packager section

You can find the tarball package on download.kde.org and it has been signed with Tuomas Nurmi's GPG key.

One of the much requested feature for Kdenlive was a modern background removal tool.

Among the many features and enhancements that will come in 2025, we are excited to announce a preview version with a background removal tool using object masks. The feature is based on SAM2‘s object segmentation. You can download the Kdenlive test alpha version from the links at the bottom of this page.

Since this is a testing preview version, the binaries are not signed and you might need to manually allow the install on Windows.

Here is a quick demo of how the feature works in screenshots:

1. Add a clip to your project
2. Select a zone to apply the background removal
3. Click on the Mask button
4. Select Configure to setup the tool (to be done only the first time)

1. Click on Install in the Object detection setup

Go drink a coffee while the module is being downloaded and installed (between 5 and 15 minutes depending on your internet connection). Currently there is not much feedback from the install, we will improve this so just be patient.

Kdenlive downloads the smallest model by default. Once it shows up, you can close the dialog and start using the feature.

1. Click on the Create new mask button
2. Click on the object you want to keep (foreground)
3. When the white mask appears, click on Generate Mask
4. The video mask task starts, drink another coffee

When the video mask is created, it will appear in the mask manager dialog (2).

1. Drag your clip zone from the clip monitor to timeline
2. Select the newly created mask
3. Click on Apply Mask

https://kdenlive.org/wp-content/uploads/2024/12/dino-final.mp4

Success, you can now enjoy your video without the background.

Of course, this feature can also be used for other exciting things like applying an effect or a color correction to a specific object only.

Keep in mind that this is an alpha version, we will enhance and polish it for the upcoming 25.04 version. Happy editing!

Linux AppImage download:

https://files.kde.org/kdenlive/unstable/kdenlive-25.04.0-alpha-x86_64.AppImage.mirrorlist

Windows download:

https://files.kde.org/kdenlive/unstable/kdenlive-25.04-alpha-x86_64.exe.mirrorlist

Flatpak:

Check our experimantal nightly version (see instructions at the bottom of our download page)

The post Kdenlive new year preview appeared first on Kdenlive.

Unfortunately, there won't be any "This Week in KDE Apps" blog post this week as I (Carl) and others are at the #38C3 (Chaos Communication Congress) in Hamburg. But if you are also there, don't hesitate to come by and say hi.

61st issue of Andrei Neagoie's must-read monthly Python Newsletter: Octoverse Results Reveal, GPU Computing, and much more. Read the full newsletter to get up-to-date with everything you need to know from last month.

Review: The Last Hour Between Worlds, by Melissa Caruso

Series: The Echo Archives #1 Publisher: Orbit Copyright: November 2024 ISBN: 0-316-30364-X Format: Kindle Pages: 388

The Last Hour Between Worlds is urban, somewhat political high fantasy with strong fae vibes. It is the first book of a series, but it stands alone quite well.

Kembral Thorne is a Hound, a member of the guild that serves as guards, investigators, and protectors. Kembral's specialty is Echo retrieval: rescues of people and animals who have fallen through a weak spot in reality into one of the strange, dangerous, and malleable layers called Echoes. Kem once rescued a dog from six layers down, an almost unheard-of feat.

Kem is also a new single mother, which means her past two months have been spent in a sleep-deprived haze revolving exclusively around her much-beloved infant. Dona Marjorie Swift's year-turning party is the first time she's been out without Emmi since she gave birth, and she's only there because her sister took the child and practically shoved her out the door. Now, she's desperately trying to remember how to be social and normal, which is not made easier by the unexpected presence of Rika at the party.

Rika Nonesuch is not a Hound. She's a Cat, a member of the guild of thieves and occasional assassins. They are the nemesis of the Hounds, but in a stylized and formalized way in which certain courtesies are expected. (The politics of this don't really make sense; you just have to go with it.) Kem has complicated feelings about Rika's grace, banter, and intoxicating perfume, feelings that she thought might be reciprocated until Rika drugged her during an apparent date and left her buried under a pile of garbage. She was not expecting Rika to be at this party and is definitely not ready to have a conversation with her.

This emotional turmoil is rudely interrupted by the death of nearly everyone at the party via an Echo poison, the appearance of a dark figure driving a black sword into someone, and the descent of the entire party into an Echo.

This was one of those books that kept getting better the farther into the book I read. I was a bit leery at first because the publisher's blurb made it sound more like horror than I prefer, but this is more the disturbing strangeness of fae creatures than the sort of gruesomeness, disgust, or body horror that I find off-putting. Most importantly, the point of this book is not to torture the characters or scare the reader. It's instead structured a bit like a murder mystery, but one whose resolution requires working out obscure fantasy rules and hidden political agendas. One of the currencies in the world of Echos is blood, but another is emotion, revelation, and the stories that bring both, and Caruso focuses the story more on that aspect than on horrifying imagery.

Rika frowned. "Resolve it? How?"

"I have no idea." I couldn't keep my frustration from leaking through. "Might be that we have to delve deep into our own hearts to confront the unhealed wounds we've carried with us in secret. Might be that we have to say their names backward, or just close our eyes and they'll go away. Echoes never make any damned sense."

Rika made a face. "We'd better not have to confront our unhealed wounds, or I'm leaving you to die."

All of The Last Hour Between Worlds is told in the first person from Kem's perspective, but Rika is the best character in this book. Kem is a rather straightforward, dogged, stubborn protector; Rika is complicated, selfish, conflicted, and considerably more dynamic. The first obvious twist in her background I spotted so long before Kem found out that it was a bit frustrating, but there were multiple satisfying twists after that. As advertised in the blurb, there's a sapphic romance angle here, but it's the sort that comes from a complicated friendship and a lot of mutual respect rather than love at first sight. Some of their relationship conflict is driven by misunderstanding, but the misunderstanding happens before the novel begins, which means the reader doesn't have to sit through the bit where one yells at the characters for being stupid.

It helps that the characters have something concrete to do, and that driving plot problem is multi-layered and satisfying. Each time the party falls through a layer of reality, it's mostly reset to the start of the book, but the word "mostly" is hiding a lot of subtlety. Given the clock at the start of each chapter and the blurb (if one read it), the reader can make a good guess that the plot problem will not be fully resolved until the characters fall quite deep into the Echoes, but the story never felt repetitive the way that some time loop stories can. As the characters gain more understanding, the problems change, the players change, and they have to make several excursions into the surrounding world.

This is the sort of fantasy that feels a bit like science fiction. You're thrown into a world with a different culture and different rules that are foreign to the reader and natural to the characters. Part of the fun of reading is figuring out the rules, history, and backstory while watching the characters try to solve the puzzles they're faced with.

The writing is good but not great. Characterization was good enough for a story primarily focused on action and puzzle-solving, but it was a bit lacking in subtlety. I think Caruso's strengths showed most in the world design, particularly the magic system and the rules followed by the Echo creatures. The excursions outside of the somewhat-protected house struck a balance between eeriness and comprehensibility that reminded me of T. Kingfisher or Sandman. The human politics were unfortunately less successful and rested on some tired centrist cliches. Thankfully, this was not the main point of the story.

I should also warn that there is a lot of talk about babies. Kem's entire identity at the start of the novel, to the point of incessant monologue, is "new mother." This is not a perspective we get very often in fantasy, and Kem eventually finds a steadier balance between her bond with her daughter and the other parts of her life. I think some readers will feel very seen. But Caruso leans hard into maternal bonding. So hard. If you don't want to read about someone who is deliriously obsessed with their new child, you may want to skip this one.

Right after I finished this book, I thought it was amazing. Now that I've had a few days to think about it, the lack of subtlety and the facile human politics brought it down a notch. I'm a science fiction reader at heart, so I loved the slow revelation of mechanics; the reader starts the story by knowing that Kem can "blink step" but not knowing what that means, and by the end of the story one not only knows but has opinions about its limitations, political implications, and interactions with other forms of magic. The Echo worlds are treated similarly, and this type of world-building is my jam. But the cost is that the human characters, particularly the supporting cast, don't get the same focus and therefore are a bit straightforward and obvious. The subplot with Dona Vandelle was particularly annoying.

Ah well. Kem and Rika's relationship did work, and it's the center of the book.

If you like fantasy mechanics but are a bit leery of fae stories because they feel too symbolic or arbitrary, give this a try. It's the most satisfyingly constructed fae story that I've read in a long time. It's not great literary fiction, but it's also not trying to be; it's a puzzle adventure, and a well-executed one. Recommended, and I will definitely be reading the sequel.

Content notes: Lots of violent death and other physical damage, creepy dream worlds with implied but not explicit horror, and rather a lot of blood.

Followed by The Last Soul Among Wolves, not yet published at the time I wrote this review.

Rating: 8 out of 10

Screen magnification is an accessibility feature that enlarges the screen to make text, images, and other user interface components easier to see or read. It is not something that requires constant developer attention, however, in Plasma 6.3, the zoom plugin received some improvements that I’d like to go over quickly.

Pixel grid A script element has been removed to ensure Planet works properly. Please find it in the original post.

Arguably, it will be too hard to read text if the screen is “too” zoomed in. There are several ways how this case can be handled. For example, the magnification factor can be capped (e.g. to x8 or x10), or do nothing and just display blurry upscaled screen contents… or display something else.

With the old behavior, the zoom plugin used not to do anything special when the magnification factor reaches a high value, but with the new behavior, it is going to display the individual pixels on the screen. This can be very useful to developers, designers, etc.

System settings

In addition to the new pixel grid mode, the system settings for the zoom plugin received minor polishing to look more consistent with other config modules.

Future improvements

Keyboard shortcuts are not the only way how the zoom plugin can be triggered. For example, it can be also triggered by pressing Meta and Control keys and scrolling the mouse wheel to zoom. However, it is not exposed anywhere in the user interface and some people may prefer zooming with just the Meta key pressed. In order to address the discoverability issue of the mouse wheel gesture and allow using a different combination of modifier keys, there is already a patch to add the corresponding system setting, but it’s 6.4 material. It would be also nice to move screen magnifier settings from the desktop effects config module to the accessibility config module.

Last but not least, the zoom effect currently uses the bi-linear magnification filter, which produces okay-ish visual results, but it’s worth looking for alternative upscaling algorithms that handle edges better so zoomed in text looks less blurry.

Changelog

Hello,

I need your help. I’ve created a first version of Skrooge that can be built on KF6 and Qt6 (Its temporary number version is 2.33.8).

I use it daily for managing my own accounts. However, before releasing an official version, I’d like some of you to test it and provide feedback by reporting any issues you encounter.

I’m counting on you! To get started, check out the download section and the README.md.

Thanks in advance!

This tutorial looks at how to deploy a Django app to AWS ECS with AWS Copilot.

As I was tired of long build times, so I convinced my boss to buy me a Lenovo Legion pro 7. The reason is: this laptop has an AMD Ryzen 9 7945HX that has 16 cores (32 threads). This reduces a lot the time I have to just wait for my laptop to compile, or run unit tests, especially for big packages like Ceph, OpenVSwitch, and so on.

When buying it, I knew it would not be a good fit for Debian, as this type of laptop is aimed at gaming, and the support under Linux is rather bad. I wish Lenovo had other policies, but that is the way it is: if you’re a Linux user, you’re not suppose to be needing a big CPU, apparently.

Anyways, I slowly have been able to fix all issues over this year. In this blog post I’ll explain how I fixed all problems, in the hope it can be useful to others. And I’ll explain what the src:lenovolegionlinux package (that I now maintain in Debian) does.

Video

The laptop comes with an nVidia RTX-4080 and a Radeon. I quickly tried the radeon, but couldn’t make it work with an external monitor. So I gave up on it, disabled it, and now I’m using the proprietary nVidia driver from non-free. I don’t like it: the nVidia card drains too much power, and I don’t care at all 3D acceleration. I would have prefer an intel board, but no choice: all laptops with this kind of CPU comes with gamer’s 3D card. Anyways, apart from the power issue, it works out well.

Fan control

This sounds like a non-issue, but it is a huge one. Indeed, if not controlling the fan, it is impossible to get the full potential of the CPUs that are otherwise throttling. One may end up using the laptop at a few hundred MHz instead of 5GHz+. More on this later.

Sound

It took me a really long time to figure out what to do. Indeed, while the sound card works out of the box, the issue was that my laptop came with a TI (Texas Instrument) speaker firmware that isn’t on by default. I suppose the purpose is to save on power when it isn’t in use. Anyways, to have sound working, one need in Debian, to run at least kernel 6.10, which means for me, running the Bookworm backport, so that there’s a kernel module for the speakers. But that’s not it. The speakers also need a proprietary firmware in /lib/firmware/TAS2XXX38*.bin. I was able to find that in the ti.com forum. As I tried so many packages, I wouldn’t be able to tell which one was the correct one. Once that was done, the firmware needs to be initialized through the i2c interface. I could find a script that did that, which I pushed in my lenovolegionlinux package (see below).

WiFi

WiFi worked out of the box for me, just it wouldn’t wake up if I closed the laptop lead. This fixed it for me in /etc/modprobe.d/rtw8852be.conf:

options rtw89_pci disable_aspm_l1=y disable_aspm_l1ss=y
options rtw89_core disable_ps_mode=y

lenovolegionlinux package

I came across https://github.com/johnfanv2/LenovoLegionLinux which I packaged. The result is now 4 binary packages: lenovolegionlinux-dkms that provides the kernel module for accessing the fan control. python3-legion-linux that provides legion_cli and legion_gui, written in Python, that make it possible to control the kernel module. I often use sudo legion_gui, click on “Other options” and then switch the power profile from quiet to balanced. Many things on this GUI do no work for me, like the fancurve thingy, but should be working for other flavors of Legion laptops. Please feel free to contribute. There’s also legiond that provides a daemon for setting-up the fan curve on wake up. And finally, I pushed my i2c speaker script to a new lenovolegionlinux-sound debian binary package that I have just uploaded today, in the hope it may be useful for others.

Conclusion

Finally, almost everything is (almost) working as expected. Just my webcam (lsusb says it’s a Luxvisions Innotech Limited Integrated Camera) went dark at some point (it did work previously). It is now as if it is working, but just transmitting a black picture. If anyone knows how to fix, please tell me. Also, I only get 40 minutes of battery time if I’m lucky, I hope this could be fixed. But overall, I’m happy of the laptop.

Thanks to Ding Shenghao for his support of many people in the ti.com forum. Thanks to the people maintaining the LenovoLegionLinux that helped me a lot writing this Debian package.

Please try and report issue with lenovolegionlinux in Debian, and help me improving it. It is in Salsa’s debian namespace in the hope that others may push contributions.

On Android, there's a spellchecker popup that occasionally appears over the keyboard, getting very annoyingly in the way. See for example this unanswered question with screenshots.

It looks like a feature of the keyboard, but it's not, and so I looked and I looked and I could not find how to turn it off.

The answer is to look for how to disable the spellchecker in the keyboard section of the android system settings, not in the android keyboard app settings.

See for example this answer on stackexchange.

Spyder's lead maintainer, Carlos Cordoba, shares his insights on the projects and features he helped develop for Spyder 6.0, particularly UI/UX and where the IDE is headed next.

A variant of the yield statement that can result in more concise code.