I've known for some time now not to trust media formats to remain easy to access as time goes on. Floppy disks, ZIP disks, SCSI…
So nice the home movies are now in the cloud (and on USB drives as additional backup).
For HD DV tapes there's also HDVSplit [2].
[0] https://www.videohelp.com/software/DVIO
This is very much incorrect. Maybe the subsystem wasn't built into a custom kernel you're using?
edit: google says improvements through 2026, support through 2029
But yes, it will be supported through 2029, and then after that, it could remain in the kernel longer, there's no mandate to remove it if I'm reading the maintenance status correctly: https://ieee1394.docs.kernel.org/en/latest/#maintenance-sche...
> [After 2029, it] would be possibly removed from Linux operating system any day
An Ubuntu support page says eth1394 has been removed from the kernel since version 2.6.22.
Edit: This was a VERY old laptop. I think it has a 32 bit processor. Maybe that confounded the issue.
If the job is a one-time transfer to get files from old media to new media, is there any reason not to use an old Linux kernel on (non-RPi) compatible hardware that had IEEE 1394 enabled by default instead of compiling a new kernel for RPi with IEEE 1394 enabled
I have a long-in-the-tooth investment in Fireware audio devices (Presonus) in my studio - 19” rack interfaces with 10 I/O’s, as well as the StudioMix mixer with 20 or so .. I’ve been keeping an aging iMac around to use all of this with and it still just plain works, but having the option to replace it with an rPi is really appealing. The system is mostly used for tracking, so having REAPER on the rPi, connected to all that FireWire gear, just seems such a nice idea…
I wonder what the load will be like, though? Can the latest rPi with PCI hat and Firwire interface handle 40 channels of audio over FireWire, I wonder? I know the issue would mostly be SD-card write speeds and so on .. maybe this disqualifies the rPi - but certainly there are other ARM-based SBC’s that this same technique could be applied to ..
For better performance, I'd plug in a USB SSD (USB 3.0 can put through 300 MB/sec or more), or even use built in Ethernet, good for writing 100 MB/sec out to a NAS or another networked computer.
But since Raspberry Pi launched their own microSD cards, I've been buying them. They haven't failed me yet and are pretty fast.
I don't hammer them with I/O though. For heavy writes, I'd consider Sandisk's higher tier cards (esp. Extreme Pro), which I use in my cameras and never managed to break one.
Yeah, its just a dedicated DAW in the rig, used only for recording multiple tracks for later transfer to other modern machines for further work ..
In the kernel, the last commit in the IEEE 1394 area was a month or so ago—it's not 'active' maintenance, but its definitely being maintained, and is quite stable in my testing. (Thanks a ton to the current maintainer, who's going to go through the 3 year process of sunsetting full kernel support, and coordinating that with external projects!)
Every Apple device from the late 90s to 2012 had FireWire. Most Sony PCs from the late 90s to 2009. Google estimates that at over 100M systems with FireWire. There were 50M Zip drives, in comparison.
I know I should probably move on, but I have a lot of FireWire block devices and video equipment. The disk/disc drives can be moved to USB, but the video equipment cannot.
And floppy support is needed for cloud-init, heh.
[0]https://ntrs.nasa.gov/api/citations/20060009084/downloads/20...
https://github.com/torvalds/linux/commit/0d6dd4738dbcc32b60c...
> Linux will likely drop support for IEEE 1394 in 2029
Good to know!
Some ancient hardware which is still actively being used and which has plenty of maintainers willing to keep it up-to-date will stick around.
A driver of only a few years old with roughly zero drivers, no maintainers, and which forms an obstacle for other work? That'll be gone very quickly.
And more disappointed that distributions especially Debian the "universal operating system" has dropped support for i586 already (and is dropping support for i686)
Open-source doesn't have the same pressures of commercial software from Apple or Microsoft. I really love the idea of obsessive, perfectionism approach of providing indefinite hardware support to obscure old hardware (but especially once-popular old hardware), with adequate automated testing suites to test ancient hardware.
Maybe with agentic AI coding we'll be able to expand support windows, and even bring back hardware support for older hardware.
Look at who contributes to the Linux kernel. We'd never have "secure" boot or any of that hostile lockdown stuff if it wasn't tainted with commercial interests pushing their agenda.
To be fair, there is value to be had in reasonably trustworthy cryptography and computing. As long as you can enroll your own certificates in the secure-boot trustchain, you can have a device where you can be reasonably certain that, even assuming an evil-maid attack, as long as your computer is powered down, it is protected against a wide, wide class of attacks.
And for some people, that matters. Even in the US, greetings go out to ICE.
Open source has a pressure that's often even more difficult to overcome: limited spare time from volunteer maintainers. Volunteers are usually drawn from the pool of users. There aren't many i586 users left, so the pool of volunteers is small enough that there's no one able or willing to maintain Debian for it.
If you're that disappointed, step up to maintain the i586 port! If you're unable or unwilling to do so, then you have your answer, generalized across all i586 enthusiasts, as to why they dropped support.
But I suspect that's not really the hurdle: none of the existing Debian developers care enough about it to maintain it, and no one who cares about it enough about it is willing to maintain it.