linux-kernel - Peanut gallery 2c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250811154826.509952-1-james@egdaemon.com>
Date: Mon, 11 Aug 2025 11:48:26 -0400
From: James Lawrence <jalexanderlawrence@...il.com>
To: tytso@....edu
Cc: admin@...inas.su,
	gbcox@....us,
	josef@...icpanda.com,
	kent.overstreet@...ux.dev,
	linux-bcachefs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	list-bcachefs@...lthompson.net,
	malte.schroeder@...ip.de,
	sashal@...nel.org,
	torvalds@...ux-foundation.org
Subject: Peanut gallery 2c

I've been a user of bcachefs for over 2 years now and I must say in that time watching the drama
play out in the lkml most of it isn't coming from kent. Interestingly like ext4 its one of the few filesystems
I have *not* had to think about while providing far more functionality all while marked as experimental.

What I've found most interesting in watching it play out is that the criticisms of kent are rarely on the technical issues.
its mostly 'how dare he point out the issues in other file systems', 'how dare he point out issues with the kernel's engineering processes'
as if that is somehow unthinkable. Are we not allowed to critize poorly performing systems and processes?

Isn't that *precisely* what engineering is all about *improving* poorly performing systems? Have we all forgotten this? How about instead of
complaining that kent is critiquing your processes, fix them. address the actual critiques. its pretty hard to critique something that has been resolved no?

linus if you dont like the timing of kent's pull requests just ignore it until the next cycle, no one is forcing you and kent certainly can't.
It'll be inconvenient for those of us downstream who absolutely adore the fast pace of the fixes kent has provided when we run into problems, but we'll survive we went in knowing
we'd run into issues and if they're serious we'll work around the delays caused by upstream in our own way.

If maintainers have actual technical issues with bcachefs, then they can bring those up with some ideas for solutions. they can bring hard evidence to the table and
not 'someone said something about code i work on, that i took offense to and then did nothing to address, as a reason for their code existing'.

I would very much like to see bcachefs remain because its been a breeze to setup, use, and maintain. Backups are a breeze, I can safely mess with my entire
system with a single command to produce a snapshot prior to starting that is basically instant. Something that previously required an entire esoteric distribution ecosystem dedicated to immutability to accomplish.

And since other FS maintainers are not stepping up to the plate and improving or implementing new filesystems to address their own featureset and branding short comings,
I'm not terribly interested in what they have tso say on the matter. And neither should you linus, let them be upset that *experimental* *opt in* systems can
(and should) operate under different development processes. I certainly give my engineers/researchers a ton of leeway long as their work is opt in.

And when kent is ready to take off the experimental label, then rake bcachefs over the coals as much as you want to make sure its actually ready.

Until then maybe consider not making your own life harder by trying to gate keep the development process for an actively developing entirely opt in/experimental system?

Apologies for bothering everyone with my 2c,
James Lawrence
Principal Engineer