I see what you're saying. I guess I take the line that there's a difference between saying "hey, that's stupid" and "hey, that's stupid and we should ban it". People have the right to do stupid things. Which is just as well, given some of the things I've done over the years. I guess my comment is actually even a third kind - "hey, that's stupid, it's a byproduct of a highly toxic corporate culture, let's focus on beating up evil ideas rather than each other".
Startups are a dime a dozen, after allowing for inflation. Clearly creating one isn't outside the scope of human endeavour. Startups that are successful are generally copied and get turned into powerpoint presentations for sociologists. It should not be impossible to create a startup that is logically sound and non-toxic. If it were easy or obvious, it would probably already be done. Well, I guess bits and pieces have - HP's work on "Open Plan" seemed to be on the right lines, and Peoplesoft claimed to have overcome corporate cynicism for a while. I'm sure there are other examples out there, bits and pieces that actually worked, for whatever reason.
(It's important to use what works - the "dot bomb" era showed us what happens when you copy things that don't work but score highly on buzzword bingo.)
If the story is accurate, then these people have no medical backup (as they would in professional boxing) and, in fact, no idea of what medical consequences there might be. It's hard to tell, in the brain haemorrage case, what actually happened. We see a couple of lines that tell us exactly nothing. However, if people actually go to work on smashed ribs, they are likely to be going to work with far more serious (but less obvious) injuries.
(The brain has no nerve endings, so I suspect you can suffer a lot of injuries there without being able to personally tell much. Actually, that WOULD explain why Silicon Valley has been turning out such crap recently - they're all brain-dead.)
Yes, frustrations are understandable and evidence of a sick, unhealthy work environment. A healthy work environment should have ways of avoiding stress building up (such as by ensuring employees aren't treated as raw meat - frozen until fried). That should be when tech employees (who are supposedly intelligent - WAY above average intelligence) figure out better ways to do things - and do them. Y'know, given the choice of kicking someone half to death in a bout of frustration, or setting up a startup that has none of the stress issues, gets twice as much done, and has devoted employees because their brains are intact... I know which I'd call the smarter.
These fight clubs are stupid and ultimately have to destroy their participants. The body can only absorb so much - it doesn't repair indefinitely and you don't get to regenerate. However, the corporate attitude that creates them is not merely stupid, inferior and inefficient, but as close to evil as a secular environment can get.
This is the kind of attitude that was featured in the ORIGINAL "Rollerball" - the craving for more and more violent outlets, because of pressure. Hell, this is the kind of attitude which created historic figures like Nero and Calligula. Never mind the pop psychology, we have real-world examples of what happens to a society when senseless self-destruction becomes the only meaningful outlet.
...that FFTW is the most widely used FFT package out there. I do seem to recall an @Home project (Messiene Primes? Can't remember) that uses their own FFT code, because of problems with FFTW on specific applications.
You are correct that FFTW has undergone some massive reworking and is currently at 3.1.1 (although Fedora Core 5 is only on 3.1). What would be wonderful would be for FFTW to add in hooks for PAPI (a powerful profilling library) to establish how fast the code actually is and where improvements could be made. It would both help the developers figure out what needs to be accelerated, and help convince those of us who have become skeptical of performance claims that there is something to cheer about.
(I hate being cynical; it's not in my nature. It is, however, the natural byproduct of seeing too many bogus performance claims and outright fraudulant benchmarks. I don't much care WHO produces genuinely useful data or WHO has the ultimate in FFT technology; what I do care about is having a way to know WHICH data and WHICH technology is top of the heap. Hell, if independent reviewers actually got paid, I'd add the damn hooks myself, run the tests and publish the results on an advert-free site.)
...but FFTW may well be the fastest "all-round generic" FFT program (I don't know if that's true or not, though), but there are FFT packages which are faster - DJBFFT is one such program. Of course, there will undoubtably be even faster methods, as I'm certain there will be generalizations in places that could be divided into faster, more specific algorithms, and I don't believe DJBFFT has any hand-optimizations for processors past the Pentium Pro, suggesting it won't take advantage of any capabilities of multi-core CPUs, 64-bit CPUs or additional instructions.
(Professor Bernstein, in an e-mail reply to a question, did mention he was going to update DJBFFT, but this does not appear to have happened. In all probability he lacks the time, but that doesn't solve the problem of needing high-power FFT software. FFTW, although slightly better on updates, isn't massively better. What is needed is for someone to start a project with the goal of writing code as fast as DJBFFT, as generic as FFTW, and as active as LinuxBIOS or the Linux Kernel in terms of getting new code out there.)
Experience is 90% of the profession. Theory is 50%. (Yeah, yeah, I know, but I was using a Pentium.)
Seriously, yes, try things out. Write your own mini programs, get involved in projects, try experiments to see what happens. Not everything has to be long and complicated, either - start by writing a Java applet that produces animation by colour cycling, for example, or a simulator for a very primitive, fictional microprocessor. In fact, pick anything that isn't too trivial, but would actually be interesting for you, and write it.
For networking, practice with Zebra or Quagga to get a feel for the concepts in network routing, then use something like NS to simulate a network with routers (you can even plug Quagga or Xorp in, I believe) and see what happens when you try things out. You don't need a couple of physical Cisco routers and a dozen boxes to do this, you only have to run a program which shows you what would happen if you did.
If you want to play with a nameserver, that's even easier. Start by doing a zone transfer. There are some public zones out there, and they will give you a feel for how zones are laid out. Now create a zone of your own. Add a hook in the master file to point to the DNS server you usually use, modify your resolver to use your local DNS server and modify your DHCP client settings to NOT pull the DNS information. Reboot your machine. If you can still resolve IP addresses, you are the proud owner of a fully-functional DNS system.
When doing any of these, remember that what you are learning is the syntax and the semantics. There may be better ways of laying things out, or logically composing things - that's always going to be true, though, so don't worry about it. Courses are great for learning theory, and theory will tell you about the composition part.
You MAY hear lecturers talking of people learning "bad habits" when they are self-taught. That can happen, but the only time it is really true is when the person has forgotten how to learn. Forgetting how to learn is the ultimate in bad habits in IT, because things change so quickly. What was true may be false or purple a week later. You just don't know. For that reason, being open to change and understanding that change is a very important part of the field.
The only absolutes in IT are:
No computer derived from the Turing Machine can solve a non-computable problem, no matter how much time it has or how much memory it has.
Every computer derived from the Turing Machine can solve every computable problem in some finite amount of time, provided it has sufficient memory.
Hard drives are magically aware of when they are filled with un-backed-up data, and will choose this moment to crash.
I thought the sheep in New Zealand were the pirates. Oh, no, that's the Kea. Notorious theives, Kea - they'll steal anything they can reach. I've heard that one group of Kea have now set up a car dealership, using bits they've stolen off tourist's vehicles. Wouldn't surprise me at all if they've learned how to surf the Internet and pirate software.
Forcing content providers to provide, well, content is hardly a bad thing.:) If a provider creates an obligation for itself, which is witnessed, then it is a gentleman's agreement which (in the UK, at least) is as enforcable as any written contract.
But, yes, my system does force providers to constantly upgrade their technologies. All of their technologies. The pressure would be on them, and they would have to grow or die.
For the authentication, I'm thinking much the same system as for SSL. Each device would have an X.509 (or something similar) which is signed by a trusted third party. Authentication, then, is simply a matter of getting the certificate, checking that it is signed by a known certificate vendor, and checking that the signature has not been altered. It would then be up to the DRM code on the sender device to determine if the recipient is authorized. Some devices may track how many copies they've made and stop when they hit the upper limit indicated by the metadata. There's all sorts of ways it can be done.
(If the certificate contains the DRM scheme + version in use, then all devices can trade known lists of broken DRM schemes. Sure, some copying onto broken systems will happen, this kind of propogation is sloooow. On the other hand, it places the least constraint on users, and I consider that a far greater benefit than speeding up the random walk of the DRM lists, as those are inevitably going to be out of date all of the time anyway, so speeding things up won't buy you anything.)
I can almost forgive them a whole bunch of their sins for this. If they pressure the EU on limiting DRM or getting products to interoperate, that will help, too.
I'm picturing that each DRM player would carry an X.509 certificate that has been produced by a "well known" party - in much the same way they do for use on secure websites. Authentication would then simply be a matter of each machine verifying that the certificate has been correctly signed. The certificates are then used to form your secure transport between the two DRM devices. Outside authentication or external tools would be unnecessary and cumbersome.
You are correct that my idea is that every system should interoperate cleanly, and you are correct that this means that you can eliminmate the DRM. I still feel it's an improvement over what we currently have, so if DRM is going to be a fact of life, we might as well have a system that's actually useful to users. Congrats on coming up with a neat way of breaking my system, btw.
No, my system wouldn't work if you went through an intermediate phase, as it relies on each device operating entirely on a native DRM scheme which may or may not differ from any other DRM scheme. Going through a clearing house would merely mean it gets re-DRMed twice for every transfer, at the risk of losing meta-data in that extra stage.
There is a way to do this, but it's an arms-race of a sort. The corporations producing the technology would need to develop better players and better media that was still backwards-compatiable. The older players would be able to get some of the data, but there'd be loss because of inferior formats, inferior compression and/or less space available.
This means that those wanting the "full" effect would need the latest players (and therefore the latest DRM). Copies made onto older players with broken DRM schemes would be inferior copies and therefore less attractive. This doesn't solve the broken DRM hole - it still exists - and the market won't bear a new digital format every month, but it would make bulk-copying for reasons of piracy a much more expensive deal even if the updates were once a year or every other year.
In the end, all DRM schemes can be broken. My scheme is merely a transfer protocol between two DRM schemes, so can actually be very strong, but the DRM itself is the weakest spot. For that reason, the pressure should be directed back on industry to evolve past the threat, rather than the existing approach which is to devolve the users into cabbages. They'll get along much faster if the corporations cooperate - with themselves and the technologically aware outside - so the obvious first step is to promote, or enforce, whatever cooperation the corporations can stomach without imploding.
(Well, you can afford to have a few implode. It might give the rest an incentive to do their work, rather than to pressure lawmakers to obligate the users to do it for them.)
Hey, it happens to the best of us. And to me as well. Hmmmm, that's a tough one. I dislike intensely solutions that cripple (or outlaw) technologies. It is better to make advances somewhere else. Of course, you do need to add a dash of common sense. Hydrogen bombs at Walmart would not be a good idea - at least, not until technology is a LOT more advanced and humans have socially matured somewhat.
Ok, where does the optical digital output fit into this? Well, IMHO it is a reasonable technology, therefore should absolutely NOT be banned or crippled through DRM, other technology or by law. In fact, I'm picturing a variant of exactly that to hook DRM-enabled devices together for authorized copying.
Does it defeat my meta-DRM scheme? The metadata would be lost, so any recording from the optical digital output would lack that information. It does break my scheme, yes, if you made your recording via a non-DRM device. In such a case, you've eliminated all protections at zero loss of useful information.
When copying onto a DRM device following my suggestions, the story is a little different. My scheme substitutes maximum restrictions, for each control table entry for which metadata isn't available, so recording onto such a DRM device would impose stricter limitations than the original digital copy. That would be fine for personal use (you just want A of the original - for the car, or whatever) but would be limiting for a pirate bent on mass production.
It would ease a LOT of restrictions and limitations on purely personal use. Yes, it's broken in that an exploit does provably exist, and all you need is one exploit. It would place limits on what pirates could use for mass production, which is supposedly what DRM is for in the first place, so it's not completely a failure. And it would be more effective at doing so than the crap we have at present, so it would be something of an improvement.
After that, I would say that it was up to industry to evolve faster than the pirates (which really don't exist as more than a tiny blip in things anyway). Since that means producing the best recorders and players (not the most inhibiting), the consumer benefits. In fact, the more consumers spend, the more they'll benefit. (Which is the exact opposite of current DRM approaches, where the more customers finance the R&D, the less they get, which is one reason why pirates exist at all.)
Analogue systems are far too important, far too valuable, to simply be banned. Furthermore, to outlaw a species of technology for the sole purpose of promoting another species of technology is absurd (and speciesist). Analogue technology is also very important, as it is proving to be far more durable and far more portable than digital systems. You absolutely want to be able to copy stuff into analogue formats.
How would my proposal work with this, though? You are correct that DRM schemes don't cross over into the analogue world. (Well, that's not 100% true, as there have been copy-protection schemes for tapes.)
The answer is that there would need to be an intermediate device that was authorized to receive the digital stream, and which could then transfer JUST the data (in converted form) to tape. The copy on tape would be unprotected, but it would be authorized to be unprotected.
Would manufactuers go for that? That would be a tough sell, but might be possible. They'd need to add to the DRM systems some means of restricting the number of copies, or something similar to that.
Also, isn't a "smart DAC" of this kind defeating DRM in the first place? No, because it's not about preventing someone making copies, it is about controlling and managing the process, and ensuring that the maximum rights are preserved in a copy. Where the copy can't preserve rights, then the manufacturer - not the user - needs to be SOL. The user should not be limited by the capability or imagination of a manufacturer.
In my descriptions, I pointed out that not all DRM information could be copied on all systems, and that such information will simply need to be dropped. The analogue tapes are merely the logical extreme of this. Furthermore, my descriptions are merely intended as proof that DRM, interoperability, competition and affordability are not mutually exclusive, but if done right can even complement each other very nicely. I don't agree with DRM in the first place, but if we're going to suffer with it, then damnit, I want to suffer from the very best.
Digital rights exerts a pressure. This can be a pressure on the user to conform to a certain behaviour, or it can be a pressure on corporations to evolve better solutions. Both will create positive feedback loops. If you try to constrain the user more and more, the userbase will stagnate and die. If you try to force progress, then users will increase their expectations as fast as companies can progress to meet them, with the slower companies simply being run over.
In the end, nothing is going to progress faster than it has to. Where there isn't a perceived need, an "itch" that has to be scratched or a market that could be better utilized, there will be no progress. DRM provides a need. The first impulse of the corporations is to kill that need, because progress is expensive, but banning things is cheap (for them). Interoperability provides another need, and again the first impulse is to kill it. Monopolies make for a lot of power and glory, whereas both competition and cooperation are expensive and draining of energy.
The laws on DRM and interoperability of media systems should (in my not-so humble opinion) be used to foist cooperative evolution in technology through both pressures. I want to hear screams and howls of pain and anguish from the USPO - not because software engineers broke in and took revenge, but because the volume of genuine, bleeding-edge, novel work they're having to go through has to be airlifted in by transport planes.
Ok, the method works on the basis that the sender can convert the DRM formatted data into an un-DRMed version that is encrypted such that only the authorized recipient can decrypt it. The metadata used to describe what the DRM is actually protecting, how, and in what way, is also copied across in this way.
It is perfectly true that the recipient need not re-constitute the DRM scheme (using its own methods), so that would need to be protected by law. I don't see that being a significant problem, though. The French proposal would be entirely compatible with a law requiring that the receiving system rebuild DRM.
(In fact, the DMCA - evil though it is - would not conflict with my proposal, as it doesn't require anybody to reverse-engineer anything or know anything about the internals of anyone's protection system.)
Transfer of data via a secure but vendor-neutral channel is not a new idea - it is very unlikely every banking computer in the world runs exactly the same software! - however, I would venture to suggest that it's not a method developers of DRM for music or movies have considered at this time. If they had, I doubt there would have been nearly the fuss about the French proposal. For that matter, CSS might still be unbroken, as it was only because there was a monoculture that the breaking of one key meant the breaking of the whole system.
(Monocultures are vulnerable, precisely because an attack against one element will work equally against all elements. Biologists regard them as BAD, and I see no reason to differ when it comes to secure systems.)
I therefore contend that by creating monocultures - whether within a single platform or across all platforms - actually harms the corporations involved and invalidates their security measures. If they want true security, they NEED diversity and a secure DRM exchange protocol. Therefore, interoperability will be a Good Thing for companies, as it will strengthen DRM and reduce piracy, without impacting any consumer's ability to use whatever OS they choose.
No, not really. Let's take the encryption component, for example. For that, you have two choices: you can filter your encrypted content into a universally sharable format that is encrypted using a public key encryption algorithm (such as RSA). You can then exchange keys using one of the standard key exchange algorithms. The recipient can then decrypt the content and re-encrypt it in its native format.
The second option is for the intended recipient to transmit a public key (well, not really public since only the content holder will receive it). The content holder then decrypts the content and uses the public key obtained to build an SSL tunnel to the recipient, which can then re-encrypt it natively.
Ok, that handles that part. Now we need the data format. This will contain one or more of DRM headers, DRM data, and content. Since the data is encrypted in transit, using keys only the two parties know, we don't need DRM protections, only the DRM information. By ripping out the DRM, then converting that information into XML or some other "universal" format, we can preserve the DRM information without needing the DRM to be active.
At the destination, the DRM meta-data is then parsed. Those elements for which no local definition exists would be dropped, and those elements not filled by the meta-data would be set to the most constrained values allowed. The protections may change, with such a system, but they should average out.
We now have a universal DRM exchange protocol that needs to know NOTHING about any foreign DRM mechanisms and therefore does NOT need to be patched as new formats come out, and does NOT need to be bloated with a multitude of foreign algorithms. All it needs is an industry-standard XML template, an implementation of RSA, an industry-standard public key exchange mechanism and optionally an implementation of SSL.
Total hardware complexity? One standard encryption chip and one moderate-sized FPGA should be sufficient. Two scraps of silicon, adding maybe a couple of grammes to the total weight. I can really see this killing the entire music industry... assuming the entire music industry is in fact a small piece of blue-green algae and the chips are dropped on it from an altitude of 30,000 feet.
Far as I know, this only affects the basic JPEG. JPEG2000 is still encumbered, as I believe that's a different set of patents. However, that's largely moot - PNG is lossless and often compresses better than JPEG, but JPEG is still the format of choice for, say, digital camera makers and websites. If freedom was sufficient, in itself, the format would have been dead and buried within 60 seconds of the patents being filed. It's not "necessary", there were superior, unencumbered alternatives that most OS' can display well or, at least, equally well to JPEGs.
No, the core problem wasn't with the patents, although those were bad enough. The core problems are ignorance (most people don't know what options exist), inertia (those who do often won't take advantage of them because it requires change) and stagnation (sufficient inertia kills all incentive to further develop alternatives). I would not be against compulsary education on how to be versatile, for this reason.
It is hard to blame Fogent alone, when the entire national attitude is based so firmly on milking every old idea for what it's worth, whilst the populace make no effort to avoid being bilked. As with those in Dilbert who have met the "world's most desperate Venture Capitalist", it becomes hard not to just take the money and run.
This isn't to say such conduct is good or acceptable - it isn't, in my opinion. Rather, it is to say that we should be addressing the whole problem, not merely a selection of the symptoms.
I agree 98% with what you say, but can't think of a "World Class" University in or around "Silicon Glen" in Scotland, or in Wales (former home of Inmos and the Transputer - a stunning piece of R&D for the time), and cannot think of any "Silicon Valley"-like environment in Manchester, that has not only a long-standing tradition of experimentation and research, but five World Class Universities.
I'd also expect something in the Oxbridge (Oxford and Cambridge Universities) region, but maybe they spend all their creative energy on boat races. Hey, very few could hope to question the sheer mass of brainpower there, or their thousand-year tradition of eccentricity and experimentation, or the sheer volume of bleeding-edge science, so you've got to explain the total lack of bleeding-edge industry there somehow.
If your grandmother is the founder and president of the local Linux User Group, the biker chick for the local chapter of Hell's Angels, or (worst of all) beating you in WoW, which she connects to from her OpenBSD system, then you probably would invite her.
No, a given user's ISP will be charged more for their fat pipe to the Internet and therefore will charge their customers more for access. If the price remained the same, the outer ISPs would all lose money on the deal.
Because routing is dynamic, the problem is actually worse than that, particularly if peering essentially collapses and different backbone providers charge each other for preferred bandwidth and/or preferred routing. Those prices will bubble up through the system, hitting the end-point ISPs, followed by not only the content provider but the consumer as well.
This could easily end up with the consumer paying four or five times the average price hike, because ultimately nobody else will be willing to pick up the tab.
Also bear in mind that since bandwidth is constant, "preferred customers" really means selling those customers OTHER customers' bandwidth without their permission or knowledge. This will NOT be used to increase the bandwidth available, or even use it more efficiently. So if a customer is preferred enough, that customer's competitors' bandwidth can be reduced to effectively zero.
(Using the Evil Highway Analogy, it's one thing for a truck to have a "wide load" sign and step a little into the neighboring lanes, but entirely another for trucks to mount plasma cannons for the express purpose of vaporizing anything within a hundred foot radius.)
Ok, you won't have much in the way of collecting power (too few dishes) but the resolving power would be amazing. Now, you don't need much in the way of collecting power to see "bright" radio sources - electrically active planets, for example, nearby stars, or globular clusters.
Your resolving power, however, should be pretty damn amazing at 20 miles diameter. Ok, so what's wanted here is something nice and noisy, where your ability to isolate a region of sky and/or track an object would be of value.
You could probably track the storms on Jupiter - you can detect those with even a trivial dipole and a receiver in the right range, so you've certainly got more collecting power than necessary. Not sure how accurate your measurements would be, but that would make a fascinating experiment.
GnuRadio will turn your computer into a suitable receiver (provided you either have a soundcard that works at the right frequency, OR you have a suitable analog-to-digital converter plugged in somewhere). You then need to process the streams into something interesting. I believe AIPS is what you'll want for this. It is "professional" Open Source software for interferometry (read: the interface is crappy, but the logic is superb).
The nearer satellites - such as those orbiting Mars - should be well within your ability to receive and track. I doubt there will be any encryption on the data being sent to Earth, so you might be able to get real-time(!) images from the probes. The only question there is whether the signal would be strong enough to correctly interpret. The same would be true of anything sent by the Cassini probe, although it is much further away and therefore would be far fainter, so you might be restricted to just knowing where it was. Which would be pretty damn good, even so.
I would certainly encourage you to give it a try and see what you can do, and also to diary what works. You may well be able to do far better than I expect - it depends on how big the dishes are and how well you are able to sort signal from noise.
You get your Real Ultimate Power badge if you can intercept a message from either Voyager probe, and an honorary lifetime membership of the Q Continuum if you can get any kind of signal at all from one of the Pioneer probes.
(Note to the humour-deprived: If NASA can barely achieve the former, and can't achieve the latter at all, on the Deep Space Network, there is no friggin' way an amateur is going to on three dishes... unless they ARE in the Q Continuum, in which case the prize is easy.)
Re:Seems primitive. (Resolution v. Lightgathering)
on
Looking for Life in Light
·
· Score: 3, Informative
Yes, I'm certain.... but it is why you need the density of dishes. If you had one dish on each corner of a square, one kilometer on a side, then you would have the collecting area of those four dishes. Which, if they are TV dishes, is very little. If, however, you have that same square but one dish every five meters, you would have 200 x 200 dishes, for a total of 40,000. If each dish has a collecting area of one square meter, you then have a total collecting area of 40,000 square meters.
In practice, the Square Kilometer Array is intended to have a collecting area close to the physical area of one million square meters - requiring almost no gaps to exist between dishes.
My first calculation would be for dishes with a wider gap, which would give you much greater flexibility on pointing the damn thing, as you can't see through the other dishes. Personally, I consider this to be a much superior design, even though it would cost on the collecting area. Unfortunately, they are the ones being paid, even if I am the one who is right...
By way of comparison, Jodrell Bank Radio Telescope is a paltry 76 meters across, for a total collecting area of 4560 square meters, and that's one of the largest single steerable telescopes out there.
I'm going to guess that a collecting area about nine times that of Jodrell Bank, combined with a resolving ability that is, well, astronomical, you would get a very respectable image of Earth-like planets around other stars. If we accept the SKA group's claims, then you've a collecting area 250 times that of Jodrell Bank.
I first heard the 100LY=1 pixel resolution with SKA from Jill Tarter, head of the SETI Institute at a talk she gave at NASA Langley. From crunching the numbers, I can see nothing that could seriously contradict the claim. Even if you assume my model is the more reasonable implementation, the complete MERLIN network that has been detecting jovian planets for some time has only a fraction of that collecting area - probably something like a quarter or a fifth. (Aside from Jodrell Bank, the next-largest radio telescope in the UK is a paltry 32 meters across.)
If we go with SKA's claims, then we're talking about collecting possibly hundreds of times the total radiation, which would definitely be enough to spot even the tiniest of worlds - provided it had some characteristic reflected in the radio spectrum.
(It's also worth bearing in mind that networks such as MERLIN, which are hundreds of kilometers across, are set up for VLBI - very long baseline interferometry. That's fine, when you're talking about gas clouds or stars, but is probably none-too-hot for spotting very fast pulsars or rocky inner planets. On the other hand, a kilometer would let you use regular interferometry, which means these things would show up quite nicely.)
There are three drawbacks to all of this, and I'm surprised none of the posters has commented on them (so far). First, interferometry requires very exact timing of all the delays in the system, or it won't work. Let's go with the SKA estimate and say the dishes are 1 meter apart. Your clock must count an integral number of ticks for every meter the signal travels from the dishes, even after allowing for the natural variation in the data lines varying the speed of the signal. This is some astonishingly serious timekeeping.
The second problem is to keep the signal noise-free. Easy, for a giant single steerable dish - you plunk it in the middle of nowhere and surround it with a huge Faraday cage that only obscures the horizon. When you've a few tens of thousands - or millions - of very small dishes, the problem isn't so easy. The terrestrial radio sources will be far harder to screen out - not just
If I compile the Java code with GCJ, then I shouldn't need a JVM. If someone would get around to building a processor-in-memory hardware Java implementation, you'd have a Java Physical Machine and again would not require a virtual machine. "Need", then, is a little strong. It would be more correct to say that - as of right now - most Java applications will indeed be run in a virtual machine, and require the components within that machine, but they are only run virtually because that is how it is traditionally done.
If/when the kilometer array is built (it's an array of small radio telescopes, where the array has a diameter of a kilometer and a density of one dish every couple off metters or so), they will be able to resolve Earth-sized planets at a distance of 100 light years.
How will this help? Radio telescopes can look at the absorbtion spectrum of the planet for the tell-tale lines of water, methane, oxygen (both O2 and O3), and other markers of highly reactive chemicals - especially when they will react with each other. When you have an atmosphere that is chemically violently unstable (as is the case on Earth), it must be being maintained by some process.
That's the first clue, but only the first. The second clue is that "dead" planets will be in equilibrium with their surroundings, but "living" planets will always be in opposition. (Organisms will always create a dynamic equilibrium that suits them, so must always counter any and all natural phenomena that would push the system away from that preferred state. Simple negative feedback.)
Simple radio telescopes can do all this now, no new optical technology need be developed, and no assumptions about the type of life need be made. (All the above assumes is that life can never be inert and that any specific organism cannot function equally under all potential conditions. That's broad enough, although there will probably be exceptions even then.)
The Km array proposed (and the hectare array already built) are just a huge stack of ordinary satellite TV dishes. This could be done by anyone at any time. A mile array would give you 2.5x2.5 pixels ast 100 lightyears - enough to discern if weather patterns exist, though not enough for any long-range forecasts.
Some of the recently-discovered trans-Neptunian planets/planetoids cross the heliopause and actually reside outside of it for most of their respective orbits. (When they are outside, they are outside the "solar system" proper, so are they part of our system or "extrasolar"?)
This means that the center of mass (both instantaneous and over time) for the solar system is off-center, and that the Kuipier Belt may be non-uniform (which may therefore provide more screening from the galactic winds on that side).
Now, because the sun is not stationary with respect to the galaxy, the galactic winds will not be uniform in the direction of motion. Because the galaxy is not of uniform composition, the galactic winds will also be predominantly from the galactic core. (The galaxy will have a galactic equiv. of the heliopause, in which the pressure from the galaxy will match the pressure from remote galaxies.)
However, it's never quite that simple. There are structures in the galaxy that are significantly off the galactic plane, and these too will be exerting some pressure from their own particle streams.
All in all, the idea that the heliopause isn't a perfect circle isn't that mysterious. What IS mysterious is why anyone thought it would be, and what is intriguing is what shape it actually has, given the sheer number of factors that could influence it.
...I was trying to isolate specific characteristics, in the hope that it might then be possible to draw a clear boundary. (When you have a single point - "causes significant harm to a third party" - it's unclear how to define what is significant or sufficient. It's easy to define that the absolute center-point must be a case of where free speech should be capped. It is also easy to prove that if all factors carried equal weight, the boundary must describe a sphere over as many dimensions as there are factors to consider. It is also easy to prove that different factors can have different weight, producing a different geometry. Assuming a principle exists (or could exist) to determine the relative weights of the factors, and assuming you can prove the value of some point on some boundary for some geometry, you can then prove the value of all points for all geometries.
(Intuitively, this is something you should be able to prove by a combination of induction and geometry.)
Slashdot Mirror
If they're being kept in the dark, then they're feeding off 24-hour news.
Startups are a dime a dozen, after allowing for inflation. Clearly creating one isn't outside the scope of human endeavour. Startups that are successful are generally copied and get turned into powerpoint presentations for sociologists. It should not be impossible to create a startup that is logically sound and non-toxic. If it were easy or obvious, it would probably already be done. Well, I guess bits and pieces have - HP's work on "Open Plan" seemed to be on the right lines, and Peoplesoft claimed to have overcome corporate cynicism for a while. I'm sure there are other examples out there, bits and pieces that actually worked, for whatever reason.
(It's important to use what works - the "dot bomb" era showed us what happens when you copy things that don't work but score highly on buzzword bingo.)
(The brain has no nerve endings, so I suspect you can suffer a lot of injuries there without being able to personally tell much. Actually, that WOULD explain why Silicon Valley has been turning out such crap recently - they're all brain-dead.)
Yes, frustrations are understandable and evidence of a sick, unhealthy work environment. A healthy work environment should have ways of avoiding stress building up (such as by ensuring employees aren't treated as raw meat - frozen until fried). That should be when tech employees (who are supposedly intelligent - WAY above average intelligence) figure out better ways to do things - and do them. Y'know, given the choice of kicking someone half to death in a bout of frustration, or setting up a startup that has none of the stress issues, gets twice as much done, and has devoted employees because their brains are intact... I know which I'd call the smarter.
These fight clubs are stupid and ultimately have to destroy their participants. The body can only absorb so much - it doesn't repair indefinitely and you don't get to regenerate. However, the corporate attitude that creates them is not merely stupid, inferior and inefficient, but as close to evil as a secular environment can get.
This is the kind of attitude that was featured in the ORIGINAL "Rollerball" - the craving for more and more violent outlets, because of pressure. Hell, this is the kind of attitude which created historic figures like Nero and Calligula. Never mind the pop psychology, we have real-world examples of what happens to a society when senseless self-destruction becomes the only meaningful outlet.
You are correct that FFTW has undergone some massive reworking and is currently at 3.1.1 (although Fedora Core 5 is only on 3.1). What would be wonderful would be for FFTW to add in hooks for PAPI (a powerful profilling library) to establish how fast the code actually is and where improvements could be made. It would both help the developers figure out what needs to be accelerated, and help convince those of us who have become skeptical of performance claims that there is something to cheer about.
(I hate being cynical; it's not in my nature. It is, however, the natural byproduct of seeing too many bogus performance claims and outright fraudulant benchmarks. I don't much care WHO produces genuinely useful data or WHO has the ultimate in FFT technology; what I do care about is having a way to know WHICH data and WHICH technology is top of the heap. Hell, if independent reviewers actually got paid, I'd add the damn hooks myself, run the tests and publish the results on an advert-free site.)
(Professor Bernstein, in an e-mail reply to a question, did mention he was going to update DJBFFT, but this does not appear to have happened. In all probability he lacks the time, but that doesn't solve the problem of needing high-power FFT software. FFTW, although slightly better on updates, isn't massively better. What is needed is for someone to start a project with the goal of writing code as fast as DJBFFT, as generic as FFTW, and as active as LinuxBIOS or the Linux Kernel in terms of getting new code out there.)
Seriously, yes, try things out. Write your own mini programs, get involved in projects, try experiments to see what happens. Not everything has to be long and complicated, either - start by writing a Java applet that produces animation by colour cycling, for example, or a simulator for a very primitive, fictional microprocessor. In fact, pick anything that isn't too trivial, but would actually be interesting for you, and write it.
For networking, practice with Zebra or Quagga to get a feel for the concepts in network routing, then use something like NS to simulate a network with routers (you can even plug Quagga or Xorp in, I believe) and see what happens when you try things out. You don't need a couple of physical Cisco routers and a dozen boxes to do this, you only have to run a program which shows you what would happen if you did.
If you want to play with a nameserver, that's even easier. Start by doing a zone transfer. There are some public zones out there, and they will give you a feel for how zones are laid out. Now create a zone of your own. Add a hook in the master file to point to the DNS server you usually use, modify your resolver to use your local DNS server and modify your DHCP client settings to NOT pull the DNS information. Reboot your machine. If you can still resolve IP addresses, you are the proud owner of a fully-functional DNS system.
When doing any of these, remember that what you are learning is the syntax and the semantics. There may be better ways of laying things out, or logically composing things - that's always going to be true, though, so don't worry about it. Courses are great for learning theory, and theory will tell you about the composition part.
You MAY hear lecturers talking of people learning "bad habits" when they are self-taught. That can happen, but the only time it is really true is when the person has forgotten how to learn. Forgetting how to learn is the ultimate in bad habits in IT, because things change so quickly. What was true may be false or purple a week later. You just don't know. For that reason, being open to change and understanding that change is a very important part of the field.
The only absolutes in IT are:
I thought the sheep in New Zealand were the pirates. Oh, no, that's the Kea. Notorious theives, Kea - they'll steal anything they can reach. I've heard that one group of Kea have now set up a car dealership, using bits they've stolen off tourist's vehicles. Wouldn't surprise me at all if they've learned how to surf the Internet and pirate software.
But, yes, my system does force providers to constantly upgrade their technologies. All of their technologies. The pressure would be on them, and they would have to grow or die.
For the authentication, I'm thinking much the same system as for SSL. Each device would have an X.509 (or something similar) which is signed by a trusted third party. Authentication, then, is simply a matter of getting the certificate, checking that it is signed by a known certificate vendor, and checking that the signature has not been altered. It would then be up to the DRM code on the sender device to determine if the recipient is authorized. Some devices may track how many copies they've made and stop when they hit the upper limit indicated by the metadata. There's all sorts of ways it can be done.
(If the certificate contains the DRM scheme + version in use, then all devices can trade known lists of broken DRM schemes. Sure, some copying onto broken systems will happen, this kind of propogation is sloooow. On the other hand, it places the least constraint on users, and I consider that a far greater benefit than speeding up the random walk of the DRM lists, as those are inevitably going to be out of date all of the time anyway, so speeding things up won't buy you anything.)
I can almost forgive them a whole bunch of their sins for this. If they pressure the EU on limiting DRM or getting products to interoperate, that will help, too.
You are correct that my idea is that every system should interoperate cleanly, and you are correct that this means that you can eliminmate the DRM. I still feel it's an improvement over what we currently have, so if DRM is going to be a fact of life, we might as well have a system that's actually useful to users. Congrats on coming up with a neat way of breaking my system, btw.
No, my system wouldn't work if you went through an intermediate phase, as it relies on each device operating entirely on a native DRM scheme which may or may not differ from any other DRM scheme. Going through a clearing house would merely mean it gets re-DRMed twice for every transfer, at the risk of losing meta-data in that extra stage.
There is a way to do this, but it's an arms-race of a sort. The corporations producing the technology would need to develop better players and better media that was still backwards-compatiable. The older players would be able to get some of the data, but there'd be loss because of inferior formats, inferior compression and/or less space available.
This means that those wanting the "full" effect would need the latest players (and therefore the latest DRM). Copies made onto older players with broken DRM schemes would be inferior copies and therefore less attractive. This doesn't solve the broken DRM hole - it still exists - and the market won't bear a new digital format every month, but it would make bulk-copying for reasons of piracy a much more expensive deal even if the updates were once a year or every other year.
In the end, all DRM schemes can be broken. My scheme is merely a transfer protocol between two DRM schemes, so can actually be very strong, but the DRM itself is the weakest spot. For that reason, the pressure should be directed back on industry to evolve past the threat, rather than the existing approach which is to devolve the users into cabbages. They'll get along much faster if the corporations cooperate - with themselves and the technologically aware outside - so the obvious first step is to promote, or enforce, whatever cooperation the corporations can stomach without imploding.
(Well, you can afford to have a few implode. It might give the rest an incentive to do their work, rather than to pressure lawmakers to obligate the users to do it for them.)
Ok, where does the optical digital output fit into this? Well, IMHO it is a reasonable technology, therefore should absolutely NOT be banned or crippled through DRM, other technology or by law. In fact, I'm picturing a variant of exactly that to hook DRM-enabled devices together for authorized copying.
Does it defeat my meta-DRM scheme? The metadata would be lost, so any recording from the optical digital output would lack that information. It does break my scheme, yes, if you made your recording via a non-DRM device. In such a case, you've eliminated all protections at zero loss of useful information.
When copying onto a DRM device following my suggestions, the story is a little different. My scheme substitutes maximum restrictions, for each control table entry for which metadata isn't available, so recording onto such a DRM device would impose stricter limitations than the original digital copy. That would be fine for personal use (you just want A of the original - for the car, or whatever) but would be limiting for a pirate bent on mass production.
It would ease a LOT of restrictions and limitations on purely personal use. Yes, it's broken in that an exploit does provably exist, and all you need is one exploit. It would place limits on what pirates could use for mass production, which is supposedly what DRM is for in the first place, so it's not completely a failure. And it would be more effective at doing so than the crap we have at present, so it would be something of an improvement.
After that, I would say that it was up to industry to evolve faster than the pirates (which really don't exist as more than a tiny blip in things anyway). Since that means producing the best recorders and players (not the most inhibiting), the consumer benefits. In fact, the more consumers spend, the more they'll benefit. (Which is the exact opposite of current DRM approaches, where the more customers finance the R&D, the less they get, which is one reason why pirates exist at all.)
How would my proposal work with this, though? You are correct that DRM schemes don't cross over into the analogue world. (Well, that's not 100% true, as there have been copy-protection schemes for tapes.)
The answer is that there would need to be an intermediate device that was authorized to receive the digital stream, and which could then transfer JUST the data (in converted form) to tape. The copy on tape would be unprotected, but it would be authorized to be unprotected.
Would manufactuers go for that? That would be a tough sell, but might be possible. They'd need to add to the DRM systems some means of restricting the number of copies, or something similar to that.
Also, isn't a "smart DAC" of this kind defeating DRM in the first place? No, because it's not about preventing someone making copies, it is about controlling and managing the process, and ensuring that the maximum rights are preserved in a copy. Where the copy can't preserve rights, then the manufacturer - not the user - needs to be SOL. The user should not be limited by the capability or imagination of a manufacturer.
In my descriptions, I pointed out that not all DRM information could be copied on all systems, and that such information will simply need to be dropped. The analogue tapes are merely the logical extreme of this. Furthermore, my descriptions are merely intended as proof that DRM, interoperability, competition and affordability are not mutually exclusive, but if done right can even complement each other very nicely. I don't agree with DRM in the first place, but if we're going to suffer with it, then damnit, I want to suffer from the very best.
Digital rights exerts a pressure. This can be a pressure on the user to conform to a certain behaviour, or it can be a pressure on corporations to evolve better solutions. Both will create positive feedback loops. If you try to constrain the user more and more, the userbase will stagnate and die. If you try to force progress, then users will increase their expectations as fast as companies can progress to meet them, with the slower companies simply being run over.
In the end, nothing is going to progress faster than it has to. Where there isn't a perceived need, an "itch" that has to be scratched or a market that could be better utilized, there will be no progress. DRM provides a need. The first impulse of the corporations is to kill that need, because progress is expensive, but banning things is cheap (for them). Interoperability provides another need, and again the first impulse is to kill it. Monopolies make for a lot of power and glory, whereas both competition and cooperation are expensive and draining of energy.
The laws on DRM and interoperability of media systems should (in my not-so humble opinion) be used to foist cooperative evolution in technology through both pressures. I want to hear screams and howls of pain and anguish from the USPO - not because software engineers broke in and took revenge, but because the volume of genuine, bleeding-edge, novel work they're having to go through has to be airlifted in by transport planes.
It is perfectly true that the recipient need not re-constitute the DRM scheme (using its own methods), so that would need to be protected by law. I don't see that being a significant problem, though. The French proposal would be entirely compatible with a law requiring that the receiving system rebuild DRM.
(In fact, the DMCA - evil though it is - would not conflict with my proposal, as it doesn't require anybody to reverse-engineer anything or know anything about the internals of anyone's protection system.)
Transfer of data via a secure but vendor-neutral channel is not a new idea - it is very unlikely every banking computer in the world runs exactly the same software! - however, I would venture to suggest that it's not a method developers of DRM for music or movies have considered at this time. If they had, I doubt there would have been nearly the fuss about the French proposal. For that matter, CSS might still be unbroken, as it was only because there was a monoculture that the breaking of one key meant the breaking of the whole system.
(Monocultures are vulnerable, precisely because an attack against one element will work equally against all elements. Biologists regard them as BAD, and I see no reason to differ when it comes to secure systems.)
I therefore contend that by creating monocultures - whether within a single platform or across all platforms - actually harms the corporations involved and invalidates their security measures. If they want true security, they NEED diversity and a secure DRM exchange protocol. Therefore, interoperability will be a Good Thing for companies, as it will strengthen DRM and reduce piracy, without impacting any consumer's ability to use whatever OS they choose.
The second option is for the intended recipient to transmit a public key (well, not really public since only the content holder will receive it). The content holder then decrypts the content and uses the public key obtained to build an SSL tunnel to the recipient, which can then re-encrypt it natively.
Ok, that handles that part. Now we need the data format. This will contain one or more of DRM headers, DRM data, and content. Since the data is encrypted in transit, using keys only the two parties know, we don't need DRM protections, only the DRM information. By ripping out the DRM, then converting that information into XML or some other "universal" format, we can preserve the DRM information without needing the DRM to be active.
At the destination, the DRM meta-data is then parsed. Those elements for which no local definition exists would be dropped, and those elements not filled by the meta-data would be set to the most constrained values allowed. The protections may change, with such a system, but they should average out.
We now have a universal DRM exchange protocol that needs to know NOTHING about any foreign DRM mechanisms and therefore does NOT need to be patched as new formats come out, and does NOT need to be bloated with a multitude of foreign algorithms. All it needs is an industry-standard XML template, an implementation of RSA, an industry-standard public key exchange mechanism and optionally an implementation of SSL.
Total hardware complexity? One standard encryption chip and one moderate-sized FPGA should be sufficient. Two scraps of silicon, adding maybe a couple of grammes to the total weight. I can really see this killing the entire music industry... assuming the entire music industry is in fact a small piece of blue-green algae and the chips are dropped on it from an altitude of 30,000 feet.
No, the core problem wasn't with the patents, although those were bad enough. The core problems are ignorance (most people don't know what options exist), inertia (those who do often won't take advantage of them because it requires change) and stagnation (sufficient inertia kills all incentive to further develop alternatives). I would not be against compulsary education on how to be versatile, for this reason.
It is hard to blame Fogent alone, when the entire national attitude is based so firmly on milking every old idea for what it's worth, whilst the populace make no effort to avoid being bilked. As with those in Dilbert who have met the "world's most desperate Venture Capitalist", it becomes hard not to just take the money and run.
This isn't to say such conduct is good or acceptable - it isn't, in my opinion. Rather, it is to say that we should be addressing the whole problem, not merely a selection of the symptoms.
I'd also expect something in the Oxbridge (Oxford and Cambridge Universities) region, but maybe they spend all their creative energy on boat races. Hey, very few could hope to question the sheer mass of brainpower there, or their thousand-year tradition of eccentricity and experimentation, or the sheer volume of bleeding-edge science, so you've got to explain the total lack of bleeding-edge industry there somehow.
If your grandmother is the founder and president of the local Linux User Group, the biker chick for the local chapter of Hell's Angels, or (worst of all) beating you in WoW, which she connects to from her OpenBSD system, then you probably would invite her.
Because routing is dynamic, the problem is actually worse than that, particularly if peering essentially collapses and different backbone providers charge each other for preferred bandwidth and/or preferred routing. Those prices will bubble up through the system, hitting the end-point ISPs, followed by not only the content provider but the consumer as well.
This could easily end up with the consumer paying four or five times the average price hike, because ultimately nobody else will be willing to pick up the tab.
Also bear in mind that since bandwidth is constant, "preferred customers" really means selling those customers OTHER customers' bandwidth without their permission or knowledge. This will NOT be used to increase the bandwidth available, or even use it more efficiently. So if a customer is preferred enough, that customer's competitors' bandwidth can be reduced to effectively zero.
(Using the Evil Highway Analogy, it's one thing for a truck to have a "wide load" sign and step a little into the neighboring lanes, but entirely another for trucks to mount plasma cannons for the express purpose of vaporizing anything within a hundred foot radius.)
Your resolving power, however, should be pretty damn amazing at 20 miles diameter. Ok, so what's wanted here is something nice and noisy, where your ability to isolate a region of sky and/or track an object would be of value.
You could probably track the storms on Jupiter - you can detect those with even a trivial dipole and a receiver in the right range, so you've certainly got more collecting power than necessary. Not sure how accurate your measurements would be, but that would make a fascinating experiment.
GnuRadio will turn your computer into a suitable receiver (provided you either have a soundcard that works at the right frequency, OR you have a suitable analog-to-digital converter plugged in somewhere). You then need to process the streams into something interesting. I believe AIPS is what you'll want for this. It is "professional" Open Source software for interferometry (read: the interface is crappy, but the logic is superb).
The nearer satellites - such as those orbiting Mars - should be well within your ability to receive and track. I doubt there will be any encryption on the data being sent to Earth, so you might be able to get real-time(!) images from the probes. The only question there is whether the signal would be strong enough to correctly interpret. The same would be true of anything sent by the Cassini probe, although it is much further away and therefore would be far fainter, so you might be restricted to just knowing where it was. Which would be pretty damn good, even so.
I would certainly encourage you to give it a try and see what you can do, and also to diary what works. You may well be able to do far better than I expect - it depends on how big the dishes are and how well you are able to sort signal from noise.
You get your Real Ultimate Power badge if you can intercept a message from either Voyager probe, and an honorary lifetime membership of the Q Continuum if you can get any kind of signal at all from one of the Pioneer probes.
(Note to the humour-deprived: If NASA can barely achieve the former, and can't achieve the latter at all, on the Deep Space Network, there is no friggin' way an amateur is going to on three dishes... unless they ARE in the Q Continuum, in which case the prize is easy.)
In practice, the Square Kilometer Array is intended to have a collecting area close to the physical area of one million square meters - requiring almost no gaps to exist between dishes.
My first calculation would be for dishes with a wider gap, which would give you much greater flexibility on pointing the damn thing, as you can't see through the other dishes. Personally, I consider this to be a much superior design, even though it would cost on the collecting area. Unfortunately, they are the ones being paid, even if I am the one who is right...
By way of comparison, Jodrell Bank Radio Telescope is a paltry 76 meters across, for a total collecting area of 4560 square meters, and that's one of the largest single steerable telescopes out there.
I'm going to guess that a collecting area about nine times that of Jodrell Bank, combined with a resolving ability that is, well, astronomical, you would get a very respectable image of Earth-like planets around other stars. If we accept the SKA group's claims, then you've a collecting area 250 times that of Jodrell Bank.
I first heard the 100LY=1 pixel resolution with SKA from Jill Tarter, head of the SETI Institute at a talk she gave at NASA Langley. From crunching the numbers, I can see nothing that could seriously contradict the claim. Even if you assume my model is the more reasonable implementation, the complete MERLIN network that has been detecting jovian planets for some time has only a fraction of that collecting area - probably something like a quarter or a fifth. (Aside from Jodrell Bank, the next-largest radio telescope in the UK is a paltry 32 meters across.)
If we go with SKA's claims, then we're talking about collecting possibly hundreds of times the total radiation, which would definitely be enough to spot even the tiniest of worlds - provided it had some characteristic reflected in the radio spectrum.
(It's also worth bearing in mind that networks such as MERLIN, which are hundreds of kilometers across, are set up for VLBI - very long baseline interferometry. That's fine, when you're talking about gas clouds or stars, but is probably none-too-hot for spotting very fast pulsars or rocky inner planets. On the other hand, a kilometer would let you use regular interferometry, which means these things would show up quite nicely.)
There are three drawbacks to all of this, and I'm surprised none of the posters has commented on them (so far). First, interferometry requires very exact timing of all the delays in the system, or it won't work. Let's go with the SKA estimate and say the dishes are 1 meter apart. Your clock must count an integral number of ticks for every meter the signal travels from the dishes, even after allowing for the natural variation in the data lines varying the speed of the signal. This is some astonishingly serious timekeeping.
The second problem is to keep the signal noise-free. Easy, for a giant single steerable dish - you plunk it in the middle of nowhere and surround it with a huge Faraday cage that only obscures the horizon. When you've a few tens of thousands - or millions - of very small dishes, the problem isn't so easy. The terrestrial radio sources will be far harder to screen out - not just
"We" can't be a primitive, it's a composite type.
If I compile the Java code with GCJ, then I shouldn't need a JVM. If someone would get around to building a processor-in-memory hardware Java implementation, you'd have a Java Physical Machine and again would not require a virtual machine. "Need", then, is a little strong. It would be more correct to say that - as of right now - most Java applications will indeed be run in a virtual machine, and require the components within that machine, but they are only run virtually because that is how it is traditionally done.
How will this help? Radio telescopes can look at the absorbtion spectrum of the planet for the tell-tale lines of water, methane, oxygen (both O2 and O3), and other markers of highly reactive chemicals - especially when they will react with each other. When you have an atmosphere that is chemically violently unstable (as is the case on Earth), it must be being maintained by some process.
That's the first clue, but only the first. The second clue is that "dead" planets will be in equilibrium with their surroundings, but "living" planets will always be in opposition. (Organisms will always create a dynamic equilibrium that suits them, so must always counter any and all natural phenomena that would push the system away from that preferred state. Simple negative feedback.)
Simple radio telescopes can do all this now, no new optical technology need be developed, and no assumptions about the type of life need be made. (All the above assumes is that life can never be inert and that any specific organism cannot function equally under all potential conditions. That's broad enough, although there will probably be exceptions even then.)
The Km array proposed (and the hectare array already built) are just a huge stack of ordinary satellite TV dishes. This could be done by anyone at any time. A mile array would give you 2.5x2.5 pixels ast 100 lightyears - enough to discern if weather patterns exist, though not enough for any long-range forecasts.
This means that the center of mass (both instantaneous and over time) for the solar system is off-center, and that the Kuipier Belt may be non-uniform (which may therefore provide more screening from the galactic winds on that side).
Now, because the sun is not stationary with respect to the galaxy, the galactic winds will not be uniform in the direction of motion. Because the galaxy is not of uniform composition, the galactic winds will also be predominantly from the galactic core. (The galaxy will have a galactic equiv. of the heliopause, in which the pressure from the galaxy will match the pressure from remote galaxies.)
However, it's never quite that simple. There are structures in the galaxy that are significantly off the galactic plane, and these too will be exerting some pressure from their own particle streams.
All in all, the idea that the heliopause isn't a perfect circle isn't that mysterious. What IS mysterious is why anyone thought it would be, and what is intriguing is what shape it actually has, given the sheer number of factors that could influence it.
(Intuitively, this is something you should be able to prove by a combination of induction and geometry.)