He did not talk about the technical disadvantages of current free source control software like cvs (too many to list for a project like Linux, might I add). Instead, he posted a political rant.
Imagine this scenario:
Using the free version of BitKeeper, a developer contributes patches to Gnome.
Someone in another division of the developer's employer is selling a slightly-customized version of CVS.
Therefore, the developer committed a copyright violation by using the free version of BitKeeper (because their employer is competition to BK).
Therefore, the patch is a gain arising from an unlawful (and possibly criminal) act.
Therefore, BitMover, Inc. has a remedial (and possibly punitive) interest in the patch.
Therefore, BitMover, Inc. might be able to enjoin against the use of the patch, and possibly recover damages from those who distribute it.
The discussion is very technically-relevant. Having your developers go to jail, being sued for benefitting from ill-gotten gains, and having to revert patches are issues of major importance to the Linux kernel.
Simply put, anybody who uses the free version is walking on legal quicksand, and by extension so are the projects they contribute to. I know that Larry McVoy almost certainly won't run somebody into the ground just because he can, but what if BitMover goes bankrupt, perhaps many years from now? In that case, the right to sue under the BK license would devolve to the creditor, who could be considerably less friendly. A contract that depends on the goodwill of a particular person is an exceedingly dangerous legal instrument, and can blow up in your face with no warning. I wouldn't touch the free version of BK with a ten foot pole.
That's why RMS is getting excited: not because BitMover is evil today, but because somebody nasty could gain retroactive control of license enforcement tomorrow, and use that to disrupt free software projects.
Personally I don't have any problem with the pay/lease versions of BK. You pay, you get the software, pretty standard and safe. What I have a problem with is a legal minefield masquerading as freeware.
You're absolutely right about "distribution" versus "selling". In many situations the distinction will not be obvious to a court, which means that the smallest disagreement will become a protracted legal battle. It turns the license into a legal minefield. That Larry McVoy brushes it off so easily should be disturbing to anybody contemplating a contract with BitMover, Inc. The man clearly needs a prosthetic lawyer grafted onto his torso.
The same issue applies to competition. Is Perforce competition? Certainly. What about Subversion? Probably. What about an engineering doument control system? Maybe. What about a web content management system? Maybe. If I add version tracking and rollback to the web content system, does it become more competitive? Who knows? If the content system uses an object database (e.g., Zope) instead of a classical filesystem, does that make it less competitive? Who knows? What about a weblog system that tracks updates? Who knows?
"Who knows?" scares me. I don't like contracts where I don't know where I stand, but where I can be retroactively declared to be in violation. Contracts like that are the stuff of nasty legal battles.
The school owns the network. And if a particular DHCP client or domain controller capable OS does something nasty, they can nix it. And furthermore, they can nix it regardless.
Right, just like ISPs. And just like ISPs, if they do annoying and idiotic things, one day they will discover that their rich and/or clueful customers will have disappeared.
Ah, Sapporo, just about the biggest can/bottle of beer you can buy in OK that doesn't have "malt liquor" written on it. The gyrations currently being felt in my head were contributed to in a major way by two big-ass cans of Sapporo. That reminds me, I'm out of sake...
OTOH, they're not an efficient use of aluminum--the cans are damn thick.
Obligatory on-topic Nakamura statement: Nakamura's situation is a damn shame. He has done more for the human race than most medium-sized cities. Nichia's failure to reward him is shameful, and as an electrical engineer who designs blue emitters into products, I shall not forget it. Can you say design loss?
Wouldn't work. When one bank is driving the shared bus, the other has to be turned off, and standard DDR modules won't have the correct timing for that.
The difference in sound was immediately evident even on my laptop speakers. The Ogg files, after taking at least three times as long to encode on my P3 700MHz, were very lacking in bass and had an overall hollow or light feeling.
How the brain interprets sound is very complex. It could be that your MP3 encoder murdered the treble, making the bass seem louder. Or maybe not.
I felt that the MP3 was a much better representation of the CD, and certainly more pleasant to listen to. Hopefully another format will spring up to combat Ogg if MP3 does go away (which isn't likely anyway).
I'd like to point out that the actual data formats are usually *extremely* flexible. They give the encoder many, many, many different ways to represent a given sound. And that's the problem: there are trillions of possible representations of the sound, and the encoder has to pick just one. That's a hard job, and different encoders have different degrees of success for different sounds. It's even true for different MP3 encoders. Take a look around the web and you'll find MP3 encoder comparisons that find dramatic differences.
The only reason why Unix is case sensitive is because it was easier, and faster to implement it as such in the early days.
No, it's because case sensitivity is the Right Thing.
It is also a security concern. If I have 2 files, which are identical except for case it is possible I could run the wrong one. Why? Point and Click interfaces barely show a difference between o and O, etc.
If by "Point and Click" you mean "the egregiously bad fonts chosen for Windows", I agree. They have other problems, such as "1Il" (one capital-eye lowercase-ell) and "O0" (oh zero). (Will the real Bruce Perens please stand up?;-)
There is also no need for 2 files with the same name, and different case when it comes to SOURCE CODE. I have seen more than 1 program implemented like this and it is downright confusing and stupid. " No no, not "ubergeek.c", "Ubergeek.c"... etc.
On the other hand, it is arguably useful to distinguish between file.c and file.C.
I've been working in a database language that is case-insensitive for a number of years as well. It is damn nice to not have to worry about somebody typing something in differently than expected. It isn't a problem. And I don't have to call UPPER every time I do something!
All computers are not Vaxes. All text is not 7-bit ASCII. For a general purpose Unicode-compatible system, **THERE IS NO WAY TO BE CASE INSENSITIVE**. Period. End of story. No further discussion. How do you handle "Â" versus "â"? Or "" versus ""? (Capital thorn versus small thorn.) Or "Æ" versus "aE"? Or similar things for terrorist languages like Arabic and Klingon? Or the Russian letter whose name escapes me that looks exactly like a capital "O" but *isn't*. (That one's good for all sorts of fun.) The answer is that you don't even try. Anything you do is going to break badly, and a system that is randomly broken is less useful than a system that is consistent.
Wasnt the original reason for this that files that were especially important were capitalised (README, INSTALL, etc) specifically so they'd head up the list in ls.
You can prepend 0 (numeral zero) to the few files that need it to force them to sort to the top, then do case-insensitive sorting. This convention is already in use. E.g., Documentation/00-INDEX in the Linux kernel sources.
Galapagos is great. Deep and wide philosophical scope, but still fun and comprehensible.
My suggestions: The City and the Stars by Arthur C. Clarke is classic sci-fi dystopia. The Folk of the Fringe by Orson Scott Card is an optimistic post-apocalyptic dystopia.
The second most beautiful thing is a cop giving somebody like you a ticket for "Obstructing Traffic" for camping out in the passing lane.
Duh, but it's not to make life easier for criminals who believe that the speed limit statues magically do not apply to them, due to their obviously superior knowledge of what speed is suitable for a particular road. It's because the law generally allows cops and emergency vehicles to break the speed limit by a certain amount, *without* having flashing lights, sirens, or markings. If more than one lane is available, a car that doesn't yield right to overtaking traffic *is* obstructing cop/emergency vehicle traffic and can reasonable be ticketed.
How would the black box be any different than keeping a journal? As I said before, the car is your property (just like the journal) and is protected via the same rights.
Journals and diaries can -- and have -- been subpoened. The Fourth Amendment requires only that a lawful warrant be obtained first. The Fifth Amendment restrictions on self-incrimination only apply to *you* personally, not records that are stored outside your body on inanimate objects.
Re:Sadly Intel has the upper hand here
on
AMD's 64-Bit Chip
·
· Score: 2
Err what games do you play that need that much RAM?
Offhand, I can't think of a single game in the past five years that hasn't been RAM starved. Every level load time and overly repeated texture implies insufficient memory (or that the game was chopped down to fit machines with insufficient memory).
Besides, the vendors can't wait until their customers hit the limit to start designing the next generation of hardware. From project start, it takes 3-6 years to get a new CPU core to the mass market.
Re:Sadly Intel has the upper hand here
on
AMD's 64-Bit Chip
·
· Score: 2
Of course that brings up the whole question of why you'd need a 64-bit CPU for a desktop machine.
32 bits can only address 4 GB of RAM, which is starting to look uncomfortably small for many applications (AI, modelling, gaming, video processing, etc.).
The P4 trace cache is cool, but (1) it's only 12Kops deep, and (2) it doesn't globally optimize, it just remembers. OTOH, if global optimization was easy we'd all be buying Itaniums.
I wouldn't underestimate the importance of low power design at the architectural level. If you could design a P4 1 GHz-equivalent computer that would fit in a shirt pocket and run 12 hours on a charge, you'd have a sales winner. And you will never be able to do that using the P4 or Itanium approaches (cache and prefetch the shit out of everything, and use the widest & fastest busses that can be fabbed and packaged). Smart portable devices are the future of computing, if for no other reason than the desktop market is saturating(ed).
Also, the fastest CPUs are rapidly approaching the propagation delay limit and pipelining is running out of steam (look at the absurd 20-stage pipeline of the P4). Past that limit, advances in throughput will come from parceling out work units to sub-CPUs. Transmeta's approach has some chance of untangling the dependencies and creating the work units, but a hardwired decoder is hopeless. I'd just say "SMP" (or ultrahypermegathreading buzzword of the week), but software designers have a poor history of moving beyond uniprocessor.
When it became clear that they'd underestimated x86 performance curves, they needed some reason for having spent all that money on Linus's salary.
I think it was the external bus they underestimated. If the CPU is a lot faster than its bus, there's a huge payback for reducing cache misses and stalls through optimization. So far Intel has (partially) defeated that problem by clever heuristics and big improvements in the bus, but the bus can only be improved so far. (When I first heard how the P4 was keeping the bus saturated to improve performance, I was shocked that they would resort to such a sledgehammer approach, and also shocked that that approach had a payback.) At some point the only solution will be intelligent prefetching. Worse luck for Transmeta, that point is probably several years in the future.
It's not even as fundamentally radical an implementation technique as it initially sounds; it's a slippery slope from microcode+trace cache to "code morphing."
No reasonable amount of P4 microcode will ever run Java, Python, or C#.;-) I seriously doubt that's what Transmeta was shooting for, but I'd pay through the nose for a machine that could do a Python VM opcode every 10 nanoseonds.
The trouble with Transmeta was that the feature people wanted was fine-grained power management, not software translation into microcode.
Depends on your point of view. I consider controlling the CPU core voltage and clock speed as rather coarse grained.
Transmeta's "code morphing" turned out to be another Really Neat Computer Architecture Idea that Doesn't Matter.
No, it's a major advance in instruction decoding. Conventional IA-32 decoders are hardwired into transistors. They do perform extremely well, but at a very high cost in power and die area, and because they're hardwired it's difficult to design complex behavior. Hardwired logic giveth, but hardwired logic also taketh away. From a power point of view, they're very coarse grained: decoding instructions full-bore, or turned off. (And they have no sense of importance: code that runs for a microsecond every ten minutes is treated the same as the inner loop of a rendering algorithm.)
The Transmeta instruction decoder, on the other hand, is extremely fine-grained. It gives code the amount of attention it deserves. For rarely-executed code, the decoder wastes little power and does a suboptimal decoding. The more frequently code is executed, the more power the decoder burns to optimize it. Especially frequent decodings are cached so they can be used later with zero decoding. (Which hardwired decoders have a lot of trouble doing.)
The Transmeta decoder also has the potential for really neat tricks. E.g., you could put multiple ALUs and FPUs in the CPU, but leave them completely turned off except when a heavy-duty computational algorithm truly needs them. Ditto for power-hungry L1/2 caches. When your decoder is firmware, you can afford to try all sorts of things, and just not use them if it's too hard to get right, but complexity like that gives nightmares to the designers of hardwired decoders.
It goes to the graveyard with... single-instruction multiple-datastream machines...
You mean like IA-32?;-)
The same thing will probably happen to Intel's Itanium, which, even within Intel, is considered a marginal idea.
The latest Itanium 2 benchmarks look pretty good. With some more tweaking, I won't be surprised if the I2 will give the largest available computational throughput per CPU. I think technically it can be made to work well. The question is, how many people need absolute peak performance per CPU, die area, power consumption, and bus width be damned? I suspect that's a small market. Most people in the data serving and technical computing markets can just slap some more CPUs in their cluster if it's too slow. (And you can reasonably contemplate putting 500 Crusoes in a rack, and tossing the rack into some random warehouse. Equivalent Itanium power would be vastly more expensive and require a carefully-engineered cooling system.)
As another poster replying to this post stated so nicely, the people being responsible for IT at Sherwin Williams will be pissing their pants.
Why? Unless they were blindingly stupid, they have a contract that allows them to clone the software to their heart's content (possibly paying a modest royalty to TL or TL's creditors), and that gives them access (perhaps via IBM) to the source code, which means they can keep deploying and repairing cash registers without missing a beat.
Even if both they and the project survive this, they will put a big shiny plate over their bed "Nobody ever got fired for buying Microsoft".
When you're through with that crack pipe, pass it over here.;-)
Win2K Pro costs around $75, and requires on the order of $50 in extra hardware (big hard drive, extra RAM, faster CPU) to run well. For 9700 cash registers, Windows increases the cost by $1.2M. (I'm ignoring the substantial cost of client access licenses for Microsoft servers.)
$1.2M can pay for a lot of glitches. It can buy 7000 man-hours of top engineering support (at $100/hour), and still be a net savings.
And this analysis ignores the effects of reliability (cash registers crashing == customer alienation and lost sales), and long-term supportability (trying getting Win2K support in 2008).
And I've never heard of a natural pesticide that is as dangerous as man-made ones.
Many common plants contain extremely toxic chemicals. Make a salad of tobacco and the nicotine will kill you. Amanitas phalloides mushrooms are famously poisonous. So is jimson weed. Many spices and flavoring herbs are poisonous in larger quantities. Numerous plants contain potentially dangerous amounts of oxalic acid. Milkweed is so poisonous that many insects can't eat it. Monarch butterflies do, however, and in the process become so poisonous that nothing will eat them; another species of butterfly evolved to look like monarchs to scare off predators.
Man-made pesticides do awful things to your body and the environment.
Rubbish apocalyptic religion. The scientific truth can be found by simply looking outside: if pesticides were as bad as the envirodorks say, everything would be dead.
(The main problem with synthetics are that certain chemicals structures are highly persistent, esp. molecules containing halogens or aromatic rings. If you use them indiscriminantly, they tend to build up over time, which is much worse than simply being toxic.)
They can't add fertilizers, etc, that speed up the growth of the plant/fruit/vegetable, but often leave them tastless.
Breeding for durability is a bigger part of the problem. From a seller's point of view, a good tomato is one that can be spend weeks in a truck; taste is simply not a consideration. Likewise, a florist's ideal rose is indestructible, rather than a fragrant variety you'd want to grow in a garden.
1. Have premium components on hand. If somebody is willing to pay $70 for speakers, they're probably willing to pay $75. If all you have are $12 speakers, it's hard to tack on a completely gratuitous $5 of profit.
2. Sell quiet computers. Keep the showroom quiet so you can point out how quiet the machines are.
3. Except for the simplest things like picking out the right cable, charge for support. Keep the rates reasonable, and charge in small (5-10 minute) increments. Support includes helping them select virus scanners and firewalls, setting it up to call their ISP, recovering from crashes and infections, backups, etc. Many people have real trouble with the most basic things.
4. Charge for training. I personally would not want to do training, but if you can stomach it it's a revenue source. There are companies that do nothing but computer training.
5. Promote the price-saving aspect of upgrades.
6. Hopefully this is so obvious you've already done it, but standardize on a few models of boards (motherboard, video card, etc.) Hunting for upgrades and drivers, and making them play well together, burns time and therefore money.
7. Use OEM OSes. Retail Windows 2000 is $200. (Or is it $300? I forget.) OEM Win2K is $85.
8. If you're doing free/discounted support, choose OSes that tend not to break. E.g., use Win2K and set the security up properly.
9. Sell support packages. (Other people have mentioned this.)
10. It's hard to sell premium services if the shop feels like a grocery store. Have comfy chairs for the customers to wait in. If you need to discuss, e.g. different options for a custom machine, have a table that the two of you can sit at.
11. Housecalls. People who can pay for them, can pay a lot for them.
12. Promote your services. Advertise, have signs in the store, make sure machines leave with pamphlets, get their address and follow up with mailings, bring it up as you're selling.
13. Salesmanship. How you sell often determines whether you make the sale, not what you sell. Don't offer a maintenance contract, ask them what they're going to do when the software inevitably eats itself. Don't be exaggerate or be melodramatic, just tell it like it is. If they decline, tell them they can always come in for service later.
Every object (mutex, sem, section, event, thread, process, file, socket, etc) in Windows can be waited on, and you can wait on any number and combination of objects at once, in either an AND or OR configuration. e.g. wait for a mutex AND an async socket IO; or wait for a semaphore OR a thread to end OR an event.
Not serial ports--they take a different API. (Last I heard, I may be misinformed.)
Linux has kernel scheduled processes, userland threads (kernel threads are available)...
As somebody else points out, Linux kernel threads do exist and are usually used. More importantly, the Linux kernel multiprogramming model makes no distinction between threads and processes. A thread is simply a process that shares memory with another process. Linux thread creation and switching are very fast, forking a new process is only a little more expensive than starting a new thread.
A condition variable one of the few time-waitable objects in Linux (all objects are time-waitable in Windows; mutexes and semaphores are not time-waiting in Linux).
However, when your pipes are fast you don't *need* a tasteless profusion of inter-context communication, and Linux pipes are time waitable (using the conventional I/O waiting API: select, poll,/dev/poll). The only thing Linux lacks is the ability to wait for several conditions to become true using a single system call. (You can do AND with blocking read(2), but you can't wait on anything else at the same time.)
Benchmarking thread creation is a load of crap. Few seriously high-performance servers use a thread-per-connection architecture anymore; and at the very least they use thread pools.
If your threads suck, you are constrained to use a thread pool. If your threads are good, you can use whatever is appropriate for the job. (There are many small jobs that thread-per-connection will handle just fine provided your OS isn't raping you for it.)
Slashdot Mirror
Simply put, anybody who uses the free version is walking on legal quicksand, and by extension so are the projects they contribute to. I know that Larry McVoy almost certainly won't run somebody into the ground just because he can, but what if BitMover goes bankrupt, perhaps many years from now? In that case, the right to sue under the BK license would devolve to the creditor, who could be considerably less friendly. A contract that depends on the goodwill of a particular person is an exceedingly dangerous legal instrument, and can blow up in your face with no warning. I wouldn't touch the free version of BK with a ten foot pole.
That's why RMS is getting excited: not because BitMover is evil today, but because somebody nasty could gain retroactive control of license enforcement tomorrow, and use that to disrupt free software projects.
Personally I don't have any problem with the pay/lease versions of BK. You pay, you get the software, pretty standard and safe. What I have a problem with is a legal minefield masquerading as freeware.
The same issue applies to competition. Is Perforce competition? Certainly. What about Subversion? Probably. What about an engineering doument control system? Maybe. What about a web content management system? Maybe. If I add version tracking and rollback to the web content system, does it become more competitive? Who knows? If the content system uses an object database (e.g., Zope) instead of a classical filesystem, does that make it less competitive? Who knows? What about a weblog system that tracks updates? Who knows?
"Who knows?" scares me. I don't like contracts where I don't know where I stand, but where I can be retroactively declared to be in violation. Contracts like that are the stuff of nasty legal battles.
Sounds like a great way to take a core sample of your thumb too...
OTOH, they're not an efficient use of aluminum--the cans are damn thick.
Obligatory on-topic Nakamura statement: Nakamura's situation is a damn shame. He has done more for the human race than most medium-sized cities. Nichia's failure to reward him is shameful, and as an electrical engineer who designs blue emitters into products, I shall not forget it. Can you say design loss?
Wouldn't work. When one bank is driving the shared bus, the other has to be turned off, and standard DDR modules won't have the correct timing for that.
Because s/he apparent couldn't use Google to find the Unix versions.
My suggestions: The City and the Stars by Arthur C. Clarke is classic sci-fi dystopia. The Folk of the Fringe by Orson Scott Card is an optimistic post-apocalyptic dystopia.
Besides, the vendors can't wait until their customers hit the limit to start designing the next generation of hardware. From project start, it takes 3-6 years to get a new CPU core to the mass market.
The P4 trace cache is cool, but (1) it's only 12Kops deep, and (2) it doesn't globally optimize, it just remembers. OTOH, if global optimization was easy we'd all be buying Itaniums.
I wouldn't underestimate the importance of low power design at the architectural level. If you could design a P4 1 GHz-equivalent computer that would fit in a shirt pocket and run 12 hours on a charge, you'd have a sales winner. And you will never be able to do that using the P4 or Itanium approaches (cache and prefetch the shit out of everything, and use the widest & fastest busses that can be fabbed and packaged). Smart portable devices are the future of computing, if for no other reason than the desktop market is saturating(ed).
Also, the fastest CPUs are rapidly approaching the propagation delay limit and pipelining is running out of steam (look at the absurd 20-stage pipeline of the P4). Past that limit, advances in throughput will come from parceling out work units to sub-CPUs. Transmeta's approach has some chance of untangling the dependencies and creating the work units, but a hardwired decoder is hopeless. I'd just say "SMP" (or ultrahypermegathreading buzzword of the week), but software designers have a poor history of moving beyond uniprocessor.
I think it was the external bus they underestimated. If the CPU is a lot faster than its bus, there's a huge payback for reducing cache misses and stalls through optimization. So far Intel has (partially) defeated that problem by clever heuristics and big improvements in the bus, but the bus can only be improved so far. (When I first heard how the P4 was keeping the bus saturated to improve performance, I was shocked that they would resort to such a sledgehammer approach, and also shocked that that approach had a payback.) At some point the only solution will be intelligent prefetching. Worse luck for Transmeta, that point is probably several years in the future. No reasonable amount of P4 microcode will ever run Java, Python, or C#.The Transmeta instruction decoder, on the other hand, is extremely fine-grained. It gives code the amount of attention it deserves. For rarely-executed code, the decoder wastes little power and does a suboptimal decoding. The more frequently code is executed, the more power the decoder burns to optimize it. Especially frequent decodings are cached so they can be used later with zero decoding. (Which hardwired decoders have a lot of trouble doing.)
The Transmeta decoder also has the potential for really neat tricks. E.g., you could put multiple ALUs and FPUs in the CPU, but leave them completely turned off except when a heavy-duty computational algorithm truly needs them. Ditto for power-hungry L1/2 caches. When your decoder is firmware, you can afford to try all sorts of things, and just not use them if it's too hard to get right, but complexity like that gives nightmares to the designers of hardwired decoders.
You mean like IA-32?Win2K Pro costs around $75, and requires on the order of $50 in extra hardware (big hard drive, extra RAM, faster CPU) to run well. For 9700 cash registers, Windows increases the cost by $1.2M. (I'm ignoring the substantial cost of client access licenses for Microsoft servers.)
$1.2M can pay for a lot of glitches. It can buy 7000 man-hours of top engineering support (at $100/hour), and still be a net savings.
And this analysis ignores the effects of reliability (cash registers crashing == customer alienation and lost sales), and long-term supportability (trying getting Win2K support in 2008).
(The main problem with synthetics are that certain chemicals structures are highly persistent, esp. molecules containing halogens or aromatic rings. If you use them indiscriminantly, they tend to build up over time, which is much worse than simply being toxic.)
Breeding for durability is a bigger part of the problem. From a seller's point of view, a good tomato is one that can be spend weeks in a truck; taste is simply not a consideration. Likewise, a florist's ideal rose is indestructible, rather than a fragrant variety you'd want to grow in a garden.2. Sell quiet computers. Keep the showroom quiet so you can point out how quiet the machines are.
3. Except for the simplest things like picking out the right cable, charge for support. Keep the rates reasonable, and charge in small (5-10 minute) increments. Support includes helping them select virus scanners and firewalls, setting it up to call their ISP, recovering from crashes and infections, backups, etc. Many people have real trouble with the most basic things.
4. Charge for training. I personally would not want to do training, but if you can stomach it it's a revenue source. There are companies that do nothing but computer training.
5. Promote the price-saving aspect of upgrades.
6. Hopefully this is so obvious you've already done it, but standardize on a few models of boards (motherboard, video card, etc.) Hunting for upgrades and drivers, and making them play well together, burns time and therefore money.
7. Use OEM OSes. Retail Windows 2000 is $200. (Or is it $300? I forget.) OEM Win2K is $85.
8. If you're doing free/discounted support, choose OSes that tend not to break. E.g., use Win2K and set the security up properly.
9. Sell support packages. (Other people have mentioned this.)
10. It's hard to sell premium services if the shop feels like a grocery store. Have comfy chairs for the customers to wait in. If you need to discuss, e.g. different options for a custom machine, have a table that the two of you can sit at.
11. Housecalls. People who can pay for them, can pay a lot for them.
12. Promote your services. Advertise, have signs in the store, make sure machines leave with pamphlets, get their address and follow up with mailings, bring it up as you're selling.
13. Salesmanship. How you sell often determines whether you make the sale, not what you sell. Don't offer a maintenance contract, ask them what they're going to do when the software inevitably eats itself. Don't be exaggerate or be melodramatic, just tell it like it is. If they decline, tell them they can always come in for service later.
The article quotes 97% attenuation, which is 15dB, which is little enough that there's no point in doing it.
Also that weird non-ducted turbofan that had the vanes mounted on the outside. (Did that ever make it into commercial production?)
Two words: Bussard ramjet. (Not that I think it can work, but, hey, it's fun to think about.