It is fairly well recognized that most people are seriously risk adverse. For example, given a choice between two bus schedules, one that makes you wait eight minutes every time, and the other that makes you wait five minutes three times and then fifteen minutes once, most people will choose the eight-minute schedule. Yes, they wait less time on average with the other schedule, but they are risk adverse and will "pay" a premium in order to avoid the 15-minute outcome.
I myself am work adverse, and since there are four people on four computers behind the firewall server attached to the cable modem at my house, and one of the four is a teenaged boy whose downloads dwarf the rest of us, I am adverse to trying to define what each person's "fair" share of a metered limit would be, and even more adverse to having to implement it. I will pay more for the flat-rate plan just to avoid those hassles.
This particular techie legend has been around for as long as I've been driving (~30 years), which would mean that the patent protection period has expired and the invention has passed into the public domain. Except, of course, that no one has ever actually shown the 100 MPG carburators to actually work....
How many other potential and real limitations are there on lithography-like processes?
One potential problem that has been solved (so far) is the problem of mechanically positioning things with a very high degree of accuracy. An actual IC is composed of several layers "printed" by several different masks, and each mask must be positioned over the wafer precisely so that the different features of a component (eg transister) are properly aligned.
How accurately can we position things today? How much better can we get? Are there other kinds of process limitations that have to be solved in order to take advantage of smaller features?
Yes, I was assuming that the box would be buffering frames. I don't recall the allowed propogation delay in milliseconds either, but the total length of a coax Ethernet is limited to about a kilometer. I think there's also a minimum spacing restriction as well, coax taps have to be at least two meters apart?
As I recall from other IBM articles, the chief programmer team organization led to startling gains in productivity. But it never became wide-spread at IBM because they had an order of magnitude more projects than they had people who were qualified to be chief programmers. This is probably true at most places...
Today in my PC I can have a full resolution frame grabber (about $50!), a processor that is fast enough to compress in real time, and a disk that is big enough to store the results. It's sort of out there at the leading edge, but it's feasible. Tivo and Replay deal with the processing problem (made more acute since they need to do simultaneous encode and decode) by using a hardware encoder to do the compression but soon enough it will be affordable to do it with software. Converting from digital on the cable to analog NTSC and back to digital costs you one or two dB in signal-to-noise, which is barely visible to trained viewers. So with negligible degradation, I can still make a digital copy of the content.
Unless the studios and networks can get rid of analog altogether, I'm always going to be able to make reasonable digital copies using the above kind of equipment.
The pencils that I find really amusing are the mechanical ones that are made to look like the classic yellow No. 2 wooden pencil. The lead feeds automatically as you use it, and can't be pushed back up into the body, so it marks on the inside of bags and pockets like a real wooden pencil too.
This could be the beginning of my worst-case scenario from the break-up of MS into OpsCo and AppsCo. Of course, it could still work even if they don't get busted up.
C# turns into real middleware. Under Jackson's remedy terms, it belongs to AppsCo; OpsCo is not allowed to do middleware. Through the use of decent automated tools, AppsCo ports major applications, starting with the Office suite, to C#. Now you have to have C# on your machine, at least the runtime, to run Office. Other applications follow.
AppsCo announces C# for Linux. Now Office runs there, and then more AppsCo apps run there, and pretty soon most desktop Linux boxes have C#. Repeat for Macs, Solaris, etc.
AppsCo provides the C# runtime to other apps companies for free distribution. Tools for conversion from Windows to C# are made available at reasonable cost (at least initially). Other app companies begin porting rapidly to C# in order to get in on the multiplatform wave.
Unable to compete on the merits of Windows as only an operating system, and with flagging sales as servers and desktops move to Linux and elsewhere (now that the application barrier to entry has gone away), OpsCo is out of business in five years...
Of course, the C# middleware has lots of undocumented APIs that only AppsCo can take advantage of, and when necessary they can move major pieces of key applications into the middleware...
I would be afraid of it working the other way 'round -- MS the application company creating a middleware layer that all their apps depend on, and that they give away, and port to a variety of other operating systems (eg, Linux). Others are allowed to make use of the middleware and bundle it with their apps, and because of the application dominance, this middleware quickly becomes universal.
Then we find out that there are a bunch of hidden APIs in the middleware that only MS the app company knows about that makes their apps run better than anyone else's... deja vu! And the app company has managed to get rid of a lot of crufty old code and now runs on platforms with reliable file systems, decent task scheduling, etc.
A couple of years ago I had a job that involved taking a variety of demonstrations around the country to show the benefits of cable modem service. One of our demos was of networked computer games. One of those games was a multiplayer motocross race. The physics of the jumps was visually very good.
About one person in four had some problem with nausea while playing the game. No one ever actually puked, but one woman came pretty close. Closing your eyes usually corrected the problem almost immediately. Based on fuzzy recollections of various classes and readings, our conclusion was that the problem involved conflicting visual signals (I'm at the top of a jump and should be in free fall) and the signals from the inner ears (I'm just sitting in a chair at one gravity).
I guess I would tend to agree with Rob, if systems research is fairly narrowly defined to operating systems on single machines. The "research" being done on OSs on single machines does seem (for the most part) to have the problems he describes -- narrow, derivative, measurement-oriented, etc. Possibly useful, but not big or bold.
I also agree with him on the possibilities for doing different things, particularly component architectures and distributed stuff. I believe that in the business I'm in (future cable television networks), there are lots of problems involving components and distribution that don't have known answers. Problems that, in particular, involve heterogeneous collections of systems.
And finally (I can't believe I'm about to say something marginally nice about Microsoft), I think you might make a case that Microsoft has been doing innovative work in the component and distribution spaces, if you leave out the heterogeneous part. ActiveX, scripting, parts of the Office suite and the browser available to other parts, etc. You can argue that they didn't do all of the proper research before they rushed it into product -- if they had, they would surely have included a security model in there somewhere. You can argue about that Visual Basic sucks as a language, but there are a lot of VB components available for free or commercially. They may have done it badly, but they have done some new things.
As I recall from some PBS program, DeBeers the large diamond comapny does not operate (ie, sell diamonds) in the US because they are clearly in violation of US antitrust law and would be subject to prosecution. As a result, US jewelers must go to countries where DeBeers does operate, purchase their diamonds, and then the US company does the importing. I believe that the warrenty, etc, that you get when you purchase the diamond in the US is from the US company -- you have no access to DeBeers itself. To avoid US antitrust law, Microsoft would also have to avoid operating in the US.
So presumably a US company would go to Canada and buy copies of the Microsoft product, import them to the US as the property of the US company and then resell them. If the US company chose to rip out pieces and package in new things before reselling, could Microsoft get any court to enforce the license terms forbidding such changes? The violation would have occured in the US where the license is (presumably) illegal...
Over the years, I have invested a great deal of time and money into the skills needed to pursue my chosen career. That's probably true for most working/. readers as well. I know that most professional musicians have made the same, if not larger, investments in learning the skills that they need. In all cases, be it music or software development, some creative talent and a lot of hard work produce something which (at least some) other people find useful.
Artists (and other creative people) are entitled to receive a monetary return on their investment in acquiring valuable skills and creating useful stuff, if they so choose. Copyright is about protecting the creators' rights to such returns. Some creators don't want/need to make money and distribute their creations freely -- I've done that in at least one case, but not in all cases. My choice, not anyone else's.
To those who believe that using Napster to distribute copyrighted material without permission of the creator is okay, put yourself in the artists' position: spend years acquiring the skills, lots and lots of hours and effort producing the work, and now someone claims that you're not entitled to compensation for any of that work. I'd certainly be pissed off about it!
Should the Internet be a platform that allows an artist to distribute his/her work and receive fair payment (as determined by the artist) for it? Absolutely! But that's not what Napster does, is it?
An OO language requires that I think about aggregating related attributes (objects), a restricted set of operations that can be applied to those (methods), and the relationships between objects of similar and dissimilar types. Encapsulation of the actual data and use of a restricted set of operations to manipulate them helps get better results since it's harder to "cheat" in the sense of reaching across and tweaking some value in an unrelated structure, so you have a better chance that your objects' collective state satisfies all the necessary invariants after an operation. Good programmers have always done these things even without OO languages, although it tends to involve a lot of personal discipline.
Rigorous enforcement of these principles by the language/compiler makes other things possible. Code reuse in the small by inheritance or delegation (depending on whose model you like), although very little of what I work on seems to benefit from inheritance. Code reuse on a larger scale by components. And it's certainly easier to deal with things like
this.action(parms)
than it is to handle a whole bunch of things like
action_class(this, a) action_class2(this, a, b) action_class3(this, a, b, c)
and so on. Late binding allows more nice stuff than early binding, at the cost of some efficiency, etc.
I count all of this stuff as "thinking about data" and believe that an OO language requires that you spend more time on it. You appear to think that an OO lanuage gives you something different. Care to expand on that a bit?
One thing I believe I've learned in 25 years of coding is that your data structures are really important. I've written my share of spaghetti code, and it always results from badly organized data. Too much global data, failure to use reasonable structures, using the wrong structures, etc. Fortunately, much of the code I write these days is used for exploratory purposes and I get a chance to rewrite some of the bad parts. And the only times that the code ever really improves is when I restructure the data.
One of the good things about OO languages (and I'm not particularly fond of OO) is that they make you think about your data more. OO is not a silver bullet, though, since it's certainly possible to use one to organize your data badly. No language is a substitute for an experienced developer with some talent for organizing data in the right way for the particular project.
Of course, this is not a new concept. Fred Brooks said it nicely in The Mythical Man-Month, a book which should be required reading for everyone who does software development, and more so for people who manage development efforts.
I worked at Bellcore after AT&T was broken up in 1984, in an organization that wrote requirements for the regional Bell companies' networks. We were required to make those requirements available to all parties on an equal basis. Another part of Bellcore wrote support software based on those requirements in competiton with other companies. Naturally, the Bellcore developers wanted access to early versions of the requirements, and knew the people writing the requirements, so we got lots of calls from the developers.
Under the terms of the breakup, we had to keep copies of every version of every document we wrote for seven years. These records, as well as people's paper and computer files, were subject to legal search in cases where we were accused of providing early information to any vendor, including the Bellcore developers. Failure to keep the records properly was a criminal violation. Giving out early info was a criminal violation.
Everyone who was hired at Bellcore received training about these conditions within their first 10 days on the payroll. Everyone received annual training, just to refresh our memory, and the instructors always closed the day with the reminder, "If you violate the law, you go to jail." The DOJ did come in and check records in response to complaints by outside parties about improper Bellcore behavior. The threat of 18 months in a federal prison and a felony conviction on my record provided added incentive to behave properly.
If a Microsoft breakup requires that the different parts do not share private information, it is certainly possible to establish record-keeping practices that will make it possible to track down illegal sharing. And after the first set of developers go to jail for either (a) improper sharing or (b) improper record keeping, I'll bet that it never happens again.
One of the problems with the Bellcore situation was that with potential violations occuring because of the interactions between two parts of the same company, the DOJ and the court were in the long-term business of watching what was going on, which they did not like. I believe that the market forces mentioned above will work against conspiring by multiple former-Microsoft companies within a year or two, but only if they are different companies! If they are just different divisions within the same company, where there is a possiblity of increasing total profit by reducing the profit of one organization (ie, don't publish Office for Linux because the increased Office profits are less than the losses suffered by Windows), then the DOJ and court are stuck in the long-term auditing business.
Heinlein's "Time Enough for Love", where a copy of your current state can be copied into a younger cloned body, or into appropriate self-aware computer hardware. More interesting is the case of the self-aware computer who is going to be copied into a human, and since the brain only has like 1% of the storage capacity of the computer, has to decide which memories to take with and which to dump.
You can get the specs, but the last time I looked you have to agree that you won't use them to build a product that does the same functions -- that is, you can't use the specs for.doc to build a word processor. I still claim it's not an open standard -- MS can change it arbitrarily, without notice, and has done so repeatedly in the past.
This is indeed the part that I find incomprehensible about businesses: that they would allow a vendor to tie up the business' own data in proprietary secret file formats. If my data are stored in an open format, then there can be competitors in the particular application market. If storing documents, spreadsheets and presentations in a standard open format were a requirement, Office (and all of its competitors) would be priced much lower because of competition. I personally think that this is at least as important as open source. I may eventually choose an open source application to manipulate the data for the reasons that Alan gives, but I also have the option of choosing between multiple closed apps that may have their own set of advantages.
I actually think the automotive analogy is closer to this (open data standards) than it is to open source. All of the apps (cars) can use the same data (roads). Open source seems more like saying "I can replace the piston rods with something different if I want to."
Slashdot Mirror
It is fairly well recognized that most people are seriously risk adverse. For example, given a choice between two bus schedules, one that makes you wait eight minutes every time, and the other that makes you wait five minutes three times and then fifteen minutes once, most people will choose the eight-minute schedule. Yes, they wait less time on average with the other schedule, but they are risk adverse and will "pay" a premium in order to avoid the 15-minute outcome.
I myself am work adverse, and since there are four people on four computers behind the firewall server attached to the cable modem at my house, and one of the four is a teenaged boy whose downloads dwarf the rest of us, I am adverse to trying to define what each person's "fair" share of a metered limit would be, and even more adverse to having to implement it. I will pay more for the flat-rate plan just to avoid those hassles.
This particular techie legend has been around for as long as I've been driving (~30 years), which would mean that the patent protection period has expired and the invention has passed into the public domain. Except, of course, that no one has ever actually shown the 100 MPG carburators to actually work....
One potential problem that has been solved (so far) is the problem of mechanically positioning things with a very high degree of accuracy. An actual IC is composed of several layers "printed" by several different masks, and each mask must be positioned over the wafer precisely so that the different features of a component (eg transister) are properly aligned.
How accurately can we position things today? How much better can we get? Are there other kinds of process limitations that have to be solved in order to take advantage of smaller features?
Yes, I was assuming that the box would be buffering frames. I don't recall the allowed propogation delay in milliseconds either, but the total length of a coax Ethernet is limited to about a kilometer. I think there's also a minimum spacing restriction as well, coax taps have to be at least two meters apart?
As I recall from other IBM articles, the chief programmer team organization led to startling gains in productivity. But it never became wide-spread at IBM because they had an order of magnitude more projects than they had people who were qualified to be chief programmers. This is probably true at most places...
Today in my PC I can have a full resolution frame grabber (about $50!), a processor that is fast enough to compress in real time, and a disk that is big enough to store the results. It's sort of out there at the leading edge, but it's feasible. Tivo and Replay deal with the processing problem (made more acute since they need to do simultaneous encode and decode) by using a hardware encoder to do the compression but soon enough it will be affordable to do it with software. Converting from digital on the cable to analog NTSC and back to digital costs you one or two dB in signal-to-noise, which is barely visible to trained viewers. So with negligible degradation, I can still make a digital copy of the content.
Unless the studios and networks can get rid of analog altogether, I'm always going to be able to make reasonable digital copies using the above kind of equipment.
The pencils that I find really amusing are the mechanical ones that are made to look like the classic yellow No. 2 wooden pencil. The lead feeds automatically as you use it, and can't be pushed back up into the body, so it marks on the inside of bags and pockets like a real wooden pencil too.
C# turns into real middleware. Under Jackson's remedy terms, it belongs to AppsCo; OpsCo is not allowed to do middleware. Through the use of decent automated tools, AppsCo ports major applications, starting with the Office suite, to C#. Now you have to have C# on your machine, at least the runtime, to run Office. Other applications follow.
AppsCo announces C# for Linux. Now Office runs there, and then more AppsCo apps run there, and pretty soon most desktop Linux boxes have C#. Repeat for Macs, Solaris, etc.
AppsCo provides the C# runtime to other apps companies for free distribution. Tools for conversion from Windows to C# are made available at reasonable cost (at least initially). Other app companies begin porting rapidly to C# in order to get in on the multiplatform wave.
Unable to compete on the merits of Windows as only an operating system, and with flagging sales as servers and desktops move to Linux and elsewhere (now that the application barrier to entry has gone away), OpsCo is out of business in five years...
Of course, the C# middleware has lots of undocumented APIs that only AppsCo can take advantage of, and when necessary they can move major pieces of key applications into the middleware...
I would be afraid of it working the other way 'round -- MS the application company creating a middleware layer that all their apps depend on, and that they give away, and port to a variety of other operating systems (eg, Linux). Others are allowed to make use of the middleware and bundle it with their apps, and because of the application dominance, this middleware quickly becomes universal.
Then we find out that there are a bunch of hidden APIs in the middleware that only MS the app company knows about that makes their apps run better than anyone else's... deja vu! And the app company has managed to get rid of a lot of crufty old code and now runs on platforms with reliable file systems, decent task scheduling, etc.
A couple of years ago I had a job that involved taking a variety of demonstrations around the country to show the benefits of cable modem service. One of our demos was of networked computer games. One of those games was a multiplayer motocross race. The physics of the jumps was visually very good.
About one person in four had some problem with nausea while playing the game. No one ever actually puked, but one woman came pretty close. Closing your eyes usually corrected the problem almost immediately. Based on fuzzy recollections of various classes and readings, our conclusion was that the problem involved conflicting visual signals (I'm at the top of a jump and should be in free fall) and the signals from the inner ears (I'm just sitting in a chair at one gravity).
I also agree with him on the possibilities for doing different things, particularly component architectures and distributed stuff. I believe that in the business I'm in (future cable television networks), there are lots of problems involving components and distribution that don't have known answers. Problems that, in particular, involve heterogeneous collections of systems.
And finally (I can't believe I'm about to say something marginally nice about Microsoft), I think you might make a case that Microsoft has been doing innovative work in the component and distribution spaces, if you leave out the heterogeneous part. ActiveX, scripting, parts of the Office suite and the browser available to other parts, etc. You can argue that they didn't do all of the proper research before they rushed it into product -- if they had, they would surely have included a security model in there somewhere. You can argue about that Visual Basic sucks as a language, but there are a lot of VB components available for free or commercially. They may have done it badly, but they have done some new things.
So presumably a US company would go to Canada and buy copies of the Microsoft product, import them to the US as the property of the US company and then resell them. If the US company chose to rip out pieces and package in new things before reselling, could Microsoft get any court to enforce the license terms forbidding such changes? The violation would have occured in the US where the license is (presumably) illegal...
Over the years, I have invested a great deal of time and money into the skills needed to pursue my chosen career. That's probably true for most working /. readers as well. I know that most professional musicians have made the same, if not larger, investments in learning the skills that they need. In all cases, be it music or software development, some creative talent and a lot of hard work produce something which (at least some) other people find useful.
Artists (and other creative people) are entitled to receive a monetary return on their investment in acquiring valuable skills and creating useful stuff, if they so choose. Copyright is about protecting the creators' rights to such returns. Some creators don't want/need to make money and distribute their creations freely -- I've done that in at least one case, but not in all cases. My choice, not anyone else's.
To those who believe that using Napster to distribute copyrighted material without permission of the creator is okay, put yourself in the artists' position: spend years acquiring the skills, lots and lots of hours and effort producing the work, and now someone claims that you're not entitled to compensation for any of that work. I'd certainly be pissed off about it!
Should the Internet be a platform that allows an artist to distribute his/her work and receive fair payment (as determined by the artist) for it? Absolutely! But that's not what Napster does, is it?
An OO language requires that I think about aggregating related attributes (objects), a restricted set of operations that can be applied to those (methods), and the relationships between objects of similar and dissimilar types. Encapsulation of the actual data and use of a restricted set of operations to manipulate them helps get better results since it's harder to "cheat" in the sense of reaching across and tweaking some value in an unrelated structure, so you have a better chance that your objects' collective state satisfies all the necessary invariants after an operation. Good programmers have always done these things even without OO languages, although it tends to involve a lot of personal discipline.
Rigorous enforcement of these principles by the language/compiler makes other things possible. Code reuse in the small by inheritance or delegation (depending on whose model you like), although very little of what I work on seems to benefit from inheritance. Code reuse on a larger scale by components. And it's certainly easier to deal with things like
this.action(parms)
than it is to handle a whole bunch of things like
action_class(this, a)
action_class2(this, a, b)
action_class3(this, a, b, c)
and so on. Late binding allows more nice stuff than early binding, at the cost of some efficiency, etc.
I count all of this stuff as "thinking about data" and believe that an OO language requires that you spend more time on it. You appear to think that an OO lanuage gives you something different. Care to expand on that a bit?
One of the good things about OO languages (and I'm not particularly fond of OO) is that they make you think about your data more. OO is not a silver bullet, though, since it's certainly possible to use one to organize your data badly. No language is a substitute for an experienced developer with some talent for organizing data in the right way for the particular project.
Of course, this is not a new concept. Fred Brooks said it nicely in The Mythical Man-Month, a book which should be required reading for everyone who does software development, and more so for people who manage development efforts.
I worked at Bellcore after AT&T was broken up in 1984, in an organization that wrote requirements for the regional Bell companies' networks. We were required to make those requirements available to all parties on an equal basis. Another part of Bellcore wrote support software based on those requirements in competiton with other companies. Naturally, the Bellcore developers wanted access to early versions of the requirements, and knew the people writing the requirements, so we got lots of calls from the developers.
Under the terms of the breakup, we had to keep copies of every version of every document we wrote for seven years. These records, as well as people's paper and computer files, were subject to legal search in cases where we were accused of providing early information to any vendor, including the Bellcore developers. Failure to keep the records properly was a criminal violation. Giving out early info was a criminal violation.
Everyone who was hired at Bellcore received training about these conditions within their first 10 days on the payroll. Everyone received annual training, just to refresh our memory, and the instructors always closed the day with the reminder, "If you violate the law, you go to jail." The DOJ did come in and check records in response to complaints by outside parties about improper Bellcore behavior. The threat of 18 months in a federal prison and a felony conviction on my record provided added incentive to behave properly.
If a Microsoft breakup requires that the different parts do not share private information, it is certainly possible to establish record-keeping practices that will make it possible to track down illegal sharing. And after the first set of developers go to jail for either (a) improper sharing or (b) improper record keeping, I'll bet that it never happens again.
One of the problems with the Bellcore situation was that with potential violations occuring because of the interactions between two parts of the same company, the DOJ and the court were in the long-term business of watching what was going on, which they did not like. I believe that the market forces mentioned above will work against conspiring by multiple former-Microsoft companies within a year or two, but only if they are different companies! If they are just different divisions within the same company, where there is a possiblity of increasing total profit by reducing the profit of one organization (ie, don't publish Office for Linux because the increased Office profits are less than the losses suffered by Windows), then the DOJ and court are stuck in the long-term auditing business.
Heinlein's "Time Enough for Love", where a copy of your current state can be copied into a younger cloned body, or into appropriate self-aware computer hardware. More interesting is the case of the self-aware computer who is going to be copied into a human, and since the brain only has like 1% of the storage capacity of the computer, has to decide which memories to take with and which to dump.
You can get the specs, but the last time I looked you have to agree that you won't use them to build a product that does the same functions -- that is, you can't use the specs for .doc to build a word processor. I still claim it's not an open standard -- MS can change it arbitrarily, without notice, and has done so repeatedly in the past.
This is indeed the part that I find incomprehensible about businesses: that they would allow a vendor to tie up the business' own data in proprietary secret file formats. If my data are stored in an open format, then there can be competitors in the particular application market. If storing documents, spreadsheets and presentations in a standard open format were a requirement, Office (and all of its competitors) would be priced much lower because of competition. I personally think that this is at least as important as open source. I may eventually choose an open source application to manipulate the data for the reasons that Alan gives, but I also have the option of choosing between multiple closed apps that may have their own set of advantages.
I actually think the automotive analogy is closer to this (open data standards) than it is to open source. All of the apps (cars) can use the same data (roads). Open source seems more like saying "I can replace the piston rods with something different if I want to."