It's the other way around. Parallel capacitors boost capacitance to the sum of the individuals. It's like increasing the plates' area. Serial connected capacitors do the reverse: decreased capacitance with greater breakdown voltage, like the dielectric's thickness is increased.
The local machine boots using PXE. Clonezilla itself is transferred from a TFTP server as a squashfs and loaded into memory. When that OS boots, it mounts a network share using CIFS that contains the image to be installed. All of the local SATA disks are named sda, sdb, etc. A script determines which SATA disk is the correct one (must be non-rotational, must be a specific size and type), deletes every SCSI device (which includes ATA devices too), then mounts only the chosen disk to make sure it's named sda.
Clonezilla will not allow an image cloned from a device named sda to be written to a device with a different name -- this is why I had to make sure that sda is always the correct SSD.
There was no need to physically disconnect anything. We didn't actually use any SCSI devices, but Linux (and in turn, the Debian-based Clonezilla) uses the SCSI kernel driver for all ATA devices, so SATA SSDs also appeared as SCSI hosts and could be handled as such. If I had to manually unplug and reconnect hundreds of physical cables, I'd send my resignation directly to my boss' printer.
I presume you have had to run on RAM, considering you removed all drives
Yes. Mass deployment using Clonezilla in an extremely heterogenous environment. I had to make sure the OS got installed on the correct SSD, and that it was always named sda, otherwise Clonezilla would shit itself. The solution is a hack held together by spit and my own stubbornness, but it works.
Only if you're working with SCSI hardware. On Linux, SATA (and probably PATA) devices use the same kernel driver as SCSI, and appear on the system as SCSI hosts. You can find them in /sys/class/scsi_disk or by running lsblk -o NAME,HCTL.
Broke: /dev/sd*
Woke: /dev/disk/by-id/*
Bespoke: finding the correct device's SCSI host, detaching everything, then reattaching only the one host to make sure it's always /dev/sda. (edit) In software. SATA devices also show up as SCSI hosts because they use the same kernel driver.
I've had to use all three methods. Fucking around in /sys feels like I'm wielding a power stolen from the gods.
I'm going to guess you've never been part of a project with complexity and sheer black magic fuckery comparable to Ventoy. The developer (a singular person) had to make a choice between:
Pandering to a small group of vocal open-source extremists, dedicating a large part of their time to changing the incredibly complex build process to also build the binaries of other open-source projects, potentially at the cost of stability, eventually arriving at a product with the same feature set, pleasing some open-source extremists, but still receiving criticism for "taking a year to respond to a genuine concern"; or
Not doing that and focusing their effort on stability and compatibility fixes to arrive at an improved product.
I've read the original issue thread front to back, and it's a fucking clown show. I can't blame the developer for not wanting to engage with those people. Nobody is entitled to the developer's time or attention. Right now the issue is being worked on, which is more than most of the whiners can say about themselves; if you think that's still insufficient, do better.
Yes, but people have concerns. Ventoy is fully open-source, but the build process pulls binary blobs (compiled executables, think of them like blob chips) from other F/OSS projects, which is an issue for some people. They have legitimate concerns about trusting Ventoy because they have to implicitly trust the projects that Ventoy pulls from but can't verify what is getting pulled. If such a project were to become compromised (the way XZ-Utils was), it would eventually spread to Ventoy.
That being said, the developers (or singular developer, not sure) are taking steps to reduce Ventoy's dependency on external blobs. It's a difficult task and they have limited resources, but they have acknowledged that it is an issue and are working on a solution.
The minimum spec is whatever e-waste you can find that still powers on.
My home server has an i3-4160, 10 gigabytes of mis-matched RAM, a ten-year-old 240 GB SSD with 36000 hours on it, and three 1 TB hard drives in a RAID5 array each with ~25000 power-on hours. It runs Proxmox on the metal with a virtualized OPNsense, Nextcloud, and Jellyfin server (plus smaller services). Jank levels are high, but not fatal, and it was mostly free.
That's not how any of this works. Not-quite-Hitler would still be exposed to the same influences and grow up to be the same person.