Announcement

Collapse
No announcement yet.

Paragon Submits Third Version Of New NTFS Kernel Driver For Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • gregzeng
    replied
    Many comments here show so much ignorance of Paragon, The Linux Foundation, and open source products. Conspiracy theories and backdoors everywhere, are favorite hobbies. Russians, Germans but no Chinese, Japanese or drug cartels this time?
    To the beginners here, products of The Linux Foundation are released as open source code. This code can be examined, and modified, before it is compiled into binary code for computers to use. Most (all?) creators of this binary code specialize this open source code. Changes are made for different hardware, preferences and operating needs. Many code compilers remove stuff added by The Linux Foundation. There is at least one voluntary organization that proudly removes the "binary blobs;' added by The Linux Foundation.
    Most compilers seem to add their own code to the open source product. This open source product is released every few days. The only organization that offers the compiled version of every open source Linux Kernel is Ubuntu. Every other group or organization cannot afford the time, skill & discipline needed to compile every bug-fix and change in the releases from The Linux Foundation. On their official Ubuntu web site, you have exactly 2,030 ready to run compiled Linux kernels waiting for you to download, right now, from "2016-04-06 08:00", to "2020-08-27 09:07".
    Unknown to slow learners here, is that Microsoft has released it's commercial version to Linux coders, free of legal constraints, via the "Open Source Initiative". This explains Paragon's "initiative". The older 3G NTFS etc is facing being very useless. This has implications also for BTRFS & ZFS. We need more comparisons on these file systems, for reliability, RAID, defragmenting, speed, self-repair, indexing, encryption & compression.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by milkylainen View Post

    I'm a bit wary of all corporate attempts at submitting a large blob of code.
    Be it Microsoft, Paragon, Intel or whatever.
    It's not much of a conspiracy.
    Just normal, not being a stupid asshole, do your due dilligence kind of sense.
    Linux Foundation is a corporate entity, albeit a non-profit one.

    So all the programmers, developers, and maintainers they support should be equally suspect by your logic.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by milkylainen View Post
    Here is to hoping that kernel folks live up to the high code standards they have set.
    I for one do not want this patch to pass unless bucketloads of rounds has been passed.
    Given its shitty state, I actually expect it.

    Also. I'd seriously scrutinize that code for built in exploits.
    Russian in origin, German HQ.
    Paragon is also heavily tied to government contracts and security agencies with various data storage technologies.
    This thread has it's Slashdot or QAnon conspiracy theory moment in it's very first post. So sad.

    Leave a comment:


  • birdie
    replied
    Originally posted by reavertm View Post

    Don't be silly. Word "blob" in software development does not have to literally mean binary large object. It can be used to describe anything vaguely big and too large to grasp. Which is exactly what previous patch was, and kernel devs complained accordingly.
    This time patch has been split to patch series so should be easier to review, some people can focus on their specific parts of interest, etc.
    Find something else to be picky about.
    It wasn't me who was effing picky in the first place and who didn't even want to see the code merged at all, and cited possible backdoors implanted by the Russias/Germans. And this guy still insists on not merging it as if he has a good alternative which he doesn't. If you are afraid of backdoors, do not bloody use it in your Linux. God. Open Source fanatics oftentimes are the worst enemies of open source.

    Also he claims he has verified all the code running on his Linux PC or maybe he meant something else - doesn't matter. This some excellent level 100 BS. Not a single person on Earth can do that in their entire lifetime for the average Linux desktop running e.g. Linux + Gnome + Web Browser. We are talking about millions of lines of very complicated code.

    So, this entire conversation that this code drop might be riddled with backdoors is pure BS/insanity. Even if it is, the guy is running a huge software stack he has no means of verifying EVER unless he has billions of dollars and an army of talented C/C++/ASM programmers. Oh, and by the time they are done verifying the code which will take years, they will discover so many bugs their effort will be rendered futile.
    Last edited by birdie; 29 August 2020, 08:25 PM.

    Leave a comment:


  • muncrief
    replied
    Well, I have a built-in prejudice against Paragon because I bought their Ext4 drivers for Windows, twice, and all they ever did was wipe out my Linux Ext4 filesystems, once even requiring a complete reinstall.

    The essential problem with their Ext4 drivers was that they changed Linux filesystem permissions to the point where they were unusable without extensive repair. And not just root filesystems, but any filesystem without the default permissions they seemed to expect. And this even happened when I tried to mount Ext4 partitions as read only.

    This has nothing to do with their NTFS drivers of course, it's just a general comment on my experience with Paragon.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by milkylainen View Post
    I'm a bit wary of all corporate attempts at submitting a large blob of code.
    The whole thing is only 27k lines of code, which isn't that much. And filesystems are pretty well understood/easy to review, compared to a lot of code that you might see in the kernel - especially 20+ year old filesystems.

    Leave a comment:


  • reavertm
    replied
    Originally posted by birdie View Post
    milkylainen

    Going full insult mode and still taking pleasure in demonstrating your misuse of words? Weird. I'd be ashamed.
    Don't be silly. Word "blob" in software development does not have to literally mean binary large object. It can be used to describe anything vaguely big and too large to grasp. Which is exactly what previous patch was, and kernel devs complained accordingly.
    This time patch has been split to patch series so should be easier to review, some people can focus on their specific parts of interest, etc.
    Find something else to be picky about.
    Last edited by reavertm; 29 August 2020, 06:16 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by doublez13 View Post
    Not that I use WSL, but I'm wondering I'm MS will leverage this to better file sharing between Windows and WSL environments. I'm actually quite shocked they're using Plan9 for sharing.
    The answer would be for WSL NTFS is almost absolutely useless. NTFS is not designed to be a shared file system for sharing between Windows and VMs(yes this includes WSL2) you need a file system designed to be shared and preferable light.
    https://www.linux-kvm.org/page/9p_virtio

    This is where plan9 shared usage comes from. Please note using SMB to share with VMs is still done but is really heavy.
    Plan9 is not ideal either but its lighter than implementing SMB.

    https://virtio-fs.gitlab.io/design.html

    There is work to move over to a fuse based on the Linux side.

    https://github.com/billziss-gh/winfuse/releases

    The windows version of fuse I really would like to see Microsoft supporting so virtio-fs can be used.

    Linux kernel implementing NTFS does not help with WSL issues as the problem space is different. Linux implementing NTFS could allow horrible NTFS for EFI partition in time.

    Really Linux kernel with NTFS and exfat out of file systems Microsoft so call maintains there is still 3 left Linux kernel does not have.

    Transaction-Safe FAT File System (TFAT) and Transaction-Safe Extended FAT File System (TexFAT) these are not major compatibility issues as you can use a vfat or exfat driver to read them of course it would be nice if Microsoft released permission for the Linux kernel to implement those two just the same. Only file system Windows has left that causes any compatibility issues is ReFS and this would still would require a patent license/grant from Microsoft.

    In some ways Linux kernel supporting NTFS will put pressure on Microsoft to get ReFS working to keep multi boot systems being some what of a pain.

    Leave a comment:


  • birdie
    replied
    milkylainen

    Going full insult mode and still taking pleasure in demonstrating your misuse of words? Weird. I'd be ashamed.

    BLOB, from Wikipedia: In the world of free and open-source software, the term is also borrowed to refer to proprietary device drivers, which are distributed without their source code, exclusively through binary code; in such use, the term binary blob is common, even though the first letter in the blob abbreviation already stands for binary.

    No, Paragon did not submit a blob. NVIDIA/AMDPRO proprietary graphics drivers contain blobs.

    Leave a comment:


  • Slartifartblast
    replied
    Originally posted by milkylainen View Post

    But then again, being an embedded Linux developer for 20 years+,
    having built all minor revisions of the kernel since 2.0.3x-something (I think).
    Done mips, hp-ux, sparc, blackfin, sh, arm, x86, xtensa, cris, powerpc archs and probably a few more boards and ports.
    I did my master thesis on free CPU architectures 18 years ago.
    Am I supposed to be impressed by this ?


    Leave a comment:

Working...
X