I am shocked by this - the quote in below is very concerning:

“However, in 2024, the situation changed: balenaEtcher started sharing the file name of the image and the model of the USB stick with the Balena company and possibly with third parties.”

Can’t see myself using this software anymore…

    • gnuhaut@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      20 hours ago

      I don’t think oflags=direct has any influence on the result. Apparently that’s about disabling the page cache in the kernel, which can avoid a situation in which the system slows down due to buildup yet-to-write pages.

      • massacre@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        18 hours ago

        Perhaps not. But the flag allows for direct I/O for data, bypassing buffers which can be overrun with certain size blocks, potentially causing dirty buffer depending on the machine being used. My understanding is that it’s “more reliable” for writing (especially on shitty USB Flash drives) and getting the exact ISO properly written.

        But it could be useless all the same - I’m just pointing out that OPs command is not the one recommended by Fedora when writing their ISO. Also OP is less likely to pull the drive before buffers have flushed this way.

        • gnuhaut@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          17 hours ago

          Oh yeah that’s where I was getting at, but I didn’t have time to write that out earlier. I agree that OP probably pulled out the usb stick before buffers were flushed. I imagine that direct I/O would mitigate this problem a lot because presumably whatever buffers still exist (there would some hardware buffers and I think Linux kernel I/O buffers) will be minimal compared to the potentially large amount of dirty pages one might accumulate using normal cached writes. So I imagine those buffers would be empty very shortly (less than one second maybe?) after dd finishes, whereas I’ve seen regular dd finish tens of seconds before my usb stick stopped blinking it’s LED. Still if you wait for that long the result will be the same.

      • Rogue@feddit.uk
        link
        fedilink
        arrow-up
        16
        ·
        1 day ago

        You didn’t screw up, you beautifully proved why the CLI is never a simple solution.

        • admin@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          18 hours ago

          It reminded me when I told a coworker he could force the Windows shutdowns with the command 'shutdown -p -f" from either a Run.exe or a cmd window.

          Then he said it wasn’t working, and that the cmd window would just open and close quickly but no shutdown.

          Imagine my surprise when he was doing shutdown -pf .

        • Abnorc@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          24 hours ago

          This is why people trying to pass this as a primary option baffle me a bit. dd is not that bad in isolation, but all of these little commands add up.

          If we want Linux to be mainstream, we need to accept that most users aren’t going to be linux enthusiasts. They just want a PC that works normally.