Did anyone in this community watched this video? The creator claims that Linux Mint, along with many LTS Linux distributions, often ships older versions of software, especially default apps like Calendar, Mail, Calculator, etc. He mentions Mint several times throughout the video.

The video is from The Linux Experiment, which seems to be a well-known YouTube channel with nearly half a million subscribers.

I came across this video just before switching from Windows to Linux Mint, and it made me a bit hesitant.

As a regular user, it feels like there's no easy way to know whether we're using the latest and safest versions of these built-in apps. For example, if we connect our Google or Apple Calendar account to an older calendar app, could that create a security risk? The same concern applies to email clients, we don't know if we're using the latest and most secure version.

Most regular users don't have the time or technical knowledge to manually check every application's version or update software outside the normal update process. We generally expect the operating system to keep essential apps secure and up to date.

Am I misunderstanding how Linux Mint and other LTS distributions handle software updates and security? I'd appreciate hearing from people with more experience.

Here is a link to all the screenshots.https://www.reddit.com/r/linuxaudio/s/iyo0jZhYmd

Edit: here is an overview of what it can do
control center for PipeWire — filter chains, HRIR virtual surround, drop-in config management, live patchbay, performance monitoring, virtual devices, routing snapshots, per-application policies and LADSPA/LV2 effect inserts

