15 comments

[ 3.4 ms ] story [ 38.0 ms ] thread
Good. Means it's more lean. And nothing's stopping someone installing NTFS functionality with apt. I once had to add exFAT[0] compatibility to Ubuntu because I had a thumb-drive flashed in that format.

[0] https://itsfoss.com/mount-exfat/

The new NTFS driver is still included in the kernel.
Leaner on the source code side. The developer wrote that nobody is building it. If it were in obvious use, they could not even propose removal, Linux promises not to break existing systems by upgrading to a newer kernel.
> And nothing's stopping someone installing NTFS functionality with apt.

This would be wildly slow (if it runs in userspace using FUSE)

The good thing is that the kernel still includes a (better) ntfs driver

> This removes the old ntfs driver. The new ntfs3 driver is a full replacement that was merged over two years ago.

>This would be wildly slow (if it runs in userspace using FUSE)

NTFS-3G through FUSE is what most people are using. It's slower, but not that slow.

ntfs3 hasn't seen that much large-scale deployment, and you don't have to look very far to find people complaining about ending up with a messed up filesystem from it. I'd put a very modest level of trust in it not eating your data.

(comment deleted)
FUSE drivers are slow, but "wildly slow" is an overstatement.

Anyway, between FUSE, epoll, DMA, and userspace networking Linux is already enough of a microkernel to benefit from it; so when do our CPU oligopolists plan to turn their shared memory hardware into a useful message passing mechanism?

couldn't you just not include it when you build the kernel
Nice! Russians opensourced a good ntfs driver finally, so we can retire an old stuff that was slow and generally a headache for years.
Paragon Software, particularly Konstanin Kamarov - it’s worth being specific.

This read-write driver has been a tremendous help to me, from Linux 5.15 till now. I hope they can soon publish the mkfs tool they committed to previously as well.

(comment deleted)