why don't they just carefully excavate into it from the outside, instead of going to all the touble of sending these robots in etc...
Let me get this straight. You want to explore one of the wonders of the world, by cutting fucking great holes in it?!
Another approach that might work would be to take an industrial X-ray device and try to map out voids in the building by the equivalent of CAT. Such machines are already used to do non-destructive inspections of buildings looking for failure (though I doubt they try to send an x-ray beam through hundreds of metres of stone).
This would take a while, but would provide a reasonably complete low-resolution map of the pyramid's structure. Sink a few shafts to the side of the pyramid, and you can get the underground structure (if any) too.
Umh, ever thought that there might be some difference between hard solid material like stone, metals, and liquids like water... that just might make this approach unusable?
Actually, sonar works quite well through stone. The problem is that cracks and boundaries between different materials cause a lot of reflection and scattering.
It's _dirt_ that would be a nightmare to send sonar through, but even that would work at low frequencies.
If it was possible to use sonar like this, caverns of Bora Bora (in Afganistan, the supposed stronghold of mr. Laden et al) would have been piece of cake to take care of.
Again, this could easily have been done - it would just have taken more work than was practical.
This kind of technique is used all the time when prospecting for oil. You have a bomb in one place, and a bunch of seismic sensors in others. Set off the bomb, and look for reflections from the kinds of formations that trap oil.
News flash: if changing resolution improves performance, then your problem is that you're fillrate bound on the raphics card. Nothing to do with your CPU
That depends. Objects that take up fewer pixels (either far away or viewed up close at lower-res) are drawn with lower poly-count models. If you're CPU bound dealing with any of the geometry, this can cause the game to be slower at higher resolution (when more objects need the more detailed models).
Even when you're fill-rate limited, the fault can be with the game. The unpatched version of Tribes 2 ran like a slide show on my machine. As far as I could tell, this is because it wasn't doing nearly enough culling and hidden-surface removal before rendering the scene (this caused certain telltale visual artifacts). The patch boosted performance to a playable level.
For microprocessors and motherboards, prices are tied to the linewidth cycle.
A couple of months after a new linewidth becomes available, you get a few marginally higher-speed samples at a huge price.
Over the next six months, speed ramps up by a factor of 2 and prices drop on the older stuff. During this time any new chipsets introduced for the new hardware mature.
6 months after a linewidth switch, buy from the low end of the new speed grade range. You'll get a good price, and won't be obsolete for a year or more (as opposed to the usual 6 months).
There should be similar cycles for RAM (twice as fast, since they step lithography in cycles twice as fine), but in practice this isn't the case. Because margins are so thin, you get the occasional upset that drastically affects price (sometimes with help - the warehouse fire that quadrupled RAM prices a few years back only affected 3% of production capacity, according to rumour).
Processors are driven by linewidth, and motherboards are driven by processors, but most other things are market driven and so not as easy to predict. Other posters seem to have a better handle on this than I do:).
I'm concerned by this too. The central HyperTransport links in an 8-way system will be heavily contended for many workloads. (Not to mention the latency even in the absence of contention.) Something has to give.
If I understand correctly, the Sledgehammer has an extra HT link port, which will let them add extra processors as a mesh instead of a chain. The problem still occurs, but it's less crippling for large processor counts.
I'd have to doublecheck this feature, of course.
They may also be banking on fewer processors being used for most applications. I'm actually kind of impressed with their four-processor demo. It's large enough to be impressive, and for shared-bus schemes to bog down, but small enough that even with randomly-distributed data, really long hops will be uncommon. I don't see them competing in the Starfire/Sunfire's market any time soon, so larger systems might not be a problem.
So, for multiple processors working on a shared workload, you're screwed.
From the Hammer presentations I've seen, this is not true at all. The HT link between CPUs is 6.4GB/s, which is actually faster than the direct-attached memory (~5.3GB/s). Since the HT controllers are running at >2GHz, they introduce minimal latency.
I'll believe this when I see it, I'm afraid. You're trying to burst, at minimum, a 64-byte cache line over a HT link 32 bits wide, over a motherboard (the HT link can't do that bridge at 2 GHz, period). So you have at least 16 bus cycles for the data alone. The full overhead is request->proc2ctl->proc2mem/cache->long data burst. Even worse than that if you have to go through more than one processor (the Hammer boards we saw pictures of had processors daisy-chained. Ugh.). Latency from this will be very substantial. Migrating/copying pages is the only way to substantially reduce this in a NUMA system.
If I'm proven wrong when the system ships, I'll be the first to cheer, believe me.
For workloads that have shared data but that *aren't* saturating the memory bus, a shared-bus system would be faster. For workloads that do saturate the bus, NUMA is faster even with the delay, except under pathological conditions (i.e. all data in *one* processor's memory bank, with no migration).
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
I don't think this is true either. Contention for a cache line will simply bounce the line between caches, which is much faster on Hammer than on a 400MHz shared-bus SMP.
Depends on the coherence mechanism, and on how many steps through the daisy-chain you have to take for AMD's system.
In general, performance won't be much worse with NUMA (and could easily be better), but that doesn't change the fact that with contention it'll suck hard no matter what you do. HT bandwidth doesn't save you, which was the implication of the original post that I took issue with.
By moving the memory controller onto the processor and providing communication between processors over a hypertransport link (3.2GB/sec for bandwidth actually increases as more cpus are added! This is in contrast to a normal MP system where as more cpus are added, there is increased competition for a fixed resource (main memory) which is already the bottleneck in many single processor applications.
This is true only if the processors are running tasks with unrelated working sets (and if the data for each task is in that processor's memory).
If you have tasks that require memory managed by another processor, you have to go through the hypertransport link and the other processor's memory controller to get it. This will be _slow_. HT is decent, but nowhere near as good as a direct connection to memory, and there _will_ be delays due to arbitration on the second chip and the various buffering stages the data transfer has to go through.
So, for multiple processors working on a shared workload, you're screwed.
The only way to ameliorate this is to have very smart OS-level memory management that can duplicate shared-but-not-modified pages across multiple memory banks, and both OS and processor support for update-based coherence between the banks. The hardware support for this is a bit tricky, and the OS support will be a nightmare if the OS wasn't NUMA-friendly to begin with.
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
So, don't rejoice yet. We'll only know for sure how well this will work when we have Hammer systems on our desks.
Lot of posts are screaming "again, again"... but the fact is a 64 bit processor is one devil to design. The biggest problem with current processors is that to design such devices we *have* to use dynamic logic. Ask any VLSI design engineer.. that is no joke. Infact many multipliers and dividers have to be hand edited!
This is true for any processor, 64-bit, 32-bit, or otherwise. If you want the last 20%-30% of the performance, it will involve hand-optimization and an ungodly amount of work.
Designing a 64-bit chip vs. a 32-bit chip, OTOH, is mainly just replicating elements, though you do need design tweaking for a few pieces that don't scale well.
Re. dynamic logic, it really depends on the process you're using and what your design goals are. There are a lot of "gotchas" that you're undoubtedly already aware of that can degrade performance in a dynamic logic system, and other tradeoffs that are made when adding dynamic components to an otherwise-static system.
As with other design choices, there's no _requirement_ to do this. You just get a performance boost for certain specialized types of structure, which can justify the headaches if that kind of structure is on your critical path.
For a 64-bit processor that doesn't use dynamic logic (last I checked), just look at the MIPS line.
As for the 333mhz bus, I heard somewhere that the memory bus speed isn't the bottleneck for the Athlon processors...
Depends on what you're doing.
The P4, especially configured expensively, has a kickass memory subsystem on the motherboard (dual-channel anything will score high on bandwidth-bound tests). The fact that the Athlon doesn't has hurt its relative benchmark results even more than the speed war has.
I still love the Althlon, and I still avoid the P4 on (personal) principle, but a faster memory bus is a Good Thing for AMD.
The Hammer will live or die on this too. We don't have a real-world test of how well its memory subsystem works yet. The NUMA scheme for multiprocessor systems also gives me pause (without migration/copying of non-local pages, it'll bog down like crazy under certain conditions).
A well-performing Hammer will push AMD back into prominence. I strongly suspect that they're at least partly buying time to tune the core.
An interesting qestion is: is there such a thing as true randomness? How would you define it?
Read up on "entropy" for an introduction.
A sequence is random if, no matter what you do, you can't predict it with more than the randomly-expected accuracy.
Most people consider throwing a dice and reading the number on the top a random value. Is it? In theory, if you could measure the mass, stability, material etc. of the dice, the force which threw it, the properties of the table [...]
Some processes are truly random. Various quantum effects (as far as we can tell). Things like thermal noise in circuits (which is what most electronic random-noise generators amplify). You correctly point out that it's hard to cancel all non-random inputs to a system that measures a truly random variable, but you can get very close (and have a value that approaches truly random probabilities within known tolerances).
In practice, even (good) pseudo-random sequence generators are close enough for most practical purposes.
Lets face it: current computers and humans are both as bad as each other at randomness. The fact that computers have to "calculate" randomness is a bad sign in itself, and the humans that program these computers are almost utterly incapable of perceiving true randomness anyway.
Unless, of course, they're mathematicians, in which case they have a host of very powerful techniques for getting quite good evaluations of randomness, and a wide selection of sophisticated algorithms for producing really good pseudo-random sequences.
In summary, you are both overstating the problem and ignoring the vast body of experience built up for dealing with it.
You can also buy true random number generator cards off the shelf if you *really* can't live with a software solution. But be warned, these are suceptible to external influences (biasing them) and tend to be quite slow compared to PRNG techniques (even good PRNGs).
Re:Development isn't much different than Everquest
on
Inside Ximian
·
· Score: 2
"Oh, yes! Writing code and squashing bugs. I usually get here at 7, 7:30 a.m., and I learned not to turn on the lights, because there are probably people who have been here all night coding, who are asleep on the couch or the floor."
Also much like grad school (weekends? What are those?)
U of T has had an open network for over a year now. It was done as such for the benefit of the students. I don't know what the details are for access control, but with hundreds or thousands of wireless users, I doubt they even care much.
Ok, then it isn't the nameless prof.
It just disturbs me that, in addition to having basically insecure workstations with their arses hanging out on the 'net with little or no filtering, that we are doing the equivalent of giving anyone who walks by an ethernet cable and saying "here! don't bother attacking us remotely, we'll give you a direct link!".
To their credit, the administrators do a fine job of keeping the system up and running. I just find security around here a little worrisome.
The truth of the matter is: there are only two introductory physics textbooks: Halliday & Resnick, and the Feynman lectures. The first is DULL, and the second is unusable. All others are ripoffs of H&R, not done as well.
I hear you re. the Feynman lectures. Weren't those originally grad lectures, or am I off-base?
My physics text is the Tipler book, which was both understandable and engaging (but then, I'm a wierdo who likes this kind of thing and breezed through the first year or two of calculus). YMMV.
Solar = destroy you planet faster... The process for making silicon solar cells is very very VERY nasty and pollutes worse than dumping raw gasoline directly into a lake
Not if you're using thin-film cells.
Also not if you're using concentrators and very small cells.
Especially not if you're doing both.
Also especially not if you're using a non-photovoltaic system, like concentrators and a heat engine.
Of the "alternative" energy production schemes proposed, I find solar farms to be the most plausible as a real solution. (Not the solution I'd choose, but at least a potentially practical alternative.)
That said, we could probably start stuffing multi-channel digital signals into the spaces between the existing analog channels, or do some frequency hopping spread spectrum into those gaps, and get some decent performance in existing bandwidth.
While in principle we could do that, in practice the problems are twofold.
Firstly, we'd need to be using extremely good equipment to get the required dropoff in intensity outside our desired bands. Software radio isn't a magic bullet, here. Nonlinearities in your output stages and jittering and drifting in your modulation clock are just a few of the many things that conspire to screw you up here.
And building a bandpass filter that sharp the old-fashioned way is just painful.
So, we wouldn't be able to do this easily or cheaply.
Secondly, getting permission to use an already-claimed section of bandwidth makes pulling teeth look easy, so I doubt such a system would ever realistically be implemented. If you're not worried about legality, just use a lower-quality software radio rig to transmit spread-spectrum signals below the noise floor and pray that nobody near you notices fading.
But, again, it's a nifty toy, and potentially quite useful as a simultaneous multi-channel _receiver_, which is what most of the first-glance stuff on the software radio page was about. Also useful as a tool if you're doing R&D with radio devices (and so have permission to clutter the spectrum in your area).
Practially, this means that you can transform your machine into a WiFi or Bluetooth system by simply installing the right software. It also means that as new future wireless technologies emerge, your hardware can support them by a simple software install.
And a hardware upgrade, since your WaveMangler 3700 card can only handle signals up to 3.7 GHz, but the new Sub Ether Space Net nodes talk at 5.2 GHz...
To my understanding you can have a very high number of digital channels inside a single band which makes licensed analog frequencies just a waste of money to corporations if they use GNURadio as a means to transmit data long distances.
Not strictly true.
The amount of data that you can stuff into one frequency band within given power and noise specifications has a hard limit, no matter what the encoding scheme. Every once in a while someone claims that spread-spectrum or scrambled or UWB some other encoding scheme will surmount this, and every time someone else points out that this is not correct.
The encoding in conventional radio broadcasts is wasteful, but they don't need to adopt software-controlled radio to get better information densities. Look at satellite relays or any other data transfer in regimes where bandwidth is expensive to see what can actually be done.
Software-definable radio is still an interesting subject, of course.
I'd like a CD with both clients and a registration card asking me which one is my primary gaming platform.
Hear, hear.
This would guarantee that all versions were widely stocked, at no extra charge to the gaming stores, and the registration card (or an "OS ID" string transmitted by the binary) would tell the company how popular each OS choice was with their gamers.
The only problem being that, as per a previous post, the OpenGL (read: non-Windows) versions are still buggy. Oh well.
Slashdot Mirror
It's kind of eye-opening when you think about how games that seemed so great so long ago can now be fit on something so small as a card.
Remember the atari? You can fit the code and data from an atari cartridge on an 8.5x11 sheet of paper in human-readable form. With mnemonics, not hex.
Ditto the works of the 4k demo crowd from years ago. I really should look those up again.
why don't they just carefully excavate into it from the outside, instead of going to all the touble of sending these robots in etc...
Let me get this straight. You want to explore one of the wonders of the world, by cutting fucking great holes in it?!
Another approach that might work would be to take an industrial X-ray device and try to map out voids in the building by the equivalent of CAT. Such machines are already used to do non-destructive inspections of buildings looking for failure (though I doubt they try to send an x-ray beam through hundreds of metres of stone).
This would take a while, but would provide a reasonably complete low-resolution map of the pyramid's structure. Sink a few shafts to the side of the pyramid, and you can get the underground structure (if any) too.
Umh, ever thought that there might be some difference between hard solid material like stone, metals, and liquids like water... that just might make this approach unusable?
Actually, sonar works quite well through stone. The problem is that cracks and boundaries between different materials cause a lot of reflection and scattering.
It's _dirt_ that would be a nightmare to send sonar through, but even that would work at low frequencies.
If it was possible to use sonar like this, caverns of Bora Bora (in Afganistan, the supposed stronghold of mr. Laden et al) would have been piece of cake to take care of.
Again, this could easily have been done - it would just have taken more work than was practical.
This kind of technique is used all the time when prospecting for oil. You have a bomb in one place, and a bunch of seismic sensors in others. Set off the bomb, and look for reflections from the kinds of formations that trap oil.
Unless people start buying on the high end again, there may never be a desktop version of Hammer.
It's possible that AMD's falling victim to the Osborne Effect. I know _I'm_ waiting until I can get a Hammer system before upgrading.
News flash: if changing resolution improves performance, then your problem is that you're fillrate bound on the raphics card. Nothing to do with your CPU
That depends. Objects that take up fewer pixels (either far away or viewed up close at lower-res) are drawn with lower poly-count models. If you're CPU bound dealing with any of the geometry, this can cause the game to be slower at higher resolution (when more objects need the more detailed models).
Even when you're fill-rate limited, the fault can be with the game. The unpatched version of Tribes 2 ran like a slide show on my machine. As far as I could tell, this is because it wasn't doing nearly enough culling and hidden-surface removal before rendering the scene (this caused certain telltale visual artifacts). The patch boosted performance to a playable level.
wtf is linewidth?
The minimum gate width on a transistor in an integrated circuit chip.
This is what the "0.25/0.18/0.13 micron" stuff you've been hearing about is.
Smaller is faster and/or lower-power, depending on what you optimize for.
For microprocessors and motherboards, prices are tied to the linewidth cycle.
:).
A couple of months after a new linewidth becomes available, you get a few marginally higher-speed samples at a huge price.
Over the next six months, speed ramps up by a factor of 2 and prices drop on the older stuff. During this time any new chipsets introduced for the new hardware mature.
6 months after a linewidth switch, buy from the low end of the new speed grade range. You'll get a good price, and won't be obsolete for a year or more (as opposed to the usual 6 months).
There should be similar cycles for RAM (twice as fast, since they step lithography in cycles twice as fine), but in practice this isn't the case. Because margins are so thin, you get the occasional upset that drastically affects price (sometimes with help - the warehouse fire that quadrupled RAM prices a few years back only affected 3% of production capacity, according to rumour).
Processors are driven by linewidth, and motherboards are driven by processors, but most other things are market driven and so not as easy to predict. Other posters seem to have a better handle on this than I do
I'm concerned by this too. The central HyperTransport links in an 8-way system will be heavily contended for many workloads. (Not to mention the latency even in the absence of contention.) Something has to give.
If I understand correctly, the Sledgehammer has an extra HT link port, which will let them add extra processors as a mesh instead of a chain. The problem still occurs, but it's less crippling for large processor counts.
I'd have to doublecheck this feature, of course.
They may also be banking on fewer processors being used for most applications. I'm actually kind of impressed with their four-processor demo. It's large enough to be impressive, and for shared-bus schemes to bog down, but small enough that even with randomly-distributed data, really long hops will be uncommon. I don't see them competing in the Starfire/Sunfire's market any time soon, so larger systems might not be a problem.
It'll be fun to see what happens.
I don't know a helluva lot about rabbit anatomy, but I don't think the rabbit penis qualifies as the "next big thing" by any measure.
It's a mammal, with as complex a body and biology as our own.
Make something work (reliably) under these test conditions, and humans are not very far away.
So, for multiple processors working on a shared workload, you're screwed.
From the Hammer presentations I've seen, this is not true at all. The HT link between CPUs is 6.4GB/s, which is actually faster than the direct-attached memory (~5.3GB/s). Since the HT controllers are running at >2GHz, they introduce minimal latency.
I'll believe this when I see it, I'm afraid. You're trying to burst, at minimum, a 64-byte cache line over a HT link 32 bits wide, over a motherboard (the HT link can't do that bridge at 2 GHz, period). So you have at least 16 bus cycles for the data alone. The full overhead is request->proc2ctl->proc2mem/cache->long data burst. Even worse than that if you have to go through more than one processor (the Hammer boards we saw pictures of had processors daisy-chained. Ugh.). Latency from this will be very substantial. Migrating/copying pages is the only way to substantially reduce this in a NUMA system.
If I'm proven wrong when the system ships, I'll be the first to cheer, believe me.
For workloads that have shared data but that *aren't* saturating the memory bus, a shared-bus system would be faster. For workloads that do saturate the bus, NUMA is faster even with the delay, except under pathological conditions (i.e. all data in *one* processor's memory bank, with no migration).
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
I don't think this is true either. Contention for a cache line will simply bounce the line between caches, which is much faster on Hammer than on a 400MHz shared-bus SMP.
Depends on the coherence mechanism, and on how many steps through the daisy-chain you have to take for AMD's system.
In general, performance won't be much worse with NUMA (and could easily be better), but that doesn't change the fact that with contention it'll suck hard no matter what you do. HT bandwidth doesn't save you, which was the implication of the original post that I took issue with.
By moving the memory controller onto the processor and providing communication between processors over a hypertransport link (3.2GB/sec for bandwidth actually increases as more cpus are added! This is in contrast to a normal MP system where as more cpus are added, there is increased competition for a fixed resource (main memory) which is already the bottleneck in many single processor applications.
This is true only if the processors are running tasks with unrelated working sets (and if the data for each task is in that processor's memory).
If you have tasks that require memory managed by another processor, you have to go through the hypertransport link and the other processor's memory controller to get it. This will be _slow_. HT is decent, but nowhere near as good as a direct connection to memory, and there _will_ be delays due to arbitration on the second chip and the various buffering stages the data transfer has to go through.
So, for multiple processors working on a shared workload, you're screwed.
The only way to ameliorate this is to have very smart OS-level memory management that can duplicate shared-but-not-modified pages across multiple memory banks, and both OS and processor support for update-based coherence between the banks. The hardware support for this is a bit tricky, and the OS support will be a nightmare if the OS wasn't NUMA-friendly to begin with.
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
So, don't rejoice yet. We'll only know for sure how well this will work when we have Hammer systems on our desks.
Lot of posts are screaming "again, again"... but the fact is a 64 bit processor is one devil to design. The biggest problem with current processors is that to design such devices we *have* to use dynamic logic. Ask any VLSI design engineer.. that is no joke. Infact many multipliers and dividers have to be hand edited!
This is true for any processor, 64-bit, 32-bit, or otherwise. If you want the last 20%-30% of the performance, it will involve hand-optimization and an ungodly amount of work.
Designing a 64-bit chip vs. a 32-bit chip, OTOH, is mainly just replicating elements, though you do need design tweaking for a few pieces that don't scale well.
Re. dynamic logic, it really depends on the process you're using and what your design goals are. There are a lot of "gotchas" that you're undoubtedly already aware of that can degrade performance in a dynamic logic system, and other tradeoffs that are made when adding dynamic components to an otherwise-static system.
As with other design choices, there's no _requirement_ to do this. You just get a performance boost for certain specialized types of structure, which can justify the headaches if that kind of structure is on your critical path.
For a 64-bit processor that doesn't use dynamic logic (last I checked), just look at the MIPS line.
As for the 333mhz bus, I heard somewhere that the memory bus speed isn't the bottleneck for the Athlon processors...
Depends on what you're doing.
The P4, especially configured expensively, has a kickass memory subsystem on the motherboard (dual-channel anything will score high on bandwidth-bound tests). The fact that the Athlon doesn't has hurt its relative benchmark results even more than the speed war has.
I still love the Althlon, and I still avoid the P4 on (personal) principle, but a faster memory bus is a Good Thing for AMD.
The Hammer will live or die on this too. We don't have a real-world test of how well its memory subsystem works yet. The NUMA scheme for multiprocessor systems also gives me pause (without migration/copying of non-local pages, it'll bog down like crazy under certain conditions).
A well-performing Hammer will push AMD back into prominence. I strongly suspect that they're at least partly buying time to tune the core.
An interesting qestion is: is there such a thing as true randomness? How would you define it?
Read up on "entropy" for an introduction.
A sequence is random if, no matter what you do, you can't predict it with more than the randomly-expected accuracy.
Most people consider throwing a dice and reading the number on the top a random value. Is it? In theory, if you could measure the mass, stability, material etc. of the dice, the force which threw it, the properties of the table [...]
Some processes are truly random. Various quantum effects (as far as we can tell). Things like thermal noise in circuits (which is what most electronic random-noise generators amplify). You correctly point out that it's hard to cancel all non-random inputs to a system that measures a truly random variable, but you can get very close (and have a value that approaches truly random probabilities within known tolerances).
In practice, even (good) pseudo-random sequence generators are close enough for most practical purposes.
Lets face it: current computers and humans are both as bad as each other at randomness. The fact that computers have to "calculate" randomness is a bad sign in itself, and the humans that program these computers are almost utterly incapable of perceiving true randomness anyway.
Unless, of course, they're mathematicians, in which case they have a host of very powerful techniques for getting quite good evaluations of randomness, and a wide selection of sophisticated algorithms for producing really good pseudo-random sequences.
In summary, you are both overstating the problem and ignoring the vast body of experience built up for dealing with it.
You can also buy true random number generator cards off the shelf if you *really* can't live with a software solution. But be warned, these are suceptible to external influences (biasing them) and tend to be quite slow compared to PRNG techniques (even good PRNGs).
"Oh, yes! Writing code and squashing bugs. I usually get here at 7, 7:30 a.m., and I learned not to turn on the lights, because there are probably people who have been here all night coding, who are asleep on the couch or the floor."
Also much like grad school (weekends? What are those?)
U of T has had an open network for over a year now. It was done as such for the benefit of the students. I don't know what the details are for access control, but with hundreds or thousands of wireless users, I doubt they even care much.
Ok, then it isn't the nameless prof.
It just disturbs me that, in addition to having basically insecure workstations with their arses hanging out on the 'net with little or no filtering, that we are doing the equivalent of giving anyone who walks by an ethernet cable and saying "here! don't bother attacking us remotely, we'll give you a direct link!".
To their credit, the administrators do a fine job of keeping the system up and running. I just find security around here a little worrisome.
I notice one of the big red "abuse me" circles right in the middle of the U of Toronto engineering buildings, where they should know better.
I'd make snarky comments about the prof who I suspect might be running the open network, but in this case I have no strong reason to suspect it's him.
The truth of the matter is: there are only two introductory physics textbooks: Halliday & Resnick, and the Feynman lectures. The first is DULL, and the second is unusable. All others are ripoffs of H&R, not done as well.
I hear you re. the Feynman lectures. Weren't those originally grad lectures, or am I off-base?
My physics text is the Tipler book, which was both understandable and engaging (but then, I'm a wierdo who likes this kind of thing and breezed through the first year or two of calculus). YMMV.
Solar = destroy you planet faster... The process for making silicon solar cells is very very VERY nasty and pollutes worse than dumping raw gasoline directly into a lake
Not if you're using thin-film cells.
Also not if you're using concentrators and very small cells.
Especially not if you're doing both.
Also especially not if you're using a non-photovoltaic system, like concentrators and a heat engine.
Of the "alternative" energy production schemes proposed, I find solar farms to be the most plausible as a real solution. (Not the solution I'd choose, but at least a potentially practical alternative.)
That said, we could probably start stuffing multi-channel digital signals into the spaces between the existing analog channels, or do some frequency hopping spread spectrum into those gaps, and get some decent performance in existing bandwidth.
While in principle we could do that, in practice the problems are twofold.
Firstly, we'd need to be using extremely good equipment to get the required dropoff in intensity outside our desired bands. Software radio isn't a magic bullet, here. Nonlinearities in your output stages and jittering and drifting in your modulation clock are just a few of the many things that conspire to screw you up here.
And building a bandpass filter that sharp the old-fashioned way is just painful.
So, we wouldn't be able to do this easily or cheaply.
Secondly, getting permission to use an already-claimed section of bandwidth makes pulling teeth look easy, so I doubt such a system would ever realistically be implemented. If you're not worried about legality, just use a lower-quality software radio rig to transmit spread-spectrum signals below the noise floor and pray that nobody near you notices fading.
But, again, it's a nifty toy, and potentially quite useful as a simultaneous multi-channel _receiver_, which is what most of the first-glance stuff on the software radio page was about. Also useful as a tool if you're doing R&D with radio devices (and so have permission to clutter the spectrum in your area).
The best place to get a broad foundation is probably the place that's designed to teach it to you.
Visit your local university's bookstore, and pick up a first-year physics textbook, and probably a first-year calculus textbook too.
These will keep you busy for months or years. I know I'm still looking through my physics text every now and then for interesting tidbits.
As students enter university from a wide variety of backgrounds, the first-year texts start at an understandable level.
Practially, this means that you can transform your machine into a WiFi or Bluetooth system by simply installing the right software. It also means that as new future wireless technologies emerge, your hardware can support them by a simple software install.
And a hardware upgrade, since your WaveMangler 3700 card can only handle signals up to 3.7 GHz, but the new Sub Ether Space Net nodes talk at 5.2 GHz...
Still fun and useful, though.
To my understanding you can have a very high number of digital channels inside a single band which makes licensed analog frequencies just a waste of money to corporations if they use GNURadio as a means to transmit data long distances.
Not strictly true.
The amount of data that you can stuff into one frequency band within given power and noise specifications has a hard limit, no matter what the encoding scheme. Every once in a while someone claims that spread-spectrum or scrambled or UWB some other encoding scheme will surmount this, and every time someone else points out that this is not correct.
The encoding in conventional radio broadcasts is wasteful, but they don't need to adopt software-controlled radio to get better information densities. Look at satellite relays or any other data transfer in regimes where bandwidth is expensive to see what can actually be done.
Software-definable radio is still an interesting subject, of course.
I'd like a CD with both clients and a registration card asking me which one is my primary gaming platform.
Hear, hear.
This would guarantee that all versions were widely stocked, at no extra charge to the gaming stores, and the registration card (or an "OS ID" string transmitted by the binary) would tell the company how popular each OS choice was with their gamers.
The only problem being that, as per a previous post, the OpenGL (read: non-Windows) versions are still buggy. Oh well.