So, the FFT breaks down a signal into both a sine *and* cosine, summed together (they use a really neat math trick involving imaginary exponents to do this:) ). The only problem with this for compression is that you end up with twice the amount of data you started with!
I probably should have mentioned that I already know how the FFT works; I was just wondering why it would be unsuitable.
I'd get around it producing twice as much data by discarding half of it. The real and complex components of the spectrum of a purely real signal will be symmetric and antisymmetric, respectively, so I can discard half of each and then reconstruct them before I do the IFFT when unpacking the compressed data.
The DCT can be mathematically derived from the FFT by doing similar tricks, as you're probably already familiar with (you treat the input waveform as half of a symmetric signal, which has no imaginary component in its twice-as-long FFT).
Out of curiosity, what is the basis behind the MDCT? I've heard of it but haven't seen an explanation of how it works.
[OT: I replied to your antimatter post with some of the information you asked for. Short version: It's really, *really* expensive to produce, and solar radiation isn't energetic enough to help.]
Found this late while browsing through your comment history for signal processing posts. Hopefully you check for replies now and then. A couple of pieces of relevant information:
Indeed, its manufacture is highly inefficient. In fact, its maximum possible manufacturing efficiency is a mere 50% yield, and such a yeild is beyond the wildest expectations of most scientists. But, there is a much greater inefficiency involved here (actually two of them): acceleration energy and relativistic effects.
The problem is that antiproton production is something like a million-to-one inefficient. You could still do it, but it would cost far less just to build a laser array to remotely propel a solar sail (for interstellar travel), or to use fusion or fission drives (for interplanetary travel).
Assuming 100%-efficient magical synthesis of antimatter from electrical energy at 10 cents per kW/hr, it would cost $2.5 trillion per tonne. An antimatter-powered ship capable of interstellar flight within a lifetime would need to have about half its weight as fuel. Antimatter drives have great mass efficiency, but horrible energy efficiency. They work as photon drives; most of your momentum comes out as gamma rays, even with meson production from the antiproton reactions.
This gives a fuel cost of about $1.25 trillion per tonne of unfuelled craft weight (only half of the fuel is antimatter).
Plugging in realistic numbers for the cost of antimatter production gives quintillions of dollars. An array of lasers the diameter of Neptune still costs less.
Re. relativistic effects, you can avoid most of them by limiting your craft velocity to, say, 0.7-0.8c. That gives you a factor of about 1.5 mass increase and time dilation, which doesn't throw off your numbers much.
Re. carrying your reaction mass with you, you do indeed require exponentially more mass to gain velocity once your fuel mass dominates craft mass. What this in practice means is that instead of picking a speed and finding the required fuel ratio, you should pick a feasible fuel ratio and then find the resulting speed.
It turns out that a really-well-engineered fusion drive could give you tolerable interstellar travel times (a few generations), for far less cost than an antimatter drive. Or, you could use externally powered systems like solar sails or Bussard ramjets and still save money. The laser sail, at least, could be built with current technology (though it's still expensive as heck).
For interplanetary travel, a fission or fusion drive is more than adequate.
Thus, I don't think that antimatter will ever be a practical spacecraft fuel.
Now, a real issue to be investigated from the sun is (and, please, all ye experts on particle accelerators and animatter production, step in and comment (probably badly, sure, but its an idea)) whether or not you could produce antimatter from solar rays, which travel at a good percentage of the speed of light (sorry, no numbers on me right now). Most high-energy particle emissions from the sun are light nucleii, such as hydrogen and helium, but the sun does eject some denser nucleii. It'd be a free source of high-energy collisions, and you might be able to filter anitmatter from that in a fairly simple, low-weight, free-power (the main reason), low maintinence method, if you could set up simple automation.
The problem is that in order to produce antiprotons, you need particle energies greater than twice the rest mass of a proton - i.e. greater than about 2 GeV. The particles in the corona and solar wind are almost all of far lower energy, if I understand correctly.
I'm assuming that your first priority is protecting machines administered by the university. Students' personal machines are probably beyond the coverage of university site licenses, and 90% or more of the students will either ignore administrative requests, or spend 5 minutes trying to figure out how to follow them and then give up.
For the Windows network, my best suggestion would be a combination of virus scanning and regular, automated reinstall.
Put virus scanners on all of the machines, as part of their standard installation. If it's Nav, tell it to check incoming file attachments and documents - this is very, very helpful (my old workplace had a problem with macro viruses). You can probably get away with telling it to scan only local drives.
Put another virus scanner on a machine with direct access to all directories on the fileserver. It'll do your sweep of the network drives. You can either create a special NT profile for it that gives it access to all drives, or (failing that) you can run it on the fileserver itself at 4am Sunday morning (not Monday morning, because students will pull all-nighters on Sunday to finish projects due on Monday - I've TAd courses where they regularly did this).
Next, set up the user machines with one of the third-party bootstraps that compares all system files to copies on the network server, removes anything that shouldn't be there, and fixes anything that's changed. This is the only way I know of to really bulletproof Windows, and as far as I can tell, it does work. The version installed on the PCs at my university also wiped the local drives and did a full reinstall weekly. Either tell the users to power off the PCs at the end of the day, or send an admin around to do it at the end of every week.
Needless to say, you should enable boot virus protection in the BIOS. While you're there, you should also force booting from the hard drive first and then password the BIOS, to prevent student shennanigans. This is standard practice at most shared PC installations I've seen.
Re. Macs, you're on your own. This is outside of my experience.
Re. Linux, *BSD, Solaris, etc, you probably don't have much to worry about to the first order. The vast majority of viruses run under Windows. Anything malignant in the user's files should be caught by the sweep of the fileserver. I don't really see what could go wrong in an environment like this, given that the user doesn't have root access.
To make *sure* the user doesn't have root access, set the machine to boot off of the hard drive first and lock down the BIOS, for any *nix-on-PC machines. If you're paranoid, set up a cron job to refresh the machine's configuration from a CVS server nightly or weekly, just in case something goes strange or is tampered with.
If you're really feeling paranoid about *nix terminals, make them all netboot off of the file server, with the local hard drive just being swap space. Keep a close eye on the server's configuration, and you should be fine.
In summary, with a bit of planning, you should be fine under most conditions. Virus-hardening merges naturally with hardening against bit-rot and active attacks by the users.
One of the most overhyped issues of IT today is virii. I have downloaded countless programs from the internet and only once had a virus install.
Until we installed a virus checker at my old workplace, we were inundated with macroviruses in Word documents - many of them from our clients (large, hopefully professional companies who shall remain nameless).
We were lucky. All these tended to corrupt were new documents we were writing. This person may not be so lucky.
Also, we all know that half of the students will be installing their own entertainment applications. It's not beyond reason to think that one may pick up a bug. Heck, if it's anything like my undergrad days, the students will have already be storing pirated games in secret locations, possibly with the help of moles in the sysadmin office.
Word macro viruses would be my main worry, though. These are _endemic_ to all Windows environments I've run across that exchange documents with the outside world.
OK, I can see them yanking your site if they didn't like it. Their servers, their right to what's on them. However, pressing criminal charges and having you banned from campus seems a little harsh. They could at least have slapped your wrist first and talked to you about it.
According to the article, they _did_ ask him repeatedly to remove material they found objectionable. He refused repeatedly. Criminal charges are still a bit harsh (they could have just replaced him as the site administrator), but it isn't as if he had no previous contact at all.
Hasn't this already been used for a while in several fab houses?
When I went through Comp. Eng. undergrad, I was told that there were two layout styles used in industry. "Manhattan rules", which forced all edges in the layout to be horizontal or vertical, and "Brooklyn rules", which let you use diagonal edges as well.
The high-level synthesis tools won't care - they're just manipulating gates from the cell libraries, and letting the place-and-route tool worry about layout.
The place-and-route tool would have to be tweaked to allow diagonal lines, which would be a substantial undertaking, but hardly earth-shattering.
The cell libraries would have to have modules implemented that took advantage of the layout rules, but you have to make new cell libraries for every new process anyways.
The lithography process itself doesn't care what design rules you use. It just forms images that have a certain minimum feature size and certain mask positioning tolerances.
If Brooklyn rules really are used in industry, then these tools already exist.
I'm just trying to figure out what's "news" here. (Maybe mixing the two rules methods, which is a fairly neat trick to help those stuck with Manhattan libraries.)
This technology looks interesting, but I am curious if it will extend to odor-sensitive devices available for a wider range of scents. Imagine a security device that ensured that each person smelled right before allowing entry (similar to a dog, but not distracted by food).
...And then you switch to a different brand of deodourant...
While smell is probably too variable to use as a security device, sensors like this certainly exist. There was a flurry of annoucements over the past year about "biochip" sensor array that could measure more or less arbitrary sets of chemicals in air or water. You could also go the old-fashioned route and install a gas chromatograph in the building's entrance annex (briefcase-sized combined mass spectrometer/gas chromatograph devices were build for police use a few years back, though they're expensive as heck).
The usual application touted for this kind of multiple-chemical detector is medical diagnostics (measuring chemicals in the blood), but you could also use them as pollution guages, or in an improved breathalyzer, or as a pheromone sensor to let machines sense the moods of humans to a rough degree ("he's in a rotten mood; time to brew coffee").
It might or might not be possible to use the plastics mentioned in the article as wide-spectrum detectors. It would depend on how tailorable their responses are, and how selective the tailored responses can be made.
But seriously, do we have laser destructive enough to warrant being on a super vehicle? If so, why is this the first I have heard of them?
Because they suck compared to guns:).
Any decent-sized industrial CO2 laser could be used as a weapon, if you cart around a generator to run it with.
Advantage:
If you can track the target, you've *hit* the target.
Disadvantages:
Lasers hitting haze scatter. Lasers also disperse due to diffraction and poor optics. CO2 lasers are also absorbed by the CO2 in the air. All of this limits range.
You can store a lot of machine guns with ammo for the same amount of weight.
Metal stamped with cube mirror patterns will really ruin the day of whoever's firing the laser (the armour will burn from the light it doesn't reflect, but it'll still send > 90% of the laser light back to the turret).
Lasers will almost certainly be useful for niche applications, but for damaging most small-ish targets, it's hard to beat kinetic slugs.
According to our current base of knowledge of physics, antimatter is the end all of power generation. As far as propulsion goes, the biggest, baddest anti-matter drive that we can build can would only theoretically be able to travel us just shy of 1/2 the speed of light.
Actually, you can get to as high a speed as you like, just like with any other reaction drive. It just takes exponentially more fuel (the 1/e point for the cargo:total mass ratio happens when your ship momentum per unit mass equals the exhaust momentum per unit mass ("momentum per unit mass" is just velocity, for non-relativistic speeds)).
As for being the "end all of power generation", you're ignoring efficiency of power capture. Most of the energy from matter/antimatter annihilation comes out as gamma rays. You can't focus or reflect gamma rays. The best you could do for an antimatter rocket would be to use a big block of concrete to absorb all of the gamma rays going in one direction, pushing the block (and ship) in the other direction. This is far from being perfectly efficient.
Some proposed schemes use the mesons and other crud produced by proton/antiproton annihilations as reaction mass, directing them with magnetic fields, but most of the annihilation energy still goes into gamma rays, so you're only capturing a small fraction of the energy for useful thrust.
According to my own calculations, you *just might* be able to build a fusion drive that's more efficient in practical use than an antimatter drive (because it's not stuck with the very low thrust per unit energy of a photon drive, and can divert most or all of its exhaust in useful directions). Regardless of which is more efficient in practical use, fusion drives will be much, much, much cheaper (production efficiency for antiprotons is *extremely* horrible, and won't be getting much better).
All of this is ignoring drives that use an external power source, like laser sails or the Bussard ramjets mentioned by another poster.
The advantage of Open Source and Free Software is that you do have the source in case you need to modify the existing system.
You do if you're developing software in-house, too. Non-extensible software is still non-extensible, and making it extensible and documenting it properly is still a large short-term expense with little tangible to show for it (however valuable it may be in the long term). Look at how much people griped while Mozilla was in rewrite-limbo for an example of the usual reaction to this.
We need HAL to lead us out of the imminent abyss of anarchy and into the lucid sunlight of a new tomorrow.
Hmm.
I think I'll give the same response my friends gave me when I proposed this idea:
Trust The Computer.
The Computer is Your Friend.
[Designing an AI that can run the world properly under all circumstances, when we can't even agree on what "properly" is, will be orders of magnitude harder than solving the Strong AI problem, which won't be a cakewalk either.]
The reason why most software isn't flexible enough to be extended easily is that it's usually easier in the short term to write non-flexible software and to document its design poorly.
In the real world, you are almost never given enough time or resources to finish a software project. Part of this is third-party influence - the nature of the market, trade show deadlines, customer deadlines if you're contracting, etc - and part of this is management that believes in short-term profit above all else.
Sometimes you're lucky enough to avoid one or both of these factors, or to be in a position where you can force software development to take as much time as it needs. Most of the time you can't.
It's hard enough getting a working, tested, and documented product to ship. Getting an extensible product on top of that is a task of Herculean magnitude.
Thus, I think that most software will continue to be difficult to adapt to new tasks.
Exceptions exist, but bear in mind that even Open Source and Free Software projects will feel some of these pressures, so they won't necessarily be immune.
I'd love to see Canadians set foot on Mars, but at $500M Cdn (around $300M US), it's going to be a probe, if anything, that's sent there. This is about the right price range.
A manned ship that could be self-sufficient for the required travel times would cost as much as a space station, because it would *be* a space station.
As for the latitude comment made by another poster, the article mentions that they're going to contract out for launch capability, which probably means using one of the commercial launch companies in the US. This is more or less standard practice for industry launches.
What? "Share your philosophies on IP..."? The guy is looking to hire people for a closed source company. It has nothing to do with finding people who "share his philosophy".
This is why he wrote, "Selectively creating jobs for this group seems an appropriate way of giving back to the community"? He's using company resources to support a cause he *personally* believes in. The *company* just wants the best coders it can get for the positions.
(a) he thinks they have proven abilities
Sure. By all means encourage resumes from them. But excluding everyone *else*, when everyone else includes a large number of people with comparable abilities, is harmful to the company's aim (finding good coders). Thus, this action would be harming the company, to support a personal cause of the interviewer. Not a good thing.
Suppose a job applicant puts a lot of charity work (volunteering at a homeless shelter, say) on his resume. An employer decides to hire him because (a) the employer thinks that skills acquired in volunteering also apply to the workplace and (b) the employer agrees that charity for the homeless is a good thing.
Reason (a) is a great reason. Reason (b) is grounds for firing. See above - it is the *duty* of the interviewer to be *impartial*, and to hire based only on suitability for the *company's* goals - not based on non-work-related opinions of the interviewer.
hey, did you actually _read_ the article? He said he will get _thousands_ of applicaions, most of them unqualified. Sifting through the crap was why he asked the question.
Actually, I did read the article. He said "hundreds", not "thousands".
If you have thousands of applications for a handful of positions, it means you aren't making the posted job requirements high enough.
If you have thousands of applications for dozens of positions, then you can afford the manpower to have several people sift resumes.
If you have a few hundred resumes for a small number of positions, and you're responsible for interviewing, then you had better *make* the time to sift through those applications, because it's your job to consider all of the candidates. If the majority are "crap", then you can throw out almost all of them after about 15 seconds each, and have a much smaller stack left over to deal with.
Lastly, his proposed solution does not substantially improve the quality of the resumes he'll get (small effects notwithstanding). I've been on both sides of the Open/Closed coding fence, so I feel qualified to comment on this one.
Your point is well-taken. But no matter where I go looking for resumes, I'll get more resumes than I can ever respond to. I can get literally dozens of resumes weekly from any recruiter I contact. Game programming is an attractive field.
This is where first-pass filters come in. There are several (somewhat arbitrary) filters you can use to toss out many of the resumes that are still based more or less on ability.
I personally just skim resumes on the first pass looking for "good" and "bad" flags.
Coding as a hobby is a "good" flag. Awards are a "good" flag. A mile of past experience doing useful work is a "good" flag. High marks if they're a recent graduate is a "good" flag.
Absence of experience is a "bad" flag. Absence of anything other than school projects and grunt work is a "bad" flag. Lack of diversity in languages and systems known is a "bad" flag, though not a crippling one. Low or mediocre marks if they're a recent graduate is a "bad" flag.
You get the idea. Using criteria like these, I can sift through a couple of resumes per minute, and chuck three quarters of them. The ones I keep get a closer look, and there's a manageable number of them.
If I just dump half of them out of hand (by excluding a candidate group), though, I'm not dividing based on quality (for the most part). This means I have fewer high-quality candidates to choose from, which is a Bad Thing even discounting the fact that I'd be fired.
What I see in common with free software hobbyists is the motivation to write code. Philosophical points aside, if I can hire from a pool of people more likely to be motivated to write code, I'm ahead.
I agree that coding as a hobby is a good sign that someone's a good coder. However, this would probably best be used as a filter later in the pipe. Hobbyists don't necessarily know what they're doing or have the expertise you require any more than non-hobbyists would.
If you are in charge of hiring programmers, you should hire the best programmers for the job. If they end up being Open Source or Free Software people, great - but if you make your candidate pool *only* Open Source or Free Software programmers, you will be fired, and rightly so.
Make your candidate pool as wide as possible, and do not filter it based on your own biases. If you think there's a lot of talent in the Open Source and Free Software communities, then by all means encourage applicants - but encourage the standard channels as well.
Filtering based on whether or not the candidates share your philosophies on IP is just as bad as, say, giving all of your friends the first shot at the interviews. You'd be arbitrarily ignoring (discriminating against) a wide pool of skilled applicants who would be just as good at the job.
Whenever I need to do more in the shell than loop through a few files, I write it in Lisp (I've written 5-line programs to leech an entire Web page's MP3 archive).
for instance if it were wrong, then (since we have a fairly good grasp of the distances involved, we would simply miscalculate the mass of a planet. And believe it or not we could probably go for quite some time convinced that jupiter was heavier or lighter than it was without finding a condradiction.
If we were only looking at the orbits of the planets about the sun, this would most certainly be correct. However, we've also observed the orbits of the moons of the various gas giants about their primaries, and measured with fanatical precision the paths of the probes we've sent to and past the gas giants. If the mass values for the gas giants were off, this would have very substantial effects on the orbits of their moons and on the trajectories of probes that have visited.
Now, I can't remember the specifics, but the general equations we use when utilizing relativistic motion are actually still only approximations -- it's just that the third, fourth, etc. order terms of the equation are so small that you can ignore them.
The thing is - what happens over large distances? Well, the smaller terms will start to become very important. I've got to wonder if they forgot that the equations they'll typically use ARE approximations which are simplified for ease of use in calculations?
If I understand correctly, the approximations only cause problems in very extreme situations (sharply curved space, very high matter or energy densities, very oddly configured space, etc.). At the probes' location, space is so flat you could treat it with Newtonian mechanics and have a great deal of trouble finding discrepencies with observations.
Thus, I doubt that equation approximations are the cause of the problem in this case.
On the other hand, if I recall correctly there has been interesting speculation about the full versions of the equations allowing negative mass to be generated under some conditions. I'd have to study my relativity book a lot more thoroughly to tell if that's even remotely sane, though.
CPU speed might very well be irrelevant to your decision. If you're making a web server farm, your local disk access bandwidth and network bandwidth may be the limiting factors. (Local disk access because you want silly amounts of swap space to allow caching of many pages in virtual memory).
The Right Thing to do, given that you have a hefty cluster-building budget to work with, is to buy one of each type of machine, subject them to simulated loads, and see how they perform. Throttle network and fileserver and database server bandwidth to simulate demands from the rest of the cluster when running the test.
Don't have time to run the test? Then I hope you're good at guessing.
You should also consider hardware/software support availability and cost, and in-house expertise when making the decision, naturally.
Any estimates on the size of the USPTO's patent database? If it's something that could reasonably fit on a few hundred CDROMs, it might be worth asking them to think about distributing it.
Having an on-site copy of the database for searching and data-mining at your local university or large company's library would raise very interesting applications. Write the correct tools, and you could easily see what the state-of-the-IP-art is in any given field, and I'm sure that organizations like the EFF would like an easier way to peer-review the patent database, too.
OTOH, if you'd need the proverbial 747 full of CDs, this wouldn't be practical.
If they're slowing as they get very far from the Sun, that seems to imply that the force of gravity is not dropping of quite as fast as 1/r^2.
The problem is, as the article points out, we would have seen the effects of this on the orbits of the planets if this was the case.
I'm personally wondering about drift in the probes' radio sources throwing off the doppler measurements, but if this was happening they should have caught it already (you can directly measure the probes' positions by measuring the round-trip signal times to them at a few different imes during the year).
Slashdot Mirror
So, the FFT breaks down a signal into both a sine *and* cosine, summed together (they use a really neat math trick involving imaginary exponents to do this :) ). The only problem with this for compression is that you end up with twice the amount of data you started with!
I probably should have mentioned that I already know how the FFT works; I was just wondering why it would be unsuitable.
I'd get around it producing twice as much data by discarding half of it. The real and complex components of the spectrum of a purely real signal will be symmetric and antisymmetric, respectively, so I can discard half of each and then reconstruct them before I do the IFFT when unpacking the compressed data.
The DCT can be mathematically derived from the FFT by doing similar tricks, as you're probably already familiar with (you treat the input waveform as half of a symmetric signal, which has no imaginary component in its twice-as-long FFT).
Out of curiosity, what is the basis behind the MDCT? I've heard of it but haven't seen an explanation of how it works.
[OT: I replied to your antimatter post with some of the information you asked for. Short version: It's really, *really* expensive to produce, and solar radiation isn't energetic enough to help.]
Found this late while browsing through your comment history for signal processing posts. Hopefully you check for replies now and then. A couple of pieces of relevant information:
Indeed, its manufacture is highly inefficient. In fact, its maximum possible manufacturing efficiency is a mere 50% yield, and such a yeild is beyond the wildest expectations of most scientists. But, there is a much greater inefficiency involved here (actually two of them): acceleration energy and relativistic effects.
The problem is that antiproton production is something like a million-to-one inefficient. You could still do it, but it would cost far less just to build a laser array to remotely propel a solar sail (for interstellar travel), or to use fusion or fission drives (for interplanetary travel).
Assuming 100%-efficient magical synthesis of antimatter from electrical energy at 10 cents per kW/hr, it would cost $2.5 trillion per tonne. An antimatter-powered ship capable of interstellar flight within a lifetime would need to have about half its weight as fuel. Antimatter drives have great mass efficiency, but horrible energy efficiency. They work as photon drives; most of your momentum comes out as gamma rays, even with meson production from the antiproton reactions.
This gives a fuel cost of about $1.25 trillion per tonne of unfuelled craft weight (only half of the fuel is antimatter).
Plugging in realistic numbers for the cost of antimatter production gives quintillions of dollars. An array of lasers the diameter of Neptune still costs less.
Re. relativistic effects, you can avoid most of them by limiting your craft velocity to, say, 0.7-0.8c. That gives you a factor of about 1.5 mass increase and time dilation, which doesn't throw off your numbers much.
Re. carrying your reaction mass with you, you do indeed require exponentially more mass to gain velocity once your fuel mass dominates craft mass. What this in practice means is that instead of picking a speed and finding the required fuel ratio, you should pick a feasible fuel ratio and then find the resulting speed.
It turns out that a really-well-engineered fusion drive could give you tolerable interstellar travel times (a few generations), for far less cost than an antimatter drive. Or, you could use externally powered systems like solar sails or Bussard ramjets and still save money. The laser sail, at least, could be built with current technology (though it's still expensive as heck).
For interplanetary travel, a fission or fusion drive is more than adequate.
Thus, I don't think that antimatter will ever be a practical spacecraft fuel.
Now, a real issue to be investigated from the sun is (and, please, all ye experts on particle accelerators and animatter production, step in and comment (probably badly, sure, but its an idea)) whether or not you could produce antimatter from solar rays, which travel at a good percentage of the speed of light (sorry, no numbers on me right now). Most high-energy particle emissions from the sun are light nucleii, such as hydrogen and helium, but the sun does eject some denser nucleii. It'd be a free source of high-energy collisions, and you might be able to filter anitmatter from that in a fairly simple, low-weight, free-power (the main reason), low maintinence method, if you could set up simple automation.
The problem is that in order to produce antiprotons, you need particle energies greater than twice the rest mass of a proton - i.e. greater than about 2 GeV. The particles in the corona and solar wind are almost all of far lower energy, if I understand correctly.
Do you know why you wouldn't use an FFT for audio or video compression?
Out of curiosity, why?
Dabbling in signal processing and audio/video compression is one of my hobbies, though I'm only an amateur.
I'm assuming that your first priority is protecting machines administered by the university. Students' personal machines are probably beyond the coverage of university site licenses, and 90% or more of the students will either ignore administrative requests, or spend 5 minutes trying to figure out how to follow them and then give up.
For the Windows network, my best suggestion would be a combination of virus scanning and regular, automated reinstall.
Put virus scanners on all of the machines, as part of their standard installation. If it's Nav, tell it to check incoming file attachments and documents - this is very, very helpful (my old workplace had a problem with macro viruses). You can probably get away with telling it to scan only local drives.
Put another virus scanner on a machine with direct access to all directories on the fileserver. It'll do your sweep of the network drives. You can either create a special NT profile for it that gives it access to all drives, or (failing that) you can run it on the fileserver itself at 4am Sunday morning (not Monday morning, because students will pull all-nighters on Sunday to finish projects due on Monday - I've TAd courses where they regularly did this).
Next, set up the user machines with one of the third-party bootstraps that compares all system files to copies on the network server, removes anything that shouldn't be there, and fixes anything that's changed. This is the only way I know of to really bulletproof Windows, and as far as I can tell, it does work. The version installed on the PCs at my university also wiped the local drives and did a full reinstall weekly. Either tell the users to power off the PCs at the end of the day, or send an admin around to do it at the end of every week.
Needless to say, you should enable boot virus protection in the BIOS. While you're there, you should also force booting from the hard drive first and then password the BIOS, to prevent student shennanigans. This is standard practice at most shared PC installations I've seen.
Re. Macs, you're on your own. This is outside of my experience.
Re. Linux, *BSD, Solaris, etc, you probably don't have much to worry about to the first order. The vast majority of viruses run under Windows. Anything malignant in the user's files should be caught by the sweep of the fileserver. I don't really see what could go wrong in an environment like this, given that the user doesn't have root access.
To make *sure* the user doesn't have root access, set the machine to boot off of the hard drive first and lock down the BIOS, for any *nix-on-PC machines. If you're paranoid, set up a cron job to refresh the machine's configuration from a CVS server nightly or weekly, just in case something goes strange or is tampered with.
If you're really feeling paranoid about *nix terminals, make them all netboot off of the file server, with the local hard drive just being swap space. Keep a close eye on the server's configuration, and you should be fine.
In summary, with a bit of planning, you should be fine under most conditions. Virus-hardening merges naturally with hardening against bit-rot and active attacks by the users.
One of the most overhyped issues of IT today is virii. I have downloaded countless programs from the internet and only once had a virus install.
Until we installed a virus checker at my old workplace, we were inundated with macroviruses in Word documents - many of them from our clients (large, hopefully professional companies who shall remain nameless).
We were lucky. All these tended to corrupt were new documents we were writing. This person may not be so lucky.
Also, we all know that half of the students will be installing their own entertainment applications. It's not beyond reason to think that one may pick up a bug. Heck, if it's anything like my undergrad days, the students will have already be storing pirated games in secret locations, possibly with the help of moles in the sysadmin office.
Word macro viruses would be my main worry, though. These are _endemic_ to all Windows environments I've run across that exchange documents with the outside world.
OK, I can see them yanking your site if they didn't like it. Their servers, their right to what's on them. However, pressing criminal charges and having you banned from campus seems a little harsh. They could at least have slapped your wrist first and talked to you about it.
According to the article, they _did_ ask him repeatedly to remove material they found objectionable. He refused repeatedly. Criminal charges are still a bit harsh (they could have just replaced him as the site administrator), but it isn't as if he had no previous contact at all.
Hasn't this already been used for a while in several fab houses?
When I went through Comp. Eng. undergrad, I was told that there were two layout styles used in industry. "Manhattan rules", which forced all edges in the layout to be horizontal or vertical, and "Brooklyn rules", which let you use diagonal edges as well.
The high-level synthesis tools won't care - they're just manipulating gates from the cell libraries, and letting the place-and-route tool worry about layout.
The place-and-route tool would have to be tweaked to allow diagonal lines, which would be a substantial undertaking, but hardly earth-shattering.
The cell libraries would have to have modules implemented that took advantage of the layout rules, but you have to make new cell libraries for every new process anyways.
The lithography process itself doesn't care what design rules you use. It just forms images that have a certain minimum feature size and certain mask positioning tolerances.
If Brooklyn rules really are used in industry, then these tools already exist.
I'm just trying to figure out what's "news" here. (Maybe mixing the two rules methods, which is a fairly neat trick to help those stuck with Manhattan libraries.)
This technology looks interesting, but I am curious if it will extend to odor-sensitive devices available for a wider range of scents. Imagine a security device that ensured that each person smelled right before allowing entry (similar to a dog, but not distracted by food).
...And then you switch to a different brand of deodourant...
While smell is probably too variable to use as a security device, sensors like this certainly exist. There was a flurry of annoucements over the past year about "biochip" sensor array that could measure more or less arbitrary sets of chemicals in air or water. You could also go the old-fashioned route and install a gas chromatograph in the building's entrance annex (briefcase-sized combined mass spectrometer/gas chromatograph devices were build for police use a few years back, though they're expensive as heck).
The usual application touted for this kind of multiple-chemical detector is medical diagnostics (measuring chemicals in the blood), but you could also use them as pollution guages, or in an improved breathalyzer, or as a pheromone sensor to let machines sense the moods of humans to a rough degree ("he's in a rotten mood; time to brew coffee").
It might or might not be possible to use the plastics mentioned in the article as wide-spectrum detectors. It would depend on how tailorable their responses are, and how selective the tailored responses can be made.
Because they suck compared to guns
Any decent-sized industrial CO2 laser could be used as a weapon, if you cart around a generator to run it with.
Advantage:
Disadvantages:
Lasers will almost certainly be useful for niche applications, but for damaging most small-ish targets, it's hard to beat kinetic slugs.
According to our current base of knowledge of physics, antimatter is the end all of power generation. As far as propulsion goes, the biggest, baddest anti-matter drive that we can build can would only theoretically be able to travel us just shy of 1/2 the speed of light.
Actually, you can get to as high a speed as you like, just like with any other reaction drive. It just takes exponentially more fuel (the 1/e point for the cargo:total mass ratio happens when your ship momentum per unit mass equals the exhaust momentum per unit mass ("momentum per unit mass" is just velocity, for non-relativistic speeds)).
As for being the "end all of power generation", you're ignoring efficiency of power capture. Most of the energy from matter/antimatter annihilation comes out as gamma rays. You can't focus or reflect gamma rays. The best you could do for an antimatter rocket would be to use a big block of concrete to absorb all of the gamma rays going in one direction, pushing the block (and ship) in the other direction. This is far from being perfectly efficient.
Some proposed schemes use the mesons and other crud produced by proton/antiproton annihilations as reaction mass, directing them with magnetic fields, but most of the annihilation energy still goes into gamma rays, so you're only capturing a small fraction of the energy for useful thrust.
According to my own calculations, you *just might* be able to build a fusion drive that's more efficient in practical use than an antimatter drive (because it's not stuck with the very low thrust per unit energy of a photon drive, and can divert most or all of its exhaust in useful directions). Regardless of which is more efficient in practical use, fusion drives will be much, much, much cheaper (production efficiency for antiprotons is *extremely* horrible, and won't be getting much better).
All of this is ignoring drives that use an external power source, like laser sails or the Bussard ramjets mentioned by another poster.
The advantage of Open Source and Free Software is that you do have the source in case you need to modify the existing system.
You do if you're developing software in-house, too. Non-extensible software is still non-extensible, and making it extensible and documenting it properly is still a large short-term expense with little tangible to show for it (however valuable it may be in the long term). Look at how much people griped while Mozilla was in rewrite-limbo for an example of the usual reaction to this.
We need HAL to lead us out of the imminent abyss of anarchy and into the lucid sunlight of a new tomorrow.
Hmm.
I think I'll give the same response my friends gave me when I proposed this idea:
Trust The Computer.
The Computer is Your Friend.
[Designing an AI that can run the world properly under all circumstances, when we can't even agree on what "properly" is, will be orders of magnitude harder than solving the Strong AI problem, which won't be a cakewalk either.]
The reason why most software isn't flexible enough to be extended easily is that it's usually easier in the short term to write non-flexible software and to document its design poorly.
In the real world, you are almost never given enough time or resources to finish a software project. Part of this is third-party influence - the nature of the market, trade show deadlines, customer deadlines if you're contracting, etc - and part of this is management that believes in short-term profit above all else.
Sometimes you're lucky enough to avoid one or both of these factors, or to be in a position where you can force software development to take as much time as it needs. Most of the time you can't.
It's hard enough getting a working, tested, and documented product to ship. Getting an extensible product on top of that is a task of Herculean magnitude.
Thus, I think that most software will continue to be difficult to adapt to new tasks.
Exceptions exist, but bear in mind that even Open Source and Free Software projects will feel some of these pressures, so they won't necessarily be immune.
What are you talking about? Canadian labour is cheap and plentiful. So that cuts down on cost, added to all of their natural resources...
:). (No, graphics cards don't count.)
On the off chance this isn't just sature:
Aerospace R&D costs about the same here as it does in the US. The same applies to most manufacturing.
This should be pretty obvious. Otherwise, we'd be exporting high-tech manufactured products like crazy to the US
I'd love to see Canadians set foot on Mars, but at $500M Cdn (around $300M US), it's going to be a probe, if anything, that's sent there. This is about the right price range.
A manned ship that could be self-sufficient for the required travel times would cost as much as a space station, because it would *be* a space station.
As for the latitude comment made by another poster, the article mentions that they're going to contract out for launch capability, which probably means using one of the commercial launch companies in the US. This is more or less standard practice for industry launches.
It'll still be nice if it happens, though.
What? "Share your philosophies on IP..."? The guy is looking to hire people for a closed source company. It has nothing to do with finding people who "share his philosophy".
This is why he wrote, "Selectively creating jobs for this group seems an appropriate way of giving back to the community"? He's using company resources to support a cause he *personally* believes in. The *company* just wants the best coders it can get for the positions.
(a) he thinks they have proven abilities
Sure. By all means encourage resumes from them. But excluding everyone *else*, when everyone else includes a large number of people with comparable abilities, is harmful to the company's aim (finding good coders). Thus, this action would be harming the company, to support a personal cause of the interviewer. Not a good thing.
Suppose a job applicant puts a lot of charity work (volunteering at a homeless shelter, say) on his resume. An employer decides to hire him because (a) the employer thinks that skills acquired in volunteering also apply to the workplace and (b) the employer agrees that charity for the homeless is a good thing.
Reason (a) is a great reason. Reason (b) is grounds for firing. See above - it is the *duty* of the interviewer to be *impartial*, and to hire based only on suitability for the *company's* goals - not based on non-work-related opinions of the interviewer.
hey, did you actually _read_ the article? He said he will get _thousands_ of applicaions, most of them unqualified. Sifting through the crap was why he asked the question.
Actually, I did read the article. He said "hundreds", not "thousands".
If you have thousands of applications for a handful of positions, it means you aren't making the posted job requirements high enough.
If you have thousands of applications for dozens of positions, then you can afford the manpower to have several people sift resumes.
If you have a few hundred resumes for a small number of positions, and you're responsible for interviewing, then you had better *make* the time to sift through those applications, because it's your job to consider all of the candidates. If the majority are "crap", then you can throw out almost all of them after about 15 seconds each, and have a much smaller stack left over to deal with.
Lastly, his proposed solution does not substantially improve the quality of the resumes he'll get (small effects notwithstanding). I've been on both sides of the Open/Closed coding fence, so I feel qualified to comment on this one.
Your point is well-taken. But no matter where I go looking for resumes, I'll get more resumes than I can ever respond to. I can get literally dozens of resumes weekly from any recruiter I contact. Game programming is an attractive field.
This is where first-pass filters come in. There are several (somewhat arbitrary) filters you can use to toss out many of the resumes that are still based more or less on ability.
I personally just skim resumes on the first pass looking for "good" and "bad" flags.
Coding as a hobby is a "good" flag. Awards are a "good" flag. A mile of past experience doing useful work is a "good" flag. High marks if they're a recent graduate is a "good" flag.
Absence of experience is a "bad" flag. Absence of anything other than school projects and grunt work is a "bad" flag. Lack of diversity in languages and systems known is a "bad" flag, though not a crippling one. Low or mediocre marks if they're a recent graduate is a "bad" flag.
You get the idea. Using criteria like these, I can sift through a couple of resumes per minute, and chuck three quarters of them. The ones I keep get a closer look, and there's a manageable number of them.
If I just dump half of them out of hand (by excluding a candidate group), though, I'm not dividing based on quality (for the most part). This means I have fewer high-quality candidates to choose from, which is a Bad Thing even discounting the fact that I'd be fired.
What I see in common with free software hobbyists is the motivation to write code. Philosophical points aside, if I can hire from a pool of people more likely to be motivated to write code, I'm ahead.
I agree that coding as a hobby is a good sign that someone's a good coder. However, this would probably best be used as a filter later in the pipe. Hobbyists don't necessarily know what they're doing or have the expertise you require any more than non-hobbyists would.
If you are in charge of hiring programmers, you should hire the best programmers for the job. If they end up being Open Source or Free Software people, great - but if you make your candidate pool *only* Open Source or Free Software programmers, you will be fired, and rightly so.
Make your candidate pool as wide as possible, and do not filter it based on your own biases. If you think there's a lot of talent in the Open Source and Free Software communities, then by all means encourage applicants - but encourage the standard channels as well.
Filtering based on whether or not the candidates share your philosophies on IP is just as bad as, say, giving all of your friends the first shot at the interviews. You'd be arbitrarily ignoring (discriminating against) a wide pool of skilled applicants who would be just as good at the job.
Filter only on suitability for the job.
Whenever I need to do more in the shell than loop through a few files, I write it in Lisp (I've written 5-line programs to leech an entire Web page's MP3 archive).
:) :
:).
Hmm.
Well, I can seldom resist a challenge
#!/usr/bin/perl
$source = `lynx -source $ARGV[1]`;
$ARGV[1] =~ m/(\S+\/)[^\/]*/; $base = $1;
while ($source =~ m/([\w_-]+\.mp3)(.*)/is) {
$fname = $1; $source = $2;
$dummy = `lynx -dump $base/$fname > $fname`; }
Probably made a few typos in there, but oh well
for instance if it were wrong, then (since we have a fairly good grasp of the distances involved, we would simply miscalculate the mass of a planet. And believe it or not we could probably go for quite some time convinced that jupiter was heavier or lighter than it was without finding a condradiction.
If we were only looking at the orbits of the planets about the sun, this would most certainly be correct. However, we've also observed the orbits of the moons of the various gas giants about their primaries, and measured with fanatical precision the paths of the probes we've sent to and past the gas giants. If the mass values for the gas giants were off, this would have very substantial effects on the orbits of their moons and on the trajectories of probes that have visited.
Good thought, though.
Now, I can't remember the specifics, but the general equations we use when utilizing relativistic motion are actually still only approximations -- it's just that the third, fourth, etc. order terms of the equation are so small that you can ignore them.
The thing is - what happens over large distances? Well, the smaller terms will start to become very important. I've got to wonder if they forgot that the equations they'll typically use ARE approximations which are simplified for ease of use in calculations?
If I understand correctly, the approximations only cause problems in very extreme situations (sharply curved space, very high matter or energy densities, very oddly configured space, etc.). At the probes' location, space is so flat you could treat it with Newtonian mechanics and have a great deal of trouble finding discrepencies with observations.
Thus, I doubt that equation approximations are the cause of the problem in this case.
On the other hand, if I recall correctly there has been interesting speculation about the full versions of the equations allowing negative mass to be generated under some conditions. I'd have to study my relativity book a lot more thoroughly to tell if that's even remotely sane, though.
CPU speed might very well be irrelevant to your decision. If you're making a web server farm, your local disk access bandwidth and network bandwidth may be the limiting factors. (Local disk access because you want silly amounts of swap space to allow caching of many pages in virtual memory).
The Right Thing to do, given that you have a hefty cluster-building budget to work with, is to buy one of each type of machine, subject them to simulated loads, and see how they perform. Throttle network and fileserver and database server bandwidth to simulate demands from the rest of the cluster when running the test.
Don't have time to run the test? Then I hope you're good at guessing.
You should also consider hardware/software support availability and cost, and in-house expertise when making the decision, naturally.
Hmm.
Any estimates on the size of the USPTO's patent database? If it's something that could reasonably fit on a few hundred CDROMs, it might be worth asking them to think about distributing it.
Having an on-site copy of the database for searching and data-mining at your local university or large company's library would raise very interesting applications. Write the correct tools, and you could easily see what the state-of-the-IP-art is in any given field, and I'm sure that organizations like the EFF would like an easier way to peer-review the patent database, too.
OTOH, if you'd need the proverbial 747 full of CDs, this wouldn't be practical.
If they're slowing as they get very far from the Sun, that seems to imply that the force of gravity is not dropping of quite as fast as 1/r^2.
The problem is, as the article points out, we would have seen the effects of this on the orbits of the planets if this was the case.
I'm personally wondering about drift in the probes' radio sources throwing off the doppler measurements, but if this was happening they should have caught it already (you can directly measure the probes' positions by measuring the round-trip signal times to them at a few different imes during the year).