Don't get me wrong...Mr. Hawking and his peers think more before breakfast than I do in an average year, but without falsifiable hypotheses, a lot of cosmology has more to do with faith than with fact. This is not necessarily a bad thing, but one has to realize it for what it is.
Models of the universe's creation actually do produce a surprising number of testable predictions.
We see space permeated by 3K blackbody radiation. The big bang model neatly explains this (the universe was once very hot and compact). Steady-state models don't. Scratch the steady-state models.
We see a universe that is apparently geometrically "flat" (Euclidean). This eliminates a wide range of big bang models, and suggests (among other things) that the universe may have started with zero net energy (and thus be the result of a quantum fluctuation).
We see matter clumping on a small scale, but amazingly uniform on a larger scale. The degree and patterns of clumping observed suggest a period of extremely rapid expansion while the universe was very small. Thus, the various inflationary models of the universe. Some produce predicted mass distributions that match the universe's; some don't. Scratch the ones that don't.
Our models of physics at the extreme temperatures and densities that the universe looks like it had in its youth are not well-defined. Some options suggest that we'd get zillions of black holes permeating space. Do we see any? No, so scratch that range of physics models. Other options suggest gigantic artifacts like "cosmic strings" or "great walls". Do we see any? No walls, and strings are inconclusive (putting an upper limit on the number present, if any). This narrows the range of physical theories even more, which in turn gives us a better idea of how the universe would have behaved under early conditions, which lets us refine our predictions of what an old universe would look like under a given model, which lets us further prune models according to observations.
In summary, while speculation indeed occurs, when a model is selected it's usually selected based on the testable predictions it makes.
Again, a library search will turn up most of this.
The Big Bang theory always sounded too biblical to me. I mean one event from a single point exploding to create everything? We see relatively tiny bangs every day from novas and planetary death - I see no reason to think the Big Bang wasn't just a particularly large version of these daily occurences.
The Big Bang was fundamentally different in a number of ways.
Normal explosions involve moving a lot of matter and radiation around through space.
The big bang involved a lot of matter *and* space coming out of nowhere as the result of a quantum fluctuation [to grossly oversimplify].
Yes, there might be other big bangs "outside" the universe, but as both space and time exist only within the universe, we'd have no way of reaching hypothetical other universes [under the classic big bang model; other models propose bangs happening within a universe creating a new bubble of space and time, and other models propose one universe in which pockets undergo inflation and *look* like new universes from the inside.]
Your local univerity's library should have a lot of information on the subject, filed under "cosmology".
In this case you could not use a plastic backing film because the operating temperature of the cell is 1000C! I am not aware of any polymer that can take that sort of temperature (I could be wrong though).
My mistake; I was thinking photocells.
You could probably use a graphite composite, though, if weight was a serious problem. It's in vacuum, so it won't burn.
Hey, there are libraries that manage to avoid C++ constructs to abstract this sort of stuff. For example, B-tree operators could use a fixed structure in which there exists the data fields necessary for the library to do its thing, and the "payload" of the structure is a void pointer to the data referenced by the B-tree node. This means that you can have disk-resident B-trees by using the void pointer to refer instead to a byte offset; array-resident B-trees by using the void pointer to hold an index; value-oriented B-trees by having an integer value in the void pointer.
Oh, I know that you can duplicate most (or all) OO features in straight C. I've just run into the limits of practicality for this on a few occasions. At least twice I've caught myself implementing collections of function pointers in structures to emulate polymorphism. If I'm doing *that*, I might as well just use C++ and save myself a lot of hassles debugging typos.
YMMV. I realize that for some applications, having to trust automatic implementation is bad, but for most of what I work with it's worth it.
The front sheet cannot be thick -- light has to pass through it!
What you do is you use a thin film with a mesh of thicker wires over it to carry the bulk of the current. Take a look at a conventional solar cell, and you'll see a dentritic wire pattern on it that does this.
The _average_ thickness has to be enough to carry the required sheet current, even if the thickness on most of the surface is small.
GaAs has the density of steel. I think diamond is about twice that (I don't quite remember).
No, diamond is just 3.5 or so. Steel is about 8. Silicon is about 2.3.
I agree with most points, except that though in space you don't need much backing, you still need to reinforce them for launch. Which entails about 4-6gs for a shuttle, and lots of vibration.
What you'd actually do if you had a photovoltaic film (on metal or plastic) is roll it up for transport, and unfurl it in space. You can keep it thin that way.
The limiting factor will be the required thickness of the electrode films (the two metal films sandwiching the diamond film). These will have large sheet currents going through them, and so will have to be thick. The diamond film can be as thin as desired, down to a few light wavelengths, I think (a few microns).
The prime cost of putting things into space is not material, but the rockets you build to put them up there. Diamonds are much more dense than silicon or GaAs (the solar cell of choice in space nowadas, so the article is kinda wrong), so they will be correspondingly more massive.
You're talking about a film a few tens or hundreds of microns thick on a sheet of metal.
The density of the diamond film is moot point.
Even if you deposit both a metal film and a diamond film on top of a lighter substrate (like mylar or another plastic), 1) the metal film will still outweigh the diamond film - it has to be thicker, because it's carrying current sideways instead of axially, and 2) the weight of the plastic backing will be much more than the weight of either of the films, because you'd only be using a backing if you could make the films very thin (otherwise you'd just use the thicker metal layer as the backing - this is a space environment, it doesn't have to be very strong).
The feature that crops up in practice most for me is polymorphism.
I code mainly in C, not C++. I've just written yet another program that uses a binary tree to store several different types of data. The naive way of writing this is to make several different tree-node types and several sets of nearly-identical tree manipulation functions. The way I did it was to kludge things with a data type identifier and a union of the possible data stored.
The Right Way to implement this is to make an abstract class for the tree node, write the tree manipulation methods to work with the abstract class, and make derived classes that store different types of data, with appropriate constructors that initialize the data fields. Anything that doesn't have to care about the data type can just manipulate the objects as the original abstract class.
This situation has cropped up before. Any situation where I'm doing the same type of thing with many types of data can benefit from derived classes and polymorpism. This happens frequently with utility libraries that I write, but also crops up now and then with certain types of information storage task.
I still code in C most of the time, because I'm too lazy to dust off my C++ books and these are just my own projects. However, this is indeed a common set of cases where features of C++ would be useful.
Unfortunately, the question is academic for any computer-based encryption scheme. If anyone wants to know how the encryption works, they'll run the binary through a disassembler and a debugger and find out in glorious detail. Thus, against the adversaries you're interested in (people actively trying to subvert the encryption), there is no practical difference between an open and a closed encryption scheme.
Given this state of affairs, it's better to make the system open so that it can be more easily peer reviewed and audited for things like buffer overflows (yes, people who can peer-review encryption algorithms are rare, but they exist, and Joe Coder can spot stupid coding errors readily enough).
A hardware-based encryption scheme is tempting to implement, but you'll have to worry about a) your hypothetical adversaries obtaining schematics by bribery and social engineering, and b) someone gutting the box and (if necessary) stripping the chips to find out what the device is doing. Harder, yes, but not impractical by any stretch.
In summary, I don't trust obscurity to significantly hinder hostile parties' extraction of the encryption algorithm.
By far the cheapest solution will be to build an ordinary set of sliding shelves for the boxes. It works quite well; as long as you pay enough attention to ventilation, you could easily fit a dozen or more systems inside a small closet (or a rack the size of a small closet).
If you want to make things even more compact, gut the cases and screw the motherboards directly on to the shelves. Make sure you use screws small enough not to short against anything else on the motherboard, and make sure you put a sheet of cardboard or something else insulating under the motherboards (I've never trusted bare wood to be a perfect insulator; residual sap can really ruin your day, though I suppose a good paint job takes care of that). You're still not going to get a 1u machine, but it'll be easy to access the guts of each system.
If you *really* want a 1u form factor, look into getting some of those PCI riser cards that turn cards 90 degrees. That should get thet board height down to something reasonable, as long as you aren't using more than one or two cards per system (integrated chipsets are Your Friend if you're building a rack; you generally don't care about sound or a kickass graphics card for a server box).
Failing all else, remember that even the cost of a conventional rack is likely to be much less than the cost of the systems you're putting into it.
I'm glad it hasn't been launched, solar sails are far too dangerous to be allowed in orbit.
Before you condem me, think of the facts. They are talking about orbiting a huge, acre sized, piece of mylar, with controls to change it's orientation.
It's a giant space mirror!
For those of you didn't read the Mars trilogy, think back to the first time you played with a magnifying glass in your backyard.
Because far too many people seem to be taking this (hopefully) humorous post seriously:
While you could fry things magnifying-glass style with a concave mirror, you won't be able to with a solar sail. To focus light properly at all, the mirror would have to have a very precisely controlled shape. You *could* put a complicated and heavy support structure around a space mirror to adaptively shape and focus it, but you sure as heck won't see this on any solar sailcraft.
Sailcraft don't need to focus light; they just need to reflect or scatter it more-or-less backwards (or at least, less forwards than it was when it came in). Thus, they don't bother with heavy focusing gear, and so wouldn't be able to burn holes in anything if they tried.
Several useful suggestions have already been posted. One additional one: Initialization.
Rig macro wrappers for malloc() and calloc() and the like that initialize new memory to 0xdeadbeef if you have a memory debug flag active. This should make your program crash more abruptly when it starts doing something questionable.
This won't help much for finding the race condition or non-thread-safe code causing the problem, but it may give you some idea of what's being stomped, and make the heisenbug more predictable.
The sonic boom is only produced at the precise moment where the speed of travel for the plane is equal to the speed of sound. At that speed, the sound waves emitted over a period of time "bunch up" and hit together, causing a sonic boom. However, this doesn't apply once the speed gets above the speed of sound - in fact, the faster above the speed of sound that the plane gets, the less of a sonic boom effect it will produce. After Mach 2, the sonic boom effect will be less than if it were standing still.
The shockwave is only a _plane_ when you're at exactly Mach 1. However, you still do indeed get a shockwave at higher speeds. It's a cone instead of a plane, that gets a narrower and narrower aspect ratio as the plane travels faster (the cone expands radially at Mach 1, but the tip [the plane] is moving much faster).
Draw the tip of a stick across still water and watch the ripples to see what I mean. Try this at different speeds (from very slow to very fast).
As it's still a shockwave - an abrupt (discontinuous) change in the velocity and density of the air - it'll still sound like a thundercrack, and will still break windows, because it deposits all of its energy at once (when the shock passes the listener/window).
You'll actually get _more_ damage at higher Mach numbers, because the energy shed into the atmosphere is roughly proportional to the cube of the plane's speed (one of the reasons heating's a problem in hypersonic craft).
It needs to be controlable by a master computer that can link each user to any number of channels and change them around on the fly.
isn't so easy to do with plain old radio.. cool application, but likely VERY expensive..
Actually, as long as you don't need a silly number of sets, it should be straightforward with a hybrid system that doesn't require ethernet. Make each headset a good-quality walkie-talkie with its own frequency, talking to the server. Have the server handle mixing of appropriate channels. The only missing piece is a card or set of cards with multiple audio-frequency analog inputs and outputs, and the phone companies have been using cards like this for years.
You'd have to do a bit of hardware hacking to implement a system like this, but it's not terribly difficult.
For quite a while there have been persistent rumours of a US military aircraft that flies at Mach 5 using liquid methane as a fuel. That would nix the "first aircraft to travel at this speed" claim.
Are there actual records of the US craft's existence, or does it remained a rumour?
If I was HP, I'd be overjoyed to fund this meeting. It's a win/win situation.
If the Open Source community has no claim on the IP in question (as is likely for most of it), then it's good from HP's point of view to have this established as quickly as possible.
If the Open Source community _does_ have claim or partial claim to the IP, then HP earns kudos for being good sports about it, and is thus more likely to finagle dual-licensing or cross-licensing for the IP that they're interested in.
The amount of money involved is negligeable to a large organization, and the PR and potential precedent-setting benefits are substantial. Expect other companies to make backing contributions Really Soon Now.
It really got me to thinking about the implications of DataGlyphs. Suppose each of those survey forms is "pre-numbered" using DataGlyphs. Now they just need to tie the fact that you took the "blank" form from the top of the stack with your identity -- and poof the survey is no longer anonymous.
A lower-tech solution is to just write on a serial number in UV-fluorescent transparent ink. This stuff's been around for years.
Or laser-print it at stupid-DPI in flyspeck 3.
Or just remember the order in which people go into the room and surveys go into the slot.
Now, unless you're carding the people for other purposes or otherwise already have their ID, this will avail you nothing...
Previous posters have noted that LCDs drain less power than CRTs. If you can find ones that are lit by ambient light instead of a backlight, you'll cut power requirements by a huge amount again.
Netbooting instead of hard drives.
Do a ROM boot off of the network card, and store files on a good file server. Dump in lots and lots of RAM so that you don't miss the swap space (RAM is cheap). Congratulations; you've now slashed another large contributor to the power budget.
Just make sure you're using 100-mbit or better.
Unless you're *sure* you need them, leave out CDROMs.
Students will use these as CD players, draining power. Ditto sound cards; there's no reason to have them unless you're doing sound editing in the labs.
Use simple graphics cards.
You don't need the power baggage associated with a kickass graphics card's high clock rates. Unless you're doing hardware-assisted rendering, an old-fashioned card with just 2D acceleration will be fine.
A floppy drive drains power, but is occasionally needed, and isn't used much, so keep it in. Beyond that, most of the frills can go.
If coding in pairs seems a bit of a stretch to you, you might consider implementing code reviews as a first step. This is where once every so often the project members get together and review a semi-random "representative" piece of code from the project, line-by-line. You'd be amazed how many little ambiguities and kludges are found this way that you'd forgotten about.
The results are less dramatic than those advertised here, but still worthwhile for something that lasts no longer than a standard project meeting.
As other posters have mentioned, your university's job centre is the best place to start.
Failing that, the best thing to do is probably to look through the local phone book for software companies. Check their web pages to see what kind of work they do, and snail-mail your resume to them (snail-mail is better than faxing, and both are better than email, for this purpose).
Make sure to tailor your resume and cover letter to the companies you're applying to. If any of them are hiring or even *thinking* of hiring, you stand a good chance of getting interviews.
You should be aiming for an entry-level software position as an intern or a temp worker (if you're just going for the summer).
Be prepared to devote large amounts of effort to the search. I've found that there's about a 100:10:1 ratio between applications to interviews to job offers, so if you want a few offers to choose from, you'll need to send out a few hundred resumes. If you're really good, or have good-looking past experience, or have a really good interview, you may do better than this. YMMV.
They're talking about more than a laser here. One application is indeed about using the plasma as a power source The other application is more interesting. That one uses magnetic fields to focus the plasma and direct it. I have the same degree of doubt about the application's feasiblity, but they're talking about directing the plasma itself.
And I think that that last part was vapour, as per my original post.
It's a toroid of plasma. Right? A doughut of charged particles moving towards a target. What's the magnetic force on the torus? F=Q(vXB). If I remember right, shouldn't the magnetic force resulting from this situation confine the plasma to its original torus?
Firstly, your plasma is electrically neutral. It acts like a conducting neutral gas. Separating out substantial amounts of charge from the packet would a) take one heck of a lot of work, and b) cause the resulting charged packet to expand due to it repelling itself. It might be useful to use electrostatic forces to _fire_ the bolt, but when the packet leaves the gun, it's either neutral or it becomes neutral really fast by stealing charge from the atmosphere.
What would actually stabilize a plasma packet would be electric currents within the plasma. Unfortunately, this doesn't work very well.
If it has no internal currents, then magnetic forces will do nothing, as there's no magnetic field. It will then expand due to gas pressure (ignoring the effects of the atmosphere for a moment).
If it has internal currents, they'll either be toroidal (in the direction of the tube) or poloidal (winding around the tube, going through the hole).
Toroidal currents would compress the tube into a ring, fighting one expansion tendency, but would cause the ring to expand outwards (remember what happens to a closed loop carrying current).
Poloidal currents would crush the ring toroidally (the forces would "want" to shorten the circumference of the toroid), but this force would be uneven. It would be strongest near the hole in the toroid, and weakest near the edge. This would not lend itself to a balanced configuration. The poloidal currents would also make the tube of the toroid "want" to expand, again due to the same effect that pushes outwards on a closed current-carrying loop.
You can set up both toroidal and poloidal currents to try and balance these effects against each other, but this isn't very stable. It has been done in "spheromak" plasma confinement experiments, but these experiments a) are in vacuum, and so minimize outside disturbances, and b) are inside of a conducting tube, which causes "mirror currents" to be set up in the walls of the tube which stabilize the toroid.
In free air, this won't be stable. Not a chance.
What about using powerful radio waves to keep the plasma focused as it travels down range?
This is probably possible if it's travelling down an enclosed tube, or if you can otherwise focus radio beams on to it from many directions. From a single radio source in open air, I have strong doubts.
Someone I once worked with (a physics graduate) suggested that work was going on in specific places to improve some successful experiments for keeping a body of plasma from diverging within a gaseous field, i.e. the atmosphere.
This would be really neat if it could be done, but everything I know about physics says "not a chance", for a few reasons:
Your plasma is cooling off rapidly. It's touching the atmosphere, and Newton's Laws of Heating and Cooling hold. As it cools, its properties change, so any stabilization mechanism would have to be robust over a wide range of temperatures _and_ stable with temperatures changing (at different rates in different parts of the packet).
You have one hell of a lot of turbulence where the plasma packet touches the air. This would be bad enough for a packet of cold matter (e.g. water or compressed air), but with the added turbulence due to both plasma and air reacting to temperature change... Not a chance.
Your plasma packet will slow down so fast it's not funny. The 1/e velocity point is where the cross-sectional mass of the projectile is the same as the cross-sectional mass of the air it's plowed through (though you can get a fudge factor for an aerodynamic projectile). For a plasma packet, that'll be a few _inches_. Firing a plasma packet more than a few feet without having it shed all of its energy in its wake would take truly silly amounts of power.
In summary, whatever experiment is being talked about is almost certainly not the firing of a plasma packet through open air with no further intervention.
Things that I can think of that _might_ give rise to a report like this:
Firing within a pipe or in another bounded environment. If the shape is right, and the object is travelling slower than the speed of sound in the medium, you can get a "soliton wave" forming, where wake disturbances reflected off of the walls interfere constructively and stabilize the packet. This won't happen in open air. Your packet will still cool off; you'll end up with a puff of compressed air coming out the end of the pipe.
Dumping energy into the packet with a laser. If you're firing a laser along the path of the plasma packet's motion, you might get what _looks_ like a stable plasma packet moving through the air if you fire the packet faster than the speed of sound. What actually happens is that the packet smacks into the air and disperses, but creates a shockwave when it does so. Your laser heats the air behind the point of impact, which a) raises pressure, propelling the remainder of the gas packet forwards, and b) heats up the plasma. If the rate of energy input is equal to the rate of energy loss and if between confinement by the shockwave and input of matter through the shockwave mass gain equals mass loss, you might get a stable shockwave with a plasma packet at the top powered by the laser beam.
I'd personally just fire the laser beam, or dispense with the laser altogether and fire a kinetic slug, but I can see this working with enough twiddling.
So, there are a couple of effects that might look like a "plasma gun" that actually aren't, which might give rise to the reports both from your co-worker and the article.
Short version: There's nothing fundamental, there just isn't enough demand to drive the price down (standard chicken-and-egg problem).
Long version is that there are a few problems (mostly solvable):
Diffraction will limit your resolution.
You're projecting the image through a very small aperture. This causes any ray passing through the aperture to "fuzz out" over a certain angular range (as determiend by the aperture size and the wavelength of the light used). The limit is still a few thousand pixels wide for a reasonable monitor size and distance, but it's still a limit.
Making small, hi-res LCDs is very expensive.
One of the main problems with LCD manufacture is that it takes a very clean environment. The finer the resolution of the LCD, the cleaner a clean room you need, because smaller grains of dust will still interfere with manufacture. If you want to put a tiny 1280x1024 LCD into a pair of glasses, that LCD will be many times more expensive than a screen-sized 1280x1024 LCD. This is one of the reasons why glasses-based displays have poor resolution (coarser resolution means cheaper screens).
This applies to most types of flat-panel display, not just LCDs.
Ergonomics and convenience. Head-mounted displays aren't horrible ergonomically, but they aren't wonderful either. In their current incarnation, they're clumsier to use than a stationary monitor, and they're harder to do work on due to the lower resolution. There really isn't much of a reason (at present) to use a wearable display instead of an ordinary flat-panel display with your notebook or desktop.
The proponents of wearable computing argue that wearable computers (with displays) will be a new computing niche, but there doesn't seem to be enough demand (yet) to drive the prices down. This too is probably a convenience issue (would you really *want* to try to answer email while jogging, or in the press of rush-hour passengers while standing in a bus or train? If you're sitting down, you can use your laptop or palmtop.).
I'll be the first to cheer when affordable, high-resolution wearable displays reach the market, but they'll have to fight pricier technology and mediocre demand to do it.
What they're talking about doing is diverting some of the plasma from the shockwave of hot gas that forms around any hypersonic craft, and then using that to power a weapon.
Item number one: This is just an indirect way of drawing power from the craft's engines (as they're what push the craft along, and what give the craft the kinetic energy that it's shedding when it makes this shockwave). This is still useful, because the engines are handling an obscene amount of power.
Item number two: All they're (sanely) talking about is a laser here, folks. This has the same advantages and drawbacks of any other laser weapon: Almost zero time to reach the target, but it takes a lot more energy to do damage than (say) a railgun would, and you lose about 95%-99% of your wall-plug power as heat in the laser.
The laser will also reflect off of the plasma shell (lots of free electrons in there). I hope they're planning to fire it backwards.
Item number three: While you might be able to fire packets of plasma, this weapon would be useless in an atmosphere. Plasma is much more tenuous even than air. As soon as it hits the air, the packet disperses. What you'd actually get is something resembling a plasma torch, not a gun.
Even in space something like this is iffy. A toroid of plasma with the right combination of toroidal and poloidal currents running within it *might* be stable (in vacuum) for a short time. Most "packets" of plasma would expand due to gas pressure (they're a gas) or due to magnetic forces if you try to stabilize them with internal currents (you usually get compression in one direction at the expense of expansion in another).
Summary: An interesting thought-experiment, but not the "plasma gun" of video game fame.
I'd rather see television shows come with some sort of classification tag, so I could build custom filters to screen out the truly offensive programming on television:
The sad thing is, this kind of selective filtering would be a beautiful feature to have (especially if it replaced the commercials with a nice screen-saver).
The fun thing is that I can see something like this being rigged "ad hoc" when/if programmable TVs come to the masses (be it TIVO-style, with a separate box managing content, or integrated into the television set, or by using a computer with a tuner card instead of a TV). You could figure out what's playing by taking the time of day and your location, or a "signature" based on a hashed few-second excerpt of the show, or both, and firing them off as an anonymous query to a CDDB-style database to find out if it's something you've told it you want to watch or want to filter.
Then have a coding contest to see if you can write a filter that can automatically distinguish between a commercial and your show...
Heck, I even see an easy way to automate public and private database generation and commercial filtering, given a signature-generating algorithm. This is a really nifty problem.
Slashdot Mirror
Don't get me wrong...Mr. Hawking and his peers think more before breakfast than I do in an average year, but without falsifiable hypotheses, a lot of cosmology has more to do with faith than with fact. This is not necessarily a bad thing, but one has to realize it for what it is.
Models of the universe's creation actually do produce a surprising number of testable predictions.
We see space permeated by 3K blackbody radiation. The big bang model neatly explains this (the universe was once very hot and compact). Steady-state models don't. Scratch the steady-state models.
We see a universe that is apparently geometrically "flat" (Euclidean). This eliminates a wide range of big bang models, and suggests (among other things) that the universe may have started with zero net energy (and thus be the result of a quantum fluctuation).
We see matter clumping on a small scale, but amazingly uniform on a larger scale. The degree and patterns of clumping observed suggest a period of extremely rapid expansion while the universe was very small. Thus, the various inflationary models of the universe. Some produce predicted mass distributions that match the universe's; some don't. Scratch the ones that don't.
Our models of physics at the extreme temperatures and densities that the universe looks like it had in its youth are not well-defined. Some options suggest that we'd get zillions of black holes permeating space. Do we see any? No, so scratch that range of physics models. Other options suggest gigantic artifacts like "cosmic strings" or "great walls". Do we see any? No walls, and strings are inconclusive (putting an upper limit on the number present, if any). This narrows the range of physical theories even more, which in turn gives us a better idea of how the universe would have behaved under early conditions, which lets us refine our predictions of what an old universe would look like under a given model, which lets us further prune models according to observations.
In summary, while speculation indeed occurs, when a model is selected it's usually selected based on the testable predictions it makes.
Again, a library search will turn up most of this.
The Big Bang theory always sounded too biblical to me. I mean one event from a single point exploding to create everything? We see relatively tiny bangs every day from novas and planetary death - I see no reason to think the Big Bang wasn't just a particularly large version of these daily occurences.
The Big Bang was fundamentally different in a number of ways.
Normal explosions involve moving a lot of matter and radiation around through space.
The big bang involved a lot of matter *and* space coming out of nowhere as the result of a quantum fluctuation [to grossly oversimplify].
Yes, there might be other big bangs "outside" the universe, but as both space and time exist only within the universe, we'd have no way of reaching hypothetical other universes [under the classic big bang model; other models propose bangs happening within a universe creating a new bubble of space and time, and other models propose one universe in which pockets undergo inflation and *look* like new universes from the inside.]
Your local univerity's library should have a lot of information on the subject, filed under "cosmology".
In this case you could not use a plastic backing film because the operating temperature of the cell is 1000C! I am not aware of any polymer that can take that sort of temperature (I could be wrong though).
My mistake; I was thinking photocells.
You could probably use a graphite composite, though, if weight was a serious problem. It's in vacuum, so it won't burn.
Hey, there are libraries that manage to avoid C++ constructs to abstract this sort of stuff. For example, B-tree operators could use a fixed structure in which there exists the data fields necessary for the library to do its thing, and the "payload" of the structure is a void pointer to the data referenced by the B-tree node. This means that you can have disk-resident B-trees by using the void pointer to refer instead to a byte offset; array-resident B-trees by using the void pointer to hold an index; value-oriented B-trees by having an integer value in the void pointer.
Oh, I know that you can duplicate most (or all) OO features in straight C. I've just run into the limits of practicality for this on a few occasions. At least twice I've caught myself implementing collections of function pointers in structures to emulate polymorphism. If I'm doing *that*, I might as well just use C++ and save myself a lot of hassles debugging typos.
YMMV. I realize that for some applications, having to trust automatic implementation is bad, but for most of what I work with it's worth it.
The front sheet cannot be thick -- light has to pass through it!
What you do is you use a thin film with a mesh of thicker wires over it to carry the bulk of the current. Take a look at a conventional solar cell, and you'll see a dentritic wire pattern on it that does this.
The _average_ thickness has to be enough to carry the required sheet current, even if the thickness on most of the surface is small.
GaAs has the density of steel. I think diamond is about twice that (I don't quite remember).
No, diamond is just 3.5 or so. Steel is about 8. Silicon is about 2.3.
I agree with most points, except that though in space you don't need much backing, you still need to reinforce them for launch. Which entails about 4-6gs for a shuttle, and lots of vibration.
What you'd actually do if you had a photovoltaic film (on metal or plastic) is roll it up for transport, and unfurl it in space. You can keep it thin that way.
The limiting factor will be the required thickness of the electrode films (the two metal films sandwiching the diamond film). These will have large sheet currents going through them, and so will have to be thick. The diamond film can be as thin as desired, down to a few light wavelengths, I think (a few microns).
The prime cost of putting things into space is not material, but the rockets you build to put them up there. Diamonds are much more dense than silicon or GaAs (the solar cell of choice in space nowadas, so the article is kinda wrong), so they will be correspondingly more massive.
You're talking about a film a few tens or hundreds of microns thick on a sheet of metal.
The density of the diamond film is moot point.
Even if you deposit both a metal film and a diamond film on top of a lighter substrate (like mylar or another plastic), 1) the metal film will still outweigh the diamond film - it has to be thicker, because it's carrying current sideways instead of axially, and 2) the weight of the plastic backing will be much more than the weight of either of the films, because you'd only be using a backing if you could make the films very thin (otherwise you'd just use the thicker metal layer as the backing - this is a space environment, it doesn't have to be very strong).
The feature that crops up in practice most for me is polymorphism.
I code mainly in C, not C++. I've just written yet another program that uses a binary tree to store several different types of data. The naive way of writing this is to make several different tree-node types and several sets of nearly-identical tree manipulation functions. The way I did it was to kludge things with a data type identifier and a union of the possible data stored.
The Right Way to implement this is to make an abstract class for the tree node, write the tree manipulation methods to work with the abstract class, and make derived classes that store different types of data, with appropriate constructors that initialize the data fields. Anything that doesn't have to care about the data type can just manipulate the objects as the original abstract class.
This situation has cropped up before. Any situation where I'm doing the same type of thing with many types of data can benefit from derived classes and polymorpism. This happens frequently with utility libraries that I write, but also crops up now and then with certain types of information storage task.
I still code in C most of the time, because I'm too lazy to dust off my C++ books and these are just my own projects. However, this is indeed a common set of cases where features of C++ would be useful.
Unfortunately, the question is academic for any computer-based encryption scheme. If anyone wants to know how the encryption works, they'll run the binary through a disassembler and a debugger and find out in glorious detail. Thus, against the adversaries you're interested in (people actively trying to subvert the encryption), there is no practical difference between an open and a closed encryption scheme.
Given this state of affairs, it's better to make the system open so that it can be more easily peer reviewed and audited for things like buffer overflows (yes, people who can peer-review encryption algorithms are rare, but they exist, and Joe Coder can spot stupid coding errors readily enough).
A hardware-based encryption scheme is tempting to implement, but you'll have to worry about a) your hypothetical adversaries obtaining schematics by bribery and social engineering, and b) someone gutting the box and (if necessary) stripping the chips to find out what the device is doing. Harder, yes, but not impractical by any stretch.
In summary, I don't trust obscurity to significantly hinder hostile parties' extraction of the encryption algorithm.
By far the cheapest solution will be to build an ordinary set of sliding shelves for the boxes. It works quite well; as long as you pay enough attention to ventilation, you could easily fit a dozen or more systems inside a small closet (or a rack the size of a small closet).
If you want to make things even more compact, gut the cases and screw the motherboards directly on to the shelves. Make sure you use screws small enough not to short against anything else on the motherboard, and make sure you put a sheet of cardboard or something else insulating under the motherboards (I've never trusted bare wood to be a perfect insulator; residual sap can really ruin your day, though I suppose a good paint job takes care of that). You're still not going to get a 1u machine, but it'll be easy to access the guts of each system.
If you *really* want a 1u form factor, look into getting some of those PCI riser cards that turn cards 90 degrees. That should get thet board height down to something reasonable, as long as you aren't using more than one or two cards per system (integrated chipsets are Your Friend if you're building a rack; you generally don't care about sound or a kickass graphics card for a server box).
Failing all else, remember that even the cost of a conventional rack is likely to be much less than the cost of the systems you're putting into it.
I'm glad it hasn't been launched, solar sails are far too dangerous to be allowed in orbit.
Before you condem me, think of the facts. They are talking about orbiting a huge, acre sized, piece of mylar, with controls to change it's orientation.
It's a giant space mirror!
For those of you didn't read the Mars trilogy, think back to the first time you played with a magnifying glass in your backyard.
Because far too many people seem to be taking this (hopefully) humorous post seriously:
While you could fry things magnifying-glass style with a concave mirror, you won't be able to with a solar sail. To focus light properly at all, the mirror would have to have a very precisely controlled shape. You *could* put a complicated and heavy support structure around a space mirror to adaptively shape and focus it, but you sure as heck won't see this on any solar sailcraft.
Sailcraft don't need to focus light; they just need to reflect or scatter it more-or-less backwards (or at least, less forwards than it was when it came in). Thus, they don't bother with heavy focusing gear, and so wouldn't be able to burn holes in anything if they tried.
Several useful suggestions have already been posted. One additional one: Initialization.
Rig macro wrappers for malloc() and calloc() and the like that initialize new memory to 0xdeadbeef if you have a memory debug flag active. This should make your program crash more abruptly when it starts doing something questionable.
This won't help much for finding the race condition or non-thread-safe code causing the problem, but it may give you some idea of what's being stomped, and make the heisenbug more predictable.
The sonic boom is only produced at the precise moment where the speed of travel for the plane is equal to the speed of sound. At that speed, the sound waves emitted over a period of time "bunch up" and hit together, causing a sonic boom. However, this doesn't apply once the speed gets above the speed of sound - in fact, the faster above the speed of sound that the plane gets, the less of a sonic boom effect it will produce. After Mach 2, the sonic boom effect will be less than if it were standing still.
The shockwave is only a _plane_ when you're at exactly Mach 1. However, you still do indeed get a shockwave at higher speeds. It's a cone instead of a plane, that gets a narrower and narrower aspect ratio as the plane travels faster (the cone expands radially at Mach 1, but the tip [the plane] is moving much faster).
Draw the tip of a stick across still water and watch the ripples to see what I mean. Try this at different speeds (from very slow to very fast).
As it's still a shockwave - an abrupt (discontinuous) change in the velocity and density of the air - it'll still sound like a thundercrack, and will still break windows, because it deposits all of its energy at once (when the shock passes the listener/window).
You'll actually get _more_ damage at higher Mach numbers, because the energy shed into the atmosphere is roughly proportional to the cube of the plane's speed (one of the reasons heating's a problem in hypersonic craft).
It needs to be controlable by a master computer that can link each user to any number of channels and change them around on the fly.
isn't so easy to do with plain old radio.. cool application, but likely VERY expensive..
Actually, as long as you don't need a silly number of sets, it should be straightforward with a hybrid system that doesn't require ethernet. Make each headset a good-quality walkie-talkie with its own frequency, talking to the server. Have the server handle mixing of appropriate channels. The only missing piece is a card or set of cards with multiple audio-frequency analog inputs and outputs, and the phone companies have been using cards like this for years.
You'd have to do a bit of hardware hacking to implement a system like this, but it's not terribly difficult.
For quite a while there have been persistent rumours of a US military aircraft that flies at Mach 5 using liquid methane as a fuel. That would nix the "first aircraft to travel at this speed" claim.
Are there actual records of the US craft's existence, or does it remained a rumour?
The amount of money involved is negligeable to a large organization, and the PR and potential precedent-setting benefits are substantial. Expect other companies to make backing contributions Really Soon Now.
It really got me to thinking about the implications of DataGlyphs. Suppose each of those survey forms is "pre-numbered" using DataGlyphs. Now they just need to tie the fact that you took the "blank" form from the top of the stack with your identity -- and poof the survey is no longer anonymous.
A lower-tech solution is to just write on a serial number in UV-fluorescent transparent ink. This stuff's been around for years.
Or laser-print it at stupid-DPI in flyspeck 3.
Or just remember the order in which people go into the room and surveys go into the slot.
Now, unless you're carding the people for other purposes or otherwise already have their ID, this will avail you nothing...
Previous posters have noted that LCDs drain less power than CRTs. If you can find ones that are lit by ambient light instead of a backlight, you'll cut power requirements by a huge amount again.
Do a ROM boot off of the network card, and store files on a good file server. Dump in lots and lots of RAM so that you don't miss the swap space (RAM is cheap). Congratulations; you've now slashed another large contributor to the power budget.
Just make sure you're using 100-mbit or better.
Students will use these as CD players, draining power. Ditto sound cards; there's no reason to have them unless you're doing sound editing in the labs.
You don't need the power baggage associated with a kickass graphics card's high clock rates. Unless you're doing hardware-assisted rendering, an old-fashioned card with just 2D acceleration will be fine.
A floppy drive drains power, but is occasionally needed, and isn't used much, so keep it in. Beyond that, most of the frills can go.
If coding in pairs seems a bit of a stretch to you, you might consider implementing code reviews as a first step. This is where once every so often the project members get together and review a semi-random "representative" piece of code from the project, line-by-line. You'd be amazed how many little ambiguities and kludges are found this way that you'd forgotten about.
The results are less dramatic than those advertised here, but still worthwhile for something that lasts no longer than a standard project meeting.
As other posters have mentioned, your university's job centre is the best place to start.
Failing that, the best thing to do is probably to look through the local phone book for software companies. Check their web pages to see what kind of work they do, and snail-mail your resume to them (snail-mail is better than faxing, and both are better than email, for this purpose).
Make sure to tailor your resume and cover letter to the companies you're applying to. If any of them are hiring or even *thinking* of hiring, you stand a good chance of getting interviews.
You should be aiming for an entry-level software position as an intern or a temp worker (if you're just going for the summer).
Be prepared to devote large amounts of effort to the search. I've found that there's about a 100:10:1 ratio between applications to interviews to job offers, so if you want a few offers to choose from, you'll need to send out a few hundred resumes. If you're really good, or have good-looking past experience, or have a really good interview, you may do better than this. YMMV.
They're talking about more than a laser here. One application is indeed about using the plasma as a power source The other application is more interesting. That one uses magnetic fields to focus the plasma and direct it. I have the same degree of doubt about the application's feasiblity, but they're talking about directing the plasma itself.
And I think that that last part was vapour, as per my original post.
It's a toroid of plasma. Right? A doughut of charged particles moving towards a target. What's the magnetic force on the torus? F=Q(vXB). If I remember right, shouldn't the magnetic force resulting from this situation confine the plasma to its original torus?
Firstly, your plasma is electrically neutral. It acts like a conducting neutral gas. Separating out substantial amounts of charge from the packet would a) take one heck of a lot of work, and b) cause the resulting charged packet to expand due to it repelling itself. It might be useful to use electrostatic forces to _fire_ the bolt, but when the packet leaves the gun, it's either neutral or it becomes neutral really fast by stealing charge from the atmosphere.
What would actually stabilize a plasma packet would be electric currents within the plasma. Unfortunately, this doesn't work very well.
If it has no internal currents, then magnetic forces will do nothing, as there's no magnetic field. It will then expand due to gas pressure (ignoring the effects of the atmosphere for a moment).
If it has internal currents, they'll either be toroidal (in the direction of the tube) or poloidal (winding around the tube, going through the hole).
Toroidal currents would compress the tube into a ring, fighting one expansion tendency, but would cause the ring to expand outwards (remember what happens to a closed loop carrying current).
Poloidal currents would crush the ring toroidally (the forces would "want" to shorten the circumference of the toroid), but this force would be uneven. It would be strongest near the hole in the toroid, and weakest near the edge. This would not lend itself to a balanced configuration. The poloidal currents would also make the tube of the toroid "want" to expand, again due to the same effect that pushes outwards on a closed current-carrying loop.
You can set up both toroidal and poloidal currents to try and balance these effects against each other, but this isn't very stable. It has been done in "spheromak" plasma confinement experiments, but these experiments a) are in vacuum, and so minimize outside disturbances, and b) are inside of a conducting tube, which causes "mirror currents" to be set up in the walls of the tube which stabilize the toroid.
In free air, this won't be stable. Not a chance.
What about using powerful radio waves to keep the plasma focused as it travels down range?
This is probably possible if it's travelling down an enclosed tube, or if you can otherwise focus radio beams on to it from many directions. From a single radio source in open air, I have strong doubts.
Interesting idea, though.
This would be really neat if it could be done, but everything I know about physics says "not a chance", for a few reasons:
In summary, whatever experiment is being talked about is almost certainly not the firing of a plasma packet through open air with no further intervention.
Things that I can think of that _might_ give rise to a report like this:
I'd personally just fire the laser beam, or dispense with the laser altogether and fire a kinetic slug, but I can see this working with enough twiddling.
So, there are a couple of effects that might look like a "plasma gun" that actually aren't, which might give rise to the reports both from your co-worker and the article.
Long version is that there are a few problems (mostly solvable):
You're projecting the image through a very small aperture. This causes any ray passing through the aperture to "fuzz out" over a certain angular range (as determiend by the aperture size and the wavelength of the light used). The limit is still a few thousand pixels wide for a reasonable monitor size and distance, but it's still a limit.
One of the main problems with LCD manufacture is that it takes a very clean environment. The finer the resolution of the LCD, the cleaner a clean room you need, because smaller grains of dust will still interfere with manufacture. If you want to put a tiny 1280x1024 LCD into a pair of glasses, that LCD will be many times more expensive than a screen-sized 1280x1024 LCD. This is one of the reasons why glasses-based displays have poor resolution (coarser resolution means cheaper screens).
This applies to most types of flat-panel display, not just LCDs.
Head-mounted displays aren't horrible ergonomically, but they aren't wonderful either. In their current incarnation, they're clumsier to use than a stationary monitor, and they're harder to do work on due to the lower resolution. There really isn't much of a reason (at present) to use a wearable display instead of an ordinary flat-panel display with your notebook or desktop.
The proponents of wearable computing argue that wearable computers (with displays) will be a new computing niche, but there doesn't seem to be enough demand (yet) to drive the prices down. This too is probably a convenience issue (would you really *want* to try to answer email while jogging, or in the press of rush-hour passengers while standing in a bus or train? If you're sitting down, you can use your laptop or palmtop.).
I'll be the first to cheer when affordable, high-resolution wearable displays reach the market, but they'll have to fight pricier technology and mediocre demand to do it.
What they're talking about doing is diverting some of the plasma from the shockwave of hot gas that forms around any hypersonic craft, and then using that to power a weapon.
Item number one: This is just an indirect way of drawing power from the craft's engines (as they're what push the craft along, and what give the craft the kinetic energy that it's shedding when it makes this shockwave). This is still useful, because the engines are handling an obscene amount of power.
Item number two: All they're (sanely) talking about is a laser here, folks. This has the same advantages and drawbacks of any other laser weapon: Almost zero time to reach the target, but it takes a lot more energy to do damage than (say) a railgun would, and you lose about 95%-99% of your wall-plug power as heat in the laser.
The laser will also reflect off of the plasma shell (lots of free electrons in there). I hope they're planning to fire it backwards.
Item number three: While you might be able to fire packets of plasma, this weapon would be useless in an atmosphere. Plasma is much more tenuous even than air. As soon as it hits the air, the packet disperses. What you'd actually get is something resembling a plasma torch, not a gun.
Even in space something like this is iffy. A toroid of plasma with the right combination of toroidal and poloidal currents running within it *might* be stable (in vacuum) for a short time. Most "packets" of plasma would expand due to gas pressure (they're a gas) or due to magnetic forces if you try to stabilize them with internal currents (you usually get compression in one direction at the expense of expansion in another).
Summary: An interesting thought-experiment, but not the "plasma gun" of video game fame.
I'd rather see television shows come with some sort of classification tag, so I could build custom filters to screen out the truly offensive programming on television:
The sad thing is, this kind of selective filtering would be a beautiful feature to have (especially if it replaced the commercials with a nice screen-saver).
The fun thing is that I can see something like this being rigged "ad hoc" when/if programmable TVs come to the masses (be it TIVO-style, with a separate box managing content, or integrated into the television set, or by using a computer with a tuner card instead of a TV). You could figure out what's playing by taking the time of day and your location, or a "signature" based on a hashed few-second excerpt of the show, or both, and firing them off as an anonymous query to a CDDB-style database to find out if it's something you've told it you want to watch or want to filter.
Then have a coding contest to see if you can write a filter that can automatically distinguish between a commercial and your show...
Heck, I even see an easy way to automate public and private database generation and commercial filtering, given a signature-generating algorithm. This is a really nifty problem.