Consciousness is composed of the states of the cells in your nervous and endocrine systems (and various associated phenomena). That state is not reconstructible if the information about it is destroyed.
That doesn't say anything about cathedrals having been designed in secret, and it interprets the metaphor in terms of centralization, not secrecy:
"Eventually, Raymond would convert the speech into a paper, also titled 'The Cathedral and the Bazaar.' The paper drew its name from Raymond's central analogy. GNU programs were 'cathedrals,' impressive, centrally planned monuments to the hacker ethic, built to stand the test of time. Linux, on the other hand, was more like 'a great babbling bazaar,' a software program developed through the loose decentralizing dynamics of the Internet."
Since we all know now that any successful software project on the medium or large scale requires centralized control, and that Linux and Mozilla are examples of that, it doesn't seem much is left of Raymond's metaphor. You can no more build a serious program without making a plan and enforcing it than you could build a house that way.
Do you have a reference for cathedrals having been designed in secret?
Raymond's own take on the metaphor is about centralized versus decentralized development.
I also think it is highly arguable that major open source projects are designed in the open. Anyone who monitored the decision-making process by which Mozilla first spurned and then embraced native widgets knows that such decisions are often made by an in-group that is relatively immune to outside pressure. The clannishness of the core Linux developers is even more legendary.
Cathedrals were built in public, not in secret. In fact the whole life of a community would often revolve around the proiject while it was going on.
As for the characterization of the Linux project as decentralized and self-assembling, that's been known to be false for years. Linux is tightly held by a strong central control group, in contrast with the development model expressed in Raymond's essay.
I see. That must be why I'm typing this on a non-Microsoft OS, for which Microsoft nonetheless makes software. I was unaware of the old-time papacy having provided services at Buddhist temples.
I also note that your interpretation of the cathedral and the bazaar is very different from that of others in the thread, which underscores the point that the metaphor is unclear.
Personally, I think Raymond's framing is an attempt to appeal to anti-religious libertarians, which one often encounters in science fiction fandom. Cathedral = religion = bad, bazaar = market = good.
I'm surprised by all the comments that Sterling's speech was devoid of substance. His verbal pyrotechnics may have gotten in the way at times, but that's Sterling's schtick and he's awfully good at it. Any reasonable person ought to have been able to see through the fireworks to his many substantial points, among which were:
Open source and free software are largely about their own subculture and the social aspects of that subculture rather than about software per se.
Software written by and for programmers is unlikely to have mass appeal, but it has powerful appeal to programmers.
Free software and open source will only become relevant to the average user when they start to take users' tastes and concerns into account.
The cryptic and balky nature of current open source and free software is a draw to programmers not only because it reflects their values, but because it's in such a sorry state that there is a trenchant humanitarian appeal to help out. (By implication, better software might reduce the amount of help available, and the movement might become a victim of its own success eventually.)
Another factor drawing programmers to this development model is the lack of responsibility, since they can quit at any time.
Raymond's cathedral/bazaar metaphor does not seem to apply very well, and on examination, it's unclear what he even meant by it. Microsoft is a bazaar company, not a cathedral company. So are most software makers.
People feel increasingly oppressed by commercial software, particularly Microsoft's. They are waking up to the way the software manipulates them against their own interests.
Viruses have in particular been a wake-up call.
Free software and open source are largely imitative rather than innovative, or "piratical" rather than "creative".
Free software and open source have hidden costs, including the cost of needing to become part of a particular subculture to use them effectively.
Information is not free. Information has intrinsic costs deriving from the social context of the information. Information merchants use particular strategies to make it difficult to change established relationships. Among these are restrictive contracts, brand-specific training, search costs, proprietary formats, durable purchases, and loyalty programs.
The open source and free software community is facing a social transition from a small geek subculture to a significant dissident standing. This is going to present serious challenges.
That's scarcely a complete list of the points of substance in this talk. It may not be Sterling's finest hour -- his forte is fiction, after all -- but it is by no means a bunch of insubstantial blather. In fact he touches on many neglected but important issues.
Neither of these statements is true. Red Hat lost money again last quarter, as it always does. Mandrake, based on this announcement, is barely scraping by and may not survive the year.
MS can bluff all they want about piracy, but they know as well as anyone that you can't copyright a look + feel (remember Apple's lawsuit?).
Yes, you can protect look and feel by way of a design patent as well as by other means. Microsoft won the Apple lawsuit because it turned out that Apple had licensed the Mac look and feel to Microsoft in perpetuity for no license fees for Windows 1.0. Smart move, Apple. The reason Windows is able to exist is because it is a licensed clone of MacOS.
Still, even if the two companies are not considering a merger, AOL Timer Warner could license Red Hat for use on PCs or other devices for use with its online service.
They already did something almost exactly like that, and the product tanked, which only underscores your point about how silly it was for the reporter to say such a thing. The device was a Linux box made by Gateway. You can read about it on news.com here and here.
Twenty thousand dollars is, what, two months of the burdened cost of a single mid-range software engineer? Why is this worth an exclamation point? Many organizations pay several full-time programmers to work on open source projects -- any one of these organizations exceeds this tiny donation in a week.
Sorry, you're mistaken. Use cases are part of the requirements capturing process in the Rational Unified Process. The problem is that -- as described in great detail at the Constantine and Lockwood essay I pointed you to -- use cases involve making user interface design decisions, especially regarding sequence of actions, but also including presentation of choices and other matters. Since this is the wrong phase of the process to be making detailed design decisions, and the people making the design decisions are marketers and engineers, not designers, the decisions made are usually wrong. These premature user interface design choices then become locked in for the entire project life cycle.
Your message deals solely with the issue of premature design decisions., You did not engage other equally significant issues: that there is no place for design specialists in the Rational Unified Process, that the notoriously bad design of the Rational tools serves as a (negative) case study in the results of the Rational Unified Process, and that the way that use cases are specified creates user interfaces with a modal order of execution, an approach that violates standards of software design since 1984.
The use case model in the Rational Unified Process leads to terrible user interface design. This is evident in Rational's own notoriously badly designed products as well as in analyses of the methods by such writers as Constantine and Lockwood. Use cases make design decisions before requirements are gathered; they commit to modal sequences of execution which are in conflict with well-established principles of design; and they have no place for the participation of design specialists.
And yet it is what is being practiced in the field. There are intrinsic forces involved in UML that lead in this unpleasant direction. You haven't dealt with those factors or with the way that UML-based specification activity tends to drive out text-based specification in practice. I believe I was sufficiently specific in describing some of these factors.
To respond to some of the comments about my admittedly vague dismissal of UML's value:
It is my strong impression from seeing projects specified with UML that diagrammatic specification has an inherent tendency to be less thoughtful about aspects of a software system for which there is no built-in diagrammatic representation, and that these "semantic" parts of the design of a software system overwhelm in practice the more constrained parts of a system which can be modeled using such formalisms as sequence diagrams.
To take one example, in the creation of a music engine at one company, extensive sequence diagrams were created to show the flow of musical data between various processing components. However, the scenarios for building and installing the engine in a variety of contexts, including web plug-ins and embedded device firmware, were nowhere to be found in the specification. Attempts to get the engineers to focus on these broader usage issues got nowhere, because the incredible specificity of the sequence diagrams seemed to imply that all important questions had already been answered. The questions about installation scenario, while critical to the design of the product, seemed fuzzier and less important because there was no way of expressing them in the specificity of UML diagrams -- they involved more free-form issues and text description. UML created a false sense of concreteness that led to neglect of important issues which could only have been adequately addressed in text.
In another case, a complex nested data structure was to be saved on top of a SQL database. Intricate class diagrams and sequence diagrams for the save procedure were drawn up, but each time a save API was delivered based on these heavily reviewed UML designs, it failed to cover major cases of nesting relationships and had to be reworked from scratch. UML diagrams turned out not to describe the solution at an adequate level of abstraction to deal with the general case of nested saving -- instead, all it could do was break down the problem into some six dozen special cases, rather than proposing general rules. The conceptual questions about what it meant to save a snapshot of a complex data structure in a shared system were never asked and could not be answered at the low level of abstraction provided by UML, and so the design effort for this critical portion of the internal API never succeeded through multiple development cycles.
Thought is a thing that happens primarily in words. Where it can be formalized into diagrams, it is if often worthwhile to do so. However, given the enormous complexity of software engineering problems, this level of formalism is rarely either attainable or useful. Even if we look at highly formal domains such as science and mathematics, published papers tend to be structured as natural-language essays with inserts of formulas and tables, rather than primarily as mathematics with a smattering of natural language. Software engineering is less formal than science or mathematics, not more. Specification should remain primarily a matter of writing in natural language, with diagrams at key points where they are applicable. The labor-intensiveness and false specificity of UML leads to an approach that is the reverse of this, in which what few words remain are subordinated to elaborate diagrams of marginal value. This creates inferior system designs.
I don't find that class diagrams communicate anything that I can't understand better with a description in text, or other methods.
Yep. UML is a way for poor communicators to pretend to design. UML diagrams are notoriously bad at factoring in real-world requirements, exceptions, usage patterns, and user scenarios. In every case I've seen UML used for modeling, it has created systems which looked clean in the diagrams but which failed to function usefully once implemented due to lack of conceptual underpinnings. It will be nice to see this particular documentation fad slip beneath the waves, and people get back to describing what they want to do in thoughtful paragraphs.
Physicist Robert L Forward wrote a popular science style book, Indistinguishable From Magic. The first chapter is titled Antimatter, discussed what antimatter is, how we storeit, produce it, how we could produce it econmonically, how to use it more space travel and more mundance applictions.
He also wrote a book specifically on antimatter, which he renamed "Mirror Matter." It's an utterly ridiculous book that has us all jetting to the moon for weekend vacations in our antimatter-fueled cars by 2005. Yes, that's right, three years from now. Mind you, the book was not science fiction -- it purported to be hard-headed prediction. Among other fascinating revelations: There is actually no possibility of dangerous radiation from antimatter propulsion, because it would only produce harmless pions. (And what do the pions turn into, Bob?) We could reach the nearest star in only forty years with a few hundred kilograms of antimatter, but even though one gram of antimatter is equivalent to a Hiroshima bomb, we don't need to worry about weapons proliferation, because while it could obviously be economically feasible to produce antimatter by the kilogram, it never could be feasible to produce it by the gram! Etc., etc. The sheer idiocy of the book is staggering, and only more so because it seems as if the writer must have known better.
Try walkie-talkies. I used to play with them back when the original series was on.
Babelfish = universal translator
Which, I think, must show that you have never actually tried to use Babelfish to translate a web page.
Taser(tm) = Phaser on stun
Very true, except that it isn't that at all. It's not a ray gun, it has a short range, and it often doesn't work.
2-way videophone = Screen on the bridge
Two-way videophone prototypes were being built back in the 1960's. We had one in our science museum in Columbus, Ohio.
PC = Enterprise computer terminal
Computers in Star Trek have always been comtemporary with the computer technology at the time of production. In the 1960's, they were room-sized or refrigerator-sized. Later they became portable, achieving a laptop form factor during TNG, and a palm form factor in the 1990's. There's no prediction there at all.
Now antimatter propulsion.
Now, not. NASA is not saying this could come on line in less than about a century, and nobody is talking about using it for space warps. Yeah, it may be useful for jetting around the solar system in 2100, maybe even an unmanned long-haul star probe or two around 2150 or so, or maybe not, but it's nothing at all like warp drive.
The main site doesn't say a word about cost, and it casually postulates robotic construction, which is not a currently deployed technology even on Earth. It seems to be ivory-tower science. The CNN and New Scientist pieces just say "billions."
Is there any reason to think that this thing could actually be built for a reasonable cost? Has anyone even tried to come up with a real estimate? Bear in mind how low the estimates have been for our most recent space construction. Off the top of my head I wouldn't be surprised to see a real cost in the hundreds of billions, between dozens of Saturn V launches and the development of entirely new technologies like lunar robotic construction.
There was so much hate in some of these people, too.
Very true. I think the documentary is bound to give short shrift to this unpleasant fact, though. Listen to this utopianism from the pitch: "an entire generation started to grow up online. They knew then what so many are learning now: the thrill of communication with others like themselves, around the country and the world.... They made friendships to last a lifetime. And they changed everything." Yikes. Talk about rose-colored glasses. What about the fact that the BBS world was often a snake pit of casual bans, flame wars, and rigid groupthink?
there were just so many unpleasant folks out there they ruined the experience for everyone. They know who they are, and they didn't contribute shit other than efforts overshadowed by ugly attitudes.
The only thing I disagree with is that "they know who they are." I think the most unpleasant people in the BBS scene were people who thought very highly of themselves and their contributions, and who really believed they were improving things for everyone by carrying out personal vendettas, banning everyone they disagreed with, and leading the charge to label anyone who didn't agree with local consensus as a troll. As usual, the real black hats were the crusaders, and they were convinced they were on the side of the angels.
The problem with Argyll at present is that nobody has (yet) integrated all the pieces in such a way that your average graphic artist can make high quality profiles. The pieces are there, and they're of quite high quality. But (at present) you have to have some serious color science knowledge to ensure that you get good results.
Sorry for any confusion. By my standards, that's a bad user review. It says you can get good color out of the thing only if you're a color scientist. We were talking about the benefits of adding CMYK support to the Gimp in terms of making a competitive desktop publishing system on Linux, and Argyll in its present form falls far short of that.
I'm not getting all that much encouragement from the user community, who seems to vastly prefer whining on Slashdot about how the current state of affairs is inadequate, rather than rolling up their sleeves, learning some color theory, building profiles, and helping develop the solution.
Well, to me, someone begging for other people to do their work for them for no pay is what counts as whining. Clearly we have somewhat different value systems!
Interesting links, but they still leave open the device profiling cost, and their web pages smack of amateurism. Have there been any comparisons between their print quality and the quality of commercial color management systems? The field is littered with color management systems that never produced consistently good prints, and lacking any comparative data I'm skeptical that these two amateur projects have beat the trend.
A Google search did not turn up comparative or review information on either project, except for this negative user review of Argyll. I did turn up this page of free color management links, but no feedback from publishers or designers on how well any of them work.
Easier said than done. Color science is still serious voodoo, and entire companies have foundered on the rock of device-specific color correction. There are now a few fairly good color management systems out there, but they're not free. Creating a good free one would involve the uncompensated labor of some talented color scientists for a few years, and guess what -- the open source ideal doesn't really exist in color science, and good color scientists with a grasp of computability are very hard to find. They'll also require several supporting programmers.
Then, once you've got the basic system, you have to create profiles for all the color printers in the market; or, you can boost the difficulty level by an order of magnitude and try to create a general-purpose adaptive color calibration system so that users can calibrate their own printers -- which requires a color-calibrated scanner, and so merely shifts the per-device calibration cost, as well as requiring the user to have a scanner.
It's really hard for me to see how those things could happen in an open source environment. You're probably talking an investment of at least five million dollars.
Slashdot Mirror
Consciousness is composed of the states of the cells in your nervous and endocrine systems (and various associated phenomena). That state is not reconstructible if the information about it is destroyed.
If you have nanotech, you should be able to rebuild the body to any degree you like, atom by atom.
Why? Information about the original state of the system would be permanently lost in the crystallization process.
--
Tim Maroney tim@maroney.org
That doesn't say anything about cathedrals having been designed in secret, and it interprets the metaphor in terms of centralization, not secrecy:
"Eventually, Raymond would convert the speech into a paper, also titled 'The Cathedral and the Bazaar.' The paper drew its name from Raymond's central analogy. GNU programs were 'cathedrals,' impressive, centrally planned monuments to the hacker ethic, built to stand the test of time. Linux, on the other hand, was more like 'a great babbling bazaar,' a software program developed through the loose decentralizing dynamics of the Internet."
Since we all know now that any successful software project on the medium or large scale requires centralized control, and that Linux and Mozilla are examples of that, it doesn't seem much is left of Raymond's metaphor. You can no more build a serious program without making a plan and enforcing it than you could build a house that way.
--
Tim Maroney tim@maroney.org
Do you have a reference for cathedrals having been designed in secret?
Raymond's own take on the metaphor is about centralized versus decentralized development.
I also think it is highly arguable that major open source projects are designed in the open. Anyone who monitored the decision-making process by which Mozilla first spurned and then embraced native widgets knows that such decisions are often made by an in-group that is relatively immune to outside pressure. The clannishness of the core Linux developers is even more legendary.
--
Tim Maroney tim@maroney.org
Cathedrals were built in public, not in secret. In fact the whole life of a community would often revolve around the proiject while it was going on.
As for the characterization of the Linux project as decentralized and self-assembling, that's been known to be false for years. Linux is tightly held by a strong central control group, in contrast with the development model expressed in Raymond's essay.
--
Tim Maroney tim@maroney.org
I see. That must be why I'm typing this on a non-Microsoft OS, for which Microsoft nonetheless makes software. I was unaware of the old-time papacy having provided services at Buddhist temples.
I also note that your interpretation of the cathedral and the bazaar is very different from that of others in the thread, which underscores the point that the metaphor is unclear.
Personally, I think Raymond's framing is an attempt to appeal to anti-religious libertarians, which one often encounters in science fiction fandom. Cathedral = religion = bad, bazaar = market = good.
--
Tim Maroney tim@maroney.org
I'm surprised by all the comments that Sterling's speech was devoid of substance. His verbal pyrotechnics may have gotten in the way at times, but that's Sterling's schtick and he's awfully good at it. Any reasonable person ought to have been able to see through the fireworks to his many substantial points, among which were:
Open source and free software are largely about their own subculture and the social aspects of that subculture rather than about software per se.
Software written by and for programmers is unlikely to have mass appeal, but it has powerful appeal to programmers.
Free software and open source will only become relevant to the average user when they start to take users' tastes and concerns into account.
The cryptic and balky nature of current open source and free software is a draw to programmers not only because it reflects their values, but because it's in such a sorry state that there is a trenchant humanitarian appeal to help out. (By implication, better software might reduce the amount of help available, and the movement might become a victim of its own success eventually.)
Another factor drawing programmers to this development model is the lack of responsibility, since they can quit at any time.
Raymond's cathedral/bazaar metaphor does not seem to apply very well, and on examination, it's unclear what he even meant by it. Microsoft is a bazaar company, not a cathedral company. So are most software makers.
People feel increasingly oppressed by commercial software, particularly Microsoft's. They are waking up to the way the software manipulates them against their own interests.
Viruses have in particular been a wake-up call.
Free software and open source are largely imitative rather than innovative, or "piratical" rather than "creative".
Free software and open source have hidden costs, including the cost of needing to become part of a particular subculture to use them effectively.
Information is not free. Information has intrinsic costs deriving from the social context of the information. Information merchants use particular strategies to make it difficult to change established relationships. Among these are restrictive contracts, brand-specific training, search costs, proprietary formats, durable purchases, and loyalty programs.
The open source and free software community is facing a social transition from a small geek subculture to a significant dissident standing. This is going to present serious challenges.
That's scarcely a complete list of the points of substance in this talk. It may not be Sterling's finest hour -- his forte is fiction, after all -- but it is by no means a bunch of insubstantial blather. In fact he touches on many neglected but important issues.
--
Tim Maroney tim@maroney.org
RedHat's making a profit, Mandrake's on track to.
Neither of these statements is true. Red Hat lost money again last quarter, as it always does. Mandrake, based on this announcement, is barely scraping by and may not survive the year.
Tim
MS can bluff all they want about piracy, but they know as well as anyone that you can't copyright a look + feel (remember Apple's lawsuit?).
Yes, you can protect look and feel by way of a design patent as well as by other means. Microsoft won the Apple lawsuit because it turned out that Apple had licensed the Mac look and feel to Microsoft in perpetuity for no license fees for Windows 1.0. Smart move, Apple. The reason Windows is able to exist is because it is a licensed clone of MacOS.
Tim
Still, even if the two companies are not considering a merger, AOL Timer Warner could license Red Hat for use on PCs or other devices for use with its online service.
They already did something almost exactly like that, and the product tanked, which only underscores your point about how silly it was for the reporter to say such a thing. The device was a Linux box made by Gateway. You can read about it on news.com here and here.
Tim
Twenty thousand dollars is, what, two months of the burdened cost of a single mid-range software engineer? Why is this worth an exclamation point? Many organizations pay several full-time programmers to work on open source projects -- any one of these organizations exceeds this tiny donation in a week.
Tim
Sorry, you're mistaken. Use cases are part of the requirements capturing process in the Rational Unified Process. The problem is that -- as described in great detail at the Constantine and Lockwood essay I pointed you to -- use cases involve making user interface design decisions, especially regarding sequence of actions, but also including presentation of choices and other matters. Since this is the wrong phase of the process to be making detailed design decisions, and the people making the design decisions are marketers and engineers, not designers, the decisions made are usually wrong. These premature user interface design choices then become locked in for the entire project life cycle.
Your message deals solely with the issue of premature design decisions., You did not engage other equally significant issues: that there is no place for design specialists in the Rational Unified Process, that the notoriously bad design of the Rational tools serves as a (negative) case study in the results of the Rational Unified Process, and that the way that use cases are specified creates user interfaces with a modal order of execution, an approach that violates standards of software design since 1984.
Tim
The use case model in the Rational Unified Process leads to terrible user interface design. This is evident in Rational's own notoriously badly designed products as well as in analyses of the methods by such writers as Constantine and Lockwood. Use cases make design decisions before requirements are gathered; they commit to modal sequences of execution which are in conflict with well-established principles of design; and they have no place for the participation of design specialists.
Tim
Nobody sane is advocating this.
And yet it is what is being practiced in the field. There are intrinsic forces involved in UML that lead in this unpleasant direction. You haven't dealt with those factors or with the way that UML-based specification activity tends to drive out text-based specification in practice. I believe I was sufficiently specific in describing some of these factors.
Tim
To respond to some of the comments about my admittedly vague dismissal of UML's value:
It is my strong impression from seeing projects specified with UML that diagrammatic specification has an inherent tendency to be less thoughtful about aspects of a software system for which there is no built-in diagrammatic representation, and that these "semantic" parts of the design of a software system overwhelm in practice the more constrained parts of a system which can be modeled using such formalisms as sequence diagrams.
To take one example, in the creation of a music engine at one company, extensive sequence diagrams were created to show the flow of musical data between various processing components. However, the scenarios for building and installing the engine in a variety of contexts, including web plug-ins and embedded device firmware, were nowhere to be found in the specification. Attempts to get the engineers to focus on these broader usage issues got nowhere, because the incredible specificity of the sequence diagrams seemed to imply that all important questions had already been answered. The questions about installation scenario, while critical to the design of the product, seemed fuzzier and less important because there was no way of expressing them in the specificity of UML diagrams -- they involved more free-form issues and text description. UML created a false sense of concreteness that led to neglect of important issues which could only have been adequately addressed in text.
In another case, a complex nested data structure was to be saved on top of a SQL database. Intricate class diagrams and sequence diagrams for the save procedure were drawn up, but each time a save API was delivered based on these heavily reviewed UML designs, it failed to cover major cases of nesting relationships and had to be reworked from scratch. UML diagrams turned out not to describe the solution at an adequate level of abstraction to deal with the general case of nested saving -- instead, all it could do was break down the problem into some six dozen special cases, rather than proposing general rules. The conceptual questions about what it meant to save a snapshot of a complex data structure in a shared system were never asked and could not be answered at the low level of abstraction provided by UML, and so the design effort for this critical portion of the internal API never succeeded through multiple development cycles.
Thought is a thing that happens primarily in words. Where it can be formalized into diagrams, it is if often worthwhile to do so. However, given the enormous complexity of software engineering problems, this level of formalism is rarely either attainable or useful. Even if we look at highly formal domains such as science and mathematics, published papers tend to be structured as natural-language essays with inserts of formulas and tables, rather than primarily as mathematics with a smattering of natural language. Software engineering is less formal than science or mathematics, not more. Specification should remain primarily a matter of writing in natural language, with diagrams at key points where they are applicable. The labor-intensiveness and false specificity of UML leads to an approach that is the reverse of this, in which what few words remain are subordinated to elaborate diagrams of marginal value. This creates inferior system designs.
Tim
Forget that flipper that drops one can, and the code will take your money and say thank you, but you aren't getting any soda.
And who was it that decided that complex software systems are more like soda machines than like novels?
Tim
I don't find that class diagrams communicate anything that I can't understand better with a description in text, or other methods.
Yep. UML is a way for poor communicators to pretend to design. UML diagrams are notoriously bad at factoring in real-world requirements, exceptions, usage patterns, and user scenarios. In every case I've seen UML used for modeling, it has created systems which looked clean in the diagrams but which failed to function usefully once implemented due to lack of conceptual underpinnings. It will be nice to see this particular documentation fad slip beneath the waves, and people get back to describing what they want to do in thoughtful paragraphs.
Tim
Physicist Robert L Forward wrote a popular science style book, Indistinguishable From Magic. The first chapter is titled Antimatter, discussed what antimatter is, how we storeit, produce it, how we could produce it econmonically, how to use it more space travel and more mundance applictions.
He also wrote a book specifically on antimatter, which he renamed "Mirror Matter." It's an utterly ridiculous book that has us all jetting to the moon for weekend vacations in our antimatter-fueled cars by 2005. Yes, that's right, three years from now. Mind you, the book was not science fiction -- it purported to be hard-headed prediction. Among other fascinating revelations: There is actually no possibility of dangerous radiation from antimatter propulsion, because it would only produce harmless pions. (And what do the pions turn into, Bob?) We could reach the nearest star in only forty years with a few hundred kilograms of antimatter, but even though one gram of antimatter is equivalent to a Hiroshima bomb, we don't need to worry about weapons proliferation, because while it could obviously be economically feasible to produce antimatter by the kilogram, it never could be feasible to produce it by the gram! Etc., etc. The sheer idiocy of the book is staggering, and only more so because it seems as if the writer must have known better.
Tim
Cell phones = communicators
Try walkie-talkies. I used to play with them back when the original series was on.
Babelfish = universal translator
Which, I think, must show that you have never actually tried to use Babelfish to translate a web page.
Taser(tm) = Phaser on stun
Very true, except that it isn't that at all. It's not a ray gun, it has a short range, and it often doesn't work.
2-way videophone = Screen on the bridge
Two-way videophone prototypes were being built back in the 1960's. We had one in our science museum in Columbus, Ohio.
PC = Enterprise computer terminal
Computers in Star Trek have always been comtemporary with the computer technology at the time of production. In the 1960's, they were room-sized or refrigerator-sized. Later they became portable, achieving a laptop form factor during TNG, and a palm form factor in the 1990's. There's no prediction there at all.
Now antimatter propulsion.
Now, not. NASA is not saying this could come on line in less than about a century, and nobody is talking about using it for space warps. Yeah, it may be useful for jetting around the solar system in 2100, maybe even an unmanned long-haul star probe or two around 2150 or so, or maybe not, but it's nothing at all like warp drive.
Was this guy good or what?
Not.
Tim
The main site doesn't say a word about cost, and it casually postulates robotic construction, which is not a currently deployed technology even on Earth. It seems to be ivory-tower science. The CNN and New Scientist pieces just say "billions."
Is there any reason to think that this thing could actually be built for a reasonable cost? Has anyone even tried to come up with a real estimate? Bear in mind how low the estimates have been for our most recent space construction. Off the top of my head I wouldn't be surprised to see a real cost in the hundreds of billions, between dozens of Saturn V launches and the development of entirely new technologies like lunar robotic construction.
Tim
There was so much hate in some of these people, too.
Very true. I think the documentary is bound to give short shrift to this unpleasant fact, though. Listen to this utopianism from the pitch: "an entire generation started to grow up online. They knew then what so many are learning now: the thrill of communication with others like themselves, around the country and the world.... They made friendships to last a lifetime. And they changed everything." Yikes. Talk about rose-colored glasses. What about the fact that the BBS world was often a snake pit of casual bans, flame wars, and rigid groupthink?
there were just so many unpleasant folks out there they ruined the experience for everyone. They know who they are, and they didn't contribute shit other than efforts overshadowed by ugly attitudes.
The only thing I disagree with is that "they know who they are." I think the most unpleasant people in the BBS scene were people who thought very highly of themselves and their contributions, and who really believed they were improving things for everyone by carrying out personal vendettas, banning everyone they disagreed with, and leading the charge to label anyone who didn't agree with local consensus as a troll. As usual, the real black hats were the crusaders, and they were convinced they were on the side of the angels.
Tim
The problem with Argyll at present is that nobody has (yet) integrated all the pieces in such a way that your average graphic artist can make high quality profiles. The pieces are there, and they're of quite high quality. But (at present) you have to have some serious color science knowledge to ensure that you get good results.
Sorry for any confusion. By my standards, that's a bad user review. It says you can get good color out of the thing only if you're a color scientist. We were talking about the benefits of adding CMYK support to the Gimp in terms of making a competitive desktop publishing system on Linux, and Argyll in its present form falls far short of that.
I'm not getting all that much encouragement from the user community, who seems to vastly prefer whining on Slashdot about how the current state of affairs is inadequate, rather than rolling up their sleeves, learning some color theory, building profiles, and helping develop the solution.
Well, to me, someone begging for other people to do their work for them for no pay is what counts as whining. Clearly we have somewhat different value systems!
Best,
Tim
Quantum jumps can be from higher to lower levels as well as from lower to higher.
Tim
Interesting links, but they still leave open the device profiling cost, and their web pages smack of amateurism. Have there been any comparisons between their print quality and the quality of commercial color management systems? The field is littered with color management systems that never produced consistently good prints, and lacking any comparative data I'm skeptical that these two amateur projects have beat the trend.
A Google search did not turn up comparative or review information on either project, except for this negative user review of Argyll. I did turn up this page of free color management links, but no feedback from publishers or designers on how well any of them work.
Tim
We then need CMYK capability in The Gimp.
Easier said than done. Color science is still serious voodoo, and entire companies have foundered on the rock of device-specific color correction. There are now a few fairly good color management systems out there, but they're not free. Creating a good free one would involve the uncompensated labor of some talented color scientists for a few years, and guess what -- the open source ideal doesn't really exist in color science, and good color scientists with a grasp of computability are very hard to find. They'll also require several supporting programmers.
Then, once you've got the basic system, you have to create profiles for all the color printers in the market; or, you can boost the difficulty level by an order of magnitude and try to create a general-purpose adaptive color calibration system so that users can calibrate their own printers -- which requires a color-calibrated scanner, and so merely shifts the per-device calibration cost, as well as requiring the user to have a scanner.
It's really hard for me to see how those things could happen in an open source environment. You're probably talking an investment of at least five million dollars.
Tim
(former employee of EFI and Light Source)