this post was submitted on 06 Jun 2024
930 points (99.1% liked)

linuxmemes

21088 readers
1598 users here now

Hint: :q!

Sister communities:

Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
    • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
    • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

    • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
    [email protected]
    [email protected]
    [email protected]
    930
    the fear of missing out a better compression (lemmy.world)
    submitted 4 months ago by [email protected] to c/[email protected]
    195 comments fedilink hide all child comments
     

    Source - Posted with Reddy

    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 34 points 4 months ago* (last edited 4 months ago) (22 children)

    Can someone explain why MacOS always seems to create _MACOSX folders in zips that we Linux/Windows users always delete anyway?

    [–] [email protected] 3 points 4 months ago (1 children)

    HFS+ has a different features set than NTFS or ext4, Apple elect to store metadata that way.

    I would imagine modern FS like ZFS or btrfs could benefit from doing something similar but nobody has chosen to implement something like that in that way.

    [–] [email protected] 2 points 4 months ago (1 children)

    Yeah totally!

    frantically searches for the meaning of all those abbreviations

    [–] [email protected] 3 points 4 months ago (2 children)

    I gotcha:

    • Btrfs
      • BTree File System
        • A Copy on White file system that supports snapshots, supported mostly by
    • ZFS
      • Zetabyte File System
        • Copy on Write File System. Less flexible than BTRFS but generally more robust and stable. Better compression in my experience than BTRFS. Out of Kernel Linux support and native FreeBSD.
    • HFS+
      • what Mac uses, I have no clue about this. some Copy on Write stuff.
    • NTFS
      • Windows File System
      • From what I know, no compression or COW
      • In my experience less stable than ext4/ZFS but maybe it's better nowadays.
    [–] [email protected] 2 points 4 months ago (1 children)

    Great summary, but I've to add that NTFS is WAY more stable than ext4 when it comes to hardware glitches and/or power failures. ZFS is obviously superior to both but overkill for most people, BTRFS should be a nice middle ground and now even NAS manufacturers like Synology are migrating ext4 into BTRFS.

    [–] [email protected] 1 points 4 months ago

    Well that's good to know because I had some terrible luck with it about a decade ago. Although I don't think I would go back to windows, I just don't need it for work anymore and it's become far too complex.

    I've also had pretty bad luck with BTRFS though, although it seems to have improved a lot in the past 3 years that I've been using it.

    ZFS would be good but having to rebuild the kernel module is a pain in the ass because when it fails to build you're unbootable (on root). I also don't like how clones are dependant on parents, requires a lot of forethought when you're trying to create a reproducible build on eg Gentoo.

    [–] [email protected] 1 points 4 months ago

    Thanks!

    load more comments (20 replies)