According to the "Nyquist Theorem," you need to have twice as many digital samples as the frequency of the analog signal you are trying to represent to have enough data to accurately build it.
WRONG!
Nyquist's criterion is "You must have at least twice as many samples as the largest BANDWIDTH of the signal in order to correctly reconstruct it."
You can take a 10.7 MHz signal, and sample it at 10000 samples per second, and correctly reconstruct it, so long as the signal is guaranteed to be bandwidth limited to 10.7 MHz +/- 2.5 kHz. This is often done in software defined radio to aquire the signal from the intermediate frequency (IF) of the analog front end.
You also have to have an appropriate reconstruction filter at the output of the system in order to correctly recover the signal - if you don't have the right reconstruction filter, you will NOT reconstruct the signal correctly.
You also have to take into account the effects of any signal modulation - take a 20 kHz sine wave, and burst it for 10 msec, and you widen the bandwidth of the signal by about 100 Hz (depending upon the exact shape of the burst - a perfect square burst will widen the signal as a sinc function and will, in effect, increase the bandwidth to infinity, which is why square bursts are generally Considered Harmful in communications work).
Also, you don't oversample a signal in time to account for "rounding errors" - you oversample in time because the frequency response of sampling a system in time introduces a sinc response in frequency - by moving the sampling rate up you reduce the impact of this response on the recovered signal's frequency response. You also greately ease the requirements on the reconstruction filter - the filter can be wider (have fewer poles in the transfer function - thus fewer parts needed).
The biggest problem with backing up a live system is maintaining consistancy during the backup - a backup can take hours, and if the system is changing state during that time, you can have the last half of the backup being inconsistant with the first half.
For example - you might have something that changes both/usr/a/foo and/usr/z/bar at the same time, but if/usr/a/foo gets backed up, then thirty minutes laster/usr/z/bar gets backed up, that is a thirty minute window in which a change can happen and render the backup invalid.
That is why I suggest, for any system where you cannot take it down to single user mode during the backup, you use LVM to create the filesystems, and leave a bit of extra, uncommitted space in the LVM logical group. Then, you can:
Take system down to single user mode. Take an LVM snapshot of the volumes to be backed up. Bring system back up to normal mode. Mount snapshot (read only, of course). Back up snapshot. Release snapshot.
Even should the system change the state of the filesystem, LVM will keep the snapshot'ed state around, allowing it to be backed up with a minimum of fuss.
How about/.TV? 24 hour news and information for nerds?
Well, at least the dumbing-down has already been done, so that's not an issue.
However, if the/. crew cannot even get together for a couple more Geeks In Space episodes, what makes you think they could do so for a 24 hour video channel?
It would be all Timothy and Michael, all the time.
Email is not the only thing that can have this happen - you can also have the same sort of problems with a bank safe deposit box.
If you have a safe deposit box in your name only, and you die, until the courts approve of your estate's executor, nobody will be able to get to the contents of that box - so think twice about putting anything in a safe deposit box that would be needed by your survivors within a month or less of your demise.
I wish the creators of DVD had required players to support converting from 24 frames per second non-interlaced to 60 fields per second interlaced on the fly, rather than the current standard of the movie being converted when the disk is mastered.
When I am watching a DVD on my computer, it is trivial for my monitor to switch to 72Hz refresh, and show each movie frame for 3 refreshes, rather than getting all the interlace artifacts. It would also have improved the compression of the DVD for a given quality.
Modern games are multithreaded. Even if the game is not written to be - even if it does not use seperate threads for sound, rendering, NPC AI, and I/O - the rest of the system is running other threads (networking, interrupts, disk I/O) that are competing with the game for the CPU. A multi-CPU system can reduce that competition, allowing the system to service the NIC and hard disk IRQs while truly simultaniously servicing the game engine.
It's a pity somebody with your attention to detail couldn't be bothered to READ MY POST.
I am talking about the chip the main post is about. This is NOT a desktop chip. It is an embedded chip. Had you bothered to read ALL of my post, you might find these words familliar.
My reaction was to the breathless response by the story poster and by Cliff that *this chip* signaled the end of days - which it does not.
So, by blunting people's reation to the REAL threats, like those you point out, stories like this one cause people to be LESS likely to respond to the real threats, not more.
Bottom line: the chip THIS STORY is about is not a threat. Save your panic for the REAL threats - like what YOU listed.
First of all, this is an *EMBEDDED* processor, not an x86-class CPU. It may be used in PDAs and the like, but it is not going to be running your desktop anytime soon.
Secondly, embedded devices with encrypted onboard flash are nothing new - they've been around for years.
We had a discussion at my place of work that I'd like to let the/. peanut gallery review:
Currently, there is much discussion about the meaning of the IBM sell-off of its PC division. One of the current conjectures is that IBM might be preparing to release a low-cost PowerPC based machine for home use.
Now, if that is the case, I could see IBM going to both ATI and nVidia and saying:
OK, Sparky, here's the deal: we need a good video chip for our systems. That chip needs to have a Free driver for Linux - binary is not acceptable as the system will be PPC.
Now, our buddies over at Apple also want in on this action, so this chip would have to have accelerated 3D that was worth a damn, as well as other features to make Aqua run well - and we are working on the same sort of things with Xorg.
So, this can go down one of three ways:
We could spend the millions to design our own GPU, using strained silicon on insulator, low-K dielectrics, and copper interconnects, and blow you out of the water.
You release the specs on your chip, and we will help you remove/replace any IPR you don't own in the drivers. AND, we would offer to fab your chips for you, using SSOI, low-K, and copper. Your chips get a performance boost and power reduction, we get what we want, and everybody is happy.
OR, we could go to your competitors and make them the same offer.
Step 1: Print 8x10 picture of goatse Step 2: paste onto stiff posterboard, add handle. Step 3: Cut eyehole(s) as appropriate. Step 4: Label back "Back - toward friendly" Step 5: Hold in front of face while using kiosk.
If you go to a fireworks show where there are bleachers nearby, you can hear the same effect - as each retort goes off, you will hear a "fhweeep!" as the impulse from the report crosses the bleachers.
In effect, you are convolving an impulse (the report or hand-clap) with a series of impulses (the steps) to yield a series of impulses.
(and for other signal processing/math pedants out there - yes, a handclap only approximates an impulse, as do the stairs.)
Better still would be for needed services to make some form of command available to test whether they are up yet.
Then, should init script "foo" need "bar" running, then inside foo it could do something like:
if Wait_for_bar --max_wait 60; then foo init; else echo "ERROR" ; fi
Also, It Would Be Nice If init could capture stdout/stderr on all the init scripts, and in the cases of scripts that exit with a non-zero result (or don't exit after N seconds) show that script's output - so that running multiple scripts in parallel would not get the output streams confused.
IANAC (...) Heat it up and it becomes pure (lethal) oxygen.
Since when is pure oxygen lethal? It was used on the Apollo missions, it is used in hyperbaric chambers (at more than atmospheric pressure, I might add), and it is used by military pilots flying high-altitude aircraft to remove the nitrogen from their blood before they fly.
The only thing dangerous about pure oxygen is the fire risk - if that is why you consider it "lethal", then perhaps you might want to check the fuel tank on your car.
Slashdot Mirror
WRONG!
Nyquist's criterion is "You must have at least twice as many samples as the largest BANDWIDTH of the signal in order to correctly reconstruct it."
You can take a 10.7 MHz signal, and sample it at 10000 samples per second, and correctly reconstruct it, so long as the signal is guaranteed to be bandwidth limited to 10.7 MHz +/- 2.5 kHz. This is often done in software defined radio to aquire the signal from the intermediate frequency (IF) of the analog front end.
You also have to have an appropriate reconstruction filter at the output of the system in order to correctly recover the signal - if you don't have the right reconstruction filter, you will NOT reconstruct the signal correctly.
You also have to take into account the effects of any signal modulation - take a 20 kHz sine wave, and burst it for 10 msec, and you widen the bandwidth of the signal by about 100 Hz (depending upon the exact shape of the burst - a perfect square burst will widen the signal as a sinc function and will, in effect, increase the bandwidth to infinity, which is why square bursts are generally Considered Harmful in communications work).
Also, you don't oversample a signal in time to account for "rounding errors" - you oversample in time because the frequency response of sampling a system in time introduces a sinc response in frequency - by moving the sampling rate up you reduce the impact of this response on the recovered signal's frequency response. You also greately ease the requirements on the reconstruction filter - the filter can be wider (have fewer poles in the transfer function - thus fewer parts needed).
The biggest problem with backing up a live system is maintaining consistancy during the backup - a backup can take hours, and if the system is changing state during that time, you can have the last half of the backup being inconsistant with the first half.
/usr/a/foo and /usr/z/bar at the same time, but if /usr/a/foo gets backed up, then thirty minutes laster /usr/z/bar gets backed up, that is a thirty minute window in which a change can happen and render the backup invalid.
For example - you might have something that changes both
That is why I suggest, for any system where you cannot take it down to single user mode during the backup, you use LVM to create the filesystems, and leave a bit of extra, uncommitted space in the LVM logical group. Then, you can:
Take system down to single user mode.
Take an LVM snapshot of the volumes to be backed up.
Bring system back up to normal mode.
Mount snapshot (read only, of course).
Back up snapshot.
Release snapshot.
Even should the system change the state of the filesystem, LVM will keep the snapshot'ed state around, allowing it to be backed up with a minimum of fuss.
Well, at least the dumbing-down has already been done, so that's not an issue.
However, if the
It would be all Timothy and Michael, all the time.
And they "prove" they are "responsible" for the estate HOW? By being noted, by the court, as the executor of the estate.
Email is not the only thing that can have this happen - you can also have the same sort of problems with a bank safe deposit box.
If you have a safe deposit box in your name only, and you die, until the courts approve of your estate's executor, nobody will be able to get to the contents of that box - so think twice about putting anything in a safe deposit box that would be needed by your survivors within a month or less of your demise.
I wish the creators of DVD had required players to support converting from 24 frames per second non-interlaced to 60 fields per second interlaced on the fly, rather than the current standard of the movie being converted when the disk is mastered.
When I am watching a DVD on my computer, it is trivial for my monitor to switch to 72Hz refresh, and show each movie frame for 3 refreshes, rather than getting all the interlace artifacts. It would also have improved the compression of the DVD for a given quality.
There are some studies that link high cortisol levels (due to stress) with an increased chance of obesity.
Could it be simply that people who got enough sleep were less stressed?
Per the FSF "No GIFS" page, the reason they currently are against GIFS is the outstanding IBM patent.
Is that patent a member of the 500? And if so, will that be sufficent to change the status of GIFs, as well as the compress program?
Sounds like a great target for a virus - !nF3><0r somebody's machine, but give no sign other than scrolling a message across the moron's RAM:
D!5 DuMFu!< w@573d h!z $$$ 0n D!5 D!5Pl@Y !n573D 0f @ V!RU5 5c@nn3r! L@m3R!
No, a big L.
Modern games are multithreaded. Even if the game is not written to be - even if it does not use seperate threads for sound, rendering, NPC AI, and I/O - the rest of the system is running other threads (networking, interrupts, disk I/O) that are competing with the game for the CPU. A multi-CPU system can reduce that competition, allowing the system to service the NIC and hard disk IRQs while truly simultaniously servicing the game engine.
It's a pity somebody with your attention to detail couldn't be bothered to READ MY POST.
I am talking about the chip the main post is about. This is NOT a desktop chip. It is an embedded chip. Had you bothered to read ALL of my post, you might find these words familliar.
My reaction was to the breathless response by the story poster and by Cliff that *this chip* signaled the end of days - which it does not.
So, by blunting people's reation to the REAL threats, like those you point out, stories like this one cause people to be LESS likely to respond to the real threats, not more.
Bottom line: the chip THIS STORY is about is not a threat. Save your panic for the REAL threats - like what YOU listed.
... because this is nothing new.
First of all, this is an *EMBEDDED* processor, not an x86-class CPU. It may be used in PDAs and the like, but it is not going to be running your desktop anytime soon.
Secondly, embedded devices with encrypted onboard flash are nothing new - they've been around for years.
What about the "object oriented filesystem" that Microsoft was to release in Cairo, about 1996.
And had been rehashed in WinFS, now due Q42006.
Currently, there is much discussion about the meaning of the IBM sell-off of its PC division. One of the current conjectures is that IBM might be preparing to release a low-cost PowerPC based machine for home use.
Now, if that is the case, I could see IBM going to both ATI and nVidia and saying:
Now, the question is, how likely is this?
Not to worry - Microsoft will just release a service pack for it - that will make it stable.
Step 1: Print 8x10 picture of goatse
Step 2: paste onto stiff posterboard, add handle.
Step 3: Cut eyehole(s) as appropriate.
Step 4: Label back "Back - toward friendly"
Step 5: Hold in front of face while using kiosk.
If you go to a fireworks show where there are bleachers nearby, you can hear the same effect - as each retort goes off, you will hear a "fhweeep!" as the impulse from the report crosses the bleachers.
In effect, you are convolving an impulse (the report or hand-clap) with a series of impulses (the steps) to yield a series of impulses.
(and for other signal processing/math pedants out there - yes, a handclap only approximates an impulse, as do the stairs.)
...I was actually using that word alot lately (brushing up my English).
That would explain it, as Rendez-Vous is French. Rendez (To return, ) Vous (2nd-person formal).
I think you need to be committed.
Better still would be for needed services to make some form of command available to test whether they are up yet.
Then, should init script "foo" need "bar" running, then inside foo it could do something like:
if Wait_for_bar --max_wait 60; then foo init; else echo "ERROR" ; fi
Also, It Would Be Nice If init could capture stdout/stderr on all the init scripts, and in the cases of scripts that exit with a non-zero result (or don't exit after N seconds) show that script's output - so that running multiple scripts in parallel would not get the output streams confused.
The shift in the orbit of the spinner is small - the spinner is assumed to have much more mass than the cargo.
Usually, you will use the spinner to boost some other cargo going outward, so the net effect is zero.
Grabbing the spinner is easy - at the time you are grabbing it your relative motion is zero or pretty close to it.
Since when is pure oxygen lethal? It was used on the Apollo missions, it is used in hyperbaric chambers (at more than atmospheric pressure, I might add), and it is used by military pilots flying high-altitude aircraft to remove the nitrogen from their blood before they fly.
The only thing dangerous about pure oxygen is the fire risk - if that is why you consider it "lethal", then perhaps you might want to check the fuel tank on your car.
Funny how your sig contradicts your post....
whack.jobs
nut.jobs
outsourcing.jobs
rim.jobs