Announcement

Collapse
No announcement yet.

Linux 6.9 Set To Drop The Old NTFS File-System Driver

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

  • #41
    Originally posted by miquels View Post
    Ext4 has stored btime for a very long time, it was just not possible to query it for a while.
    Linux added a statx() syscall in 4.11 that can return btime. Glibc support was added in 2.28. Coreutils added support in 8.32 (ls and stat) in 2020.
    I'm perfectly aware of ext4 supporting btime since forever, I'm among very few people who've actually been using it.

    However there's an API only for reading btime, not writing, for which debugfs is required (a very dangerous command which can destroy your FS) which makes this a fool's errand.
    Last edited by avis; 10 March 2024, 08:06 PM.

    Comment


    • #42
      Originally posted by avis View Post

      If individual software methods become free and available to anyone, that could mean that your complete software product might be undercut by those reimplementing it using the same software methods but slightly altered in a way they are all put together. Sorry, this distinction of yours between a complete "copyrighted" product and individual software methods/patents becomes way too vague to me. I don't understand how this can work legally. It looks like the entire system becomes ripe for abuse. Or maybe I don't understand copyright but then I've never used it for anything other than literature and art. Maybe you're right. I've not seen that many software patents either.
      The individual software methods doesn't have to be free and available to everyone, now as a FOSS developer I ofc would like to have it that way, but it isn't mandatory. NanoZip is an example of this, still to date AFAIK no one have published an open source version of the compression algorithms used by that program. Looking at the binary and reverse engineering the algorithms are ofc always an option but such a recreation would be a copyright violation so one would have had to go the full route of clean-room implementation and this is both costly and resource intensive to do (and not always a successful way to avoid copyright violation).

      E.g now imagine if software patents had existed in 1979 when VisiCorp created VisiCalc, they could then have stalled the entire spread sheet application market until 2004. Now imagine just how much an impact that would have, by all accounts there would have been no Lotus 1-2-3, no MS Excel and no StarOffice (so no LibreOffice Calc). Some one would most likely had made some new spreed sheet application in 2005 but we would have lost 25 years of progress.

      Comment


      • #43
        Originally posted by F.Ultra View Post
        but we would have lost 25 years of progress.
        Spreadies were/are the glue in any organisation. Big or small
        Without them, we wouldn't be anywhere near where we are today. They've lost they're lustre compared to late inert/noughties because business is serious and all over the automation and IT thing with full blown app suites(.ostly thinking SAP right now for some reason, before web shit), but those 25 years you mention without a spreadsheet on an accountant or techies desktop?

        Lost in Spaaaace.
        Hi

        Comment


        • #44
          Originally posted by stiiixy View Post

          Spreadies were/are the glue in any organisation. Big or small
          Without them, we wouldn't be anywhere near where we are today. They've lost they're lustre compared to late inert/noughties because business is serious and all over the automation and IT thing with full blown app suites(.ostly thinking SAP right now for some reason, before web shit), but those 25 years you mention without a spreadsheet on an accountant or techies desktop?

          Lost in Spaaaace.
          Not 25 years without a spread sheet, 25 years of spread sheets looking and behaving exactly like VisiCalc did in 1979 since there would be no incentive and no reason to improve (and no competition to drive innovation) when they could just lock out and kill every single competing application due to them violating their patents.

          Comment


          • #45
            Originally posted by L_A_G View Post



            Videogame Consoles: The Sony Playstation 4, 5 and Nintendo Switch all run FreeBSD-derived OSs and are so chock full of open source in their runtime (GLIBC etc.) and development tools (GCC). Outside of their proprietary graphics APIs/libraries there's barely any entirely proprietary code in OrbisOS (PS4&5) or NX (Switch). Together they control about 90% of the console videogame market.
            No to nitpick too much but while The Nintendo Switch does use some BSD libs, the OS is not BSD-derived. It's an custom microkernel OS first found in the Nintendo DS.

            Comment


            • #46
              Originally posted by mercster View Post

              This is right, the NTFS3 driver still does not fully support NTFS journaling, i.e. if you lose power to a mounted disk, there's a good chance you'll have corruption that can only fully be clearned by a Windows rescue disk or some such. Happened to me one too many times.
              Thanks for your comment which may explain the data loss I discovered with the NTFS3 driver. I was able to recover the lost files within Windows (chkdsk), though.

              I don't like undocumented features and I am still confused about whether or not this bug was ever fixed. Other users also reported this issue, so this can't be a singular incident. I wrote about it here: https://www.heiko-sieger.info/does-t...t-directories/

              Back when the driver was introduced, I did some speed tests, though my test case is probably not the average users' way of employing NTFS. I run my NTFS partitions on LVM volumes that have been formatted by a Windows VM. There were never any problems when using the NTFS-3G driver, but the NTFS3 kernel driver managed to "loose" files. Here the speed test results: https://www.heiko-sieger.info/new-nt...n-kernel-5-15/

              Until I read that the NTFS3 developer and/or the kernel team have at least acknowledged the bug and provided a fix, I will not be using the NTFS3 kernel driver. Too risky for me.

              Comment

              Working...
              X