geoff@EDDIE.MIT.EDU@desint.UUCP (02/20/87)
From David Harrison (davidh@ic.Berkeley.EDU): > Personally, I find it interesting that IBM chose to charge customers > anything for "X-Windows" (and a fairly steep price at that), even if it > is for the device-dependent interface. I am sure that a couple of programmers > working for a couple of months could produce a device dependent interface > to almost any bit-blit architecture without too much difficulty. I wonder > whether this will set a trend for other workstation manufacturers who might > find it profitable to charge a hefty price for the device-dependent interface > to a public domain piece of software. Comments anyone? Sure. In the first place, there is a big difference between getting the latest "raw" release of the software from MIT and having a binary that will run on a PC/RT. I don't know what system the RT runs, but if it ain't 4.2, the port is nontrivial. Furthermore, the average PC/RT owner isn't on Arpanet and can't ftp the latest bug fixes from zap.mit.edu. The big problem, however, is the device-dependent interface itself. To start with, it requires kernel mods to support it. Secondly, it is simply not true that a complete interface can be produced in 4 man-months, not when you don't have hardware support. You might be able to produce a complete low-performance interface in that time frame; for sure you can produce an incomplete one (I have). High performance is another question entirely. Read Pike's paper on bitblt in SP&E (Feb '85) for a discussion of the difficulties. Or take a look at libibm in X10.4 -- that's a *lot* of code. Just compiling it to fix a bug is going to take significantly long, slowing development. And the way it's written, it's really hard to exercise every case adequately, even though the use of macros helps quite a bit. As it happens, I am currently in the process of writing a schedule for the development of a supported X product (sorry, can't say for who). It's too early to assign time frames, but it's clearly more than 4 man-months, and we wouldn't be starting from scratch. I assure you that, if I were going to deliver this product to a customer, I would plan on charging a price that made my investment worthwhile. If you find someone's price high, you are welcome to get the sources from MIT and do your own port. If the other people's price is way too high, you might even be able to make a profit selling your port for less. But don't expect people to take an unassembled bicycle, assemble it, repackage it prettily, and deliver it to you for the same price you can get the raw parts for. Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
geoff@ITcorp.com@trwrb.UUCP (02/20/87)
>From David Harrison (davidh@ic.Berkeley.EDU): > Personally, I find it interesting that IBM chose to charge customers > anything for "X-Windows" (and a fairly steep price at that), even if it > is for the device-dependent interface. I am sure that a couple of programmers > working for a couple of months could produce a device dependent interface > to almost any bit-blit architecture without too much difficulty. I wonder > whether this will set a trend for other workstation manufacturers who might > find it profitable to charge a hefty price for the device-dependent interface > to a public domain piece of software. Comments anyone? Sure. In the first place, there is a big difference between getting the latest "raw" release of the software from MIT and having a binary that will run on a PC/RT. I don't know what system the RT runs, but if it ain't 4.2, the port is nontrivial. Furthermore, the average PC/RT owner isn't on Arpanet and can't ftp the latest bug fixes from zap.mit.edu. The big problem, however, is the device-dependent interface itself. To start with, it requires kernel mods to support it. Secondly, it is simply not true that a complete interface can be produced in 4 man-months, not when you don't have hardware support. You might be able to produce a complete low-performance interface in that time frame; for sure you can produce an incomplete one (I have). High performance is another question entirely. Read Pike's paper on bitblt in SP&E (Feb '85) for a discussion of the difficulties. Or take a look at libibm in X10.4 -- that's a *lot* of code. Just compiling it to fix a bug is going to take significantly long, slowing development. And the way it's written, it's really hard to exercise every case adequately, even though the use of macros helps quite a bit. As it happens, I am currently in the process of writing a schedule for the development of a supported X product (sorry, can't say for who). It's too early to assign time frames, but it's clearly more than 4 man-months, and we wouldn't be starting from scratch. I assure you that, if I were going to deliver this product to a customer, I would plan on charging a price that made my investment worthwhile. If you find someone's price high, you are welcome to get the sources from MIT and do your own port. If the other people's price is way too high, you might even be able to make a profit selling your port for less. But don't expect people to take an unassembled bicycle, assemble it, repackage it prettily, and deliver it to you for the same price you can get the raw parts for. Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff