rdri

Does it look like I advocate for windows? Nah.

Open source is great when it works. "If there is some good patch..." and "Enough pressure and maybe..." is the sad reality of it. Why would people need to put pressure on order for Linux to start supporting features long available in file systems it supports? Why would I, specifically, should spend time on it? Does Linux want to become an os for everyone or only for people experimenting with dangerous stuff that make them lose data sometimes?

Don't get me wrong, Linux is good even now. But there is no need to actively deny points of possible improvement. When they ask you how great XFS is compared to others you shouldn't throw "exbibytes" word, you should first think what problems people might have with it, especially if they want to switch from windows.

If you setup a new install, and say you want encryption, LUKS is what you get.

And if I want to only encrypt some files? I need to create a volume specifically for that, right? Or I could just use something else.

The magic of Linux, is you can try it yourself, run your own fork and submit patches.

Well it should probably go further and offer more of another kind of magic - where stuff works as user expects it to work.

As for submitting patches, it sounds like you suggest people play around and touch core parts responsible for file system operations. Such an advice is not going to work for everyone. Open source software is not ideal. It can be ideal in theory, but that's it.

LUKS is the one to talk about as the others aren't as good an approach in general. LUKS is the recommended approach.

It looks like there are enough use cases where some people would not prefer LUKS.

None of that helps or discards anything I've said above. But it allows to say that NTFS limit can be basically 1024 bytes. Just because you like what UTF-8 offers it doesn't solve hurdles with Linux limits.

LUKS is commonly used but not the only one.

I guess something like ようこそ『追放者ギルド』へ ～無能なＳランクパーティがどんどん有能な冒険者を追放するので、最弱を集めて最強ギルドを創ります～ 1 (ドラゴンコミックスエイジ) - 荒木 佑輔.epub - 92 characters, but 246 bytes. Where on Windows this file hits 35% of the limit, on Linux it hits 96%.

The file is not some rare case. It's from a torrent, uploaded somewhere just today. There are tons of files like this with slightly or much longer names. As of 2024, they can't be served by Linux. Not in a pure file form, that is.

NTFS also has a 255 limit, but it’s UTF16, so for unicode, you will get more out of it.

I think this is a biased way of putting it. NTFS way is easy to understand and therefore manage. What's more important is that ASCII basically means English only. I've seen enough of such "discrimination" (stuff breaks etc.) based on used language in software/technology and it should end for good.

All other modernly maintained OS do UTF8, which “won” unicode.

UTF8 is Unicode. UTF8 symbols can take more than 1 byte.

Plus all the other things Linux has over Windows of course.

There are also encryption methods that slash maximum length of each filename even further.

True. Problem is, moving from more restricted system to less restricted system is a breeze, but painful otherwise. Linux is in a position where it would benefit from any little thing. People trying to switch to Linux will find path length feels like an upgrade, but file name limitation is clearly a downgrade.

Linux file system is shit? Otherwise I don't get why you've used the "because" word. NTFS is certainly not shit.

Linux still unable to catch up with NTFS when it comes to filename length, sadly. 256 bytes in an era of Unicode is ridiculous.

Basically, a corporation owning such an open source project removes almost all positive things associated with "open source". They're using it for "look we are good" much more than for "we actually care about open source community".

Russia holds considerable defense in depth.

I think you have no proofs. As a Russian, it's insane to assume Russia would spend resources on keeping any meaningful defense far from borders. And from places Putin often visits, of course.

I see what you mean. It helps predict that, but not always. This is still a lottery, and the absence of SMART only makes it a little bit more of a lottery.

Worst part is that SD cards don't have SMART, meaning you don't know when they'll die.

I mean, SMART doesn't help much with knowing about HDDs' death either. It's more often they don't show up at all, so you can't even check SMART.