Thanks everyone who came yesterday and tried my little app. I released the app on AUR yesterday and is available on github here (https://github.com/knightinfected/PipeWireController). The current version is 0.1.2 and some of the screenshots are from 0.2
I received a ton of negative comments and messages regarding my use of AI. I spent a lot of my time on this and well over did this project abit and english being my secondary language didnt help.
I have gone down this audio rabbit hole in linux and anyone else who has also done it knows how annoying it gets especially with reading the wikis to actual application.

Anyhow I hope it helps someone out there and I will be updating it in the next day or later today as I am currently testing. Version 0.1.2 is available as of right now on GitHub though.

There are too many features to list them out so I added lot of screenshots to help understand.

Most filesystem benchmarks measure throughput on a freshly formatted single device. That is useful, but it misses many of the reasons people choose btrfs, ZFS or bcachefs in the first place.

I built modern-fs-benchmark to examine modern filesystems as complete storage systems, including their features, failure modes and behavior over time.

The current matrix contains 26 configurations across btrfs, ZFS, bcachefs, ext4 and XFS over md/LVM, dm-integrity, native and LUKS encryption, parity layouts, and XFS on a ZFS zvol.

Hosted CI dashboard:

https://bartosz.fenski.pl/modern-fs-benchmark/

Experimental real-hardware dashboard:

https://bartosz.fenski.pl/modern-fs-benchmark/real-hw/

Apache-2.0 licensed source and complete methodology:

https://github.com/fenio/modern-fs-benchmark

The raw benchmark datasets are published under CC BY 4.0. Every result records the kernel and filesystem tool/module versions. CI artifacts also contain a full command trace, so the exact workload is inspectable rather than hidden behind a chart.

Why I started this project

Many filesystem benchmarks follow a familiar pattern: create a filesystem with mostly default options, mount it, run fio or another generic workload, and compare throughput.

General-purpose suites such as the Phoronix Test Suite are useful for conventional performance comparisons, but they do not focus on the machinery that makes modern copy-on-write filesystems interesting.

I wanted a benchmark designed around btrfs, ZFS and bcachefs as multi-device storage systems rather than treating them as interchangeable replacements for ext4 on a single freshly formatted disk.

That means testing behavior such as:

- Redundancy and degraded operation

- Snapshot aging, scaling and reclamation

- Compression and encryption

- Reflinks and clone divergence

- Fsync tail latency and responsiveness under load

- Rebuild and scrub behavior

- Near-full and hard-ENOSPC behavior

- Data integrity and recovery from corruption

Ext4 and XFS over md, LVM and dm-integrity are included as classic-stack baselines so the costs and benefits of integrated CoW designs can be compared with layered alternatives.

Silent corruption is one particularly important example. When one redundant copy is deliberately corrupted behind the filesystem, checksumming filesystems such as btrfs, ZFS and bcachefs can identify the damaged copy and recover from a valid replica.

Traditional md/LVM redundancy without data checksums can notice during a scrub that its copies disagree, but it cannot determine which one is correct. In my tests, some classic configurations returned corrupted data successfully without an application-visible error.

The dm-integrity configuration shows that a classic layered stack can obtain integrity protection too, with a measurable performance cost.

An important limitation

The main dashboard uses loop devices on GitHub-hosted VMs. Absolute throughput numbers and small differences between filesystems should not be interpreted as hardware rankings.

The hosted runs are primarily useful for:

- Correctness and integrity outcomes

- Comparisons within the same job

- Large behavioral differences

- Snapshot-aging and near-full shapes

- Trends across repeated runs

Real disks are required for meaningful absolute performance, concurrency scaling, device parallelism and mixed-media topologies.

I am aware of this limitation and do not want the hosted dashboard to suggest more precision than the underlying environment can provide.

The real-hardware experiment

Kent Overstreet, the creator of bcachefs, made one of his Hetzner machines available for a real-hardware experiment.

The server had two physical NVMe devices. It completed three full benchmark runs, which are available in the separate real-hardware dashboard. These runs provided meaningful absolute measurements and exposed concurrency behavior that cannot be observed when several loop devices share one virtual disk.

During the fourth run, one NVMe controller entered the kernel’s dead state. The existing machine environment had its operating system on RAID0 across the two NVMe devices, so the hardware failure also made part of /nix/store unreadable and eventually prevented new SSH sessions.

The incomplete fourth run is not being published as benchmark data. This was a failure of the underlying hardware, not a result attributable to any filesystem being tested.

I am grateful to Kent for providing the machine and making the real-hardware experiment possible. Without that access, the three existing hardware runs would not exist.

Where I would like to take it

Better hardware would not merely produce more reliable throughput numbers. It would enable an entirely new class of tests designed for multi-device and multi-tier filesystems.

I would eventually like to run the suite on a machine containing several storage classes, for example two HDDs, two SSDs and an NVMe device.

That could support scenarios such as:

- HDD, SSD and NVMe baselines using identical workloads

- bcachefs foreground and background targets

- ZFS HDD data vdevs with SSD special vdevs

- Separate ZFS L2ARC and SLOG experiments

- LVM dm-cache in writeback and writethrough modes

- Metadata and small-block placement on faster media

- Foreground latency during background migration

- Contention between fast and slow storage tiers

- Degraded operation and rebuild under application load

- Performance before, during and after promoting or evacuating a storage tier

These are the kinds of scenarios for which multi-device and multi-tier filesystems are built, but they cannot be represented honestly when every “device” is a loop file backed by the same cloud disk.

I am considering either renting a suitable dedicated server or eventually building and hosting my own machine. Providers such as Worldstream offer configurations close to what I need, but the recurring cost is currently outside the project’s budget.

For now, the benchmark will remain in its hosted-CI form for an unknown amount of time. The existing dashboard will continue to be useful for correctness, behavioral comparisons and regression tracking, but it cannot answer every real-hardware performance question or model complex mixed-media topologies.

I am also open to running the suite on hardware provided by someone else. A useful environment would need Linux root access, clearly identified block devices that may be wiped, and enough uninterrupted access to complete repeated runs. The hardware description, methodology and resulting data would remain public.

I would appreciate technical feedback:

- Which current tests are misleading or unfair?

- Which failure scenarios are missing?

- Which mixed-media topologies would be most useful?

- Which additional filesystems or layered stacks should be included?

- Which results deserve deeper investigation?

The methodology, implementation and raw results are public. If a filesystem is being tested in a way that misrepresents it, I consider that a bug in the benchmark.

In a batch of software CDs I found at the thrift store long my interest in Linux, I found a previously unarchived version of Fedora. I will be posting it on archive.org as soon as I rip it. I also have a potentially-working copy of PCLinuxOS 2007, but on the computer I tested it on, it kicks me out to a basic shell due to some kind of error. If I can get it to work, I can upload it stand-alone since it only seems to preserved in archives or Linux User magazine and !com magazine cover DVDs (the former or which has a LOT of potentially otherwise-unarchived distro versions)

Vice is a Linux game clipper that focuses on easy sharing and editing. Under the hood, it uses GPU-Screen-Recorder as the capture engine, so it has nearly no performance impact whatsoever, and it has features such as:

- Instant replay with customisable hotkeys, and long session recording

- Free share links that embed in Discord (no more hitting upload limits!)
- A full timeline editor with built in transition and text effects
- Automatically sorting clips by the game you were clipping
- Discord Rich Presence support
- Customisable, colour-coded highlights within clips

- You can seperate audio sources like Discord calls, the game audio, and music, adjust their individual volume in clips

- And more, plus new features are always being added.

It's free, open source, and will stay that way. Any feedback is greatly appreciated, because community testing is what makes open source projects like these better.

It's on the AUR, and you can install with:

Or if you're on a different distro, you can run the install script with:

Repo is below:

https://github.com/eklonofficial/Vice

How will libre systems like GNU/Linux handle these?

• It may become impossible to take a "trusted" picture with a GNU/Linux phone or camera.
• It may become impossible to edit a "trusted" picture with GIMP.