This is a good example of how most of the performance improvements during a rewrite into a new language come from the learnings and new codebase, over the languages strengths.
The I/O size is a reason why it’s better to use cp than dd to copy an ISO to a USB stick. cp automatically selects an I/O size which should yield good performance, while dd’s default is extremely small and it’s necessary to specify a sane value manually (e.g. bs=1M).
With “everything” being a file on Linux, dd isn’t really special for simply cloning a disk. The habit of using dd is still quite strong for me.
Do cp capture the raw bits like dd does?
Not saying that its useful in the case you’re describing but that’s always been the reason I use it. When I want every bit on a disk copied to another disks, even the things with no meta data present.
Interesting. Is this serious advice and if so, what’s the new canonical command to burn an ISO?
As I understand it, there isn’t really a canonical way to burn an ISO. Any tool that copies a file bit for bit to another file should be able to copy a disk image to a disk. Even shell built-ins should do the job. E.g.
cat my.iso > /dev/myusbstickreads the file and puts it on the stick (which is also a file). Cat reads a file byte for byte (test by cat’ing any binary) and>redirects the output to another file, which can be a device file like a usb stick.There’s no practical difference between those tools, besides how fast they are. E.g. dd without the block size set to >=1K is pretty slow [1], but I guess most tools select large enough I/O sizes to be nearly identical (e.g. cp).
[1] https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204
Given that this is the crucial first step in installing Linux on a new computer, the fact that there is so much mystery and arbitrariness around it seems to me pretty revealing and symptomatic of Linux’s general inability to reach ordinary folks.
Thanks for the information.
It’s actually exactly the opposite case. Any method to copy data from one location to another will work, such as by using dd, or cat, or even just formatting the drive and using cp. If you don’t want to deal with command line tools, there are many GUI tools that are literally just a couple buttons to press on all major operating systems. My personal preference for GUI liveUSB tools is Balena Etcher, or Fedora Media Writer. Both are incredibly easy to use and feature intuitive GUIs. There is no “mystery” or “arbitrariness” surrounding it at all, it’s a pretty straightforward process. Copy data from one place to another and you’re done. The only differences between the methods, as the previous comment said, is the speed of the transfer and some minor things that the end user has basically no reason to think about.
As far as its ease of installation and use goes, my tech illiterate father was able to install and use Linux Mint with zero problems and has been using it for years, so I’d say it does a pretty damn good job overall.
Wish I could agree with you on the underlying point.
My own anecdata is of normies who are absolutely resistant to the very idea of touching Linux because of its connotations of complexity. And really I don’t think they’re wrong.
My personal preference for GUI liveUSB tools is [etc]
Imagine what even this phrase must sound like to someone who has only ever used pre-installed Windows. Not being facetious.
My opinion remains that Linux could only benefit ifs distros would take hand-holding to its logical extreme and provide the actual Windows-Mac executables that make installing Linux a genuinely one-click experience. Last time I checked, Fedora did this. Pity it’s Fedora and not Debian.
/ As of Jan 2034, 512KiB is determined to be the perfect blksize to minimize system call overhead across most systems.
