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…

  • davel@lemmy.ml
    link
    fedilink
    English
    arrow-up
    63
    arrow-down
    2
    ·
    2 months ago

    ♬ Hello dd my old friend
    I’ve come sudo with you again ♬

  • Brickfrog@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    33
    ·
    edit-2
    2 months ago

    That’s interesting, apparently it was mentioned on github but nothing seems to have changed in the end

    https://github.com/balena-io/etcher/issues/3784

    Haven’t used that software in a long time but maybe there’s an opt-out somewhere during runtime? Although I don’t see why a user needs to be required to opt out of nonsense like this when just writing firmware to a USB disk.

    Only ever touched balenaEtcher when some project or distro recommended it. Overall prefer Rufus for this sort of thing when working on Windows.

    • wizardbeard@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      2 months ago

      I’ve used Sardu on Windows for making multi-iso bootable USB sticks a long time ago in the past, but I’d admittedly never looked at their ToS or Privacy Policy. My use case was slapping some live boot antivirus scanners, data recovery tools, and one or two lightweight liveboot-Linux ISOs on one USB as a portable toolkit.

      When I’m making anything else from Windows, I’ve always stuck with Rufus. Had never heard of BalenaEtcher before now.

      • Cataphract@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        2 months ago

        I"m horrible with names of programs and mess with a lot of junk comps switching out OS’s and just tinkering around so I’m always using crazy utility programs. BalenaEtcher is used in a lot of tutorials or guides for installations, I think recently both Elementary OS and even Ubuntu had instructions pointing towards BalenaEtcher.

        I never thought it was a great program, it was finicky to use and errors out quickly multiple times. Looking back I saw the signs, weird new program being promoted above other “well established” burn programs, ads, and now scrolling down their webpage it’s just a bunch of promotional subscription bullshit. I think I just threw up in my mouth a little bit looking at the “balenacloud” and “balenasense”, like if they’re collecting your data through etcher then all of that shit is probably compromised. Another fucking google wannabe corp.

  • PullPantsUnsworn@lemmy.ml
    link
    fedilink
    English
    arrow-up
    21
    ·
    2 months ago

    Is no one aware of Fedora Media Writer? It’s FOSS and the most trustworthy ISO burning software in existence. It’s only issue is that its named as if it is written only for producing Fedora bootable media. It works for everything.

      • Rowan Thorpe@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        2 months ago

        The article at the end mentions they suggest dd as alternative for MacOS (due to Unix user space). It seems the balena -> rufus decision is about the easiest-onramp Mac+Win-portable option, for those uncomfortable dropping to low-level device-writing CLI tools in their current system.

        Side-note: Last time I was on a friend’s Windows I installed dd simply enough both as mingw-w64 (native compiled) and under Cygwin. So for Windows users who are comfortable using dd it only requires a minor step. When I once used WSL devices were accessible too, but that was WSL1 (containerized), whereas WSL2 (virtualized) probably makes device-mapping complex(?) enough to not be worth it there.

  • pH3ra@lemmy.ml
    link
    fedilink
    arrow-up
    19
    ·
    2 months ago

    If you need a FOSS, cross platform GUI for bootable USB sticks, Raspberry Pi Imager is a really good solution.
    It is mainly used to flash SD cards for RPIs, but also you can burn any ISO on any support with it.

    • phar@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      2 months ago

      I used to use the fedora media writer but the RPi imager software is so easy I switched

    • ☂️-@lemmy.ml
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      2 months ago

      nah, plenty of good stuff with good ui.

      balena had effects and stuff but a pretty tasteless gui tbh, and ads promoting other shit…

  • renzev@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    ·
    2 months ago

    I remember a while back, years before this surfaced, there was a thread on /g/ with a group photo of Balena’s employees and a caption like “why does it take so many people to develop an electron wrapper around dd”. Obviously it was low effort engagement bait (balena does much more than etcher), but the comments were full of people calling the company a glowie honeypot and the like. Moral of the story: Trust the schizos, they sense spyware form lightyears away.

  • Atlas_@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    2 months ago

    Rufus is great! I worked with the maintainer to fix a bug in hardware they didn’t have and it was a very pleasant experience.

  • Andromxda 🇺🇦🇵🇸🇹🇼@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    1
    ·
    2 months ago

    Just use dd. It’s not that hard. You pass it 2 arguments: if= the file you want to flash, and of= the destination. If you’re feeling fancy, pass in some status=progress. And don’t forget to prepend it with sudo. That’s it.

    • harsh3466@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      2 months ago

      I just tried this the other day and was unable to boot from the USB. Any chance you could shed some light on what I might have screwed up?

      The command was:

      dd if=fedora.iso of=/dev/sdc bs=4M status=progress
      

      The USB stick was not mounted and the fedora image was verified. The command completed successfully but I couldn’t boot from it. When I used fedora writer to burn the same image to the same USB stick it booted no problem.

      Edit: spelling & capitalization

        • gnuhaut@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          2 months 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
            2 months 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
              2
              ·
              2 months 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.

  • N0x0n@lemmy.ml
    link
    fedilink
    arrow-up
    10
    ·
    2 months ago

    I tried belenaEtcher once on my Mac… And it seemed to me more like a spyware than an actual software, I was a bit confused and never used it again.

  • Majestic@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    2 months ago

    Yet another reason for people to run a default prompt (deny until prompt answer) firewall.