Tails - Replacing balenaEtcher with Rufus as installer for Windows
tails.net

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…

    • @Firnin@feddit.org
      0•2 months ago

      It is indeed the best way, but somehow I am still anxious using this command, even after flashing countless USB drives 😅

      • @memphis@sopuli.xyz
        0•2 months ago

        I’ve made it a habit to type out the command without sudo at first, then when it yells at me about permissions I am reminded to go back and double-check.

      • @dev_null@lemmy.ml
        0•2 months ago

        It’s faster to drag and drop a downloaded ISO and choose the target from a dropdown, than do it on a command line. And get a progress bar. As much as command line is usually faster, it isn’t in this case.

        Yes you can also get a progress bar on the command line but it’s more typing again, and realistically you need to look the option up every time if you use dd once every 3 months.

        • @madame_gaymes@programming.devEnglish
          0•2 months ago

          Lmao. Uses a computer, typing is too much. It took more typing to write your comment than to craft a tab-completed dd command, even if you had to call the help menu to refresh your available options, jus’ sayin’

          I get it though, the general public are scared of the big bad 'puter magic and need GUIs.

          • @dev_null@lemmy.ml
            0•2 months ago

            Let me try: Lmao. Uses a computer, still does stuff the slower way because learning new things is too difficult.

            To be serious, I am looking for the best solutions for my use cases, not adequate ones. Yes dd works perfectly fine and as you noted doesn’t take long to use anyway. But just because it’s fine doesn’t mean other approaches aren’t better.

            A GUI tool can offer or take a list of download URLs for common distros so downloading isn’t a separate step, it can check if the target device is a flash drive and not a hard drive by mistake, it can automatically choose the optimal block size for the device, it can verify the process by reading it back from the device, can show you the current filesystem, label, and usage of the target device to confirm, it can handle flashing to multiple devices at the same time with separate and total progress bars.

            If I wanted to do all that on the command line it’d be quite a lot of commands or a sizeable script to write. Or I can use a simple dd command and lose out on all of the above. Either way it’s a worse option. I will only use dd when a GUI tool isn’t installed, or when I’m on a system without a DE.

            • @madame_gaymes@programming.devEnglish
              0•2 months ago

              Shhh, that’s too advanced. Besides, CLI is outdated and slower than GUIs, this is just insane behavior /s

              I honestly didn’t even need to specify tab-completed. It’s still less typing than their comment unless your paths are miles long.

        • @madame_gaymes@programming.devEnglish
          0•2 months ago

          I know, but just because someone doesn’t understand something or ignores it doesn’t mean it isn’t the best/simplest choice for 90% of cases.

      • @shortwavesurfer@lemmy.zip
        0•2 months ago

        Oh, sorry. I didn’t realize you were on Windows. That’s a Linux command. I haven’t used Windows very much since about 2018, so I don’t even consider Windows anymore unless it’s brought up.

      • @ArcaneSlime@lemmy.dbzer0.com
        0•2 months ago

        Rufus.

        And who cares if there’s spyware on windows, you’re already using windows so there is, it’s windows. At that point you may as well just use etcher, but I’d use Rufus anyway because let’s be real it’s just better. The only reason not to use Rufus is because it’s windows exclusive, but if you’re using windows that probably doesn’t bother you, so…

    • @CosmicTurtle0@lemmy.dbzer0.comEnglish
      0•2 months ago

      In my early days of Linux, I royally fucked up a USB thumb drive (back when they were expensive) using dd and as a result do not trust myself with it.

      I would use Hannah Montana Linux if it was the only GUI option to burn a USB ISO.

      • @shortwavesurfer@lemmy.zip
        0•2 months ago

        Weird. I can’t even tell you how many times I’ve used that command. But it’s probably been several thousand. And I’ve never screwed up a flash drive that way.

        There has been once or twice where I’ve pulled the flash drive out too quickly after it finished writing and it actually hadn’t finished writing and had to redo it, but other than that, I’ve not actually screwed up any drives beyond repair or anything.

  • @N0x0n@lemmy.ml
    0•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.

  • OcéaneFrançais
    0•2 months ago

    Unrelated to balenaEtcher but I haven’t been able to flash ISO files from Windows 11, either by using Rufus, Etcher, Fedora Media Writer, or even the WSL. I need to borrow a computer running a FLOSS operating system or to install OpenBSD first, and then from OpenBSD to download and burn an ISO file.

    • @AugustWest@lemmy.world
      0•2 months ago

      That sounds like an issue with your computer rather than W11. I just used Etcher on my W11 desktop to flash Mint XFCE yesterday with no issues.

  • Brickfrog
    0•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.comEnglish
      0•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
        0•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.

  • @maniel@lemmy.mlEnglish
    0•2 months ago

    i still had issues using 150MB electron based bloated and heavy software instead of rufus, not that it worked for me anyway

    • @admin@sh.itjust.works
      0•2 months ago

      I only tried to use it once, and same. 150MB of a Web app to copy an ISO? I think I was using a Macbook to flash it and decided to use ventoy instead, with my PC.

      • @AnUnusualRelic@lemmy.worldEnglish
        0•2 months ago

        I understand that it needed a GUI, but 150 megs?? When :

        ~ 
❯ ll `which dd`
-rwxr-xr-x 1 root root 63K Sep 29 16:36 /usr/bin/dd*

~ 
❯
  • @SpatchyIsOnline@lemmy.world
    0•2 months ago

    Here’s a wildcard people might not know about: Raspberry Pi Imager

    I use it because it’s faster than Etcher and it also has a bunch of quick links to download popular images (mainly for RPI and other arm-based SBCs) in one click which is handy if you use those regularly.

  • @BoxOfFeet@lemmy.world
    0•2 months ago

    Wow, I was not aware of that. I really liked balena. Thankfully, I haven’t been using it since installing Mint.

    • Andromxda 🇺🇦🇵🇸🇹🇼English
      0•2 months ago

      If you actually read the post, you would have known, it does work, but there are some privacy concerns with it:

      “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.”

  • Andromxda 🇺🇦🇵🇸🇹🇼English
    0•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
      0•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

      • @Maiq@lemy.lol
        0•2 months ago

        Did you make sure that the of is correct? lsblk to make sure.

        If your sure it wrote to the right drive i would make sure that you have a good download. Did you run your checksums?

        I think fedora works with secureboot but you might want to disable it just to see if that is the issue. I believe you can reenable it after install.

        Make sure to go into the bios and boot from external drive/usb.

        Out of 15 years of using dd i have never had a problem.

        • @harsh3466@lemmy.ml
          0•2 months ago

          I did verify with lsblk, with a listing before and after plugging in the stick to be absolutely sure.

          I also did verify the checksum of the ISO.

          I’ll double check SecureBoot, but as I mentioned, the same ISO written to the same stick with Fedora writer did boot in the same machine it wouldn’t boot from with the dd version.

          I know it’s something I did or didn’t do to make it work correctly, so this is not me trying to dunk on dd, just trying to understand what I did wrong.

        • @gnuhaut@lemmy.ml
          0•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.worldEnglish
            0•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
              0•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.

          • @Rogue@feddit.uk
            0•2 months ago

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

            • @Abnorc@lemm.ee
              0•2 months 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.