That the landscape of the internet would look quite different had this come to pass is a given. What it would have looked like is a very open question.
In the 1995 era, Netscape was riding high and had good technology for the time, but had an extreme case of corporate arrogance and very little business-savvy for long term planning. At this point in time, they thought they were invincible and that they would basically lock down the browser and force everyone onto their playing field. Obviously, this didn't exactly work out. They were not even bright enough in this era to be willing to license the browser to be ported to another OS with them still retaining control of the rights -- we sat in a meeting with Andreeson sometime circa late 1995 and tried to get him to agree to a port to QNX (Photon) with us paying for it, and they had zero interest and totally blew us off. About 18 months later they came back to us more or less begging us to do the same thing. Go figure.
Of course, by then we had already teamed up with QNX and helped broker a deal in which they licensed the browser code-base from Spyglass which was developed into the QNX Voyager browser. Of course, this is was also where Microsoft got the IE1 code base from in their infamous licensing scheme of getting Spyglass to agree to give them the license on a royalty basis with Spyglass receiving a payment for every copy SOLD -- and with Microsoft then proceeding to GIVE it away rather than sell it. Spyglass eventually took them to court and won some cash but it was really a mere pittance by that point in time and basically destroyed the company. When we approached them in 95 Spyglass was still smarting from this and more than happy to deal with us (or basically ANYONE who was willing to actually pay cash for license rights).
As others have posted on this forum, the Asus RT-N16 router is one of the best routers ever made and has more capability than most users will ever take advantage of. Probably the only thing lacking from the router is dual-band support.
It has:
1) Four Gigabit LAN ports.
2) Three external DETACHABLE antennas.
3) 2 USB Ports
I have run both DD-WRT on them and Tomato USB -- and personally I find Tomato a bit more stable and easier to live with. The USB support in Tomato is also much better and MUCH easier to configure for Samba filesharing and printer support (i.e. you can do it via the UI). My own personal favorites right now would be either the main Tomato USB branch or the Tomato-RAF fork (which is what I am running).
The only real flaws with the RT-N16 are that it can run a bit warm when under a heavy CPU load (which is generally only the case if you are using it for things other than just as a basic router) and that the supplied AC "wall-wart" adapter is a bit wimpy. Simple fixes -- make sure the room you put the RT-N16 in is air conditioned and don't stack anything on top of it. Also, if you are going to be running a lot of other software on the RT-N16 (or leaving USB powered flash drives plugged in all the time) get another AC adapter with the same voltage but higher amperage ($10 off Ebay). Though it is probably no necessary for most people, it is also very easy to pop the hood on the RT-N16 and add better heatsinks to the chips and processor. I also added a fan on mine.
The reasons I needed to add the extra fan and such on mine is that I have the poor little thing overloaded a bit -- I've got the transmitter pumped up to max (60 is the max setting in Tomato for the RT-N16 -- beyond that the actual measured output curve remains flat), much larger antenna's installed, two large USB flash drives attached for use with Optware and for local storage, and I have loaded Asterisk 1.8 with Google Voice support and it's currently serving as the VOIP server and voicemail system for my home (I've got a couple of Grandstream GXP-1200's IP phones that I use and I also have a couple of old left-over SunRocket MTA6328 Gizmo's that I have unlocked and have pointed at Asterisk and then backwired into my home phone system).
The Asus RT-N16 is a real jewel.
My own experience has born out much of what the author states -- yet he really doesn't go far enough. The problem is less with the new coders and more with the system and what University's and Computer Science departments are teaching (or NOT teaching, as the case may be).
Even since as far back as 25 years ago far too many programs have been aimed at theoretical computing models and don't teach practical design methods -- especially for embedded applications. At the company I used to work for, we specifically would not hire anyone with a Computer Science degree unless they came on board as a contractor for 6 months first (until we could see if they actually had a clue) -- EE's and ECE's we would usually hire outright (though we sometimes regretted it).
The emphasis on people not understanding hardware interfacing in the article is spot on -- I deal with programmers quite often who have absolutely no clue what happens when the code they have written actually runs and tries to talk to hardware (and they have equally poor understanding of assembly code and how compiler theory applies to the translation between a high level language and what actually gets executed).
If you are dealing with Windows or OS X apps that have what amounts to unlimited memory space and an insanely fast processor, this is borderline acceptable (though it still yields horrendous code that is often far more bloated and slower than it needs to be.
To those who say that it is a bad idea for a company to allow their programmers to "waste time" writing good or optimized code, I say, "it all depends on your target market" -- and whether or not you have to support the product into the future.
I personally have worked on a project where we had 3 high level engineers spend 4 months to re-architect code in such a way as to allow us to eliminate a single IC that cost about $0.25. In essence, we spent a man year of effort to eliminate a part that cost less than a quarter -- and it was an EXCELLENT investment and made perfect financial sense. This IC was on our display processing board and went into basically every item we produced (TV sets), on multiple production lines and across basically every screen size. This same design was used (with slight modification) over almost 6 years. In each average year, over 1.5 *MILLION* of these boards were produced and sold -- which means that eliminating that part saved us around $375,000 *per year* (and probably close to $2.5M over the life of the design).
Similarly, I actually spent almost 3 months hand optimizing Keil C code (and hand-coding some routines into assembly, as I can generally do a far better job than the compiler) to allow the code to ship in a micro with one size smaller embedded ROM (at a savings of several DOLLARS per part). We shipped our initial production run with the larger part to meet schedule and then shifted over to the smaller one as production continued.
Other things that current software engineers I run across are completely ignorant of is that there ARE errors in hardware and that there ARE differences between different manufacturers devices -- and they often have to be treated quite differently. I primarily write low level embedded device drivers for a living -- and let me tell you, the number of glitches I see in hardware are legion. So are the differences in parts that are "theoretically" identical from different manufacturers. A good case in point would be when our purchasing department decided to sub a Xicor 24C series I2C EE for an ST 24C I2C EE. They are supposed identical parts, with identical specs, with identical memory capability, etc -- but the Xicor part handled the internal voltage pump differently for consecutive rewrites across blocks of memory cells than the ST part did. The end result was that while the part initially worked, they began failing in the field within a few months -- where some of the original ST parts are still working to this day. There was nothing wrong with the Xicor part, per se, and once we ch
As I said, that is why I said the 8x8 VCP part is a bit iffy in terms of how it relates to this patent.
However, the Chromatic MPACT! series of parts a dedicated GPU capable of general purpose VLIW processing, VGA, and 3D.
In essence, it *was* a dedicated VGA/3D accelerator that could also be reprogrammed to do video decode/encode and general purpose DSP functions. Basically, it was a lot like CUDA, only 10 years before the market was ready for it.
The other thing that is MOST IMPORTANT about this is that Chromatic Research was acquired by **ATI** in the 1999 time frame.
This means that as part of this acquisition, ATI acquired any rights to prior art on this patent!!!
If I could, I would. Unfortunately, very little about Chromatic Research is available on the web.
However, I can verify that, although the project ended prior to any commercial products SHIPPING, we had in lab demos of working H.263 encode/decode being done on a Chromatic MPACT board. Actually, I think I still have one of these old boards around here somewhere. I also saw working MPEG1 accelerated encode being done on an MPACT2 board, though, if memory serves, it could only accomplish I-frame only in realtime, but the code was there for full IBP delayed encoded.
I also actually WROTE and worked with code that did similar operations with both H.263 and MPEG1 on an 8x8 VCP processor. However, the card that used the VCP part was a combo board with a separate Trident 9xx series VGA chip, so it might or might not qualify.
Additionally, I have seen a very similar in house demo of the old Philips TriMedia part doing much the same in terms of video encode/decode.
The biggest point to recognize is this however:
1) Chromatic Research at the least had in-house H.263 and/or MPEG1 encoding on a VGA GPU in 1997.
2) In 1998 the company laid off half its employees and shortly thereafter was acquired by ATI Technologies.
Which means *ATI* has PRIOR ART.
So, I'll do it non-anonymously....
This is very easy to verify.
Go look up either the 8x8 VCP or the Chromatic Research MPACT! series of parts.
Specifically, the MPACT! part was released as a VGA card that implemented in VLIW software 3D, DVD decode, and a Soft Modem (yes, a modem). They additionally had software for doing both MPEG1 video encoding and H.263 video encoding for POTS teleconferencing. I still have a working PCI card that implemented VGA, soft modem, and H.263 encode to allow teleconferencing over a standard phone line using a Windows 95/98 PC.
Slashdot Mirror
That the landscape of the internet would look quite different had this come to pass is a given. What it would have looked like is a very open question. In the 1995 era, Netscape was riding high and had good technology for the time, but had an extreme case of corporate arrogance and very little business-savvy for long term planning. At this point in time, they thought they were invincible and that they would basically lock down the browser and force everyone onto their playing field. Obviously, this didn't exactly work out. They were not even bright enough in this era to be willing to license the browser to be ported to another OS with them still retaining control of the rights -- we sat in a meeting with Andreeson sometime circa late 1995 and tried to get him to agree to a port to QNX (Photon) with us paying for it, and they had zero interest and totally blew us off. About 18 months later they came back to us more or less begging us to do the same thing. Go figure. Of course, by then we had already teamed up with QNX and helped broker a deal in which they licensed the browser code-base from Spyglass which was developed into the QNX Voyager browser. Of course, this is was also where Microsoft got the IE1 code base from in their infamous licensing scheme of getting Spyglass to agree to give them the license on a royalty basis with Spyglass receiving a payment for every copy SOLD -- and with Microsoft then proceeding to GIVE it away rather than sell it. Spyglass eventually took them to court and won some cash but it was really a mere pittance by that point in time and basically destroyed the company. When we approached them in 95 Spyglass was still smarting from this and more than happy to deal with us (or basically ANYONE who was willing to actually pay cash for license rights).
As others have posted on this forum, the Asus RT-N16 router is one of the best routers ever made and has more capability than most users will ever take advantage of. Probably the only thing lacking from the router is dual-band support. It has: 1) Four Gigabit LAN ports. 2) Three external DETACHABLE antennas. 3) 2 USB Ports I have run both DD-WRT on them and Tomato USB -- and personally I find Tomato a bit more stable and easier to live with. The USB support in Tomato is also much better and MUCH easier to configure for Samba filesharing and printer support (i.e. you can do it via the UI). My own personal favorites right now would be either the main Tomato USB branch or the Tomato-RAF fork (which is what I am running). The only real flaws with the RT-N16 are that it can run a bit warm when under a heavy CPU load (which is generally only the case if you are using it for things other than just as a basic router) and that the supplied AC "wall-wart" adapter is a bit wimpy. Simple fixes -- make sure the room you put the RT-N16 in is air conditioned and don't stack anything on top of it. Also, if you are going to be running a lot of other software on the RT-N16 (or leaving USB powered flash drives plugged in all the time) get another AC adapter with the same voltage but higher amperage ($10 off Ebay). Though it is probably no necessary for most people, it is also very easy to pop the hood on the RT-N16 and add better heatsinks to the chips and processor. I also added a fan on mine. The reasons I needed to add the extra fan and such on mine is that I have the poor little thing overloaded a bit -- I've got the transmitter pumped up to max (60 is the max setting in Tomato for the RT-N16 -- beyond that the actual measured output curve remains flat), much larger antenna's installed, two large USB flash drives attached for use with Optware and for local storage, and I have loaded Asterisk 1.8 with Google Voice support and it's currently serving as the VOIP server and voicemail system for my home (I've got a couple of Grandstream GXP-1200's IP phones that I use and I also have a couple of old left-over SunRocket MTA6328 Gizmo's that I have unlocked and have pointed at Asterisk and then backwired into my home phone system). The Asus RT-N16 is a real jewel.
My own experience has born out much of what the author states -- yet he really doesn't go far enough. The problem is less with the new coders and more with the system and what University's and Computer Science departments are teaching (or NOT teaching, as the case may be).
Even since as far back as 25 years ago far too many programs have been aimed at theoretical computing models and don't teach practical design methods -- especially for embedded applications. At the company I used to work for, we specifically would not hire anyone with a Computer Science degree unless they came on board as a contractor for 6 months first (until we could see if they actually had a clue) -- EE's and ECE's we would usually hire outright (though we sometimes regretted it).
The emphasis on people not understanding hardware interfacing in the article is spot on -- I deal with programmers quite often who have absolutely no clue what happens when the code they have written actually runs and tries to talk to hardware (and they have equally poor understanding of assembly code and how compiler theory applies to the translation between a high level language and what actually gets executed).
If you are dealing with Windows or OS X apps that have what amounts to unlimited memory space and an insanely fast processor, this is borderline acceptable (though it still yields horrendous code that is often far more bloated and slower than it needs to be.
To those who say that it is a bad idea for a company to allow their programmers to "waste time" writing good or optimized code, I say, "it all depends on your target market" -- and whether or not you have to support the product into the future.
I personally have worked on a project where we had 3 high level engineers spend 4 months to re-architect code in such a way as to allow us to eliminate a single IC that cost about $0.25. In essence, we spent a man year of effort to eliminate a part that cost less than a quarter -- and it was an EXCELLENT investment and made perfect financial sense. This IC was on our display processing board and went into basically every item we produced (TV sets), on multiple production lines and across basically every screen size. This same design was used (with slight modification) over almost 6 years. In each average year, over 1.5 *MILLION* of these boards were produced and sold -- which means that eliminating that part saved us around $375,000 *per year* (and probably close to $2.5M over the life of the design).
Similarly, I actually spent almost 3 months hand optimizing Keil C code (and hand-coding some routines into assembly, as I can generally do a far better job than the compiler) to allow the code to ship in a micro with one size smaller embedded ROM (at a savings of several DOLLARS per part). We shipped our initial production run with the larger part to meet schedule and then shifted over to the smaller one as production continued.
Other things that current software engineers I run across are completely ignorant of is that there ARE errors in hardware and that there ARE differences between different manufacturers devices -- and they often have to be treated quite differently. I primarily write low level embedded device drivers for a living -- and let me tell you, the number of glitches I see in hardware are legion. So are the differences in parts that are "theoretically" identical from different manufacturers. A good case in point would be when our purchasing department decided to sub a Xicor 24C series I2C EE for an ST 24C I2C EE. They are supposed identical parts, with identical specs, with identical memory capability, etc -- but the Xicor part handled the internal voltage pump differently for consecutive rewrites across blocks of memory cells than the ST part did. The end result was that while the part initially worked, they began failing in the field within a few months -- where some of the original ST parts are still working to this day. There was nothing wrong with the Xicor part, per se, and once we ch
As I said, that is why I said the 8x8 VCP part is a bit iffy in terms of how it relates to this patent. However, the Chromatic MPACT! series of parts a dedicated GPU capable of general purpose VLIW processing, VGA, and 3D. In essence, it *was* a dedicated VGA/3D accelerator that could also be reprogrammed to do video decode/encode and general purpose DSP functions. Basically, it was a lot like CUDA, only 10 years before the market was ready for it. The other thing that is MOST IMPORTANT about this is that Chromatic Research was acquired by **ATI** in the 1999 time frame. This means that as part of this acquisition, ATI acquired any rights to prior art on this patent!!!
If I could, I would. Unfortunately, very little about Chromatic Research is available on the web. However, I can verify that, although the project ended prior to any commercial products SHIPPING, we had in lab demos of working H.263 encode/decode being done on a Chromatic MPACT board. Actually, I think I still have one of these old boards around here somewhere. I also saw working MPEG1 accelerated encode being done on an MPACT2 board, though, if memory serves, it could only accomplish I-frame only in realtime, but the code was there for full IBP delayed encoded. I also actually WROTE and worked with code that did similar operations with both H.263 and MPEG1 on an 8x8 VCP processor. However, the card that used the VCP part was a combo board with a separate Trident 9xx series VGA chip, so it might or might not qualify. Additionally, I have seen a very similar in house demo of the old Philips TriMedia part doing much the same in terms of video encode/decode. The biggest point to recognize is this however: 1) Chromatic Research at the least had in-house H.263 and/or MPEG1 encoding on a VGA GPU in 1997. 2) In 1998 the company laid off half its employees and shortly thereafter was acquired by ATI Technologies. Which means *ATI* has PRIOR ART.
So, I'll do it non-anonymously.... This is very easy to verify. Go look up either the 8x8 VCP or the Chromatic Research MPACT! series of parts. Specifically, the MPACT! part was released as a VGA card that implemented in VLIW software 3D, DVD decode, and a Soft Modem (yes, a modem). They additionally had software for doing both MPEG1 video encoding and H.263 video encoding for POTS teleconferencing. I still have a working PCI card that implemented VGA, soft modem, and H.263 encode to allow teleconferencing over a standard phone line using a Windows 95/98 PC.