• raspberriesareyummy@lemmy.world
    1435·
    2 days ago

    honestly - while a Mac is certainly less painful to use than winshit, putting rubbish files recursively into each(!!) accessed folder, on all thumbdrives ever inserted, that’s something Jobs deserves to burn in hell for.

    • ulterno@programming.devEnglish
      211·
      2 days ago

      You’d want that, but a lot of programs do that, both in Windows and Linux.

      e.g. The .directory files with the [Desktop Entry] spec by freedesktop.org
      Dolphin has the option to enable/disable the feature

      • lengau@midwest.social
        19·
        2 days ago

        FWIW Dolphin only does it if the filesystem doesn’t provide a way to add that metadata directly to the directory and you change the view configuration for that directory away from your standard configuration. Which is how the standard describes to do it. (Some file managers incorrectly add those .directory files to every directory you visit.)

        A mac will add a .DS_Store file to any directory just by breathing on it.

        • ulterno@programming.devEnglish
          41·
          2 days ago

          Well, those are different specifications. Apple(who wants everything for themselves) vs FDO(whose main goal seems to be interoperability)

          • FearfulSalad@ttrpg.network
            5·
            2 days ago

            Maybe. There are many ways to move files and directories around without using Finder, at which point all indexed data about those files and directories will be stale. Forcing something as core as mv to update Spotlight would be significantly worse, I think. By keeping the .DS_Store files co-located with the directory they index, moving a directory does not invalidate the index data (though moving a file without using Finder still does). Whether retaining indexing on directory moves is a compelling enough reason to force the files everywhere is probably dependent on whether that’s a common enough pattern among workflows of users, and whether spotlight performance would suffer drastically if it were reliant on a central store not resilient against such moves.

            So, it’s probably a shaky reason at best.

  • cm0002@lemmy.world
    112·
    2 days ago

    See also: Let’s roll our own .zip implementation that only Mac can reliably read for…reasons

    • stebo@lemmy.dbzer0.com
      63·
      2 days ago

      every time i get a zip file from a mac user it has a folder with random junk in it. what’s up with that? i can open the files without it so clearly those files are unnecessary

      • skuzz@discuss.tchncs.de
        57·
        2 days ago

        Metadata that’s a holdover from the 1980s MacOS behavior. Hilariously, today, NTFS supports that metadata better than Apple’s own filesystems of today. They can hide it in Alternate Data Streams.

  • Lazycog@sopuli.xyz
    798·
    2 days ago

    Hmm… Smells like a windows user aswell… Look at that:

    .desktop desktop.ini

    Edit: fixed the filename

  • FQQD! @lemmy.ohaa.xyz
    62·
    2 days ago

    you should do this with every one of these cases. btw, where does .Trash-1000 actually come from?

    • Lucy :3@feddit.org
      211·
      2 days ago

      I had a long and frustrating conflict with this, on this post.

      As @[email protected] (An dem Punkt könnten wir auch einfach Deutsch labern) noted, it’s a freedesktop.org specification.

      I still stand the point that it’s not very thought through (a hidden dir? Why?), and that blindly implementing it is annoying. It shouldn’t be a universal standard for all systems, as it’s only relevant if you use a file manager which can then use that dir as Trash dir - which I don’t. That could be tested by only allowing filemanagers to create the dir, and if it doesn’t exist, discard the data. That’s probably how some programs work, as only Prismlauncher has created the dir.

      Workaround: ln -s .Trash-1000 /dev/null

        • Lucy :3@feddit.org
          5·
          2 days ago

          Hab tagelang hass geschoben weil der Schmutz mir massiv Speicherplatz geklaut hat. Muss halt zu dev/null symlinken und prüfe regelmäßig global ob es ein neues davon gibt.

  • webghost0101@sopuli.xyz
    491·
    2 days ago

    I would also like a word with “bonjour” process while we’re at it.

    Thought it was a virus when I first discovered it.

    • JackbyDev@programming.devEnglish
      10·
      2 days ago

      Idk what all it does and doesn’t do, but installing it in Windows lets you find your Raspberry Pi by its “.local” hostname. I know it was originally for printers or something.

      • boonhet@lemm.ee
        7·
        2 days ago

        It’s for local service discovery. Those services may be printers on your network, or another computer sharing music on iTunes (which is why as a Windows user you’d usually get Bonjour when installing iTunes). Or maybe it’s your Raspberry Pi.

        It feels iffy because it comes bundled with other software without you being asked (IIRC) and it autoruns on startup. And I mean 20 years ago when iPods were a thing and people had to use iTunes on Windows, a couple dozen megabytes of RAM really mattered too. Hell I had 512 MB back when I had an iPod (and therefore iTunes)

    • MonkderVierte@lemmy.ml
      3·
      2 days ago

      That was what caused duplicates on setting the printer as default on dad’s PC. Just disable active scanning for new printers in the config. Was quite some detective work with examining the service file and recursively grepping /etc for variable names multiple times.

      • M.int@lemm.ee
        3·
        2 days ago

        Why is there a * in front of DS_Store?
        Seems like fastly made a small mistake find . -name '.DS_Store' -type f -print -delete would just match the exact file and is faster.

  • boonhet@lemm.ee
    191·
    2 days ago

    Just gitignore that. Same for dot idea and whatever vscode adds, if anything

      • boonhet@lemm.ee
        8·
        2 days ago

        It’s not, but I still prefer not pushing my config on others, or others pushing theirs on me.

    • JackbyDev@programming.devEnglish
      81·
      2 days ago

      Use this so that the things you need to share do get shared.

      .idea/*
!.idea/codeStyles
!.idea/runConfigurations

.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
!.vscode/*.code-snippets

      Note: I haven’t checked the vs code ones in depth, the list might not be perfect.

      • kora@sh.itjust.works
        101·
        2 days ago

        I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.

        • JackbyDev@programming.devEnglish
          41·
          2 days ago

          If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.

          • kora@sh.itjust.works
            41·
            2 days ago

            I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.

            If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.

          • Eager Eagle@lemmy.worldEnglish
            21·
            2 days ago

            Absolutely nothing wrong. Their whole argument is that it delivers no guarantees about the things set in these files, but setting these presets is more about convenience than enforcing an equal development environment.

            Whoever needs to enforce things like formatting and linting at the project level should be using a CI step.

      • Eager Eagle@lemmy.worldEnglish
        21·
        2 days ago

        .vscode doesn’t store cache or any trash like that, so if you’re including all settings, tasks, etc, you can probably just include everything.

        The only thing to keep in mind is to only add settings, extension recommendations, etc that apply to all your collaborators and aren’t just personal preferences. A few good examples are formatting rules, task definitions to run the project, and linting rules that can’t be defined somewhere else.

        • kora@sh.itjust.works
          51·
          2 days ago

          Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.

          I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.

          As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.

          • dev_null@lemmy.ml
            1·
            1 day ago

            Linting rules and scripts should never live in an IDE-specific directory.

            Of course they should. Obviously it shouldn’t be the only place they are, but committing IDE code styles settings that match the externally-enforced project styles is absolutely helpful.

            Or, in our project we have a bunch of scripts that you can run manually, but we also have commited IntelliJ run configurations that make running them a convenient in-IDE action.

          • brian@programming.dev
            3·
            2 days ago

            linting config itself wouldn’t be defined there, and it would be verified in ci and such, but a setting to tell vscode which linter and extension it should use to show warnings would be.

            modern languages may have their own way for configuration but they don’t have a way to bind it to the list of vscode tasks and define how to run a debugger, which is the part that gets stored.

            it’s easy to go overboard with extension suggestions, but I don’t think adding an extension for linter used, extension for formatter used, and any languages used if there’s a definitive extension.

            My team is split between visual studio, vscode, and I use emacs. we have config for both vs and vscode in our repos since it makes working on a new project so much nicer and means we aren’t just sharing editor configs through side channels instead. it doesn’t do anything to me if I have editor config for an IDE I don’t use in the repo, but it makes it easier for someone new to jump in with a sort of same environment immediately

          • Eager Eagle@lemmy.worldEnglish
            11·
            2 days ago

            Can we stop with the absolutes?

            It’s okay to commit IDE config if your team uses mostly one editor.

            It’s also okay to include extension recommendations. While extensions may not be needed to run the code, depending on the editor and language they’re highly desirable. It’s that kind of extension that should be recommended. I’m sure there’s a setting to disable them if, for some reason, the editor keeps asking you.

    • andioop@programming.devEnglish
      5·
      2 days ago

      git add . > git commit -m "initial" > git push

      Later when I git status or just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.

  • Psythik@lemmy.world
    203·
    2 days ago

    As much as they love to sue people, I don’t understand why Nintendo doesn’t go after Apple for trademark infringement, so that they’re forced to finally come up with a better method of storing folder attributes.

      • JackbyDev@programming.devEnglish
        6·
        2 days ago

        This is probably not a relevant counter point, just a(n un)fun fact, but Nintendo put in a patent for throwing a capture ball at monsters after Pal World was released and Pal World has to change some stuff (though I’m not sure if they’re doing it to avoid going to court because they’re concerned or if they’re being compelled).

      • M.int@lemm.ee
        2·
        2 days ago

        That doesn’t work, DS_Store are files not directories ( you need to use -type f).
        An equivalent find command would be:
        find "$HOME" -type f -name '.DS_Store' -delete -print
        find takes a while; fd is way, way faster, but find is preinstalled, so there is that.