This is exactly what magnetic flux imaging does, it just uses a regular floppy mechanism with all the risk that entails.
If one built a more sensitive head mechanism that floats above the disk, one could (say) load a disk sans envelope/case and take a flux image of it without anything touching the surface.
Then one could use the existing flux processing software (possibly tweaking it) to extract the data.
Yes, they are very obviously suggesting it didn't happen. I have no idea why certain people on the left want to ignore what is happening on Iran, and even pretend like nothing problematic is happening in Iran.
Nobody’s saying nothing problematic is happening in Iran.
What I’m saying is that a lot of people are extremely interested in seeing Iran fall and that Western media paid by Saudi Arabia has exactly zero credibility. So get better sources, that’s all.
Yes and no; kernels aren’t magic, and “change how this kernel is loaded to match how Linux does it” is actually a reasonable first assignment for an Operating Systems class at a top-tier school. (You’re basically just creating an alternative `main()` if you don’t need a RAM disk image from which to load drivers.)
What, pray tell, would you do for a first assignment in an Operating Systems class at a top-tier school that actually involves making changes to on realistic operating system code?
It looks roughly the same as when I took 15 years ago, except they switched to riscv from x86. Honestly, what you're describing sounds too difficult for a first assignment. Implementing irq handlers or syscalls on an existing codebase is far more realistic, plausible, and useful.
At the risk of getting further off-topic: what sort of system calls did they have you implement? I’ve never done but a tiny bit of kernel hacking and that sounds like a good exercise, but I’m not sure what would be a good first syscall to add.
I don't know… people were lonely before LLMs. And, they're right, this is a question one could easily paste into a frontier model and easily get back info that's way more useful than the significant majority of blog posts or replies would give! shrug But also I'd still like to hear what fooker has to say!
Parallels will run a VM that can (manually) boot bsd.rd from the EFI shell if you stick BOOTAA64.EFI and bsd.rd on a FAT32 GUID formatted.dmg, connect it to the VM, then boot EFI shell.
Type:
connect -r
map -r
fs0:
bootaa64.efi
boot bin.rd
Then you'll be in the OpenBSD installer, having booted an OpenBSD kernel.
My point is that as long as OpenBSD can boot like Linux, you just have to tell whatever VM front-end you’re using that you’re booting a Linux but give it an OpenBSD kernel and RAM disk.
Traditionally BSD has booted very differently than Linux, because Linus adopted the same boot process as MINIX when he first developed it (since he was actually using the MINIX boot blocks at first).
BSD has historically used a bootstrap that understands V7FS/FFS and can load a kernel from a path on it. MINIX takes the actual kernel and RAM disk images as parameters so it doesn’t need to know about filesystems, and that tradition continued with Linux bootstraps once it was standalone.
At least as of the last major macOS release, that will not work, because the PCIe LSI SCSI HBA driver doesn’t have the extra stuff needed to support external PCIe.
It’d be a pleasant surprise if Apple implemented that for macOS 26 but I wouldn’t hold my breath.
Interesting... What bothers me is that you'd think that with Mac Proc M2 having advertised support for "storage" cards and lots of PCIe slots, at least some SCSI HBA's would have drivers?
The SCSI protocol driver on macOS is there mostly for USB devices speaking the enhanced storage protocol and similar use cases. That’s how a USB-SCSI adapter from 1999 actually still works on modern macOS.
The PCIe SCSI card driver on macOS is for LSI32032 and related cards, and at least as of last year’s release only works on an internal PCIe slot on a Mac Pro, not in a Thunderbolt-connected slot in an external PCIe enclosure. (Apple “just” needs to implement some extra functionality to support them in external slots, but they no doubt have lots of competing work to do.)
GBSCSI and ZuluSCSI support “initiator mode” that can be used to either image an attached SCSI disk to a file on an SD card or provide live access to it over USB as a mass storage device—with better performance than the old USB 1.1 SCSI adapters too, which top out at about 750KB/sec.
They’re not really designed to be adapters in that direction anyway; the more intended use is that you use it to image a drive to a file on an SD card, and then use that file with a GBSCSI or ZuluSCSI going forward.
The point is that you can do reads/writes to it on a super-faster SD card reader on your main system, and then also use it with the ZuluSCSI/whatever. USB long ago exceeded SCSI’s data rates.
There’s a huge difference between anti-design bias and calling out Liquid Glass for the garbage human interface design that it is. If anything, it demonstrates a substantial *pro-design* bias because it shows that people actually care about design more than any “party line” here.
If one built a more sensitive head mechanism that floats above the disk, one could (say) load a disk sans envelope/case and take a flux image of it without anything touching the surface.
Then one could use the existing flux processing software (possibly tweaking it) to extract the data.
reply