from the collaboration-what-collaboration? dept.
The rise and fall of FireWire—IEEE 1394, an interface standard boasting high-speed communications and isochronous real-time data transfer—is one of the most tragic tales in the history of computer technology. The standard was forged in the fires of collaboration. A joint effort from several competitors including Apple, IBM, and Sony, it was a triumph of design for the greater good. FireWire represented a unified standard across the whole industry, one serial bus to rule them all. Realized to the fullest, FireWire could replace SCSI and the unwieldy mess of ports and cables at the back of a desktop computer.
Yet FireWire's principal creator, Apple, nearly killed it before it could appear in a single device. And eventually the Cupertino company effectively did kill FireWire, just as it seemed poised to dominate the industry.
The story of how FireWire came to market and ultimately fell out of favor serves today as a fine reminder that no technology, however promising, well-engineered, or well-liked, is immune to inter- and intra-company politics or to our reluctance to step outside our comfort zone.
(Score: 3, Interesting) by Snotnose on Thursday June 22 2017, @06:41PM (19 children)
Back on 2000 or so I worked on the Linux Firewire driver. Was sure the Isochronous feature would usher in a bright future delivering video.
You can call me antisocial. Just don't call me.
(Score: 4, Interesting) by TheGratefulNet on Thursday June 22 2017, @06:48PM (7 children)
I liked the cables and connectors. angled keyed connector that made it obvious which way to insert it; cable had a STRONG 2 wires for power, and shielded pairs for clock/data. I reused the cables and connectors to 'export' i2c from arduino systems, box to box (i2s is usually inside a box but with good cabling you can go outside the box for shortish runs).
there were some good firewire audio boxes on the market, too (high end dacs that came before UAC2 on usb audio).
"It is now safe to switch off your computer."
(Score: 5, Informative) by LoRdTAW on Thursday June 22 2017, @08:06PM (2 children)
There was an article I read a while back from one of the original 1394 engineers. One thing that he talked about was the design of the connector. The retention tabs were on the cable plug, not in the socket like USB. Whereas the USB team bungled the design and put the tabs in the USB socket housing. This means that over time as the tabs wear out, the socket couldn't properly retain a USB plug. Now that usb socket is mechanically damaged. Good luck replacing it. The 1394 plug has the tabs which means that if the plug wears and gets loose, you replace the cable, not the motherboard.
(Score: 2) by kaszz on Friday June 23 2017, @05:30AM
Great! planned obsolescence. Go-buy-new.
It may simple be a intended "feature"..
(Score: 3, Informative) by mojo chan on Friday June 23 2017, @07:35AM
That's now how USB sockets work. The metal shield that provides retention is designed to be stronger than the cable, so that the cable is the part that wears out. In fact, with decades of data we have found that it's the plastic part that holds the contacts which tends to wear out with repeated use, not the metal housing and tabs.
USB-C fixes all of that. Apple went with a simpler design but with the flaw that the contacts are used to guide the cable in when being inserted, wearing them. USB-C has the robust metal housing for guiding and retention.
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 2) by black6host on Friday June 23 2017, @01:38AM (1 child)
I still like it. My last two audio interfaces have been firewire and those have been on wintel boxes. Very low latency, great for recording. When my current one goes I don't know what I'm going to replace it with. One of the things I can do now is to intercept any audio and direct it to record on tracks in my DAW. Very handy when you want to record something that others don't want you to have a copy of. (Interface is a Saffire Pro 24, the USB version, to my knowledge, does not let you capture the audio stream.) I don't use the feature often but when needed it was quite handy.
(Score: 2) by kaszz on Friday June 23 2017, @05:33AM
Build DIY ?
Perhaps there are ready to use chips? or just go the FPGA route otherwise.
(Score: 2) by mojo chan on Friday June 23 2017, @07:38AM (1 child)
Power was one of the reasons that Firewire failed.
For a start it was variable voltage. If you were building a Firewire device you had to accept a variety of voltages, which added cost to your design, and regulate them to something useful. The USB version of any device was always going to be cheaper and "fast enough".
On the host end (the computer) you had to provide at least 12V with significant current, or you could just be cheap and provide no power but then half the Firewire devices wouldn't work... It was a mess.
The cables were more expensive for little gain too. The extra shielding was just additional cost that USB didn't need, because it uses a more robust signalling system.
And the security insanity of having an external DMA port on your computer...
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 2) by kaszz on Friday June 23 2017, @04:12PM
USB uses single ended shielding for some out of band messaging.
(Score: 1, Interesting) by Anonymous Coward on Thursday June 22 2017, @07:27PM
I hate to tell you this, but you didn't deliver.
FireWire loved to corrupt my storage. The device
didn't matter. I could use an IDE drive in a
FireWire converter box, with either of two
different chipsets, and data got mangled. I could
use CompactFlash in either of two FireWire readers,
and again my filesystem was corrupted.
USB just worked. I prefered slow-ass USB 1.1 even.
(Score: 2, Interesting) by Anonymous Coward on Thursday June 22 2017, @08:34PM (5 children)
I kind of liked Firewire, but it was a huge security risk that I don't think most people realized. Or at least non-technical people. The first time I used it for networking and had a device plugged into one computer pop up for use on the other, I realized just how dangerous the technology was.
Which is a shame, because that very aspect of it made it great for debugging frozen computers.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @08:47PM (1 child)
Well that just seems like a driver update was needed.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @09:25PM
You're missing the point, if it needs an updated driver, that's still a security problem. It's just that the incident underlined what a security problem the bus was.
(Score: 1) by Ethanol-fueled on Thursday June 22 2017, @11:39PM
I assume you're referring to DMA? Live forensic analysts liked it too, but not necessarily for its speed.
(Score: 2) by kaszz on Friday June 23 2017, @05:40AM
There could been some switch implemented for restricted use?
Ie only allow remote memory access outside of specified memory range if said switch is on.
(Score: 2) by TheRaven on Friday June 23 2017, @08:17AM
sudo mod me up
(Score: 2) by TheRaven on Friday June 23 2017, @08:24AM (1 child)
Isochronous was a killer feature for tape-based DV cameras, which would write data from the tape to FireWire at a fixed rate and had minimal buffering on the device side. Stutters writing to disk were fine, because the host could buffer in RAM, but any delays writing to the interconnect meant dropped data and video corruption. USB-2 introduced an isochronous mode, which removed FireWire's advantage here and a year or two later cameras started using Compact Flash instead of DV tapes (I still have a small stack of DV tapes still in their packaging as a result of not spotting this transition early enough).
I always felt the biggest missed opportunity with FireWire was Apple not allowing the iSight to connect directly to the iPod. My 20GB iPod had double the capacity of a DV tape (and could dump the contents to a computer a lot faster than any DV camera I used). For quite a few things I did, filming using the iSight plugged into a laptop was more convenient than using the DV camera and futzing with tapes, but for anything where I needed to move the camera a lot it was impractical to have a tethered camera. A small dock for clipping the iSight to the iPod would have been ideal for a lot of amateur film projects and would have reduced the barrier to entry for a lot of people (the iSight was about £100, the iPod around £200, DV cameras were around £400 - and a lot of people who might have wanted to buy one already had an iPod).
sudo mod me up
(Score: 2) by kaszz on Friday June 23 2017, @04:10PM
That would mean less equipment needs and low cost. Not a Apple thing..
Guess DIY would been a great thing here to workaround Apple.
(Score: 2) by driverless on Friday June 23 2017, @09:47AM
It was backed principally by two companies who are notorious for their gratuitously-incompatible lock-in-enabling technology. It was pretty much predestined to fail as they mutated it to make sure you had to buy from them.
(Score: 0) by Anonymous Coward on Friday June 23 2017, @10:01PM
OMG yes - I was making use of your work but iirc we had custom 1394 drivers for our bus-filling needs. Multisource with one storage destination, where the savings happened by using mostly off the shelf at the destination. Iirc 1394 was incredible, we tried usb2 which nominally was a little worse but iirc technically unidirectionally capped at half and (iirc... just assume that from here out...) we found we got about 1/4 to 1/8 the performance. We could saturate 1394 and basically only lose the excess. What a world of difference, in performance. We had custom 1394 drivers but then mmm maybe in 2001? or 2002? we converted to yours, when all our newer boards started running micro micro linux kernels (except for some cmos(?)->radio speed a2d->1394 chip with a surface mounted control ic, and some power circuitry).
Good times, memory lanes! Thanks for your excellent work, as far as I know that company has grown to 7+ figures of annual income and hundreds of staff, and their core products probably still use that exact same work (never waste such pristine work!)
(Score: 2) by Snotnose on Thursday June 22 2017, @06:54PM (7 children)
Back then I wondered why USB was more popular, FireWire was only a few pennies more and much faster. I was not aware of the fact Apple pulled a dick move and decided they wanted a royalty on every port. Fark em, if I was Intel I'd tell Jobs where to put his cable as well.
You can call me antisocial. Just don't call me.
(Score: 1, Informative) by Anonymous Coward on Thursday June 22 2017, @08:33PM (4 children)
Steve Jobs was at Apple's helm at the time. Assholes will be assholes.
(Score: 2) by meustrus on Thursday June 22 2017, @09:29PM (3 children)
Actually, no. From 1985 to 1997, Jobs was kicked out of the company and it was run by more typical corporate CEOs [wikipedia.org]. Those are the guys that didn't want to take risks on innovation and couldn't decide what direction to take the company.
Not that Jobs gets a free pass for screwing up FireWire licensing. But by that point it had already failed to become a standard.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Friday June 23 2017, @04:48AM (2 children)
I think on the apple side it was G3 or G4 era that they started including it. And except for apple, only Firewire 400 caught on (My 2009 era system has Firewire 400 on it. 800 never made it into the PC space, except as discreet cards AFAIK.)
Having said that, you could safely use firewire for networking, *OR* peripheral devices, but using the same port for both was just asking for trouble. And most firewire devices had a HUGE warning about corruption if you tried to access them from multiple systems simultaneously (since most/all didn't have a method of locking access to the currently in use device.)
(Score: 2) by TheRaven on Friday June 23 2017, @08:27AM (1 child)
Really? I had a little chain of two external disks using FireWire 800 and connected a Mac at each end. The disks were both mounted on one of the machines and the two used IP over FireWire for networking. I never saw problems with this config and I ran it for several months.
Well, yes. Most filesystems are not designed for concurrent access by multiple systems. Don't do that.
sudo mod me up
(Score: 2) by kaszz on Friday June 23 2017, @04:19PM
Adding to the insult.. SCSI had this multiple computers one disc feature too. And people could handle it. Nanny computers sucks.
(Score: 2) by DannyB on Thursday June 22 2017, @08:36PM (1 child)
With Apple demanding a royalty on every firewire port, there was no way I was ever going to use it. Ever. You can have a proprietary connector with royalties, or an industry standard connector with no royalties, or at least very reasonable royalties. Choose one.
Infinity is clearly an even number since the next higher number is odd.
(Score: 1, Interesting) by Anonymous Coward on Friday June 23 2017, @01:19AM
"Here's an industry standard system! Let's all agree to standardize on giving us cash for every implementation!"
Yeah, no. That's Apple technology, no matter what they want to call it.
(Score: 5, Informative) by jmorris on Thursday June 22 2017, @07:18PM (10 children)
There was another reason for FireWire's sudden demise. When somebody realized the downside of a multi-master system that can invoke DMA, every corporate and government entity banned any hardware with a firewire port from being considered for purchase. Now of course we have IOMMU tech that could safely contain the security problems but it is far too late.
(Score: 1, Interesting) by Anonymous Coward on Thursday June 22 2017, @08:07PM (1 child)
Of course, that's also the reason it was the preferred debug connection for Windows kernel debugging until Microsoft finally killed it a few months ago. None of the other transports perform nearly as well, though I'm honestly surprised it was supported for as long as it was.
(Score: 2) by LoRdTAW on Thursday June 22 2017, @08:25PM
Linux kernel had a similar setup.
(Score: 5, Insightful) by LoRdTAW on Thursday June 22 2017, @08:22PM (3 children)
[Citation Needed]
That was not the issue. The issue was Apple asking for per-port royalties and dumb ass industry partners using different names. Sony called it i.LINK, Texas Instruments called it LYNX and Apple used FireWire while a bunch of others kept calling it 1394. And to top it off, it was a two chip solution for a while with separate PHY's and controllers because of the per port fuckery.
Bottom line: It was a great bus but Apple goofed up big time.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @08:37PM (1 child)
Sony's version was pretty much only the inferior 4 pin variety as I recall. I had a laptop back then that had a port included and it was just the 4 pin type. Which was kind of annoying.
But yeah, having it named as Firewire and IEEE1394 as the most common names probably didn't help. But, it's kind of a moot point as it was a massive security problem due to it being wired directly into the system RAM. A great thing if you're a developer trying to figure out why the computer has completely frozen, but a huge security problem for everybody else.
(Score: 2) by LoRdTAW on Thursday June 22 2017, @11:13PM
It was pretty much an actual hardware bus. So like PCI, it could allow devices to bus master so to speak and initiate DMA transfers. That right there was the security problem. But That wasn't much of an issue at first. It was years after release. The big problem that never allowed it to pick up steam was Apples stupidity and per port royalties. At that point why would anyone want to pay for a port that no one was using because it was so new. It just never got the traction it needed, regardless of what security problems there were.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @09:33PM
The cost is the reason FireWire wasn't used for more consumer devices, resulting in peripherals avoiding it because they wanted people to be able to just plug their stuff in without also buying an expansion card. Corporate/government environments are different; they probably wouldn't have cared one way or another.
(Score: 2) by MichaelDavidCrawford on Thursday June 22 2017, @10:19PM (1 child)
I vaguely remember it was called FireLog but I can't find it with Google.
You need two Macs. One of them runs the hack, the other is a stock Macintosh with no special software installed.
Connect them with a FireWrite cable and that stock Mac displays a fireplace with a log burning in it.
Yes I Have No Bananas. [gofundme.com]
(Score: 1) by anubi on Friday June 23 2017, @11:14AM
Could it have been the "firestarter firewire hack" aka "Inception"?
http://www.breaknenter.org/projects/inception/ [breaknenter.org]
Really clever coding...
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by TheRaven on Friday June 23 2017, @08:30AM (1 child)
sudo mod me up
(Score: 2) by kaszz on Friday June 23 2017, @04:05PM
Make it so that the operator must approve the use of the feature. It could be as simply as the BIOS enabling/disabling the feature.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @08:09PM
firewire had the full size and the small connector. The second one was like current mini/micro usb ones, that is: look at it the wrong way and it disconnects.
openfirmware macs, other than running powerpc linux port better than intel pcs, could also boot from external firewire with no issues. Intel PCs felt one generation behind macs at the time. Then came the voluntarily crippled ipod and I smelled trouble. I wish I hadn't been so right.
(Score: 2) by idiot_king on Thursday June 22 2017, @08:45PM (2 children)
...capitalist and libertarian jokers will still say "The free market will fix it!!!!!"
They sure did! Fixed it right into oblivion.
(Score: 1, Insightful) by Anonymous Coward on Thursday June 22 2017, @09:45PM (1 child)
The market interpreted Steve Jobs to be damage, and then routed around him.
(Score: 2) by sjames on Friday June 23 2017, @09:43PM
You misspelled 'rotted'.
(Score: 2) by MichaelDavidCrawford on Thursday June 22 2017, @10:22PM (1 child)
the client code is much simpler for FireWire.
I also wrote an embedded driver for a TI Link Layer chip. That was nasty - the chip had forty 32-bit command and status registers, with some of the commands being just one bit.
But once I got that driver written, it was very easy to make use of FireWire.
Yes I Have No Bananas. [gofundme.com]
(Score: 0) by Anonymous Coward on Friday June 23 2017, @10:09PM
heh 1 bit registers - aka toggles. These are typically used for en/dis-abling peripherals, switching in/out-put lines. Sooooometimes they are tri-state on that one bit!
(Score: 2) by kaszz on Friday June 23 2017, @05:56AM (7 children)
What surprises me is that USB is such a fuckery for a peripheral port..
Couldn't they at least designed without most of the obvious crap?
It is shit!
* Polled 1000 times per second (hello? hello?)
* Half-duplex and back to back congestion that can physically burn the port.
* Relies on a single host at the top of the tree to control the network. All communications are between the host and one peripheral.
* Complex packet content and unusual payload sizes.
* Electrical single ended signaling for out of band indications.
* Limited to a maximum of 5 meters.
* A complete mess using hubs with different USB versions.
* Weak power at 2.5 watt.
* No electrical isolation.
* Mechanically weak connectors.
Now there are newer versions of USB. But it will always be stuck with the shitty legacy because you can't know what will be plugged in.
(Score: 2) by Immerman on Friday June 23 2017, @03:42PM (6 children)
Not that I'm a huge fan of the USB design, but...
> Polled 1000 times per second (hello? hello?)
Seems outlandish by human reference frames, but to the computer that's only once every few million cycles... Granted an interrupt-based design would be even more efficient.
>Relies on a single host at the top of the tree to control the network. All communications are between the host and one peripheral.
That does simplify things dramatically on the device side, which given the plethora of crappy barely-compliant-enough peripherals out there, is probably a good thing. Also sidesteps a lot of security and compatibility issues - for example you can be sure your phone and PC aren't corrupting your external hard drive by modifying the file system simultaneously.
> A complete mess using hubs with different USB versions.
Really? I've had whole "trees" of USB hubs of various ages connected and never encountered any problems. Obviously everything downstream from and old hub would be limited to the old standards, but that's true of pretty much anything.
(Score: 2) by kaszz on Friday June 23 2017, @04:03PM (5 children)
The polling is an issue because it causes latency. And when there are many devices on the bus on different hubs to complicate matters that multiplies.
Single host at the top of the tree to control the network makes it impossible to relieve the controller as a I/O bottleneck. And adds latency. If a feature is a security problem, then make it conditional to operator approval. Not impossible.
Mixed USB version cause some trouble when it's doing protocol translation.
(Score: 0) by Anonymous Coward on Friday June 23 2017, @05:04PM (1 child)
Sure, they should poll faster. 1000 Hz is borderline for music.
The UHCI interface is also kind of defective. The polling should happen fully in hardware, without needing to involve the OS.
6250 Hz, 8000 Hz, or 8192 Hz, or 10000 Hz, or 11025 Hz, or 12000 Hz, or 12500 Hz, would have been much nicer. (with various different clock compatibility tradeoffs)
But of course affordable chips (like mice and keyboard chips) were slow back in the day, so the sort-of-acceptable 1000 Hz was chosen.
(Score: 2) by kaszz on Sunday June 25 2017, @02:16AM
They could have allowed an option to specify faster polling speed. But then Winteloys and foresight are incompatible as proven by history..
(Score: 2) by Immerman on Saturday June 24 2017, @03:09PM (2 children)
True. But then USB was really designed as more of a peripheral bus initially, for use in applications where latency was basically a non-issue. You're not going to notice 1ms of latency in your mouse, keyboard, or external floppy drive. Even today it's a rare situation where it's going to matter, though granted it's a pretty lousy interface for a data-heavy simulation datastore or other latency-constrained application.
(Score: 2) by kaszz on Sunday June 25 2017, @02:23AM (1 child)
It's braindead by design. Any signal measure and characterization device will easily suffer. And it's not that it would cost a lot to make it sane.
(Score: 2) by Immerman on Sunday June 25 2017, @01:45PM
Only if the device requires real-time feedback from the PC it's feeding data to - so long as it's only reporting what it measured, a few ms of delay in getting the information is probably irrelevant. And if you're trying to precisely synchronize between devices then polling versus interrupts is irrelevant, what you need is a shared clock (which, honestly, I have no idea if USB provides in a useful manner)
As for not costing a lot to make it sane - maybe not in relation to a piece of signal processing equipment, but it would cost quite a bit more in relation to a $1 mouse (or $5 back when the standard was first created) And changing the standard today would quite likely cost backward compatibility, which is far more expensive.