In a similar vein, I would calssify ESR as Chaotic Neutral...Libertarian Gun Nut. Unless, of course, Eric means Eric Allman (or some other member of the Eric Conspiracy)
Well, server side filtering has the advantage of knowing the sender's IP and querying SPF, saves from sucking a ton of spam across a modem link, and is the only option for webmail. So for me it's a must-have.
Having said that, I think the ideal is some tweakability on server-side filtering. Even a selection box with 0% (no filtering) to 100% (most aggressive filtering but with risk of false positives) would help. If you, for example, expect mail from people who run their own SMTP on a DSL connection, you can choose a lower setting (just enough to keep webmail useable) and rely on client side filtering to weed out the rest while whitelisting your address book. If, like me, you get mail from fairly predictable sources, you can choose a higher setting.
Well, I signed a waiver for a company video. I got a dollar for it, so they could use my image in it to pitch the (soon to be worthless) stock to random investors. The video was quite lame so there goes my acting career.
I am not up to speed on the finer points of the FCC rules on interference, but some time in the mid-90's the FCC stopped caring about interference that was limited to private property. It happened in the oh-so-FCC fashion: nobody was renewing their "experimental site" licences (that listed what frequencies you were doing development work in), and then eventually you couldn't find anyone to renew or issue one even if you asked, so, fait accompli, a liberalization in the rules.
Just ask any HAM how much enforcement is going on in the HAM bands, and if they can pin down when it stopped.
Arrgh, didn't log in...The AC post describing Usermail's antispam features (basically I get maybe one spam every couple months so I don't have to worry about it), that was me.
May I suggest usermail.com? I've used them for years and found their service & spam filtering quite good. $20 a year gets you webmail, POP, IMAP, SMTPauth on port 2525, & 50 MB (though with competition heating up that storage may increase).
...forcing people into massive debt... That basically sums up about 80% of my graduating class at Harvard.
Um, no one is forcing them to go to Harvard. There are cheaper places to go. In fact, the only reasons to go to a top echelon school is either (a) Big bux after graduation or (b) The marquee value for the very rich who can afford it.
If love of knowlege, or improving humanity, is your reason for higher education, you really should be looking elsewhere.
right now poor towns in places like Africa and Pennsylvania are the world's trashcans
Brockway, PA: site of a large new landfill so east coast cities can ship their garbage out by rail. The largest employer there: Owens-Brockway, a glass bottle factory. Irony, anyone?
It appears that one way out of the NIMBY syndrome is to pick a site with low population and propose a *huge* landfill, big enough to boost the small local economy. It seems to work for prisons (viz: Bradford, PA some 50 miles north of Brockway)
Perhaps Debian is a more apt comparison, if you look past the glaring exception of how they manage packages. Though Slack is still very much the elder cousin. The strongest parallel to Gentoo seems to be that both are most popular in academia. (Just like Slack's eponymous Cult of the Subgenius)
we have helicopters too though I am nervous about their landing on top, and it is hard to see how to enable them to hook on from below.
I have come to a similar conclusion in that the design requirements for good cruising & long endurance (ie large & light), and the requirements for safe ground handling (small & strong) are in conflict. Therefore two separate vehicles may be called for.
My mental concept (I toy around with this in my head sometimes when I should be thinking of something else) is of a very large airship that flies in the stratoshpere (say, 80,000 ft) whose design would be optimized for cruising. For service & passenger/freight loading it would require a "skyport", some sort of bridge structure suspended near cruising altitude between stationary balloons. The "Very Large Airship" could alight onto the skyport in the weatherless air of the stratoshpere. For a vertical vehicle, a balloon could service the skyport, rather than a rigid ship, since the gas envelope will swell to 30x sea level volume. Imagine a scaled-up weather balloon carrying an oversized space capsule lifting up from NY harbor or Lake Constance.
The skyport would require thrusters to stay on position, but the lift baloons can be shaped with reflectors to generate solar power; every day is sunny when you are above the clouds! Passenger layovers in the skyport would have to be a couple hours so the vertical-travelling balloon can wait for a pause in the weather as needed. Pressure cabins on the cruisers/skyport/ascent balloon can be fitted with passive helicopter blades so that, in case of gas envelope failure, they can auto-copter down. One technical snag I can't find an elegant solution for is the transient dynamics of the ascent/descent. How to you stop a rapidly rising baloon? Drag a parachute underneath? A vertical jet engine? Landing on water might improve safety margins on the way down, though.
And, development-wise, how do you get there from here? Large airship designs have a big technical & investment hump to climb over before they become competitive. There aren't very many ways to mitigate risk by trying a smaller design first.
Re:using up the planet's supply of helium?
on
Zeppelin Flies Again
·
· Score: 2, Interesting
Well, there's steam like you mention. And just plain hot air (surface area to volume ratio improves with scale, so insulating the lifting gas gets easier for large airships). Ammonia is cheap and wieghs about half as much as air (giving it lift about half that of H2 or He, & comparable to steam). It is gaseous over a wider range of temperature & pressure, not particulary flammable but somewhat toxic in pure form; venting lifting gas could be hazardous at low altitudes so instead it may be necessary to squirt water into the gas envelope and take advantage of ammonia's high solubility. Hydrogen burns only in the presence of oxygen of course, so a double envelope consisting of a hydrogen-filled bag inside, say, a nitrogen/ammonia/neon-filled bag mitigates flammability hazards. Neon gas is lighter than air & may be a subsititute, albeit poorer performing, not only for lifting gas, but also for cryogenics & saturation diving as mentioned a few posts up.
Airhips' key appeal is that they can fly without much energy use; flight is their natural state. Volume goes by the cube of linear dimension so the concept lends itself to very large scale implementations. But that large scale has been their downfall; the more large and efficient they are, the more vulnerable they are to weather. If airships are to make a comeback, someone needs to solve the problems of weather survivability. Vectored thrust has helped considerably, as have modern weather prediction methods. Another approach is fly in the stratosphere...no weather up there.
It is only when you start to question those assumptions that you move forward.
That only works when you question those assumptions intelligently. Let me give an example. By the 1920's it was well known that noise power was proportional to bandwidth. Progress in radio reception quite naturally followed the path of narrowing bandwidth (from early spark-gap systems that had poor selectivity and on to elaborate tuned LC circuits). Armstrong, when developing FM, wasted years trying to get good signal-to-noise out of extremely narrowband FM systems, despite the fact that Carson had mathematically proved that this was impossible. If he had taken the time to understand the underpinnings of Carson's proof first (ie, narrowband analysis), he could have started working on wideband FM much sooner.
We know from Maxwell's equations that, given some fairly general assumptions about antenna geometery, size, gain, & bandwidth are a trade-off. It is much better to understand those assumptions (eg, the antenna doesn't change shape) than to challenge Maxwell's equations, or to spend countless hours hacking away in a lab like Armstrong did.
I'm betting this antenna has a very narrow bandwidth
My thoughts exactly. The trade-off you mention was proven from Maxwell's equations in 1947, when everyone's interest was in making small vehicle-mount antennas in the HF bands. (The proof, though, makes some assumptions about ground planes & such.) I can't remember the reference, but I think it was published in the Proceedings of the IRE.
Applying techniques like these (fractal antennas, frequency selective surfaces, artificial magnetic conductors, blah, blah, blah) to practical cellphone handsets has never proven sucessful, despite many venture-funded startups that tried (& went bust with the tech-wreck). Too many practical considerations get in the way (dual resonance for both 900 & 1800 MHz, no control over size & shape of the ground plane, dielectric loading from a human hand & head or other nearby components, must be quality controlled for large production volumes, etc.)
The biggest impediment to smaller cellphone antennas is 900 MHz support.
what significance, if any, this has for any other discipline
Well, a weaker form of the hypothesis used to prove the prime number theorem, which makes a prediction of how many prime numbers are on a given interval (e to the 1 over sqrt(pi*something), hell it's been years...anyone interested look it up in wiki yourself). Basically, someone in the 1910's proved that all the non-trivial zeros have an imaginary part really close to -1/2 (within a ~1/log(b) assymptote).
Given its relation to prime numbers, cryptography might be affected by the Riemann Hypothesis, especially if it is proven false. A "non-Riemann" zero might have some really wierd cryptographic applications.
Maybe you can generate intermediate VHDL with FPGA Compiler and then compile that with the native Actel tools, though that leaves the timing debugging directly in VHDL, I think. (Supposedly, if you migrate the functional design to an antifuse device, the timing problems simply go away because the parts are so bitchin' fast, but I cannot attest to this personally.) FPGA Complier is a 3rd party tool (by Synopsys) so I don't think there is much that Actel can do about it.
But then again I have never seen an FPGA design tool that I liked. The schematic-based designs are hell to maintain; version creep in the "parts" libraries drove me crazy. VHDL is a bit removed from the solder, kynar wire, and test probe mentality of someone like me, a mostly analog/RF guy. Without a schematic, where do you stick your simulated probe on your simulated circuit? It's bad enough that I can't jab a real probe in there. It's enough to make you think it's all somehow Microsoft's fault (since MS is clearly the source of all evil in the world).
Xilinx has low-cost and free design suites available.
I peeked over at xilinx.com, and <Gomer Pyle Voice>Shazam!</Gomer> They do now. A few years ago they really couldn't because AT&T/Lucent was a pin-compatible 2nd source (AT&T got a license in exchange for fab capacity, I think). So software support couldn't be justified as a sales cost...people could just get the cheaper Orca chips. It appears that the Xilinx 3000 & 4000 series are long gone now, and Xilinx now fabs its chips elsewhere.
There's still glitch control, though. Not a problem if your project is gonna plug into a host system (such as a PC) that has already solved power supply & shielding issues for you, so bring on those home-brew hardware MPEG encoders! But if your project is some battery-powered robotic gizmo, or a digital RF synthesizer, an SRAM based FPGA could be awfully glitchy.
Disclaimer: my wife sells Actel (which makes antifuse & flash types), on commission but over a limited territory. (In a previous job she used to sell Xilinx.) I have used SRAM and anitfuse designs (though I am not really a digital logic guy) but never flash.
No joke, there actually is such a thing. Asynchronous design is much harder to verify than ordinary clock-driven designs, but there is some evidence that that approach may help with current problems with clock distribution (obviously) and power dissipation.
There is a trade-off between speed, reliability, cost, and re-programmability.
SRAM types
Are re-programmable but require a rather slow serial load at boot-up. Reliability in embedded systems leaves something to be deisired since any brownout-induced glitch can create errors that are even worse (harder to recover from) than software glitches because wired logic doesn't have anything equivalent to code checksums or interrupt vectors. Well-paid FPGA designers are versed in the arcane art of self-verifying logic.
EEPROM types
Come alive at boot up and are much more resistant to glitches. Their performance, however, is slow. And you have limited (100,000 maybe) rewrite cycles.
Anti-fuse types
are made by Actel. They have the highest performance and best density. They come alive at boot up and are dead-nuts reliable under the worst of conditions; for example, properly qualified, they can survive the cosmic radiation in spacecraft that would leave other types toasted. The big drawback: the anti-fuse process, which works by melting diodes into short-circuits, is not eraseable.
Desktop systems (say, an add-on FPGA card) would be best served by SRAM types, since you already have a processor that requires gluttinous gobs of puritanically clean DC power. Basement hardware hackers would be better served by EEPROM or anitfuse types (depending on performance requirements), since they don't require super-expensive exotic design software.
mechanism for scraping NZ TV websites for program listings...time to create, and more importantly maintain, such a method.
Do you have any way of contacting other Kiwis who want to use MythTV? Even if it is 10 guys, or 5, the task may be easily parallelizable, and you are looking at a small faction of the work. Hell, the back room technician at the TV station may be able to help some if NZ has the hometown flavor it appears to have--to outsiders, at least (by posting a database-friendly text file of listings on the TV website, for example).
If nothing else you could put up a simple webpage or sourceforge project, and see if anyone googles in.
If Tivo or other PVR suppliers don't cater to the NZ market & you are ambitious, make a business of it and sell hardware/software/service combinations, through the local satellite TV shops, perhaps.
It wasn't just web browsers either. Datatypes supported both read/display, & write/save operations. Commercial paint programs for the Amiga were able to make an end-run around the Unisys GIF patent by leaving out GIF support in the main program, but having datatype support. To save as GIF you downloaded an open-source GIF datatype (Unisys didn't attempt to enforce against open source implementations), dropped the class description and the library code in the required directories, and the paint program handled GIF equivalently to the native formats.
I liked that line, too. By not writing in any antagonism, Ayn Rand starkly illustrated Roark's singular purpose of mind.
For those unfamilliar with the story, Roark is the archetypal creator, a competent & pioneering architect who is unswayed by shallow stylistic fads. Toohey is a parasite; his influence is entirely from being a critic who appeals to the basest of popular tastes (he himself has created nothing), and he uses his influence to impede progress in architecture.
In a similar vein, I would calssify ESR as Chaotic Neutral...Libertarian Gun Nut. Unless, of course, Eric means Eric Allman (or some other member of the Eric Conspiracy)
Well, server side filtering has the advantage of knowing the sender's IP and querying SPF, saves from sucking a ton of spam across a modem link, and is the only option for webmail. So for me it's a must-have.
Having said that, I think the ideal is some tweakability on server-side filtering. Even a selection box with 0% (no filtering) to 100% (most aggressive filtering but with risk of false positives) would help. If you, for example, expect mail from people who run their own SMTP on a DSL connection, you can choose a lower setting (just enough to keep webmail useable) and rely on client side filtering to weed out the rest while whitelisting your address book. If, like me, you get mail from fairly predictable sources, you can choose a higher setting.
Well, I signed a waiver for a company video. I got a dollar for it, so they could use my image in it to pitch the (soon to be worthless) stock to random investors. The video was quite lame so there goes my acting career.
I am not up to speed on the finer points of the FCC rules on interference, but some time in the mid-90's the FCC stopped caring about interference that was limited to private property. It happened in the oh-so-FCC fashion: nobody was renewing their "experimental site" licences (that listed what frequencies you were doing development work in), and then eventually you couldn't find anyone to renew or issue one even if you asked, so, fait accompli, a liberalization in the rules.
Just ask any HAM how much enforcement is going on in the HAM bands, and if they can pin down when it stopped.
Arrgh, didn't log in...The AC post describing Usermail's antispam features (basically I get maybe one spam every couple months so I don't have to worry about it), that was me.
You need usermail.com. See my post above.
May I suggest usermail.com? I've used them for years and found their service & spam filtering quite good. $20 a year gets you webmail, POP, IMAP, SMTPauth on port 2525, & 50 MB (though with competition heating up that storage may increase).
Um, no one is forcing them to go to Harvard. There are cheaper places to go. In fact, the only reasons to go to a top echelon school is either (a) Big bux after graduation or (b) The marquee value for the very rich who can afford it.
If love of knowlege, or improving humanity, is your reason for higher education, you really should be looking elsewhere.
One of my earliest memories is live TV coverage of Apollo-Soyuz. My young brain was very puzzled because I didn't know what number "Soyuz" was.
right now poor towns in places like Africa and Pennsylvania are the world's trashcans
Brockway, PA: site of a large new landfill so east coast cities can ship their garbage out by rail. The largest employer there: Owens-Brockway, a glass bottle factory. Irony, anyone?
It appears that one way out of the NIMBY syndrome is to pick a site with low population and propose a *huge* landfill, big enough to boost the small local economy. It seems to work for prisons (viz: Bradford, PA some 50 miles north of Brockway)
Perhaps Debian is a more apt comparison, if you look past the glaring exception of how they manage packages. Though Slack is still very much the elder cousin. The strongest parallel to Gentoo seems to be that both are most popular in academia. (Just like Slack's eponymous Cult of the Subgenius)
we have helicopters too though I am nervous about their landing on top, and it is hard to see how to enable them to hook on from below.
I have come to a similar conclusion in that the design requirements for good cruising & long endurance (ie large & light), and the requirements for safe ground handling (small & strong) are in conflict. Therefore two separate vehicles may be called for.
My mental concept (I toy around with this in my head sometimes when I should be thinking of something else) is of a very large airship that flies in the stratoshpere (say, 80,000 ft) whose design would be optimized for cruising. For service & passenger/freight loading it would require a "skyport", some sort of bridge structure suspended near cruising altitude between stationary balloons. The "Very Large Airship" could alight onto the skyport in the weatherless air of the stratoshpere. For a vertical vehicle, a balloon could service the skyport, rather than a rigid ship, since the gas envelope will swell to 30x sea level volume. Imagine a scaled-up weather balloon carrying an oversized space capsule lifting up from NY harbor or Lake Constance.
The skyport would require thrusters to stay on position, but the lift baloons can be shaped with reflectors to generate solar power; every day is sunny when you are above the clouds! Passenger layovers in the skyport would have to be a couple hours so the vertical-travelling balloon can wait for a pause in the weather as needed. Pressure cabins on the cruisers/skyport/ascent balloon can be fitted with passive helicopter blades so that, in case of gas envelope failure, they can auto-copter down. One technical snag I can't find an elegant solution for is the transient dynamics of the ascent/descent. How to you stop a rapidly rising baloon? Drag a parachute underneath? A vertical jet engine? Landing on water might improve safety margins on the way down, though.
And, development-wise, how do you get there from here? Large airship designs have a big technical & investment hump to climb over before they become competitive. There aren't very many ways to mitigate risk by trying a smaller design first.
Well, there's steam like you mention. And just plain hot air (surface area to volume ratio improves with scale, so insulating the lifting gas gets easier for large airships). Ammonia is cheap and wieghs about half as much as air (giving it lift about half that of H2 or He, & comparable to steam). It is gaseous over a wider range of temperature & pressure, not particulary flammable but somewhat toxic in pure form; venting lifting gas could be hazardous at low altitudes so instead it may be necessary to squirt water into the gas envelope and take advantage of ammonia's high solubility. Hydrogen burns only in the presence of oxygen of course, so a double envelope consisting of a hydrogen-filled bag inside, say, a nitrogen/ammonia/neon-filled bag mitigates flammability hazards. Neon gas is lighter than air & may be a subsititute, albeit poorer performing, not only for lifting gas, but also for cryogenics & saturation diving as mentioned a few posts up.
Airhips' key appeal is that they can fly without much energy use; flight is their natural state. Volume goes by the cube of linear dimension so the concept lends itself to very large scale implementations. But that large scale has been their downfall; the more large and efficient they are, the more vulnerable they are to weather. If airships are to make a comeback, someone needs to solve the problems of weather survivability. Vectored thrust has helped considerably, as have modern weather prediction methods. Another approach is fly in the stratosphere...no weather up there.
It is only when you start to question those assumptions that you move forward.
That only works when you question those assumptions intelligently. Let me give an example. By the 1920's it was well known that noise power was proportional to bandwidth. Progress in radio reception quite naturally followed the path of narrowing bandwidth (from early spark-gap systems that had poor selectivity and on to elaborate tuned LC circuits). Armstrong, when developing FM, wasted years trying to get good signal-to-noise out of extremely narrowband FM systems, despite the fact that Carson had mathematically proved that this was impossible. If he had taken the time to understand the underpinnings of Carson's proof first (ie, narrowband analysis), he could have started working on wideband FM much sooner.
We know from Maxwell's equations that, given some fairly general assumptions about antenna geometery, size, gain, & bandwidth are a trade-off. It is much better to understand those assumptions (eg, the antenna doesn't change shape) than to challenge Maxwell's equations, or to spend countless hours hacking away in a lab like Armstrong did.
I'm betting this antenna has a very narrow bandwidth
My thoughts exactly. The trade-off you mention was proven from Maxwell's equations in 1947, when everyone's interest was in making small vehicle-mount antennas in the HF bands. (The proof, though, makes some assumptions about ground planes & such.) I can't remember the reference, but I think it was published in the Proceedings of the IRE.
Applying techniques like these (fractal antennas, frequency selective surfaces, artificial magnetic conductors, blah, blah, blah) to practical cellphone handsets has never proven sucessful, despite many venture-funded startups that tried (& went bust with the tech-wreck). Too many practical considerations get in the way (dual resonance for both 900 & 1800 MHz, no control over size & shape of the ground plane, dielectric loading from a human hand & head or other nearby components, must be quality controlled for large production volumes, etc.)
The biggest impediment to smaller cellphone antennas is 900 MHz support.
I think it may have implications for cryptography. See my post higher up in this page.
what significance, if any, this has for any other discipline
Well, a weaker form of the hypothesis used to prove the prime number theorem, which makes a prediction of how many prime numbers are on a given interval (e to the 1 over sqrt(pi*something), hell it's been years...anyone interested look it up in wiki yourself). Basically, someone in the 1910's proved that all the non-trivial zeros have an imaginary part really close to -1/2 (within a ~1/log(b) assymptote).
Given its relation to prime numbers, cryptography might be affected by the Riemann Hypothesis, especially if it is proven false. A "non-Riemann" zero might have some really wierd cryptographic applications.
Maybe you can generate intermediate VHDL with FPGA Compiler and then compile that with the native Actel tools, though that leaves the timing debugging directly in VHDL, I think. (Supposedly, if you migrate the functional design to an antifuse device, the timing problems simply go away because the parts are so bitchin' fast, but I cannot attest to this personally.) FPGA Complier is a 3rd party tool (by Synopsys) so I don't think there is much that Actel can do about it.
But then again I have never seen an FPGA design tool that I liked. The schematic-based designs are hell to maintain; version creep in the "parts" libraries drove me crazy. VHDL is a bit removed from the solder, kynar wire, and test probe mentality of someone like me, a mostly analog/RF guy. Without a schematic, where do you stick your simulated probe on your simulated circuit? It's bad enough that I can't jab a real probe in there. It's enough to make you think it's all somehow Microsoft's fault (since MS is clearly the source of all evil in the world).
Xilinx has low-cost and free design suites available.
I peeked over at xilinx.com, and <Gomer Pyle Voice>Shazam!</Gomer> They do now. A few years ago they really couldn't because AT&T/Lucent was a pin-compatible 2nd source (AT&T got a license in exchange for fab capacity, I think). So software support couldn't be justified as a sales cost...people could just get the cheaper Orca chips. It appears that the Xilinx 3000 & 4000 series are long gone now, and Xilinx now fabs its chips elsewhere.
There's still glitch control, though. Not a problem if your project is gonna plug into a host system (such as a PC) that has already solved power supply & shielding issues for you, so bring on those home-brew hardware MPEG encoders! But if your project is some battery-powered robotic gizmo, or a digital RF synthesizer, an SRAM based FPGA could be awfully glitchy.
Disclaimer: my wife sells Actel (which makes antifuse & flash types), on commission but over a limited territory. (In a previous job she used to sell Xilinx.) I have used SRAM and anitfuse designs (though I am not really a digital logic guy) but never flash.
No joke, there actually is such a thing. Asynchronous design is much harder to verify than ordinary clock-driven designs, but there is some evidence that that approach may help with current problems with clock distribution (obviously) and power dissipation.
There is a trade-off between speed, reliability, cost, and re-programmability.
SRAM types
Are re-programmable but require a rather slow serial load at boot-up. Reliability in embedded systems leaves something to be deisired since any brownout-induced glitch can create errors that are even worse (harder to recover from) than software glitches because wired logic doesn't have anything equivalent to code checksums or interrupt vectors. Well-paid FPGA designers are versed in the arcane art of self-verifying logic.
EEPROM types
Come alive at boot up and are much more resistant to glitches. Their performance, however, is slow. And you have limited (100,000 maybe) rewrite cycles.
Anti-fuse types
are made by Actel. They have the highest performance and best density. They come alive at boot up and are dead-nuts reliable under the worst of conditions; for example, properly qualified, they can survive the cosmic radiation in spacecraft that would leave other types toasted. The big drawback: the anti-fuse process, which works by melting diodes into short-circuits, is not eraseable.
Desktop systems (say, an add-on FPGA card) would be best served by SRAM types, since you already have a processor that requires gluttinous gobs of puritanically clean DC power. Basement hardware hackers would be better served by EEPROM or anitfuse types (depending on performance requirements), since they don't require super-expensive exotic design software.
mechanism for scraping NZ TV websites for program listings...time to create, and more importantly maintain, such a method.
Do you have any way of contacting other Kiwis who want to use MythTV? Even if it is 10 guys, or 5, the task may be easily parallelizable, and you are looking at a small faction of the work. Hell, the back room technician at the TV station may be able to help some if NZ has the hometown flavor it appears to have--to outsiders, at least (by posting a database-friendly text file of listings on the TV website, for example).
If nothing else you could put up a simple webpage or sourceforge project, and see if anyone googles in.
If Tivo or other PVR suppliers don't cater to the NZ market & you are ambitious, make a business of it and sell hardware/software/service combinations, through the local satellite TV shops, perhaps.
what D.D.S means
D'oh! D'oh! Stop!
Dratted Dadburn Suffering
I'm sure others can build on this...
It wasn't just web browsers either. Datatypes supported both read/display, & write/save operations. Commercial paint programs for the Amiga were able to make an end-run around the Unisys GIF patent by leaving out GIF support in the main program, but having datatype support. To save as GIF you downloaded an open-source GIF datatype (Unisys didn't attempt to enforce against open source implementations), dropped the class description and the library code in the required directories, and the paint program handled GIF equivalently to the native formats.
Pretty slick, eh?
I liked that line, too. By not writing in any antagonism, Ayn Rand starkly illustrated Roark's singular purpose of mind.
For those unfamilliar with the story, Roark is the archetypal creator, a competent & pioneering architect who is unswayed by shallow stylistic fads. Toohey is a parasite; his influence is entirely from being a critic who appeals to the basest of popular tastes (he himself has created nothing), and he uses his influence to impede progress in architecture.