It turns out that most of the ownership arguments you are concerned about wouldn't hold water if actually used in court.
However, they added section 11 (Ownership) which states that code written for Apple or on behalf of Apple is not auotmatically covered by the AAPL. What this means is that any code added to an another author's code or any code written originally by Apple and licensed under the AAPL can have the AAPL revoked.
No; the exact wording is "such Apple Modifications will not be automatically subject to this License.". They don't _have_ to license their own modifications under the APSL, as any other modifying user would, but once they tack a license on there, it stays.
Exhibit A assumes that portions of the code licensed under the AAPL are already copyright by Apple. What happens if someone writes completely original code and has to display this notice? Also, does it not also mean that section 11 is *always* enforcable even if the code you wrote doesn't have Apple code in it.
The terms of the licensing agreement say that you have to apply the APSL, and hence Exhibit A, to any source files that contain Original Code or a modification thereof. However, you can distribute other files, that are completely free of Apple code, under whatever license you want, as long as the APSL applies to anything containing variants of the Original Code (which means that you couldn't GPL anything in the project, but you could LGPL or BSD it if I understand correctly). This is covered in section 2.1 (c) and in section 4.
I do agree that having to destroy code would be a Bad Thing, but nothing that I would use the code for would be grounds for termination of the license.
The patent issue still needs to be settled, though.
If Apple were required to republish changes, then a user could turn APSL into GPL as follows:
(1) embed some GPL-ed code into a change; (2) submit it, passing along the GPl-ed license in accordance with GPL; and (3) apple publishes it.
You couldn't get past step (1). The APSL makes it clear that you can't add any licensing that invalidates any of the APSL. Including the GPL in Your Modifications would certainly do this, and if I understand the GPL correctly (I may not), including it in any part of a Larger Work would too.
So maybe they need to change the way they do business.
I keep seeing this, and I keep seeing flawed justifications for it. Many of the ideas have merit, but I have yet to see a workable implementation proposed.
So, if you see a way that a _large_ truly open company can afford to pay _many_ (hundreds to thousands) full-time programmers decent salaries, please draw up a _detailed_, _complete_ business plan and post it somewhere public.
I'd love to see this done. If I could look at neat code that other people have written and modify it freely but still get paid a good full-time wage for the code that I write, I'd be ecstatic. Unfortunately, I can now only afford to write free code in my spare time, because proprietary code is the only code that my employers can afford to pay me for.
Post a _detailed_ business plan like this and businesses will listen.
A friend of mine works for NASAs storage facility. They loose about 1 tb each year. Tapes last about 4 years it takes 5 years to convert from 1 tape set to the next + the new data. So nasa looses 1 year of data for every year gained becuas of "everlasting" tape backups!
I vaguely remember hearing about this. Not to detract from your (valid) point, but what this says to me is that NASA should buy more tape copying equipment so that its rate of copying can keep up with the amount of copying that it needs to do.
If you want data to be stored forever, you could probably do it by setting up the network equivalent of a RAID, with data being duplicated on all machines. As old machines died or were removed, new machines would be added, ad infinitum.
Now, for terabytes of data, this would get a bit pricey, but it would certainly be effective for smaler amounts of data and might be worth it even for larger.
The problem is SCR lockup and it is a condition inside integrated circuits where an input is biased beyond the supply rails that can cause the semiconductor junctions to mimic a triggered SCR. The result would lock down the supply rails and heat the IC, possibly to destruction. I suppose most chips nowdays have this worked out, but it used to be something to think about.
This is indeed addressed in modern IC designs, though I don't know if it's implemented widely outside of CMOS. For CMOS circuits, you just place a fair number of "ohmic contacts" between the supply rails and substrate regions/wells. This ensures that even if a voltage spike forward-biases a junction that should never be forward-biased, it will be pulled back to the proper voltage levels in short order regardless of SCR effects.
OTOH, hot-swapping components that weren't designed to be hot-swapped is still usually a Bad Idea...
There are 3 kinds of curves that occur in nature: sinusoid, decaying exponential, and S-curve (a rising exponential which eventually levels out).
Chuck a Windows box out of a high window with substantial lateral velocity. Watch its flight path. Looks parabolic, doesn't it?:)
I realize I'm nit-picking, but there are many cases in nature where you find polynomial curves, especially in relations between parameters (radiative heat emission comes to mind, among other things). Exponentials certainly exist, but I once had the misfortune to be in an argument with someone who thought that they were the *only* kind of curve that existed, and am still touchy about the subject.
More importantly, the physical limits that shut down THz electronic computers apply to _any_ classical computing architecture; optical computing and other exotic technology can't beat the speed of light, or single-particle storage problems.
You can most certainly build a THz computer. Your signals can't make round-trip circuits in one clock cycle; so what? You just have several much smaller parts of the chip running asynchronously with each other, and get power savings to boot.
Re. single-particle storage, you are overlooking the fact that present chips are essentially two-dimensional. While there can be up to a dozen or so metal layers, there is only one diffusion layer in which transistors are fabricated. Build a three-dimensional structure, and you suddenly have a lot more room. I leave as an exercise the question of how to actually build chips like that and how to extract the heat generated by such chips.
I agree that there will be a fundamental limit due to minimum feature size, and that at some point (barring exponential increases in efficiency), heat dissipation will become proportional to computing power, but I think that the limits are a lot farther away than you place them.
Quantum computing is an interesting idea, and people now seem to be doing useful work on it. It remains to be seen how easily it can be adapted to the tasks that we currently need computers for (I realize that new tasks that can be solved will crop up suited to quantum computing capabilities, but that won't make the old tasks go away). At present, while interesting and having potential, it remains an idea.
[Point about a microsoft format that wasn't widely adopted.] [Point about PNG not being widely adopted.] [Bashing MS for being stupid about trying to get their formats adopted.]
Just as how Java could be fast with JIT's, there could be something similar to JIT's for this.
I haven't looked at the actual code, but the mechanics of this vitural DSP is probably much simpler than a Java JVM.
And therin lies the problem. High-level code can be compiled quite efficiently on multiple platforms. However, if I understand correctly, the code presented is essentially DSP assembly code (I might be wrong about this, as I still have to read the format documentation). You would have to cross-compile it to the native platform and hope that the architectural differences don't make it too inefficient.
This would give a speed boost over interpreting it, but would still in my estimation give a factor of 2-3 slowdown. This might be acceptable, or it might not - it depends on how difficult the format is to decode. The bright side is that you wouldn't need a just-in-time compiler per se; you could cross-compile everything once at the beginning. You could even cache the compiled code in case you encountered another file with the same codec (very likely, actually).
So again, we'd have to see what kinds of codecs actually get written in practice. And what kinds of players. A really good cross-compiler that optimizes for the target platform is not trivial to write.
Assuming, of course, that the standard gets adopted. IMO, a good way to speed that up would be to write a good converter of the type described in my original message, and then write a cross-compiling player good enough to let you play the resulting files at reasonable quality. Finding the manpower for this will be difficult.
This format depends on software emulation of a DSP. While this makes it very flexible, it also means that codecs will run several times more slowly than for conventional formats. If processors get fast enough, this *might* not be a problem, but I doubt it. The only thing that could make this work well is dedicated hardware (which the page mentiones that they are hoping for, but that's about it).
It's a nice idea. You could send MP3s in native format using this; just write an MP3 decoder in their DSP language. Likewise, you could effortlessly translate anything else that's stored in a presently-used format. The only problem is that, for anything complicated, your processor can't make the decoder run fast enough to give decent quality on present hardware.
They offer a pretty thorough suite of development tools. If anyone wanted to port this to Linux, they could quite easily (it's just a Small Matter of Programming).
Gee, I haven't much hoopla about ActiveX lately yet Java is still going strong.
PNG is supposedly better than GIF and JPG, yet still the web is dominated by GIF images.
Since when is PNG a Microsoft format?
An old version of the PNG specification is here. The credits list this document, at least, as being (c) MIT.
PNG was specifically created to be a.GIF-like format that people could write encoders and decoders for without having to pay royalties to anyone. It was invented because Compuserve raised a stink over image processing programs using the.GIF format, which it owns, without paying them royalties. PNG is also technically superior on a couple of points. We'll see what happens.
This is pretty exciting though, I heard on E-Town that they are building a really wide telescope that uses lot's of little telescope and some computer magic to make them act like a super sized telescope and they are going to launch it into space like Voyager. By the time it get's to Mars they are expecting it to show visual light pictures of planets around other stars.
First of all, IIRC there were about four plans on the drawing board for more advanced, space-based telescopes. Many of these would use optical interferometry to get better resolution, much as is presently done with arrays of radio telescopes. This does *not* allow you to detect fainter objects - it _does_ let you see details more clearly in objects that you _can_ see, though. The idea is that we'd be able to distinguish the image of a planet from the image of the star it orbits using telescopes like these. IIRC a proof-of-concept system was being set up on Earth by linking two conventional telescopes in adjacent observatories.
The telescopes won't go out to Mars. IIRC, they were just going a reasonable distance away from _Earth_, so that the glow of sunlight reflected off of us wouldn't interfere with their measurements as much. I don't remember exactly where they were going to be placed.
I agree that the results produced should be quite interesting.
Are these actually gas giants? Are they balls of dirt? What?
The inner one is almost certainly rock, as gas would have boiled away long ago (a planet orbiting that close to our sun would receive 350 times as much light per unit area as Earth).
OTOH, maybe a Jupiter-like planet's gravity well would be deep enough to keep it in.
I have questions about the equipment they are using and such, but the link dosn't answer much.
At least some of the planet-detecting experiments that produced results checked the doppler shift of stars' spectra, looking for periodic oscillations in how quickly it was moving towards/away from us. A regular oscillation means that it is being tugged back and forth by a planet orbiting it. This technique only works well for relatively large planets orbiting relatively close, which is why Jupiter-sized planets and larger are the kinds that are being detected.
I vaguely recall reading about another technique that actually looked for wobble in the star's position directly, but I could be mistaken about that.
The reason fusion nukes release as much radiation as fission nukes is because they rely on fission to release the heat necessary to jump-start the fussion process. And then there are neutron bombs...
Fusion produces quite a bit of radiation too. Certainly gamma radiation, but quite a bit of neutron radiation also, and this is what presents the most danger (as it is this that makes surrounding materials radioactive).
Conventional fusion weapons fuse lithium and deuterium, IIRC. Li7 + H2 -> He4 + He4 + n, or He3 + He4 + 2n, or He3 + He3 + 3n, or any of a number of other decay chains. If I understand correctly, He3 is actually more likely to form, because energetic He4 nuclei can shed their excess energy easily by emitting neutrons and turning into He3. So in summary, the neutron flux from fusion is nothing to sneeze at, and is actually greater per unit mass than that from fission.
Neutron bombs are a special case. They can be built by modifying either fission or fusion bombs, though.
Do you know how much damn a fusion bomb could do, a lot more than a nuke. And it would have low radiation meaning that the guy dropping could wait a few years and move on in.
Um, pretty much all of the larger nuclear weapons built during the last few decades have been fusion bombs.
And they produce just as much fallout and other radiation effects as fission bombs.
Please learn about a subject before posting about it.
Short run we should focus on moving to cleaner burning fossil fuels like natural gas, and slightly longer run we should think about converting to a fuel-cell based hydrogen economy. There are big efficiency and environmental wins to be had, without trying to contain a solar furnace in a magnetic bottle.
Why not use methanol? It's easy to transport, can be stored at high density, burns cleanly, and can be produced reasonably efficiently using solar energy (i.e. grow plants and ferment them). If you're trying to produce mechanical energy, then you can do that directly instead of converting from electrical energy produced by fuel cells. If you're trying to produce electricity, IIRC there were fuel cells that could process methanol. Or you could run a generator off of a methanol engine.
This reminds me - does anyone have a URL to an article that discusses in detail the many magnetic confinement schemes that have been tried over the years? In particular, I'm wondering how a "spheromak" works (the configuration described in this article is _not_ a "spheromak"), though I could stand to brush up on stellarators, also.
Ha. Here we have to take circuit analysis regardless of whether we're doing Computer Engineering or Electrical Engineering! That means an entire semester wasted analyzing non-DC circuits, when the time could be better spent playing Xpilot... er... admin'ing my very own Solaris/X86 box. oops:) The other black mark is that all courses are done in Java now, when 1% of all applications are actually written in it! Unfortunately the "useful" alternative would have been C++^H^H^HVisual C++...:(
Oh, I had to take non-DC circuit analysis too; transient signals are very important in integrated circuits, and integrated circuit design is a part of Comp. Eng.. However, I didn't have to take some of the hairier Elec courses, from Fields and Waves on up.
We have the good fortune of using C under Solaris on Sun workstations for most of our programming work.
What I really want to do is design an OS that will blow Microsoft out of the water. Of course learning how the CPU decodes a machine-language instruction through a microprogram has little to do with this (too low level). Neither does anything having to do with Java (too high level). Methinks I should have been a Computer Scientist, but there probably isn't a scholarship for those.
Actually, both of those are at least tangentially significant for OS design. Comp. Eng. should cover OS design, as it falls right in its area of influence (the layer where hardware and software meet). Comp. Sci. would teach you OS design, but there would be a vast amount of high-level and theoretical stuff thrown at you as well. Comp. Eng. focuses more on practical application, as opposed to the high reaches of theory (though we still get a bit of it).
For OS design, I strongly recommend the excellent textbook that we had in our OS course. Assuming it hasn't changed over the past year or so, it is:
William Stallings
Operating Systems: Internals and Design Principles, 3rd Edition
Of course, that only coveres half of the OS (the kernel). For driver programming, I'd suggest finding semi-decent documentation on Linux drivers and picking apart drivers in your own copy of Linux. BeOS is another good platform on which to learn driver development; there are a few good reference sites that cover its driver architecture.
There are a lot of aspects of OS design that I would have taken quite a while to find out about on my own. I know what a page table is now, and how several process scheduling algorithms work, and the merits and drawbacks of each. As well as a large amount of low-level detail about what's involved in implementing a microkernel, c/o the labs we had to do. I could have picked up all of this by spending a year taking apart the Linux kernel, but out in the working world, it's hard to find the time for major undertakings like that (I know, as I'm working now).
In summary, I was given useful information about this in my CE courses. My sympathies re. NT and Java:/.
From my own experiences and what I've heard from many others on Slashdot and elsewhere, I get the impression that there are two kinds of college or university.
Type number one is a place where people go to drink and have sex. The professors range from mediocre to truly incompetent, and nobody really learns a whole lot even if they do pay attention in class and do all of the coursework. People who have been through one of these colleges generally say that college is a waste of time. In a college like this, I agree - it is.
Type number two is different. The professors actually know what they're talking about, and many are quite bright indeed. The coursework is actually challenging. No matter how smart you are, you'll be picking up new concepts and then working your butt off to prove that you understand them. The courses that you are taking are relevant to your chosen career and teach you things that you will use after you graduate. You also learn how to learn, as many others have pointed out. I have the good fortune to be at a university like this, and it has proven invaluable for my work in the software industry.
A complaint that I sometimes hear from people who don't like college is that none of the courses are interesting. IMO, this isn't necessarily a problem with the college (though it can be for the first type of college). I was very lucky, and chose exactly the right course stream; my courses match my interests almost perfectly. But, if I'd chosen Electrical Engineering instead of Computer Engineering, I'd be stuck doing analog circuit analysis when what I really want to do is design ICs. This would not only have presented problems after graduation, but would have made my coursework alternately difficult and boring.
My advice for those pondering college is to think carefully about what they want to learn about, and to pick a good school at which to learn. This might mean a hideously expensive school, or it might not. However, if you pick a bad college or university, your time there will be a dead loss.
Likewise, picking your field is important. If you choose incorrectly, you will be forced to work your butt off learning things that just don't interest you. Don't be afraid to change fields once you have already enrolled; it's better to lose a year than to stick with something you don't like and lose four years. It will still be worth it.
If you do find a good college or university and manage to get into a field that truly interests you, then IMO you will almost certainly find post-secondary education to be worthwhile.
Ok, here is the second link again, this time done right.
And yes, I am too lazy to cut-n-paste! So it is appreciated (if done right;-)
Thanks. I feel very silly now. I think that's 3 out of 3 times that I've made a typo while mentioning something that our company has done. Let's see how long I can keep this streak going O:).
some guy yesterday, under the 'FSF new definition of free software' topic, said that you cant sue someone over the particular 'use' of a program, you can only sue them for violating a copyright or a patent.
Not strictly true, I think. An "End User License Agreement" is exactly that - a contract that the user has to agree to before they're allowed to use the software. Because the user is "voluntarily" accepting the terms of the contract, software companies can put pretty much anything they want in there, and it will be binding. If the customer doesn't like it, they can use a competitor's software instead.
We (alt.software inc.) released an OpenGL-to-D3D wrapper based on Mesa code fairly recently (with source etc.). This should allow any card that supports hardware D3D acceleration to accelerate OpenGL applications. YMMV, but from what I've seen it works reasonably well.
You can find it at http://www.altsoftware.com (click on "OpenGL"), or read about it at a href= "http://www.opengl.org/News/Archives99/Feb99.htm l"> http://www.opengl.org/News/Archives99/Feb99.html (look for 2/23/99 under the "Developer" section).
Then call SGI, Sun, IBM, and Alpha retailers, and see what you can get for the same money. Check Memory I/O, Mega/Giga-flops, SPECS, and I think you will see, we're not playing in Intel's field anymore.
I studied these companies' offerings in detail about a month ago, when I wondered how much a really _good_ multiprocessor system costs.
The answer is about $30k+ for something like a quad box, and about $100k+ for something with more respectable performance.
I've heard people quote high single-digit $k for Alpha boxen, but I'm still suspicious as to what's on the motherboard.
From what I found, both IBM and SGI had horrible price/performance ratios (for what I was looking for; my primary concern was FP performance). Sun systems were ok, but the real winner from what I could tell was HP. They sell PA-RISC 8500 boxen with large numbers of processors and respectable cache for a (relatively) reasonable price. They have a pricing sheet on their web site, though you have to dig a fair bit for it. Some of the manufacturers give Spec figures, but it's still a good idea to stop by spec.org to find out what the performance of some of the boxen listed actually ends up being.
What I concluded from the survey was that I'm better off spending $10k (Canadian) and buying 15 K62-400 boxen. The problems that I want to solve are easily compartmentalized.
Slashdot Mirror
However, they added section 11 (Ownership) which states that code written for Apple or on behalf of Apple is not auotmatically covered by the AAPL. What this means is that any code added to an another author's code or any code written originally by Apple and licensed under the AAPL can have the AAPL revoked.
No; the exact wording is "such Apple Modifications will not be automatically subject to this License.". They don't _have_ to license their own modifications under the APSL, as any other modifying user would, but once they tack a license on there, it stays.
Exhibit A assumes that portions of the code licensed under the AAPL are already copyright by Apple. What happens if someone writes completely original code and has to display this notice? Also, does it not also mean that section 11 is *always* enforcable even if the code you wrote doesn't have Apple code in it.
The terms of the licensing agreement say that you have to apply the APSL, and hence Exhibit A, to any source files that contain Original Code or a modification thereof. However, you can distribute other files, that are completely free of Apple code, under whatever license you want, as long as the APSL applies to anything containing variants of the Original Code (which means that you couldn't GPL anything in the project, but you could LGPL or BSD it if I understand correctly). This is covered in section 2.1 (c) and in section 4.
I do agree that having to destroy code would be a Bad Thing, but nothing that I would use the code for would be grounds for termination of the license.
The patent issue still needs to be settled, though.
(1) embed some GPL-ed code into a change;
(2) submit it, passing along the GPl-ed license in accordance with GPL; and
(3) apple publishes it.
You couldn't get past step (1). The APSL makes it clear that you can't add any licensing that invalidates any of the APSL. Including the GPL in Your Modifications would certainly do this, and if I understand the GPL correctly (I may not), including it in any part of a Larger Work would too.
I keep seeing this, and I keep seeing flawed justifications for it. Many of the ideas have merit, but I have yet to see a workable implementation proposed.
So, if you see a way that a _large_ truly open company can afford to pay _many_ (hundreds to thousands) full-time programmers decent salaries, please draw up a _detailed_, _complete_ business plan and post it somewhere public.
I'd love to see this done. If I could look at neat code that other people have written and modify it freely but still get paid a good full-time wage for the code that I write, I'd be ecstatic. Unfortunately, I can now only afford to write free code in my spare time, because proprietary code is the only code that my employers can afford to pay me for.
Post a _detailed_ business plan like this and businesses will listen.
I vaguely remember hearing about this. Not to detract from your (valid) point, but what this says to me is that NASA should buy more tape copying equipment so that its rate of copying can keep up with the amount of copying that it needs to do.
If you want data to be stored forever, you could probably do it by setting up the network equivalent of a RAID, with data being duplicated on all machines. As old machines died or were removed, new machines would be added, ad infinitum.
Now, for terabytes of data, this would get a bit pricey, but it would certainly be effective for smaler amounts of data and might be worth it even for larger.
This is indeed addressed in modern IC designs, though I don't know if it's implemented widely outside of CMOS. For CMOS circuits, you just place a fair number of "ohmic contacts" between the supply rails and substrate regions/wells. This ensures that even if a voltage spike forward-biases a junction that should never be forward-biased, it will be pulled back to the proper voltage levels in short order regardless of SCR effects.
OTOH, hot-swapping components that weren't designed to be hot-swapped is still usually a Bad Idea...
Chuck a Windows box out of a high window with substantial lateral velocity. Watch its flight path. Looks parabolic, doesn't it?
I realize I'm nit-picking, but there are many cases in nature where you find polynomial curves, especially in relations between parameters (radiative heat emission comes to mind, among other things). Exponentials certainly exist, but I once had the misfortune to be in an argument with someone who thought that they were the *only* kind of curve that existed, and am still touchy about the subject.
You can most certainly build a THz computer. Your signals can't make round-trip circuits in one clock cycle; so what? You just have several much smaller parts of the chip running asynchronously with each other, and get power savings to boot.
Re. single-particle storage, you are overlooking the fact that present chips are essentially two-dimensional. While there can be up to a dozen or so metal layers, there is only one diffusion layer in which transistors are fabricated. Build a three-dimensional structure, and you suddenly have a lot more room. I leave as an exercise the question of how to actually build chips like that and how to extract the heat generated by such chips.
I agree that there will be a fundamental limit due to minimum feature size, and that at some point (barring exponential increases in efficiency), heat dissipation will become proportional to computing power, but I think that the limits are a lot farther away than you place them.
Quantum computing is an interesting idea, and people now seem to be doing useful work on it. It remains to be seen how easily it can be adapted to the tasks that we currently need computers for (I realize that new tasks that can be solved will crop up suited to quantum computing capabilities, but that won't make the old tasks go away). At present, while interesting and having potential, it remains an idea.
[Point about a microsoft format that wasn't widely adopted.]
[Point about PNG not being widely adopted.]
[Bashing MS for being stupid about trying to get their formats adopted.]
The implication is certainly there, whether or not it was intended. If it wasn't intended, then I retract my statement, but I won't apologize for it.
[Point about a microsoft format that wasn't widely adopted.]
[Point about PNG not being widely adopted.]
[Bashing MS for being stupid about trying to get their formats adopted.]
there could be something similar to JIT's for this.
I haven't looked at the actual code, but the mechanics of this vitural DSP is probably much simpler than a Java JVM.
And therin lies the problem. High-level code can be compiled quite efficiently on multiple platforms. However, if I understand correctly, the code presented is essentially DSP assembly code (I might be wrong about this, as I still have to read the format documentation). You would have to cross-compile it to the native platform and hope that the architectural differences don't make it too inefficient.
This would give a speed boost over interpreting it, but would still in my estimation give a factor of 2-3 slowdown. This might be acceptable, or it might not - it depends on how difficult the format is to decode. The bright side is that you wouldn't need a just-in-time compiler per se; you could cross-compile everything once at the beginning. You could even cache the compiled code in case you encountered another file with the same codec (very likely, actually).
So again, we'd have to see what kinds of codecs actually get written in practice. And what kinds of players. A really good cross-compiler that optimizes for the target platform is not trivial to write.
Assuming, of course, that the standard gets adopted. IMO, a good way to speed that up would be to write a good converter of the type described in my original message, and then write a cross-compiling player good enough to let you play the resulting files at reasonable quality. Finding the manpower for this will be difficult.
It's a nice idea. You could send MP3s in native format using this; just write an MP3 decoder in their DSP language. Likewise, you could effortlessly translate anything else that's stored in a presently-used format. The only problem is that, for anything complicated, your processor can't make the decoder run fast enough to give decent quality on present hardware.
They offer a pretty thorough suite of development tools. If anyone wanted to port this to Linux, they could quite easily (it's just a Small Matter of Programming).
PNG is supposedly better than GIF and JPG, yet
still the web is dominated by GIF images.
Since when is PNG a Microsoft format?
An old version of the PNG specification is here. The credits list this document, at least, as being (c) MIT.
PNG was specifically created to be a
First of all, IIRC there were about four plans on the drawing board for more advanced, space-based telescopes. Many of these would use optical interferometry to get better resolution, much as is presently done with arrays of radio telescopes. This does *not* allow you to detect fainter objects - it _does_ let you see details more clearly in objects that you _can_ see, though. The idea is that we'd be able to distinguish the image of a planet from the image of the star it orbits using telescopes like these. IIRC a proof-of-concept system was being set up on Earth by linking two conventional telescopes in adjacent observatories.
The telescopes won't go out to Mars. IIRC, they were just going a reasonable distance away from _Earth_, so that the glow of sunlight reflected off of us wouldn't interfere with their measurements as much. I don't remember exactly where they were going to be placed.
I agree that the results produced should be quite interesting.
Are they balls of dirt?
What?
The inner one is almost certainly rock, as gas would have boiled away long ago (a planet orbiting that close to our sun would receive 350 times as much light per unit area as Earth).
OTOH, maybe a Jupiter-like planet's gravity well would be deep enough to keep it in.
I have questions about the equipment they are using and such, but the link dosn't answer much.
At least some of the planet-detecting experiments that produced results checked the doppler shift of stars' spectra, looking for periodic oscillations in how quickly it was moving towards/away from us. A regular oscillation means that it is being tugged back and forth by a planet orbiting it. This technique only works well for relatively large planets orbiting relatively close, which is why Jupiter-sized planets and larger are the kinds that are being detected.
I vaguely recall reading about another technique that actually looked for wobble in the star's position directly, but I could be mistaken about that.
Fusion produces quite a bit of radiation too. Certainly gamma radiation, but quite a bit of neutron radiation also, and this is what presents the most danger (as it is this that makes surrounding materials radioactive).
Conventional fusion weapons fuse lithium and deuterium, IIRC. Li7 + H2 -> He4 + He4 + n, or He3 + He4 + 2n, or He3 + He3 + 3n, or any of a number of other decay chains. If I understand correctly, He3 is actually more likely to form, because energetic He4 nuclei can shed their excess energy easily by emitting neutrons and turning into He3. So in summary, the neutron flux from fusion is nothing to sneeze at, and is actually greater per unit mass than that from fission.
Neutron bombs are a special case. They can be built by modifying either fission or fusion bombs, though.
Um, pretty much all of the larger nuclear weapons built during the last few decades have been fusion bombs.
And they produce just as much fallout and other radiation effects as fission bombs.
Please learn about a subject before posting about it.
Why not use methanol? It's easy to transport, can be stored at high density, burns cleanly, and can be produced reasonably efficiently using solar energy (i.e. grow plants and ferment them). If you're trying to produce mechanical energy, then you can do that directly instead of converting from electrical energy produced by fuel cells. If you're trying to produce electricity, IIRC there were fuel cells that could process methanol. Or you could run a generator off of a methanol engine.
This reminds me - does anyone have a URL to an article that discusses in detail the many magnetic confinement schemes that have been tried over the years? In particular, I'm wondering how a "spheromak" works (the configuration described in this article is _not_ a "spheromak"), though I could stand to brush up on stellarators, also.
Oh, I had to take non-DC circuit analysis too; transient signals are very important in integrated circuits, and integrated circuit design is a part of Comp. Eng.. However, I didn't have to take some of the hairier Elec courses, from Fields and Waves on up.
We have the good fortune of using C under Solaris on Sun workstations for most of our programming work.
What I really want to do is design an OS that will blow Microsoft out of the water. Of course learning how the CPU decodes a machine-language instruction through a microprogram has little to do with this (too low level). Neither does anything having to do with Java (too high level). Methinks I should have been a Computer Scientist, but there probably isn't a scholarship for those.
Actually, both of those are at least tangentially significant for OS design. Comp. Eng. should cover OS design, as it falls right in its area of influence (the layer where hardware and software meet). Comp. Sci. would teach you OS design, but there would be a vast amount of high-level and theoretical stuff thrown at you as well. Comp. Eng. focuses more on practical application, as opposed to the high reaches of theory (though we still get a bit of it).
For OS design, I strongly recommend the excellent textbook that we had in our OS course. Assuming it hasn't changed over the past year or so, it is:
William Stallings
Operating Systems: Internals and Design Principles, 3rd Edition
Of course, that only coveres half of the OS (the kernel). For driver programming, I'd suggest finding semi-decent documentation on Linux drivers and picking apart drivers in your own copy of Linux. BeOS is another good platform on which to learn driver development; there are a few good reference sites that cover its driver architecture.
There are a lot of aspects of OS design that I would have taken quite a while to find out about on my own. I know what a page table is now, and how several process scheduling algorithms work, and the merits and drawbacks of each. As well as a large amount of low-level detail about what's involved in implementing a microkernel, c/o the labs we had to do. I could have picked up all of this by spending a year taking apart the Linux kernel, but out in the working world, it's hard to find the time for major undertakings like that (I know, as I'm working now).
In summary, I was given useful information about this in my CE courses. My sympathies re. NT and Java
Type number one is a place where people go to drink and have sex. The professors range from mediocre to truly incompetent, and nobody really learns a whole lot even if they do pay attention in class and do all of the coursework. People who have been through one of these colleges generally say that college is a waste of time. In a college like this, I agree - it is.
Type number two is different. The professors actually know what they're talking about, and many are quite bright indeed. The coursework is actually challenging. No matter how smart you are, you'll be picking up new concepts and then working your butt off to prove that you understand them. The courses that you are taking are relevant to your chosen career and teach you things that you will use after you graduate. You also learn how to learn, as many others have pointed out. I have the good fortune to be at a university like this, and it has proven invaluable for my work in the software industry.
A complaint that I sometimes hear from people who don't like college is that none of the courses are interesting. IMO, this isn't necessarily a problem with the college (though it can be for the first type of college). I was very lucky, and chose exactly the right course stream; my courses match my interests almost perfectly. But, if I'd chosen Electrical Engineering instead of Computer Engineering, I'd be stuck doing analog circuit analysis when what I really want to do is design ICs. This would not only have presented problems after graduation, but would have made my coursework alternately difficult and boring.
My advice for those pondering college is to think carefully about what they want to learn about, and to pick a good school at which to learn. This might mean a hideously expensive school, or it might not. However, if you pick a bad college or university, your time there will be a dead loss.
Likewise, picking your field is important. If you choose incorrectly, you will be forced to work your butt off learning things that just don't interest you. Don't be afraid to change fields once you have already enrolled; it's better to lose a year than to stick with something you don't like and lose four years. It will still be worth it.
If you do find a good college or university and manage to get into a field that truly interests you, then IMO you will almost certainly find post-secondary education to be worthwhile.
And yes, I am too lazy to cut-n-paste! So it is appreciated (if done right
Thanks. I feel very silly now. I think that's 3 out of 3 times that I've made a typo while mentioning something that our company has done. Let's see how long I can keep this streak going O:).
a copyright or a patent.
Not strictly true, I think. An "End User License Agreement" is exactly that - a contract that the user has to agree to before they're allowed to use the software. Because the user is "voluntarily" accepting the terms of the contract, software companies can put pretty much anything they want in there, and it will be binding. If the customer doesn't like it, they can use a competitor's software instead.
AFAIK.
http://www.opengl.org/News/Archives99/Feb99.html
(look for 2/23/99 under the "Developer" section).
Number Nine: Direct3D (somewhat)
We (alt.software inc.) released an OpenGL-to-D3D wrapper based on Mesa code fairly recently (with source etc.). This should allow any card that supports hardware D3D acceleration to accelerate OpenGL applications. YMMV, but from what I've seen it works reasonably well.
You can find it at
http://www.altsoftware.com
(click on "OpenGL"), or read about it at
a href=
"http://www.opengl.org/News/Archives99/Feb99.ht
http://www.opengl.org/News/Archives99/Feb99.htm
(look for 2/23/99 under the "Developer" section).
I studied these companies' offerings in detail about a month ago, when I wondered how much a really _good_ multiprocessor system costs.
The answer is about $30k+ for something like a quad box, and about $100k+ for something with more respectable performance.
I've heard people quote high single-digit $k for Alpha boxen, but I'm still suspicious as to what's on the motherboard.
From what I found, both IBM and SGI had horrible price/performance ratios (for what I was looking for; my primary concern was FP performance). Sun systems were ok, but the real winner from what I could tell was HP. They sell PA-RISC 8500 boxen with large numbers of processors and respectable cache for a (relatively) reasonable price. They have a pricing sheet on their web site, though you have to dig a fair bit for it. Some of the manufacturers give Spec figures, but it's still a good idea to stop by spec.org to find out what the performance of some of the boxen listed actually ends up being.
What I concluded from the survey was that I'm better off spending $10k (Canadian) and buying 15 K62-400 boxen. The problems that I want to solve are easily compartmentalized.