There has been a drive towards the paperless office for many years now, yet the statistics show that we're using more paper per person than ever before? I propose that the reason for this is that older, management-type people who have been working for the past 20 years have a mental block against non-paper goods.
I'm afraid I have to disagree with this. I'm 23, and most of my work logs and notes are on paper. Paper has a very convenient, powerful, and user-friendly interface, is non-volatile, and if stored properly has a very long mean time before failure.
You can't embed hyperlinks in paper or run a search engine on it, but it is very good for the things that I use it for (mainly quick reference and archiving).
This is why I think that it will be a long time before paper disappears, if it ever will.
I feel sorry for anyone trying to build up marketing information based on the crap I type in.
This is really very funny. As a user, I find the picture of spammers trying to grapple with this kind of data hilarious - but as a person who has worked on similar data mining before, I find it interesting and amusing that it affects the results not one bit. It just hurts the spammers ("LART that pinhead!"):).
The statistical techniques that Gates alludes to look at average access patterns by various types of user, inferring the user types from the access patterns themselves. All they need in order to work is a tag that lets them track whichever user just started browsing. They don't need to know who the person behind the terminal is; just which hits come from which nameless user. This can be done by checking IP numbers or by handing out cookies, and generates useful statistical data.
Marketing, OTOH, gets some very creative contact information. I wonder how many times the canonical North Pole address has turned up?
Money, money, and money. Sell, sell, sell... and make more money so you can make even more money... hmm It amuses me when salespeople think they know what I want or need.
They don't know what you, personally, need, but they don't have to. The kind of data mining mentioned builds up information about what various types of "average users" need. Regardless of whether or not this corresponds to actual people, it does contribute usefully to marketing by letting them target their sales pitches more effectively to the statistical whole.
I worked on a similar software project a few years ago. It would have been able to do this quite effectively, but we ran out of development money.
Oh, did I mention the personal privacy: "Identifying the date and times involved in sequences of frequently visited web pages or frequent episodes of phone calling patterns. Finding all groups of items that are bought together with high frequency." Be careful - the "big brother" is watching you. Did you notice the frequent use of Identifying. I have an idea: how about a personal ID card with all personal info can be found. Seems pretty exciting.
You don't need to know who the users are; just what they do. As far as a statistician is concerned, you beam in, look at a few things, and beam out again. They don't need to know anything more to adjust their advertising and list of offered services.
This doesn't mean that they wouldn't _like_ to know more. If marketing could, for instance, get your mailing address they'd be happy to spam you with targeted junk mail. However, that's a secondary issue. The statistical techniques mentioned above can be applied to anonymous accesses.
I dislike MS's monopolist practices and shoddy code as much as the next person, but do we really need "reviews" of Gates' books which proudly announce that the reviewer hadn't read the book and then go on to trash it?
There were substantial portions of the book available on the web. He took care to address only these portions, supporting his opinions with quotations. This will cause some bias from his source sample being incomplete, but IMO the review was still useful.
>> How many employed programmers are there in North America?
Again, I don't know. Also lots. Sh*t loads, even. However, most of them are in-house programmers. The kind of programming that will *never* be Free Software, because it never get distributed outside the company. Trade secret, as it were.
Close, but not quite.
The vast majority of programmers are working on closed software for products that are intended to be sold. These are applications that their employer hopes to sell, or and operating system that their employer hopes to sell, or drivers that their employer has been contracted to write.
The _source_ for these projects isn't distributed outside of the companies, but the binaries sure are. That's how the companies make money, and why they hired the programmers in the first place. Programmers are _hired_ so that whoever hires them can make money.
So, whatever alternate scheme is proposed must still put money in the pockets of whoever is paying the programmers. At least enough to pay the programmers, and preferably enough to give the parent organization an incentive to start the project in the first place.
Now, not all of these projects are incompatible with open source and free software ideals. Most notably, driver design lends itself to the open paradigm, and relatively mature software products can eventually cross over.
Drivers lend themselves to being open because the person contracting for them is a hardware manufacturer. They don't make money from the sale of the drivers themselves; in fact, they often make them freely available on the web, in the graphics industry at least. If more people have the driver binaries, then more people buy their hardware. They would almost certainly be overjoyed to have the open source and free software communities write drivers for their cards, because it means that the exposure would be even greater and they'd have a larger debugging pool. Dropping a driver request into the free software community might not produce results quickly, but neither does ultimately releasing the source have any drawback. A probable scenario here is that harware developers would contract for the first version of the driver to be written, and then release the source so that they wouldn't have to pay for maintainence. They get a self-sustaining driver and increased hardware sales, and the free software community gets a neat toy to play with.
There are two reasons why this isn't done now. The first is inertia, which is a powerful force in industry. The second is paranoia. Most graphics hardware companies, at least, feel that their competitors Must Not See the register and programming specifications for their cards, as that would give them detailed knowledge of how their cards work and allow their competitors to one-up them. In practice, this isn't true (I speak as a graphics driver developer), but that is the prevailing mode of thought. I hear that Matrox has opened up a bit on this, though.
Releasing mature software products as open source doesn't benefit a company, but neither does it particularly hurt it, and it does provide potential side-benefits.
A "mature" software product in this purpose is one whose core is fundamentally complete, that is only undergoing costmetic changes or feature tweaks. I would argue that word processors and basic image manipulation programs fall into this category, though there are extensions to each that are still vivacious. Browsers probably fall into this category also, though the patchwork additon of new types of content on the 'net prevents this from completely stagnating (java, javascript, active X, and what-have-you are nontrivial to implement but must be supported regardless of their respective usefulness). When a type of product matures, there is a certain common feature set that is expected by users, there are multiple product offerings from many vendors, and the pace of development on all of these offerings has slowed or moved into the creeping featurism stage.
A "mature" class of product will tend to move into the open source / free software circle inevitably, because somebody will write an open / free version of it. The expected feature set is well-defined, and the implementation, while possibly complex, is not intrinsically difficult. A company that is developing such a product could benefit from releasing it to the open / free communities in three ways. Firstly, it gains brownie points by doing a Good Deed and supporting Open Source etc. etc. Secondly, if the product is halfway sane, the company's protocols/formats or a close variant thereof become the de facto standard for any other programs or utilities that manipulate similar data. This gives the company a head start on being able to import/export to these formats from its proprietary applications. Thirdly, this frees up resources within the company to work on more dynamic projects while their competitors are stuck supporting dead-end products.
The disadvantage is that the company must have new, living projects already in progress. If it doesn't, then either it releases the source and dies quickly, or holds on to it and sinks sedately into the mire. Either way it's out of luck.
Now, projects that the parent companies do *not* tend to benefit from releasing are the living, non-mature products that are still in the process of evolving into their final forms. If a company is selling such a product, then it believes that its product is presently the best on the market - it implements some essential function that its competitors don't, yet. Further, the company believes that it can continue to develop and extend its product in useful directions, and reap substantial benefits from doing so. If the company made the software free / open at this point, it would lose any advantage that it had over its competitors and most likely lose out on the (very substantial) direct revenue made from selling the product. It could try to make up the difference through consulting or tech support, but the returns from that would pale in comparison to those from development and sale of the product. Further, any development that it did from that point on would benefit not only it, but its competitors as well. There would be no advantage to working on it.
So, companies tend to keep major works-in-progress to themselves, and I doubt that this will change even if they do embrace open and/or free ideals. The silver lining is that if they do embrace the ideals to the extent that they can, we may have nifty source to play with when the products finally mature.
If it takes too long, we develop our own versions in the meantime.
>> How many employed programmers are there in North America?
Again, I don't know. Also lots. Sh*t loads, even. However, most of them are in-house programmers. The kind of programming that will *never* be Free Software, because it never get distributed outside the company. Trade secret, as it were.
Close, but not quite.
The vast majority of programmers are working on closed software for products that are intended to be sold. These are applications that their employer hopes to sell, or and operating system that their employer hopes to sell, or drivers that their employer has been contracted to write.
The _source_ for these projects isn't distributed outside of the companies, but the binaries sure are. That's how the companies make money, and why they hired the programmers in the first place. Programmers are _hired_ so that whoever hires them can make money.
So, whatever alternate scheme is proposed must still put money in the pockets of whoever is paying the programmers. At least enough to pay the programmers, and preferably enough to give the parent organization an incentive to start the project in the first place.
Now, not all of these projects are incompatible with open source and free software ideals. Most notably, driver design lends itself to the open paradigm, and relatively mature software products can eventually cross over.
Drivers lend themselves to being open because the person contracting for them is a hardware manufacturer. They don't make money from the sale of the drivers themselves; in fact, they often make them freely available on the web, in the graphics industry at least. If more people have the driver binaries, then more people buy their hardware. They would almost certainly be overjoyed to have the open source and free software communities write drivers for their cards, because it means that the exposure would be even greater and they'd have a larger debugging pool. Dropping a driver request into the free software community might not produce results quickly, but neither does ultimately releasing the source have any drawback. A probable scenario here is that harware developers would contract for the first version of the driver to be written, and then release the source so that they wouldn't have to pay for maintainence. They get a self-sustaining driver and increased hardware sales, and the free software community gets a neat toy to play with.
There are two reasons why this isn't done now. The first is inertia, which is a powerful force in industry. The second is paranoia. Most graphics hardware companies, at least, feel that their competitors Must Not See the register and programming specifications for their cards, as that would give them detailed knowledge of how their cards work and allow their competitors to one-up them. In practice, this isn't true (I speak as a graphics driver developer), but that is the prevailing mode of thought. I hear that Matrox has opened up a bit on this, though.
Releasing mature software products as open source doesn't benefit a company, but neither does it particularly hurt it, and it does provide potential side-benefits.
A "mature" software product in this purpose is one whose core is fundamentally complete, that is only undergoing costmetic changes or feature tweaks. I would argue that word processors and basic image manipulation programs fall into this category, though there are extensions to each that are still vivacious. Browsers probably fall into this category also, though the patchwork additon of new types of content on the 'net prevents this from completely stagnating (java, javascript, active X, and what-have-you are nontrivial to implement but must be supported regardless of their respective usefulness). When a type of product matures, there is a certain common feature set that is expected by users, there are multiple product offerings from many vendors, and the pace of development on all of these offerings has slowed or moved into the creeping featurism stage.
A "mature" class of product will tend to move into the open source / free software circle inevitably, because somebody will write an open / free version of it. The expected feature set is well-defined, and the implementation, while possibly complex, is not intrinsically difficult. A company that is developing such a product could benefit from releasing it to the open / free communities in three ways. Firstly, it gains brownie points by doing a Good Deed and supporting Open Source etc. etc. Secondly, if the product is halfway sane, the company's protocols/formats or a close variant thereof become the de facto standard for any other programs or utilities that manipulate similar data. This gives the company a head start on being able to import/export to these formats from its proprietary applications. Thirdly, this frees up resources within the company to work on more dynamic projects while their competitors are stuck supporting dead-end products.
Now, projects that the parent companies do *not* tend to benefit from releasing are the living, non-mature products that are still in the process of evolving into their final forms. If a company is selling such a product, then it believes that its product is presently the best on the market - it implements some essential function that its competitors don't, yet. Further, the company believes that it can continue to develop and extend its product in useful directions, and reap substantial benefits from doing so. If the company made the software free / open at this point, it would lose any advantage that it had over its competitors and most likely lose out on the (very substantial) direct revenue made from selling the product. It could try to make up the difference through consulting or tech support, but the returns from that would pale in comparison to those from development and sale of the product. Further, any development that it did from that point on would benefit not only it, but its competitors as well. There would be no advantage to working on it.
So, companies tend to keep major works-in-progress to themselves, and I doubt that this will change even if they do embrace open and/or free ideals. The silver lining is tha
"Anyone who's taken high-school physics can infer this if they're reasonably bright."
Yup. So can physics, chemistry, or engineering majors. I think that one of the great failures in limiting nuclear proliferation has been permitting foreign nationals to attend US colleges and uiniversities. It makes all the sense in the world to me for the US to open its borders and permit people of all nations to renounce their native citizenship, live in the US, become US citiznes, and learn all they want to. It strikes me as the height of insanity to train foreign nationals in fields which would permit their national governments to conduct a nuclear war against us.
I sincerely hope that you're being sarcastic.
Firstly, the idea of restricting knowledge sufficiently that nobody in a target nation can figure out how to build nuclear weapons is extremely disturbing. It simply _isn't_that_hard_. You would literally have to restrict everything down to basic physics texts, which seriously hampers the ability of the target nation to perform R&D in any modern industries. Is this a tolerable goal? IMO, *no*.
Secondly, it is physically impossible to restrict knowledge to the required extent. Take a look at the "anarchy" text files that were endemic in the BBS world ten years ago. Any country with a communications network of any reasonable efficiency can distribute information more quickly than it can be destroyed. All it would take is one person smuggling in a high school physics textbook - or one person to download a semi-accurate "how to build a nuke" text from the 'net - to make all of your effort worthless. Should you then destroy the communications network also? IMO, this isn't tolerable either.
So, in order to forcefully prevent countries that you don't like from learning _how_ to develop nuclear weapons, you would have to destroy both their industrial base and their communications network, and leave them locked at an early 1900s technology level. This doesn't sound justifiable to me. I was under the impression that the US supported freedom for everyone, not just themselves.
There are other alternatives. IMO, a combination of all of them would be the most effective approach:
Develop a good "nuclear umbrella".
Mutually assured destruction was a wonderful deterrent to nuclear war. The cold war actually _ended_, because both sides realized that they'd really rather not fight.
Aim your policies at catching people who produce useful amounts of weapons-grade material.
Producing enough plutonium for a nuclear weapons program takes a nuclear reactor. These put out enough gamma radiation that you can detect them from space without any difficulty, even if they're shielded. The US already has a network of satellites that does this, if I understand correctly. This network also detects any nuclear tests that are performed.
A terrorist organization could try producing enough material in their basement for one bomb, by any of several methods, but that too can be detected if you put up an umbrella of improved satellites, or overfly suspicious locations with planes carrying radiation detectors.
Promote education, democracy, and peace.
It's counterproductive to nuke someone. You just don't get a net benefit. Tyrranical leaders might not be concerned with this, but elected leaders are answerable to the people. Education allows industry to flourish, which gives the working class more money. More money in the hands of the working class means more personal freedom, and luxuries like communications networks that allow new ideas to filter in. These set the stage for governmental reform, which leads to checks on the leaders' power, even more freedom among the populace, and economic ties to the rest of the world, making nuclear war even less attractive.
So, in summary, I think that there is a better approach than the unfair one that you propose.
No, not tech support. Service. This means more along the lines of implementation -- fitting a product in with other products/needs in a business setting.
There are very significant problems with this:
There isn't enough demand.
Very few of the people that I've seen advocating alternate systems for making money by programming seem to appreciate how _many_ programmers there are. If every company that used software needed constant software firefighting, then I could see there being enough demand, but hopefully our software is better than this. The market for customization is much smaller than the market for software in general (and the latter is the market that you have to find an alternate means of paying for).
Companies have a vested interest in not paying for _open_ customizations.
As that would let their competitors use the same customizations for free. Heck, that might also give their competitors insight into what they are doing. They would be the sole entities paying for something that benefits many people; as companies are and always will be money-driven, it makes far more sense just to let someone else take the plunge. The same applies to most users, who would rather leech than fund (say) game development. How much of your shareware did you actually register? How much of your freeware did you send in donations for?
I'm not trying to be hostile here; I'm just trying to make sure that all arguments are firmly grounded in reality. There may well be ways to make this fly, but I haven't seen any presented yet.
Really, how many programmers are coding shrink-wrapped/commercial software? And how many more are working on custom implementations?
Very many and relatively few, respectively. Remember, it is applications development that rakes in most of the money for most software houses. By and large, this is done by writing an application, seeing it take off, and writing progressively better versions of it. Customization sometimes occurs but is rare, as there has to be enough of a market to justify putting in the effort to customize as opposed to improving the main product.
I say again - I would be overjoyed if someone could demonstrate an open and/or free software system that employs the same number of programmers for the same wages; it would be a win/win situation for me (I could code and look at other nifty code, and I'd still get paid). However, I have yet to see a system presented that could be implemented in practice (good ideas notwithstanding).
Service does not necessarily mean technical support of end users. Service can mean things such as Consulting services for new installs of large user bases, networks, etc. It can also mean providing other services, i.e. Internet access, storage services, etc.
There is a glut of ISPs already. The only software-related service industry that I know of that makes real money is consulting, and it's easy enough to demonstrate that this won't keep most of the former programmers off the street:
How many employed consultants are there in North America?
How many employed programmers are there in North America?
Whatever scheme is put in place, you have to end up paying the same number of programmers the same amount of money. Either the programmers themselves have to change jobs (and I'd like to *keep* getting paid to program), or else the service-oriented companies have to make enough money to pay the programmers to keep upgrading the product. I have yet to see a realistic scenerio presented that would do this.
The best scenario that I've seen yet was a suggestion that users wanting applications form user groups and hire programmers to write them. However, I am a bit too cynical to think that this kind of coordination is likely among the masses of users out there. There are a host of auxiliary problems, also, but I've already posted at length on this subject in other articles.
I think that free and/or open software is _good_, but I also think that the proprietary software industry is here to stay. At best, free and open software can keep them honest (still a worthy goal).
Someone else mentioned this possibility; take a non-critical fissionable mass, and start it on the path to fission with this laser; as long as it produces more power than is necessary to power the laser, we now have a fission reactor that generates its own power, and can't melt down because of a failure in the control process; if the laser shuts down, then the entire system stops fissioning! Instead of huge containment and control systems, a simple fuse and feedback loop to kill the laser if it overworks itself would do the job!
Yeah, there are always negative consequences to new discoveries and revelations, but imagine if sustainable fission in a room the size of your closet were possible?
There are a couple of difficulties with this. First of all, while you will get a short chain reaction starting, it will be _pretty_ short - unless you're using a sample that's _just_ shy of critical mass, I don't think you'll get more than a factor of ten magnification of your energy input. This sounds good, until you realize that most neutron production schemes are abysmally inefficient (millions-to-one inefficient or worse). If you try to increase the magnification factor by using a barely-subcritical mass, you have the problem of someone sneezing and its geometry changing to be within the critical envelope (or the original builder adding a milligram too much material).
However, there's a bigger problem with closet-sized fusion reactors - radiation. A conventional fission plant has several metres of concrete between the reactor core and anything else. This isn't because of the amount of radiation produced, but because of its penetration distance. Gamma rays can go a very long way through solid material before being stopped. A closet-sized fission reactor would slowly kill everyone on the block.
There are also issues of the size of the steam turbines and the multiple layers of isolation that prevent a reactor from easily leaking radioactive material, but I'll leave those for now.
So, a neat idea, but a bit dangerous to implement in practice:).
Heck, if you had weapons-grade U235 and weren't worrying about radiation, you could build a fission-powered steam generator the size of a breadbox without needing a neutron source.
Here's why you should not be happy about this story. This device doesn't produce useful fusion energy, but it does produce hot neutrons, and it does so cheaply. What good are hot neutrons? They can be used to transmute non-fissionable isotopes of into fissionable isotopes.
Fissionable isotopes are rare. Denying third-world bohemian have-nots access to fissionable isotopes is the linchpin of our nuclear non-proliferation strategy.
Then I'm afraid you'll have to find an alternate strategy. As another poster pointed out, you can produce copious quantities of hot neutrons quite cheaply by firing a deuteron beam into a lithium target. Anyone who's taken high-school physics can infer this if they're reasonably bright. Unless you intend to burn all physics textbooks, your have-nots will be perfectly capable of building their own devices regardless of whether they can buy yours or not.
A similar argument applies to strong encryption techniques.
In other words, small scale fusion reactors already exist, so why is this one special, other than being novel for using a laser for acceleration instead of an high-voltage electric field?
Because it's cheap, if I understand correctly:).
Also, they've been using a similar (though less powerful) laser at the University of Toronto for energy absorption studies to assist laser fusion research, so there is some additional tangential benefit. I'm curious as to whether duterium microclusters might absorb energy more efficiently than the pellets used in most laser fusion schemes. Just a thought.
moment imagine a world where a photosynthesis reaction provides the decomposition of water to its base elements, hydrogen and oxygen. These may then be re-combined in an exothermal reaction to provide heat.
IMO, it would be easier and just as useful to just crow appropriate crops and ferment them to produce methanol. Methanol burns almost as cleanly as hydrogen, is easier to store and transport, and can be used in appropriately designed internal combustion engines.
The main problem with methanol is that it can corrode metal engines at high temperatures, but I hear that good progress is being made re. ceramic engines, which are much more resistant to chemical attack (and are lighter to boot).
You don't have to worry about people drinking the methanol. Ethanol is drinkable; methanol is poisonous.
However, as another poster pointed out, your power production is still limited to the amount of power received by the earth from the sun in this scheme.
This definitely points at the fact that a low powered(relatively) setup can *start* the fusion process, while a secondary setup and process would maintain it, whether it be tokamaks or more lasers and such.
An interesting idea, but it turns out that this isn't necessary. All three of the styles of fusion reactor design that I know of have no problem triggering fusion. The difficulty is in keeping the plasma concentrated enough and hot enough for fusion to be sustained for a useful length of time.
For reference, the three styles that I know of are laser-induced fusion, magnetic confinement fusion, and a rather nifty scheme involving heating and confinement via extremely intense x-ray radiation produced by incandescent plasma.
Another point about the efficiency; it needn't truly be able to generate more energy than it uses if some way of tapping into non-useable energy(such as heat or solar) can be used. Imagine a system that is 92% efficient, but if 10% of the energy needed to operate the system could by harnessed by solar collectors in orbit, and we only need to provide 90%, the 2% difference would then be useable by us, with the remainder used to power the system.
I'm not sure that I follow your logic here; IMO, we'd be better off using the 10% from the solar satellites directly as opposed to the 2% surplus that we'd acheive from such a scheme. Also, there is the more significant problem of efficiency being closer to a billionth of a percent.
Bringing the efficiency up seems to require very large devices, though these are still buildable.
It seems to me that the efficiency of the device is most likely pretty bad. I dont know for sure, but it looks like the clusters would have to be in the laser beam, and even then its random how many of the atoms colide.
The efficiency of the device is *extremely* bad, mostly because the small clusters don't retain energy long enough to keep fusion going long enough to produce much energy (look up the "Lawson Criterion" for interesting information on this subject).
The laser delivers about 1000 J of energy over the course of 1 picosecond. The fusion produces about 10,000 neutrons. Making a _very_ rough estimate, let's assume that each reaction producing a neutron liberated a total of 10 MeV. This corresponds to a total energy produced of about 100 GeV, or 1.6e-8 J.
That puts its energy efficiency at about 0.000000001%, plus or minus a couple of orders of magnitude:).
To keep enough plasma confined for long enough to produce a useful amount of energy, you need to use larger amounts of deuterium (pellets a few tens of microns across IIRC), and extremely powerful lasers. This is what the other laser facility mentioned in the article is for.
There are at least two other ways to produce fusion relatively economically; we'll see which is finally adopted for power production some time within the next 50 years or so.
So in 10 years we can figure out a way to apply this towards real sustainable fusion, or table top fission(As another reply to your post mentioned...), or something else totally wacky unthought of (like computers - electrons!)...
This device was developed as a research tool for producing energetic neutrons. It's very useful in that regard, but research on this device doesn't contribute much towards fusion power generation. That's what the other laser that the article mentioned is for:).
I hadn't thought of using this as a fission trigger, though. That might actually be practical.
My understanding was that the Amiga died because Commodore decided to fire its engineering department and milk the product for all it was worth until it ran into the ground. This is second-hand, but from a reasonably reliable friend.
Ten or more years ago, the Amiga was a wonderful system. It had the equivalent of a first-generation hardware-accelerated graphics card built into the box years before these became available on PCs, with a cleanly designed system architecture and a reasonably nice OS and interface. This was pre-Win3.1 (remember when 286s were cutting-edge?). Among home users, at least, there was a heated debate over which system (x86 or Amiga) was the more useful. PCs might or might not have had a slight number-crunching advantage, but there were more than enough nifty features on the Amiga to make up for it.
Yes, I saw your post. If that's a "definition", it's not a good one. An apple exec I spoke with agrees that this can be tightened up. He's not digging in his heels on this, so there is little reason for you and I to argue about it.
I have nothing against it being tightened up; I'm mainly responding to the posters who feel that no definition exists at all (and repeat the "Apple-can-take-away-everything-at-whim" line). IMO, the APSL is cryptic but not ambiguous on this.
I'm actually more worried about the wording of secton 12.1, which seems to contradict the wording in other sections. The clause in question is:
"This License and the rights granted hereunder will terminate:... (b) immediately in the event of the circumstances described in section 9.1 and/or 13.6(b)"
This implies that the license will be revoked for _all_ code, while section 9.1 specifies that it is revoked only for Affected Original Code. This could be fixed by a modification along the lines of:
(b) immediately in the event of the circumstances described in section 9.1 (termination applying only to Affected Original Code, as described in section 9.1)
(c) immediately in the event of the circumstances described in section 13.6(b)
While I feel that Apple could be successfully challenged in court if it tried to yank the rug out from somebody using this approach, preventing this from happening in the first place would be nice.
Is a basement full of G3/333's with Total Impact QUad G3/333's filling all four PCI slots, (thereby giving me 15 CPUS) running some program capable of it.
Can you provide concrete prices for how much a box like that would cost? Also, is there a version of Linux or something similarly friendly that will support aggressively multithreaded programs well on that platform? I keep hearing about "Blue G3" problems and SMP not being what it could be, though the second point may not be relevant as this is wouldn't be making many kernel calls.
A minimal K62-400 box (booting off the network, no video card or hard drive) would cost the equivalent of about $400 US up here. Performance would at worst be about half that of a G3 (I'd need to check the spec figures for both to get a better estimate).
At some point I plan to drop about $10k Canadian ($6.5k US) on something like this, so I do appreciate people pointing out other options.
Though it will probably be most useful as a thought experiment, as I won't have that much free cash for about a year and a half.
I'll ask you this: If you could buy a PC running MacOS or a similarly equipped G3 running MacOS at the same price, which would you pick, ceteris paribus?
That's making a big assumption.
What is the cost/performance ratio for x86s vs. Macs?
I remember studying this at one point with respect to workstations, and coming to the appalling conclusion that the best thing to run the ray-tracer of my dreams on is a basement filled with K62-400 boxes.
The termination issue is based on the lack of a definition of Affected Original Code. They'll define it. Right now, it might mean all code.
Not as far as I can see. Section 9.1 explicitly defines "Affected Original Code" as Original Code that becomes the subject of a claim of infringement. Original Code, in turn, is defined in section 1.6 as "the Source Code of a program or other work as originally made available by Apple under this License, including the Source Code of any updates or upgrades to such programs or works made available by Apple under this License, and that has been expressly identified by Apple as such in the header file(s) of such work.".
So, Original Code is only something that is directly published by Apple.
Now, you could argue that Apple could yank the rug out from under you by republishing Covered Code that you submitted to them, whereupon it would become Original Code and therefore Affected Original Code. However, there are limits to what "Covered Code" covers.
"Covered Code" is defined in section 1.2 as "Original Code, Modifications, the combination of Original Code and any Modifications, and/or any respective portions thereof". "Modifications" are defined in section 1.5 as "any addition to, deletion from, and/or change to, the substance and/or structure of Covered Code", encompassing "(a) any addition to or deletion from the contents of a file containing Covered Code; and/or (b) any new file or other representation of computer program statements that contains any part of Covered Code" [emphasis added].
What this does and does not cover can be assessed by comparing it to the definition of a Larger Work, in section 4. The gist of it is that if you make a bug fix to Apple's code or mess with what Apple gives you directly, it becomes Covered Code. However, if you build a software package _around_ Covered Code, that uses it but adds components that are completely new and different, you have created a Larger Work. As long as you are tidy and keep most of your code in separate files, Apple can only lay claim to the components that are essentially pieces that they supplied to begin with.
One way to overcome this would be with an aging of scores. They mean less as they get older. But this would be difficult to implement and would mean keeping all scores individually with dates on them.
Another way would be to only keep score from the past few (days/months/years). Using some reasonable amount of time. This would be much easier to implement and while you still need to keep scores with dates you don't need to keep them for an eternity.
An easy way to implement aging would be to use an exponential decay aging function. The user's current accumulated average is stored, along with the date of this average's last update. When a new comment's weight is frozen (e.g. after it's been around for a week), it is averaged with the score, with the old score's weight being e^-kt, where t is the difference between the update date and the date of the last score computation, and k is a decay constant. The new post's score is weighted by one minus this value.
Under an exponential decay system a user's old posts still influence their score, but with diminishing weight, without requiring a detailed record of that user's history.
The catch is that once you've added a post's score to the average score, you can't remove it or update it if that post's score changes in the future (hence the one-week waiting period before addition in my example).
we would need VERY fast network cards, to interpret brain waves/bioelectrical pulses into binary into networkable packet data...
Not really. If you had a brain implant, then it would perform preprocessing to filter out only the information that it needed to transfer. This could be very large if you are doing a video feed to or from someone's visual cortex, or very low if you're just using a small area of the motor cortex to control a mouse.
Transmitting the nerve signals generated with perfect fidelity probably isn't needed. Just the relevant information, which can be translated back into nerve signals by the implant.
Slashdot Mirror
I'm afraid I have to disagree with this. I'm 23, and most of my work logs and notes are on paper. Paper has a very convenient, powerful, and user-friendly interface, is non-volatile, and if stored properly has a very long mean time before failure.
You can't embed hyperlinks in paper or run a search engine on it, but it is very good for the things that I use it for (mainly quick reference and archiving).
This is why I think that it will be a long time before paper disappears, if it ever will.
This is really very funny. As a user, I find the picture of spammers trying to grapple with this kind of data hilarious - but as a person who has worked on similar data mining before, I find it interesting and amusing that it affects the results not one bit. It just hurts the spammers ("LART that pinhead!")
The statistical techniques that Gates alludes to look at average access patterns by various types of user, inferring the user types from the access patterns themselves. All they need in order to work is a tag that lets them track whichever user just started browsing. They don't need to know who the person behind the terminal is; just which hits come from which nameless user. This can be done by checking IP numbers or by handing out cookies, and generates useful statistical data.
Marketing, OTOH, gets some very creative contact information. I wonder how many times the canonical North Pole address has turned up?
They don't know what you, personally, need, but they don't have to. The kind of data mining mentioned builds up information about what various types of "average users" need. Regardless of whether or not this corresponds to actual people, it does contribute usefully to marketing by letting them target their sales pitches more effectively to the statistical whole.
I worked on a similar software project a few years ago. It would have been able to do this quite effectively, but we ran out of development money.
Oh, did I mention the personal privacy:
"Identifying the date and times involved in sequences of frequently visited web pages or frequent episodes of phone calling patterns. Finding all groups of items that are bought together with high frequency."
Be careful - the "big brother" is watching you. Did you notice the frequent use of Identifying. I have an idea: how about a personal ID card with all personal info can be found. Seems pretty exciting.
You don't need to know who the users are; just what they do. As far as a statistician is concerned, you beam in, look at a few things, and beam out again. They don't need to know anything more to adjust their advertising and list of offered services.
This doesn't mean that they wouldn't _like_ to know more. If marketing could, for instance, get your mailing address they'd be happy to spam you with targeted junk mail. However, that's a secondary issue. The statistical techniques mentioned above can be applied to anonymous accesses.
There were substantial portions of the book available on the web. He took care to address only these portions, supporting his opinions with quotations. This will cause some bias from his source sample being incomplete, but IMO the review was still useful.
Again, I don't know. Also lots. Sh*t loads, even. However, most of them are in-house programmers. The kind of programming that will *never* be Free Software, because it never get distributed outside the company. Trade secret, as it were.
Close, but not quite.
The vast majority of programmers are working on closed software for products that are intended to be sold. These are applications that their employer hopes to sell, or and operating system that their employer hopes to sell, or drivers that their employer has been contracted to write.
The _source_ for these projects isn't distributed outside of the companies, but the binaries sure are. That's how the companies make money, and why they hired the programmers in the first place. Programmers are _hired_ so that whoever hires them can make money.
So, whatever alternate scheme is proposed must still put money in the pockets of whoever is paying the programmers. At least enough to pay the programmers, and preferably enough to give the parent organization an incentive to start the project in the first place.
Now, not all of these projects are incompatible with open source and free software ideals. Most notably, driver design lends itself to the open paradigm, and relatively mature software products can eventually cross over.
Drivers lend themselves to being open because the person contracting for them is a hardware manufacturer. They don't make money from the sale of the drivers themselves; in fact, they often make them freely available on the web, in the graphics industry at least. If more people have the driver binaries, then more people buy their hardware. They would almost certainly be overjoyed to have the open source and free software communities write drivers for their cards, because it means that the exposure would be even greater and they'd have a larger debugging pool. Dropping a driver request into the free software community might not produce results quickly, but neither does ultimately releasing the source have any drawback. A probable scenario here is that harware developers would contract for the first version of the driver to be written, and then release the source so that they wouldn't have to pay for maintainence. They get a self-sustaining driver and increased hardware sales, and the free software community gets a neat toy to play with.
There are two reasons why this isn't done now. The first is inertia, which is a powerful force in industry. The second is paranoia. Most graphics hardware companies, at least, feel that their competitors Must Not See the register and programming specifications for their cards, as that would give them detailed knowledge of how their cards work and allow their competitors to one-up them. In practice, this isn't true (I speak as a graphics driver developer), but that is the prevailing mode of thought. I hear that Matrox has opened up a bit on this, though.
Releasing mature software products as open source doesn't benefit a company, but neither does it particularly hurt it, and it does provide potential side-benefits.
A "mature" software product in this purpose is one whose core is fundamentally complete, that is only undergoing costmetic changes or feature tweaks. I would argue that word processors and basic image manipulation programs fall into this category, though there are extensions to each that are still vivacious. Browsers probably fall into this category also, though the patchwork additon of new types of content on the 'net prevents this from completely stagnating (java, javascript, active X, and what-have-you are nontrivial to implement but must be supported regardless of their respective usefulness). When a type of product matures, there is a certain common feature set that is expected by users, there are multiple product offerings from many vendors, and the pace of development on all of these offerings has slowed or moved into the creeping featurism stage.
A "mature" class of product will tend to move into the open source / free software circle inevitably, because somebody will write an open / free version of it. The expected feature set is well-defined, and the implementation, while possibly complex, is not intrinsically difficult. A company that is developing such a product could benefit from releasing it to the open / free communities in three ways. Firstly, it gains brownie points by doing a Good Deed and supporting Open Source etc. etc. Secondly, if the product is halfway sane, the company's protocols/formats or a close variant thereof become the de facto standard for any other programs or utilities that manipulate similar data. This gives the company a head start on being able to import/export to these formats from its proprietary applications. Thirdly, this frees up resources within the company to work on more dynamic projects while their competitors are stuck supporting dead-end products.
The disadvantage is that the company must have new, living projects already in progress. If it doesn't, then either it releases the source and dies quickly, or holds on to it and sinks sedately into the mire. Either way it's out of luck.
Now, projects that the parent companies do *not* tend to benefit from releasing are the living, non-mature products that are still in the process of evolving into their final forms. If a company is selling such a product, then it believes that its product is presently the best on the market - it implements some essential function that its competitors don't, yet. Further, the company believes that it can continue to develop and extend its product in useful directions, and reap substantial benefits from doing so. If the company made the software free / open at this point, it would lose any advantage that it had over its competitors and most likely lose out on the (very substantial) direct revenue made from selling the product. It could try to make up the difference through consulting or tech support, but the returns from that would pale in comparison to those from development and sale of the product. Further, any development that it did from that point on would benefit not only it, but its competitors as well. There would be no advantage to working on it.
So, companies tend to keep major works-in-progress to themselves, and I doubt that this will change even if they do embrace open and/or free ideals. The silver lining is that if they do embrace the ideals to the extent that they can, we may have nifty source to play with when the products finally mature.
If it takes too long, we develop our own versions in the meantime.
(/essay)
Again, I don't know. Also lots. Sh*t loads, even. However, most of them are in-house programmers. The kind of programming that will *never* be Free Software, because it never get distributed outside the company. Trade secret, as it were.
Close, but not quite.
The vast majority of programmers are working on closed software for products that are intended to be sold. These are applications that their employer hopes to sell, or and operating system that their employer hopes to sell, or drivers that their employer has been contracted to write.
The _source_ for these projects isn't distributed outside of the companies, but the binaries sure are. That's how the companies make money, and why they hired the programmers in the first place. Programmers are _hired_ so that whoever hires them can make money.
So, whatever alternate scheme is proposed must still put money in the pockets of whoever is paying the programmers. At least enough to pay the programmers, and preferably enough to give the parent organization an incentive to start the project in the first place.
Now, not all of these projects are incompatible with open source and free software ideals. Most notably, driver design lends itself to the open paradigm, and relatively mature software products can eventually cross over.
Drivers lend themselves to being open because the person contracting for them is a hardware manufacturer. They don't make money from the sale of the drivers themselves; in fact, they often make them freely available on the web, in the graphics industry at least. If more people have the driver binaries, then more people buy their hardware. They would almost certainly be overjoyed to have the open source and free software communities write drivers for their cards, because it means that the exposure would be even greater and they'd have a larger debugging pool. Dropping a driver request into the free software community might not produce results quickly, but neither does ultimately releasing the source have any drawback. A probable scenario here is that harware developers would contract for the first version of the driver to be written, and then release the source so that they wouldn't have to pay for maintainence. They get a self-sustaining driver and increased hardware sales, and the free software community gets a neat toy to play with.
There are two reasons why this isn't done now. The first is inertia, which is a powerful force in industry. The second is paranoia. Most graphics hardware companies, at least, feel that their competitors Must Not See the register and programming specifications for their cards, as that would give them detailed knowledge of how their cards work and allow their competitors to one-up them. In practice, this isn't true (I speak as a graphics driver developer), but that is the prevailing mode of thought. I hear that Matrox has opened up a bit on this, though.
Releasing mature software products as open source doesn't benefit a company, but neither does it particularly hurt it, and it does provide potential side-benefits.
A "mature" software product in this purpose is one whose core is fundamentally complete, that is only undergoing costmetic changes or feature tweaks. I would argue that word processors and basic image manipulation programs fall into this category, though there are extensions to each that are still vivacious. Browsers probably fall into this category also, though the patchwork additon of new types of content on the 'net prevents this from completely stagnating (java, javascript, active X, and what-have-you are nontrivial to implement but must be supported regardless of their respective usefulness). When a type of product matures, there is a certain common feature set that is expected by users, there are multiple product offerings from many vendors, and the pace of development on all of these offerings has slowed or moved into the creeping featurism stage.
A "mature" class of product will tend to move into the open source / free software circle inevitably, because somebody will write an open / free version of it. The expected feature set is well-defined, and the implementation, while possibly complex, is not intrinsically difficult. A company that is developing such a product could benefit from releasing it to the open / free communities in three ways. Firstly, it gains brownie points by doing a Good Deed and supporting Open Source etc. etc. Secondly, if the product is halfway sane, the company's protocols/formats or a close variant thereof become the de facto standard for any other programs or utilities that manipulate similar data. This gives the company a head start on being able to import/export to these formats from its proprietary applications. Thirdly, this frees up resources within the company to work on more dynamic projects while their competitors are stuck supporting dead-end products.
Now, projects that the parent companies do *not* tend to benefit from releasing are the living, non-mature products that are still in the process of evolving into their final forms. If a company is selling such a product, then it believes that its product is presently the best on the market - it implements some essential function that its competitors don't, yet. Further, the company believes that it can continue to develop and extend its product in useful directions, and reap substantial benefits from doing so. If the company made the software free / open at this point, it would lose any advantage that it had over its competitors and most likely lose out on the (very substantial) direct revenue made from selling the product. It could try to make up the difference through consulting or tech support, but the returns from that would pale in comparison to those from development and sale of the product. Further, any development that it did from that point on would benefit not only it, but its competitors as well. There would be no advantage to working on it.
So, companies tend to keep major works-in-progress to themselves, and I doubt that this will change even if they do embrace open and/or free ideals. The silver lining is tha
Yup. So can physics, chemistry, or engineering majors. I think that one of the great failures in limiting nuclear proliferation has been permitting foreign nationals to attend US colleges and uiniversities. It makes all the sense in the world to me for the US to open its borders and permit people of all nations to renounce their native citizenship, live in the US, become US citiznes, and learn all they want to. It strikes me as the height of insanity to train foreign nationals in fields which would permit their national governments to conduct a nuclear war against us.
I sincerely hope that you're being sarcastic.
Firstly, the idea of restricting knowledge sufficiently that nobody in a target nation can figure out how to build nuclear weapons is extremely disturbing. It simply _isn't_that_hard_. You would literally have to restrict everything down to basic physics texts, which seriously hampers the ability of the target nation to perform R&D in any modern industries. Is this a tolerable goal? IMO, *no*.
Secondly, it is physically impossible to restrict knowledge to the required extent. Take a look at the "anarchy" text files that were endemic in the BBS world ten years ago. Any country with a communications network of any reasonable efficiency can distribute information more quickly than it can be destroyed. All it would take is one person smuggling in a high school physics textbook - or one person to download a semi-accurate "how to build a nuke" text from the 'net - to make all of your effort worthless. Should you then destroy the communications network also? IMO, this isn't tolerable either.
So, in order to forcefully prevent countries that you don't like from learning _how_ to develop nuclear weapons, you would have to destroy both their industrial base and their communications network, and leave them locked at an early 1900s technology level. This doesn't sound justifiable to me. I was under the impression that the US supported freedom for everyone, not just themselves.
There are other alternatives. IMO, a combination of all of them would be the most effective approach:
Mutually assured destruction was a wonderful deterrent to nuclear war. The cold war actually _ended_, because both sides realized that they'd really rather not fight.
Producing enough plutonium for a nuclear weapons program takes a nuclear reactor. These put out enough gamma radiation that you can detect them from space without any difficulty, even if they're shielded. The US already has a network of satellites that does this, if I understand correctly. This network also detects any nuclear tests that are performed.
A terrorist organization could try producing enough material in their basement for one bomb, by any of several methods, but that too can be detected if you put up an umbrella of improved satellites, or overfly suspicious locations with planes carrying radiation detectors.
It's counterproductive to nuke someone. You just don't get a net benefit. Tyrranical leaders might not be concerned with this, but elected leaders are answerable to the people. Education allows industry to flourish, which gives the working class more money. More money in the hands of the working class means more personal freedom, and luxuries like communications networks that allow new ideas to filter in. These set the stage for governmental reform, which leads to checks on the leaders' power, even more freedom among the populace, and economic ties to the rest of the world, making nuclear war even less attractive.
So, in summary, I think that there is a better approach than the unfair one that you propose.
There are very significant problems with this:
Very few of the people that I've seen advocating alternate systems for making money by programming seem to appreciate how _many_ programmers there are. If every company that used software needed constant software firefighting, then I could see there being enough demand, but hopefully our software is better than this. The market for customization is much smaller than the market for software in general (and the latter is the market that you have to find an alternate means of paying for).
As that would let their competitors use the same customizations for free. Heck, that might also give their competitors insight into what they are doing. They would be the sole entities paying for something that benefits many people; as companies are and always will be money-driven, it makes far more sense just to let someone else take the plunge. The same applies to most users, who would rather leech than fund (say) game development. How much of your shareware did you actually register? How much of your freeware did you send in donations for?
I'm not trying to be hostile here; I'm just trying to make sure that all arguments are firmly grounded in reality. There may well be ways to make this fly, but I haven't seen any presented yet.
Really, how many programmers are coding shrink-wrapped/commercial software? And how many more are working on custom implementations?
Very many and relatively few, respectively. Remember, it is applications development that rakes in most of the money for most software houses. By and large, this is done by writing an application, seeing it take off, and writing progressively better versions of it. Customization sometimes occurs but is rare, as there has to be enough of a market to justify putting in the effort to customize as opposed to improving the main product.
I say again - I would be overjoyed if someone could demonstrate an open and/or free software system that employs the same number of programmers for the same wages; it would be a win/win situation for me (I could code and look at other nifty code, and I'd still get paid). However, I have yet to see a system presented that could be implemented in practice (good ideas notwithstanding).
There is a glut of ISPs already. The only software-related service industry that I know of that makes real money is consulting, and it's easy enough to demonstrate that this won't keep most of the former programmers off the street:
How many employed consultants are there in North America?
How many employed programmers are there in North America?
Whatever scheme is put in place, you have to end up paying the same number of programmers the same amount of money. Either the programmers themselves have to change jobs (and I'd like to *keep* getting paid to program), or else the service-oriented companies have to make enough money to pay the programmers to keep upgrading the product. I have yet to see a realistic scenerio presented that would do this.
The best scenario that I've seen yet was a suggestion that users wanting applications form user groups and hire programmers to write them. However, I am a bit too cynical to think that this kind of coordination is likely among the masses of users out there. There are a host of auxiliary problems, also, but I've already posted at length on this subject in other articles.
I think that free and/or open software is _good_, but I also think that the proprietary software industry is here to stay. At best, free and open software can keep them honest (still a worthy goal).
No, they're producing helium-3. D + D -> He3 + n. Other fusion chains may produce tritium, but this is claimed to be the dominant one.
take a non-critical fissionable mass, and start it on the path to fission with this laser; as long as it produces more power than is necessary to power the laser, we now have a fission reactor that generates its own power, and can't melt down because of a failure in the control process; if the laser shuts down, then the entire system stops fissioning! Instead of huge containment and control systems, a simple fuse and feedback loop to kill the laser if it overworks itself would do the job!
Yeah, there are always negative consequences to new discoveries and revelations, but imagine if sustainable fission in a room the size of your closet were possible?
There are a couple of difficulties with this. First of all, while you will get a short chain reaction starting, it will be _pretty_ short - unless you're using a sample that's _just_ shy of critical mass, I don't think you'll get more than a factor of ten magnification of your energy input. This sounds good, until you realize that most neutron production schemes are abysmally inefficient (millions-to-one inefficient or worse). If you try to increase the magnification factor by using a barely-subcritical mass, you have the problem of someone sneezing and its geometry changing to be within the critical envelope (or the original builder adding a milligram too much material).
However, there's a bigger problem with closet-sized fusion reactors - radiation. A conventional fission plant has several metres of concrete between the reactor core and anything else. This isn't because of the amount of radiation produced, but because of its penetration distance. Gamma rays can go a very long way through solid material before being stopped. A closet-sized fission reactor would slowly kill everyone on the block.
There are also issues of the size of the steam turbines and the multiple layers of isolation that prevent a reactor from easily leaking radioactive material, but I'll leave those for now.
So, a neat idea, but a bit dangerous to implement in practice
Heck, if you had weapons-grade U235 and weren't worrying about radiation, you could build a fission-powered steam generator the size of a breadbox without needing a neutron source.
Fissionable isotopes are rare. Denying third-world bohemian have-nots access to fissionable isotopes is the linchpin of our nuclear non-proliferation strategy.
Then I'm afraid you'll have to find an alternate strategy. As another poster pointed out, you can produce copious quantities of hot neutrons quite cheaply by firing a deuteron beam into a lithium target. Anyone who's taken high-school physics can infer this if they're reasonably bright. Unless you intend to burn all physics textbooks, your have-nots will be perfectly capable of building their own devices regardless of whether they can buy yours or not.
A similar argument applies to strong encryption techniques.
Because it's cheap, if I understand correctly
Also, they've been using a similar (though less powerful) laser at the University of Toronto for energy absorption studies to assist laser fusion research, so there is some additional tangential benefit. I'm curious as to whether duterium microclusters might absorb energy more efficiently than the pellets used in most laser fusion schemes. Just a thought.
IMO, it would be easier and just as useful to just crow appropriate crops and ferment them to produce methanol. Methanol burns almost as cleanly as hydrogen, is easier to store and transport, and can be used in appropriately designed internal combustion engines.
The main problem with methanol is that it can corrode metal engines at high temperatures, but I hear that good progress is being made re. ceramic engines, which are much more resistant to chemical attack (and are lighter to boot).
You don't have to worry about people drinking the methanol. Ethanol is drinkable; methanol is poisonous.
However, as another poster pointed out, your power production is still limited to the amount of power received by the earth from the sun in this scheme.
An interesting idea, but it turns out that this isn't necessary. All three of the styles of fusion reactor design that I know of have no problem triggering fusion. The difficulty is in keeping the plasma concentrated enough and hot enough for fusion to be sustained for a useful length of time.
For reference, the three styles that I know of are laser-induced fusion, magnetic confinement fusion, and a rather nifty scheme involving heating and confinement via extremely intense x-ray radiation produced by incandescent plasma.
Another point about the efficiency; it needn't truly be able to generate more energy than it uses if some way of tapping into non-useable energy(such as heat or solar) can be used. Imagine a system that is 92% efficient, but if 10% of the energy needed to operate the system could by harnessed by solar collectors in orbit, and we only need to provide 90%, the 2% difference would then be useable by us, with the remainder used to power the system.
I'm not sure that I follow your logic here; IMO, we'd be better off using the 10% from the solar satellites directly as opposed to the 2% surplus that we'd acheive from such a scheme. Also, there is the more significant problem of efficiency being closer to a billionth of a percent.
Bringing the efficiency up seems to require very large devices, though these are still buildable.
sure, but it looks like the clusters would have to be in the laser beam, and even then its random how many of the atoms colide.
The efficiency of the device is *extremely* bad, mostly because the small clusters don't retain energy long enough to keep fusion going long enough to produce much energy (look up the "Lawson Criterion" for interesting information on this subject).
The laser delivers about 1000 J of energy over the course of 1 picosecond. The fusion produces about 10,000 neutrons. Making a _very_ rough estimate, let's assume that each reaction producing a neutron liberated a total of 10 MeV. This corresponds to a total energy produced of about 100 GeV, or 1.6e-8 J.
That puts its energy efficiency at about 0.000000001%, plus or minus a couple of orders of magnitude
To keep enough plasma confined for long enough to produce a useful amount of energy, you need to use larger amounts of deuterium (pellets a few tens of microns across IIRC), and extremely powerful lasers. This is what the other laser facility mentioned in the article is for.
There are at least two other ways to produce fusion relatively economically; we'll see which is finally adopted for power production some time within the next 50 years or so.
This device was developed as a research tool for producing energetic neutrons. It's very useful in that regard, but research on this device doesn't contribute much towards fusion power generation. That's what the other laser that the article mentioned is for
I hadn't thought of using this as a fission trigger, though. That might actually be practical.
My understanding was that the Amiga died because Commodore decided to fire its engineering department and milk the product for all it was worth until it ran into the ground. This is second-hand, but from a reasonably reliable friend.
Ten or more years ago, the Amiga was a wonderful system. It had the equivalent of a first-generation hardware-accelerated graphics card built into the box years before these became available on PCs, with a cleanly designed system architecture and a reasonably nice OS and interface. This was pre-Win3.1 (remember when 286s were cutting-edge?). Among home users, at least, there was a heated debate over which system (x86 or Amiga) was the more useful. PCs might or might not have had a slight number-crunching advantage, but there were more than enough nifty features on the Amiga to make up for it.
But, eventually, Amigas just faded away.
I have nothing against it being tightened up; I'm mainly responding to the posters who feel that no definition exists at all (and repeat the "Apple-can-take-away-everything-at-whim" line). IMO, the APSL is cryptic but not ambiguous on this.
I'm actually more worried about the wording of secton 12.1, which seems to contradict the wording in other sections. The clause in question is:
"This License and the rights granted hereunder will terminate:
This implies that the license will be revoked for _all_ code, while section 9.1 specifies that it is revoked only for Affected Original Code. This could be fixed by a modification along the lines of:
(b) immediately in the event of the circumstances described in section 9.1 (termination applying only to Affected Original Code, as described in section 9.1)
(c) immediately in the event of the circumstances described in section 13.6(b)
While I feel that Apple could be successfully challenged in court if it tried to yank the rug out from somebody using this approach, preventing this from happening in the first place would be nice.
Can you provide concrete prices for how much a box like that would cost? Also, is there a version of Linux or something similarly friendly that will support aggressively multithreaded programs well on that platform? I keep hearing about "Blue G3" problems and SMP not being what it could be, though the second point may not be relevant as this is wouldn't be making many kernel calls.
A minimal K62-400 box (booting off the network, no video card or hard drive) would cost the equivalent of about $400 US up here. Performance would at worst be about half that of a G3 (I'd need to check the spec figures for both to get a better estimate).
At some point I plan to drop about $10k Canadian ($6.5k US) on something like this, so I do appreciate people pointing out other options.
Though it will probably be most useful as a thought experiment, as I won't have that much free cash for about a year and a half.
See my post replying to an earlier thread in this page.
That's making a big assumption.
What is the cost/performance ratio for x86s vs. Macs?
I remember studying this at one point with respect to workstations, and coming to the appalling conclusion that the best thing to run the ray-tracer of my dreams on is a basement filled with K62-400 boxes.
Not as far as I can see. Section 9.1 explicitly defines "Affected Original Code" as Original Code that becomes the subject of a claim of infringement. Original Code, in turn, is defined in section 1.6 as "the Source Code of a program or other work as originally made available by Apple under this License, including the Source Code of any updates or upgrades to such programs or works made available by Apple under this License, and that has been expressly identified by Apple as such in the header file(s) of such work.".
So, Original Code is only something that is directly published by Apple.
Now, you could argue that Apple could yank the rug out from under you by republishing Covered Code that you submitted to them, whereupon it would become Original Code and therefore Affected Original Code. However, there are limits to what "Covered Code" covers.
"Covered Code" is defined in section 1.2 as "Original Code, Modifications, the combination of Original Code and any Modifications, and/or any respective portions thereof". "Modifications" are defined in section 1.5 as "any addition to, deletion from, and/or change to, the substance and/or structure of Covered Code", encompassing "(a) any addition to or deletion from the contents of a file containing Covered Code; and/or (b) any new file or other representation of computer program statements that contains any part of Covered Code" [emphasis added].
What this does and does not cover can be assessed by comparing it to the definition of a Larger Work, in section 4. The gist of it is that if you make a bug fix to Apple's code or mess with what Apple gives you directly, it becomes Covered Code. However, if you build a software package _around_ Covered Code, that uses it but adds components that are completely new and different, you have created a Larger Work. As long as you are tidy and keep most of your code in separate files, Apple can only lay claim to the components that are essentially pieces that they supplied to begin with.
I'm afraid that I don't really see the problem.
Another way would be to only keep score from the past few (days/months/years). Using some reasonable amount of time. This would be much easier to implement and while you still need to keep scores with dates you don't need to keep them for an eternity.
An easy way to implement aging would be to use an exponential decay aging function. The user's current accumulated average is stored, along with the date of this average's last update. When a new comment's weight is frozen (e.g. after it's been around for a week), it is averaged with the score, with the old score's weight being e^-kt, where t is the difference between the update date and the date of the last score computation, and k is a decay constant. The new post's score is weighted by one minus this value.
Under an exponential decay system a user's old posts still influence their score, but with diminishing weight, without requiring a detailed record of that user's history.
The catch is that once you've added a post's score to the average score, you can't remove it or update it if that post's score changes in the future (hence the one-week waiting period before addition in my example).
Not really. If you had a brain implant, then it would perform preprocessing to filter out only the information that it needed to transfer. This could be very large if you are doing a video feed to or from someone's visual cortex, or very low if you're just using a small area of the motor cortex to control a mouse.
Transmitting the nerve signals generated with perfect fidelity probably isn't needed. Just the relevant information, which can be translated back into nerve signals by the implant.