Once the premium option for data transfers and remote control for high-end audiovisual and other devices, FireWire (IEEE 1394) has been dying a slow death ever since Apple and Sony switched over to USB. Recently Apple correspondingly dropped support for it in MacOS 26, and Linux will follow in 2029. The bright side of this when you’re someone like [Jeff Geerling] is that this means three more years of Linux support for one’s FireWire gear, including on the Raspberry Pi with prosumer gear from 1999.
If you’re not concerned about running the latest and greatest – and supported – software, then using an old or modern Mac or PC is of course an option, but with Linux support still available [Jeff] really wanted to get it working on Linux. Particularly on a Raspberry Pi in order to stay on brand.
Adding a FireWire port to a Raspberry Pi SBC is easy enough with an RPi 5 board as you can put a Mini PCIe HAT on it into which you slot a mini PCIe to Firewire adapter. At this point lspci shows the new device, but to use it you need to recompile the Linux kernel with Firewire support. On the Raspberry Pi you then also need to enable it in the device tree overlay, as shown in the article.
With this you now have FireWire 400 support right off the bat, but to use the FireWire 800 port you need to also connect external power to the adapter, which [Jeff]’s Canon GL1 video camera with its FW400 port does not require, so he didn’t bother with that.
Capturing the video from the GL1 via FW400 was done using the DVgrab utility, with a subsequent capture attempt successful. This means that at least until 2029 [Jeff] will be happily using his GL1 camera this way.
Meanwhile over on the Dark Side, you can still happily install FireWire drivers made for older Windows versions on Windows 10 and 11, which is great news for e.g. people who have expensive DAW gear kicking around. Perhaps the demise of FireWire is still a long while off as long as you’re not too picky about the OS you’re running.
I’m curious about the urgency for dropping support all together. I had a misinformed impression that Linux had really long horizons for hardware support. Like, doesn’t it still compile for the original 60mhz 32 bit Pentium from 1993? Surely FireWire products, which include some very high end video hardware from 20 years later, are more likely to see use today?
I suppose it’s a question of ancestry. Much of the Pentium code is probably still applicable to current cpus, while FireWire code is an evolutionary dead end.
It is purely a matter of maintainership and demand.
If a driver or subsystem has active maintainers and an active user base, it stays. If it does not have users, it is just s burden on its maintainers who will likely consider deprecating it. If it does not have maintainers, it just rots as the kernel changes around it and it eventually has to go if no one steps up. The bigger the driver or subsystem, the quicker this happens.
That has always been the only driving force of support. There is no hard policy on supporting things for N years, and sometimes new drivers are added for older hardware than what gets removed.
32-bit support isn’t all that common anymore among distros. I have an old EeePC, that’s 32-bit with very little ram (512mb). I’ve had a hard time finding something that would fit. Gentoo was one solution, but the compile times were awful. 32-bit distros are generally being dropped, and even then if you find one, you’ll be severely limited with packages, which will be few and outdated (on the point of repos, I think gentoo has an advantage because it will always compile the source for your architecture). It’s a bit sad because appart from that, you can still do a lot with two cores and 512mb of ram. And I really liked the size/design of that laptop, it was very handy.
Try https://antixlinux.com/
Works great with 256mb of ram (with gui) and can even install and run on just 64mb of ram. Plus you get access to all the Debian packages and more.
I would say it’s mostly because no-one is interested enough to maintain it.
The current maintainer has decided to do it only until 2029, but it seems they wouldn’t oppose someone else continuing the work https://www.phoronix.com/news/Linux-Firewire-New-Maintainer
As for “keep it until it breaks”.. I think Linux is probably far too important to include completely unmaintained code anymore. At that point you might just as well run an old kernel to have the Firewire support.
Also, nothing is legally stopping anyone from nicking the relevant firewire kernel bits and turning it into a DKMS module or similar (apart from code licensing if you happen to dislike the GPL).
Which would be the ideal fate anyway, since it’d still be accessible to those who need it, but is at the same time distanced from official kernel development.
Linux is dropping a lot of stuff recently, what’s going on?
What happens to the concept that Linux is great for old hardware?
Is planned obsolence the new paradigm in Linux land? What about sustainability?
Dropping Firewire support is as radical as dropping SCSI or IDE support, isn’t it?
Firewire aka i.Link aka IEEE 1394 is an industry standard, just like RS-232.
Also, how about networking? On Windows XP, at very least, it was possible to connect two PCs over Firewire connection.
In the days of 100 Mbit ethernet NICs, Firewire 400 and Firewire 800 were quite a speed upgrade.
Dropping Firewire because of “old hardware” looks like a lame excuse, thus.
The current Firewire hardware still works fine, after all.
Likely will do so in the next 25 years (especially pro equipment, which might be the majority), unless Linux will force the retirement.
I mean, even macOS users are unhappy about the decision to drop it in macOS 26.
While new consumer devices aren’t made anymore, perhaps, it’s perfectly easy to use Firewire on modern Macs via Thunderbolt to Firewire dongles.
A lot of professional audio interfaces (external soundcards) do still use Firewire in favor of USB.
Because it’s simply better in terms of latency, for example.
Up until USB 3.0, USB was an interface for cheap, timing uncritical consumer devices like keyboards and mice.
Firewire and USB had two different use cases up until that point.
Firewire and USB did compare like SCSI and IDE/ATAPI did.
Anyway, it’s simply depressing how much Linux world copies from Win/Mac world.
Back in the 90s, KDE and Gnome always imitated the newest Windows/Mac GUI instead of having the guts to develop something unique.
And now Linux drops hardware support just like the big players?
What’s next? Will Linux drop support for old PCs just like Windows 11 does?
dont forget, this is foss, so the maintainers are getting older also. getting a younger developer interested in That Old Stuff ™ is difficult.
There is a ton of high end pro audio stuff that will be finally obsolete as well, not to mention Film and photo scanners. mist of the time people use age correct computers for them because that is the only setup that works.
What’s the big deal, maybe you want to step in to maintian the driver? Or create a DKMS module out of it?
Both can be true at the same time, it does still support older stuff far better than anything else, but you can’t expect folks to keep putting in the work to support the old stuff forever, especially the unpaid maintainers…
And you can if you really want to still tweak (if needed) and compile the old unmaintained code for anything you like if you really want to, and often it will still just work alongside the most bleeding edge kernel.
Or just do as the CNC machinists, lab equipment users etc are so likely to have done keep on running something obsolete (XP in many cases for years after support was dropped).
I am guessing that someone and that means you Joshua, did not maintain enought driver sourcecode in the kernel. .-)
Olaf
Hm. Counter question – how comes Linux supports so many irrelevant niche architectures all the time,
but same time has no concerns about dropping stuff in a blink of an eye that’s actually useful or has an existing userbase? :)
And why can’t there be external modules anymore? What happened to modprobe?
If it’s still there, couldn’t Firewire be implemented as an external module somehow?
A big issue with Linux is of course that it’s a monolithic kernel with no fixed driver ABI, which is why you need to keep updating those kernel modules and a hybrid kernel like NT6 with fixed ABI can use the same kernel driver for a few decades.
Of course, getting Linus to admit that not having a fixed ABI for drivers was a mistake will happen right after the heat death of the Universe.
It would also mean that almost no new open source drivers would be created anymore. Vendors only do this, because they need to be compatible to the current Kernel,
It would also mean that you can compile that Realtek WNIC driver once and update the kernel without having to plug in the Ethernet to recompile said driver module once again.
Yes, I’m very salty about that.
Firewire is irrelevant and niche to me. What is irrelevant and niche to one person is critical to another. If they were to drop everything irrelevant and niche to focus on what you care about, there would be torches and pitchforks.
That is easy. Someone wrote a driver for a hardware he owns and like to use. For example many years ago I did this for a CD-rom. But a few years later you have a different hardware and not interested in the old one anymore.
Olaf
Hm. Great attitude. I hope Linux devs have no pets or elderly relatives to care for.. 🙄
Would you maintain a driver you wrote in your free time indefinitely? I wouldn’t, unless someone paid me and even then I would prioritize my current projects.
Linux dropping hardware is annoying.
386, 486, firewire…
Yes, but with code donated from Microslop its kernel now supports ＣＯＰＩＬＯＴ ＫＥＹ available on those modern lapslop keyboards.
If Jeff really wants Linux to support FireWire, why doesn’t he volunteer to maintain the drivers? I don’t imagine it would be that hard for someone who can write low-level code and who still has hardware on hand that uses it.
Somebody is currently trying to recreate Firewire support for macOS26+: https://github.com/mrmidi/ASFireWire
It seems he has made already a lot of work, very impressive!
But he also says that you need to have a paying Apple Developper account ($99/y i think) in order to be able to load this new driver in the OS.
Genuine question: what do you have to “maintain” in the code for such an old technlology ? There’s no more evolution or standard revision, no new functionality to add. Since the existing code has been tried and used since a long time now, and is working well, what do you have to do to keep using it with new/future OS versions?
Changes in the kernel change the ways the drivers can talk to hadware/kernel/programs. Older functions are replaced, structures change names, etc.
Then if you want to mantain it, you need to adapt it to the newer code of the kernel.
Never pronounce the “p” in raspberry (wait for it)
https://m.youtube.com/watch?v=FtwWzhwQ2vs&pp=ygUpYm90cyBpbiB0aGUgaGFsbCBob3cgZG8geW91IGtpbGwgYSBnaG9zdD8%3D
If you play brass you know how to razz it up. Be careful if you say the plural of wasp, you may get stung several times, same with that polymath word across the pond. Mathsss. Watch out! Snake!
FireWire controllers had a bunch of exploits back in the day because they could write to system RAM bypassing the CPU. Made them really quick for low latency data transfer, but also vulnerable for stuff they shouldn’t really do.
You can carry on running your old Linux kernel forever. You can run an old Linux in a VM and pass in the PCI firewire device to it, while everything else runs on a newer host kernel. It makes sense to eventually get rid of old hardware support from brand new kernels when people aren’t using it anymore. But it makes me sad for the expensive multichannel audio gear I bought that had firewire connections and would still work today if I had a firewire interface to plug it into.
That is fair enough, but also worth noting that many of us are not going to be old enough or lucky enough to have found this nice firewire gear as this many decades after it went out of production only a fraction of the stuff is still working…
i think “dropping support” is giving people a bunch of crazy ideas…microsoft / apple / google go out of their way to ensure that old software breaks. but linux is open, you can do what you want. You can use an old kernel with an old distribution. You can expend your own effort to make an old kernel work with a new distribution. You can backport new features into the older kernels, or you can drag old drivers into newer kernels. The sky is really the limit.
Dropping 386 support was mentioned, and it makes a great example. No one is actually annoyed at dropping 386 support (they are misreporting their own experience!), because if you ran a modern linux on a 386, you would be bowled over with how bloated it has become. In the grand scheme of things, Linux is still very efficient, but the days where you could fit a kernel and userland on a single 1.44M floppy are long gone. The days where you can easily install Debian on a 170MB HDD from 1994 are long gone…
Except they aren’t! You can still download ancient versions of Debian! You can run 1990s software on 1990s hardware as easily as ever. And if you really, really want to, you can hack modern software (or software from any decade in between) to run on any arbitrarily-limited platform. And all of this hacking is way easier than it was…even leaving AI aside, we just have incredible tools…in the 1995, the kernel source was much smaller but even so you had to be judicious with “find . -type f | xargs grep” — it required too much patience. But today i do global grep across gigabytes of code in less than a second. I can bring up emulated environments for testing that are a thousand times faster than the real thing. And archiving generations of old software on modern terabyte hard disks is sooo easy!
So in 2030, it will be dead easy to use a 1 year out-of-date kernel to access your old firewire devices, but already, the devices themselves will have experienced mechanical / electrical attrition. By 2040, finding modern working firewire hardware will be much harder than finding a 15-year-old kernel. It really, truly, doesn’t matter.
Got any proof? I know pleny of major TOP 500 companies (think NASA, Tesla, NASDAQ, Boeing etc.) who are left in trouble because Linux dropped support for chips which are still used in hardware like Fighter Jets, Civilian Aeroplanes, Radio Aquisition Units, Space Telescopes etc.
Life is not just Google and Apple who want you to buy NEW smartphones every 6 months because they support new “apps”.
No you don’t, like i said: you are misrepresenting their experiences. I assure you that aerospace contractors who are so change-averse that they are using decades-old CPUs are also so change-averse that they are using decades-old software. That’s exactly my point — if you’re exceedingly conservative in one dimension, you aren’t going to want the bleeding edge in another!
Or, if you prefer: citation needed.