ZFS does have bit-rot checksum detection/repair, but the encrypted file feature was a bit of a YOLO feature for awhile. Not sure where it is at these days, as ddr5 ram prices skew away most of ZFS best key features. =3

IMO use LUKS unless you really need the features of ZFS native enc.

It's a lovely filesystem and it can work in very stodgy ways with zetabytes on Serious Hardware, but it can also work with relatively small devices on silly hardware.

Another example: I've got a ZFS scratch disk that has seen dozens of terabytes written. It's an old ~120GB Intel-branded SATA SSD that is connected with a very cheap SATA to USB3 adapter cable. I've been using it this way for years.

All of the Internet lore has told me that this must result in resolute failure. Whether because USB is broadly not a serious data bus, or because ZFS doesn't like non-serious things, or because 1 copy is 0 copies, or because SSDs are fragile creatures that hate write cycles, or because I've created a portal to hell, or something else: The lore states that it must result in failure, and usually stipulates that ZFS would amplify this concern.

But it's been great. Really. Zero issues -- except when I unplugged it on accident while it was hot...but even then, it came back fine. (Of course it did. ZFS is intended to be robust in the face of unplanned failures regardless of cause.)

And because ZFS: If it ever has any issues, then they'll be reported and logged either in the normal course of doing things, or during a periodic scrub. Every read is checksummed (even in normal operation), and every discrepancy is reported. It's been clean.

It is my intent to keep it as a scratch disk until it becomes problematic, and my further hope is to be able to analyze those problems once they occur.

It won't last forever, but it's lasted for quite a long time so far. (A little bit of inquiry with smartctl and some math just now shows that it has endured writes equivalent to ~43,000% of its capacity.)

I think scale is also BSD licensed (atleast the gui and middleware)

One must have principles onesself to see this as imortant though.

A lot of people use words like "practical" or "pragmatic" to avoid inconvenience.

I've already been using zVault for a year which is a fork of the last truenas core, but it never got any further updates and it's about to become impossible to run up to date software in jails on the old host. The pkg repos that support the host version are about to go eol and the binaries will be gone. So I've already gone through the "what if this doesn't go anywhere?"

My point: It's a pain but I won't relieve that pain by running trunas scale.

I'd rather try switching to xigmanas or dump the whole concept of the front end and just run plain freebsd and learn a few commands to manage storage and file services directly and a maybe a seperate dedicated jail manager like bastille. At least that way I can never be stuck in this position again where I can't update my own software because someone else stopped updating their software.

You can integrate a fleet of Linux storage servers with a collection of K8s clusters more easily than a you can BSD storage servers. Getting BSD and Linux talking smoothly needs Real Unix Skills.

Colleagues in K8s shops tell me that their k8s guys come for help with complex tasks like.... deleting files. They know to construct and deploy containers, but not how to delete a file without using a GUI (meaning Windows or at best WSL).

I am told that some companies are now demanding "bash" among the list of skills for would-be container-herders. And here, "bash skills" means you should know to to create, edit, and then delete a file -- over an ssh connection.

He'll keep ramping up his vibe coding, because he can see it's the future.

And with BSD licenced code this is their right.

And it's my and anyone else's right to observe all of this and criticize it.

I explicitly stated in my comment that we pay for open source (via vendor support). That is not the issue.

It is now a common business strategy to commercialise an open source project. FreeNAS was commercialised as TrueNAS, which is now having some of the source pulled.

TrueNAS doesn’t exist in a vacuum. It’s built on source projects.

They're allowed to stop publishing new work whenever they want to. That's part of the free, open-source software game, wherein: We're all free to provide as much as we wish, and also free to consume as much as we want. Nobody necessarily owes anyone else anything and it's really very beautiful in these ways. This is enabled in large part due to the very low cost of distributing copies of intangible software (which can be very close to zero).

But when money gets involved, then things become different. Contracts can be had. Support requirements can be determined. If a contract requires 5 years of support, then it can be reasonably expected for support to continue for at least 5 years.

It's OK to want that, and to never use software that doesn't involve money. It's also OK for an author/company/org to not want that, and to never agree to those terms.

These are different goals, but one party doing it one way doesn't detract from another party doing it some other way. It's all OK.

People act like you're saying Disney should be able to hold a copyright on Mickey Mouse for over 100 years.

Calling it a "rug pull" when the creator of an open source project decides to stop giving away future work for free is a delusional level of self-entitlement.

(1) The previous releases are still open source. If you don't like it, fork the last free release and maintain it yourself.

(2) People deserve whatever the market is willing to pay for their work. See above.

Frankly, if D. Richard Hipp decided to stop giving away future versions of SQLite for free, I would be the first person to congratulate him for finally having the courage to put his foot down and say "my fellow committers and I deserve at least a few million dollars for 20 years of work making something that billions of machines rely upon."

I suppose the key is whether you consider vibe coding a bad thing or a good thing. Because if it's good, then that's good news, right?

This is literally why BSD exists in the first place. To allow companies compete freedom with the code, including freedom to not release changes.

I hate to break it to you: basically every commercial storage vendor on the planet bases their appliances on either BSD or Linux and not a single one is sharing their proprietary code with you. There’s nothing shameful about it, they built a company to make money.

My point is that there's stuff that I have worked on to scratch an itch and don't feel the need for monetary compensation. I believe there's an intrinsic need to be part of something bigger than ones self, and participating by volunteering time to have the satisfaction of knowing that you helped make something you care about better is not a bad thing, if on your own terms.

The way DRH has talked about SQLite is that he is financially secure and by giving it away gets both the reward mentioned above as well as maintaining the value of the free software which he can still make money off of support contracts. He is choosing to do this because for him that effort is the most rewarding.

FOSS has been a foundational facet of the work we get well-paid to participate in. This is a case in which we have the option to have our cake and share it too.

None of this means you have to participate in this way, but I suggest that your viewpoint is yours and may not be shared by everybody else in the community.

If you want to make the world a better place, just be a friend to people. Just being someone you would consider a good friend adds incalculable value to the world, especially in world now full of people single-mindedly farming for attention on social media. Application protocols become obsolete, but people remember how you treated them, and it influences how they treat people in a never-ending chain... At least that's my $0.02.

It was good talking to you, take care man!