Sad news from Ubuntu founder Mark Shuttleworth today: longtime Ubuntu and Debian contributor Steve Langasek has passed away. In a touching post on the Ubuntu Discourse, Mark Shuttleworth shares: “Steve passed away at the dawn of 2025. His time was short but remarkable. He will forever remain an inspiration.” “Judging by the outpouring of feelings this week, he is equally missed and mourned by colleagues and friends across the open source landscape, in particular in Ubuntu and Debian where he was a great mind, mentor and conscience.” As a former Debian and Ubuntu release manager, and a long-term Canonical employee, […]

You're reading Long-Time Ubuntu Contributor Steve Langasek Has Passed Away, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.

NIST’s second draft of its “SP 800-63-4“—its digital identify guidelines—finally contains some really good rules about passwords:

The following requirements apply to passwords:

1. lVerifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a signgle character when evaluating password length.
5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).

Hooray.

News article.Shashdot thread.

Data scientists love debating which skills are essential for success in the field. It makes sense: in a rapidly changing ecosystem that adopts new and powerful technologies all the time, job requirements and toolkits never stop evolving.

Statistics seem to be one major outlier, though. Data professionals of all stripes seem to agree that a solid foundation in stats and math will make your life easier regardless of your role, and can open up opportunities that would otherwise remain beyond reach.

To help you on your learning journey, we’re sharing a few of our favorite recent posts that focus on statistics for data science and machine learning. They go from the basics all the way to more specialized use cases, but they’re all accessible, beginner-friendly, and emphasize practical applications over lofty theory. Let’s dive in!

• Stats novice? Not for long! If you’re tackling stats for the first time in your professional life—and especially if your memories of high school math inspire more dread than joy—you’re bound to appreciate Chi Nguyen’s simple explanations of basic concepts.
• A structured approach to learning statistics. Looking for a thorough, step-by-step resource for learning stats? Adrienne Kline recently launched an excellent Statistics Bootcamp that unpacks the math behind all the data science libraries practitioners use daily. (If you’ve already discovered the first installment, linked above, parts two and three are already out!)
• Making sense of occasionally confusing terms. For his debut TDS article, Ajay Halthor shared a lucid explanation of likelihood, and focused on the role it plays in machine learning, as well as its sometimes hard-to-grasp connection to probability, an equally crucial concept.

• Putting your statistical know-how to good use. There’s always a gap between theoretical knowledge and its effective application. Mintao Wei’s recent contribution does a great job bridging it, as it walks us through the process of selecting the right statistical tests for a range of A/B testing metrics.
• The inner workings of a powerful algorithm, explained. The bootstrap, says Christian Leschinski, “is an algorithm that allows you to determine the distribution of a test statistic without doing any theory.” It’s also one that’s been “widely overlooked.” Harnessing his deep knowledge as a statistician, Christian guides us through the magic behind the boostrap, and shows how it can help practitioners in their analyses.
• Why it’s crucial to connect statistics to business outcomes. Cassie Kozyrkov identifies the challenges data professionals face when they bring their stats and math knowledge to work projects, and stresses the importance of data budgeting, a topic college classes rarely cover. (If you’d like to read more of Cassie’s insights—and you should!—don’t miss our brand-new Q&A with her, which touches on data career paths, the value data analysts bring to companies, and much more.)

All stats-ed out, are we? We hope not, but just in case—here are some non-statistics-related reading recommendations we think you’ll enjoy.

• In her first TDS post, Sara Tähtinen offered a useful, thorough breakdown of the EU’s Artificial Intelligence Act, covering its major implications for practitioners, and sharing her own views on this landmark legislative effort.
• Gadi Singer’s new article continues to refine the concept of cognitive AI, and lays out four properties that will be crucial for its emergence: a world model, a theory of mind, continual learning, and late-binding context.
• If you’re looking to read about a project that’s both fun and thought-provoking, Egon Ferri’s exploration of AI-generated art fits the bill (it also features Pikachus in the style of Picasso, van Gogh, and many other artists you might recognize).
• A perennial problem for data teams both big and small is addressing ad-hoc requests from other stakeholders. Olivia Tanuwidjaja’s new guide will help you keep things under control and focus on the projects that matter.

Your support means so much to us — thank you for reading our authors’ work; a special shoutout goes to all of you who’ve recently become Medium members.

Until the next Variable,

TDS Editors

Stats for Data Science, from the Ground Up was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

Flatpak is a way to distribute applications on Linux. Its container-style approach allows applications to run across Linux distributions. This means native packages (rpm, deb, etc) are not needed and it's relatively easy to get your app to Linux users with fewer worries about distro compatibility. This makes life a lot easier for developers and is also convenient for users.

I've run popular applications like OBS Studio as flatpaks and even publish my own on Flathub, a popular hosting site for applications. Today I figured out how to debug flatpaks, which requires some extra steps that I'll share below so I don't forget them myself!

Bonus Tip: Testing local flatpaks

If you're building a flatpak of your own application it's handy to use the dir sources type in the manifest to compile your application's source code from a local directory instead of a git tag or tarball URL. This way you can make changes to the source code and test them quickly inside Flatpak.

Put something along these lines in the manifest's modules object where /home/user/my-app is you local directory with your app's source code:

{
     "name": "my-app",
     "sources": [
         {
             "type": "dir",
             "path": "/home/user/my-app"
         }
     ],
     ...
}

Building and installing apps with debuginfo

flatpak-builder(1) automatically creates a separate .Debug extension for your flatpak that contains your application's debuginfo. You'll need the .Debug extension if you want proper backtraces and source level debugging. At the time of writing the Flatpak documentation did not mention how to install the locally-built .Debug extension. Here is how:

$ flatpak-builder --user --force-clean --install build my.org.app.json
$ flatpak install --user --reinstall --assumeyes "$(pwd)/.flatpak-builder/cache" my.org.app.Debug

It might be a good idea to install debuginfo for the system libraries in your SDK too in case it's not already installed:

$ flatpak install org.kde.Sdk.Debug # or your runtime's SDK

Running applications for debugging

There is a flatpak(1) option that launches the application with the SDK instead of the Runtime:

$ flatpak run --user --devel my.org.app

The SDK contains development tools whereas the Runtime just has the files needed to run applications.

It can also be handy to launch a shell so you can control the launch of your app and maybe use gdb or strace:

$ flatpak run --user --devel --command=sh my.org.app
[📦 my.org.app ~]$ gdb /app/bin/my-app

Working with core dumps

If your application crashes it will dump core like any other process. However, existing ways of inspecting core dumps like coredumpctl(1) are not fully functional because the process ran inside namespaces and debuginfo is located inside flatpaks instead of the usual system-wide /usr/lib/debug location. coredumpctl(1), gdb, etc aren't Flatpak-aware and need extra help.

Use the flatpak-coredumpctl wrapper to launch gdb:

$ flatpak-coredumpctl -m <PID> my.org.app

You can get PID from the list printed by coredumpctl(1).

Conclusion

This article showed how to install locally-built .Debug extensions and inspect core dumps when using Flatpak. I hope that over time these manual steps will become unnecessary as flatpak-builder(1) and coredumpctl(1) are extended to automatically install .Debug extensions and handle Flatpak core dumps. For now it just takes a few extra commands compared to debugging regular applications.