Read more of this story at Slashdot.
Not the best film ever, but in today's Hollywood landscape it's a rare breath of fresh air. Kane Parsons takes the internet meme concept he started on YouTube and actually makes a feature-length film that's doing great at the box office.
The mood is great. That unsettling stillness of these generic liminal spaces. For something that builds a feeling / mood, the flick would benefit from a butcher in the editing room. I'd probably still not give it the extra star, but this really isn't the kind of movie that needs the extra 20 minutes.
Biggest entertainment was definitely watching my son freak out in the third act. :)
★★★★☆
libdex 1.2 is still in pre-alpha phase but it is also far enough along that it is worth talking about the direction: libdex is growing from a library of future and fiber helpers into a more complete concurrency toolkit.
The most important 1.2 theme is that applications can now describe not just what work should happen concurrently, but how that work should be bounded and owned. DexLimiter lets a workload run with a fixed concurrency budget, with dex_limiter_run() handling the common fiber case by acquiring a permit before work starts and releasing it after the fiber completes. For larger workflows, DexTaskGroup gives related futures a structured scope that can be closed, awaited, or cancelled as one unit.
That combination makes cleanup much easier to reason about when a workflow has many moving pieces. A loader can start many subtasks, keep only a useful number active at once, and return a single future representing the whole operation. If the window closes, the project changes, or the operation times out, the group gives the application one place to cleanly shut the work down.
static DexFuture * load_many_files (GPtrArray *files) { g_autoptr(DexTaskGroup) group = dex_task_group_new (0); g_autoptr(DexLimiter) limiter = dex_limiter_new (8); for (guint i = 0; i < files->len; i++) { GFile *file = g_ptr_array_index (files, i); dex_task_group_add (group, dex_limiter_run (limiter, NULL, 0, load_one_file, g_object_ref (file), g_object_unref)); } return dex_future_with_timeout_seconds (dex_task_group_close (group), 10); }There is also a new DexThreadPool for the cases that are not naturally fiber-shaped. Fibers and schedulers are still the right fit for cooperative async work, but many applications need to integrate blocking libraries, database clients, filesystem helpers, or other foreign code. A fixed pool of reusable OS threads, dex_thread_pool_submit(), and asynchronous dex_thread_pool_close() give that integration story a bounded queue and an explicit shutdown path.
Deadlines are another practical piece of the same story. The new timeout wrappers, including dex_future_with_timeout_seconds() and dex_future_with_deadline(), turn time limits into ordinary future composition. Instead of open-coded timeout state spread across an application, a future can resolve normally, reject normally, or reject with DEX_ERROR_TIMED_OUT when the deadline wins.
On the I/O side, 1.2 continues filling in the operations that make responsiveness easier to preserve. dex_aio_open() and dex_aio_close() matter because even operations that look small can stall when they touch the kernel, storage, or network-backed filesystems. Keeping those calls in libdex’s file-descriptor AIO model makes it easier to keep them off the UI thread, using io_uring where it is available and the fallback AIO backend elsewhere.
The broader GIO coverage is intentionally less surprising, but still important. More app launching, GFile, stream, socket, resolver, proxy, TLS, DTLS, permission, subprocess, and Unix-facing APIs now have future-first wrappers. That is the kind of coverage people should expect from libdex over time: not every wrapper needs a release headline, but each one reduces the pressure to leave the future model for common GNOME application work.
This first blog post marks the opening of the internationalization blog! The i18n team will use it to share news and projects on the current plans. Don’t forget to subscribe!
The i18n team has seen some changes recently, at the beginning of 2026 and we thought it was necessary to publicly announce this change and introduce ourselves a bit.
Before all, we want to greet and deeply thank all internationalization coordinators that participated in the project so far and made GNOME what is is now. We are a global software community of volunteers, leading the free software ecosystem and are accessible in many languages. With this, we cover almost everyone on Earth. Thank you very much Andre, Alexandre, Claude, Daniel, Gábor, Gil, Mario, Piotr, Petr, Kjartan and all the others. Without you this wouldn’t have been possible.
What is internationalization?Internationalization, or i18n for short, is the act of ensuring software or documentation can be used in other languages, countries, and cultures. This means designing and developing applications in a way that removes barriers to localization, making it possible to adapt them without requiring significant engineering changes.
In practice, this involves separating user-facing text from the source code, so it can be translated easily, and ensuring that the software correctly handles different character sets and writing systems, including right-to-left scripts. It also means being mindful of cultural conventions such as date and time formats, number formatting, currencies, and units of measurement.
Internationalization goes beyond text. It includes accommodating differences in sorting rules (collation), keyboard input methods, plural forms, and even layout considerations, as translated text can vary significantly in length. Developers must also ensure that their software supports Unicode and uses libraries or frameworks that simplify handling these variations.
For the GNOME community, internationalization is a collaborative effort between developers, designers, and translators. By preparing software properly, the i18n team enables localization contributors to focus on producing high-quality translations, ensuring that GNOME is accessible and welcoming to users all around the world.
A new teamThe team has reborn with new faces: Anders Jonsson, Rafael Fontenelle and Guillaume Bernard, respectively coordinators of the Swedish, Brazilian Portuguese and French team. Let’s introduce ourselves a bit…
Rafael (@rafaelff) is coordinator of the GNOME Brazilian Portuguese Team for more than 13 years after a short but intense period of contribution as translator. Besides GNOME, he contributes to the translation of Python Docs, R language, Fedora, TranslationProject (GNU projects, etc.) and others. Also maintains some packages in Arch Linux’s AUR.
Anders (@ajonsson) is coordinator of the GNOME Swedish Team for over 10 years, translator in the Swedish branch of the Translation Project, and a member of the GIMP Team with a focus on internationalization questions and testing.
Guillaume (@gbernard) is coordinator of the GNOME French Team since this year after 14 years of contributions, first as a translator, reviewer and after a few years, he has been involved in submitting team’s translations. He is the maintainer of GNOME Damnes Lies, our translation platform since 2020. He took this responsibility after years of dedication from Claude. Thank you again for this mentorship!
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Each release of Debian has a shiny new theme, which is visible on the boot screen, the login screen and, most prominently, on the desktop wallpaper. Debian plans to release Trixie, the next release, next year. As ever, we need your help in creating its theme! You have the opportunity to design a theme that will inspire thousands of people while working in their Debian systems.
For the most up to date details, please refer to the wiki.
We would also like to take this opportunity to thank Juliette Taka Belin for doing the Emerald theme for bookworm.
The deadlines for submissions is: 2024-09-19
The artwork is usually picked based on which themes look the most:
If you'd like more information or details, please post to the Debian Desktop mailing list.
The following contributors got their Debian Developer accounts in the last two months:
The following contributors were added as Debian Maintainers in the last two months:
Congratulations!