The Flownet article was nice. I got reminded of lots of old networking stuff, e.g., ATM.

From about 1980 to about 2000, LAN technology was a chaotic war. The war part was from all the competitive battles. The chaos was from all the different technologies, often to address some of the issues in the link you gave. There was no cheap, easy, perfect solution.

So, there were the various versions of Ethernet. Also there was token ring. And of course ATM, really intended for voice and video streams. And I forget some of the clever addressing ideas.

The problem was, year by year, all the ideas that looked good one year were swamped just by much faster data rates the next year. Finally, TCP/IP let the lower levels be sloppy, e.g., have dropped packets, out of order packets, goofy packet timing, etc. For streaming (not conversational) video over TCP/IP, just have a lot of data rate (that is, a network with much more data rate than might think would be needed) and buffer at the receiving end.

Flownet looks like a nice solution for a problem that, however, was well on the way to going away due mostly just to much faster data rates.

It's nice that Flownet was developed so nicely on Linux, so quickly, and for so little cash.

But for making a business out of Flownet, I wouldn't have tried: Basically would have to go to some big office buildings with some big LANs running Linux (so that your device driver development would work) and have them convert over to Flownet. But mostly those offices would have been running Windows for which there were no Flownet device drivers. And mostly those offices were busy, at each computer upgrade, riding the Windows, Ethernet, Cisco LAN switch and/or TCP/IP router horses. Flownet would have been a tough sale.

I know; that's easy to see with 20/20 hindsight. But those years, I was using first 4 Mpbs token ring and then 16 Mbps token ring and watching 10/100/1000 Ethernet rise. I could see that token ring was dying. Also dying was IBM Systems Network Architecture (SNA). In IBM Research, I went to lots of research presentations where the speakers were hinting how dumb it was for reliability not to go just end to end as in TCP/IP.

Flownet was a long way from "orders of magnitude" (factors of 10) better. Flownet was aimed at a market with a lot of big, powerful players -- IBM, Cisco, Juniper, and more -- and where the market was in chaos due to the rapid speed increases of Ethernet, the death of dial-up, AOL, Prodigy, and Compuserve, the use of the coaxial cable of cable TV to carry telephone and Internet traffic to SMBs and living rooms, all the legal stuff about sharing the last mile, ADSL, etc.

When the giants are in a chaotic war, looking for critical mass, setting de facto standards, and pushing data rates by 1-3 factors of 10, little guys stay out.

In broad terms, right now is a great opportunity: Get to use HTML as a great user interface well understood by 3+ billion people. Get to develop Web pages that will look good on anything from a smartphone to a work station with a Web browser up to date as of about 10 years ago. Get to exploit the Internet which for the more developed countries can easily supply 10+ Mbps data rates to everyone, fixed or mobile. Get to use Windows or Linux for Web servers, and using commodity motherboards and processors can build one heck of a Web server for $1500. Can put that Web server in nearly any room in the industrialized world that has a cable TV connection. Are just awash in powerful, often quite cheap or free infrastructure software from operating systems, data base managers, Web server and page tools, language processors, communications, etc. E.g., now the Ethernet, cable TV, ISP, Internet backbone connections and TCP/IP stack software are nearly universal and rock solid.

Now get just to build on these resources and get to avoid developing them.

Now, just think of something good to do with these resources, along the lines I outlined.

In particular, now get to stay the heck away from developing hardware, fighting industry standards, writing device drivers, hanging on by fingernails as processor clocks and data rates are increasing by more than an order of magnitude, developing your own user interface (as AOL tried/had to do), etc.