A diesel engine has no torque at 0 rpm (that's why an electric motor is used to start it, and why it idles)
An electric motor typically has maximum torque at 0 rpm - coils can reach their full field strength and waste no time (due to inductance, di/dt=V/L) switching the current in them.
And all this time I thought that this was the definitive guide. Silly me. It's cool that 802 standards (which usually cost big bucks) are now available for a free download once they've been in print for 6 months. Way to go, IEEE! Now, if we can just convince ANSI to do the same... See also the main 802.11 homepage
It doesn't really have anything to do with what type of program it is....even single player games would be affected. it's simply an infectable executable that was run.
> I shouldn't have to run external programs to play games online.
So you won't run the wolfenstein demo? Or even the full install from the CD? If you would, then you could theoritically get a virus (no, not starting any rumors here). You do understand that you're limiting yourself to games that run solely from the browser and even then, there's no guarantee that you won't get malware.
Damn. It took me longer to get around the lameness filter than it did to find the code. What the point of the "code" selection on the comment form when all it does is change the font?
And the funny thing - when I added the above paragraph to the post, it didn't pass the compression test -- but all that repetition I used did pass, and adding the above useful paragraph should have made it better... oh well...
Compiled under turbo c circa 3/97. As you can see, I've got one wire powering the 1820, and another for the data. I think I'm using the parallel port's open collector output with a built-in pull-up resistor, as required by the DS1820.
The us_delay function is a hacked-up form of the built-in turbo c library tick_delay function - I'm not sure if it's still copyrighted, so I didn't include it. It may not be that useful because it was custom-tuned to my 486. Yep, I had an oscilliscope available to do the tuning, but there are otherways to tune the loop.
lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away)
So, for 5 volts over a 10k thermister, you get 0.0025W. Over a 100k resistor, you'll get 0.00025W. Hardly enough to toast any parts, but ideally you want no self-heating (which means power=0).
But, as long as you're not measuring the ambient temperature in the middle of a block of styrofoam, you won't really need to worry about selfheating - if you're in a good airflow or well connected to a mass of metal, any extra selfheating power will be disipated - there's not much temperature difference between a processor operating at 10 W and 10.00025 W.
The most extreme, fun way is to use pyrometric cones - just wait for these cones to droop and move the joystick, and you'll find out the temperature! Here's how to use the cones when upgrading the wiring of your computer.
Dallas has a demo application you can use as an example - a weather station and some good application note examples. It uses the DS1820 or the DS18S20 and you can get up to 2 free samples of each. This device is digital, so no calibration is needed for the accuracy you need. They have a lot of other temperature sensors; some even have alarm outputs, so once you program it, reading only one bit will tell you if the temperature is out of limits. It has a well-written and complete datasheet. They've got software for win32, linux, beos, java, and 8051. If you write your own software or modifiy theirs, you don't really need a serial port adapter; just a wire on the parallel port will do (and it will power the device, too!!)
If anyone's interested, I can dig up some c-code that I used - it works with the parallel port under dos.
Re:In all seriousness, random libs *suck*
on
Pet Bugs?
·
· Score: 2
I was debugging a vender's fibre channel driver, supplied of course, as just a binary file and a few hook-like functions I could modify. I got a filesystem working over the fibre channel/SCSI, but using their functions, the individual block read/write test didn't quite work... the first 3 bytes were always wrong. I called the company, and they said, yeah, the first 3 bytes were always wrong, it's close enough.
I did a little more investigation and looked at their self-made pseudorandom number generator. It produced numbers like this: 35, 84, 17, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3...
They were never returning any data - it mostly matched because the first block written looked just like the last one. I still don't know how or why the filesystem worked on it (even though it was calling the same basic functions)...
Traditional CD's (like when used for music) are constant linear velocity. CDROM players vary, but can be constant angular velocity - this means that they don't have to change speed of the disc when accessing different areas (which takes some time to do), but also means that the linear speed (proportional to data transfer rate) varies between the inside and outside. That's why drives are labeled as "max ##x" - that's the transfer rate at the outside; at the same CAV, the transfer rate will be less at the inner grooves.
I was just going for a ballpark number, so it's still a good estimate. As a side note, I'm not so sure that this could have been done purely in software with a traditional drive.
First, there's the position synchronization issue -- there's no way to reference what angle of the CD you're writing to. And since CDs vary in their pitch, either intentionally (the main difference between 74 and 80 minute CDs) and accidently, you couldn't reliably precalculate where along the linear track to burn.
The other issue is actual control of the laser. Since recording is done by varying the pit lengths (or something like that), there is always a burn mark and the the only variation that your data causes to this is at a microscopic level.
Uh, they use relatively high-power lasers in fibre optics to achieve gigabit speeds easily. It's not that hard - usually diodes are driven with a constant-current source, and a fast-switching FET is used to short out the diode to turn it off. The power supply isn't shorted because the constant-current source limits the amount of current the circuit can draw.
Let's do some math: CD players turn at 1.2-1.4 m/s Constant Angular Velocity. To get 250 dpi at that speed (1X), each dot is 78 uSec, or about 12,800 dots/second. Gigabit speeds are literally a million times faster.
I'm not so sure that the laser is actually burning through the reflective backing, though - it looks like the pattern is only visible on the underside data area - just like you can see the difference between burnt and unburnt data.
Re:Yeah, we think highly of foreigners here.
on
Greenbacks No More
·
· Score: 1
Synaptics has a new touchpad for notebooks called the cPad. It has a B&W LCD under a (mostly) clear touchpad that can be used as a secondary display. It has it's own API, and looks pretty neat - it saves valuable screen space and I hope I could move the task bar down there. I've only seen it on the Toshiba Satellite 5100 series, but I'm sure Synaptics is agressively marketing it to other laptop manufacturers.
Re:Yeah, we think highly of foreigners here.
on
Greenbacks No More
·
· Score: 2
Well, let's take the disney land analogy that another poster used. Would I sue Disney if I were riding the Snow White ride and got run over by oncoming traffic, I think most people would think I could sue.
But it's an analogy that is just as silly as the ford one - it all comes down to what the customer expectations are for the product and how they jive with what Microsoft is willing to provide.
Microsoft requires users to dial into their servers -- not servers owned by the game's publisher. This is a big sticking point with some of the software companies because it violates the "don't let anyone get between you and your customers" rule of business. Since it's microsoft-certified software, microsoft hardware, and a microsoft network, you'd think you were in a safe area. But, microsoft can't control everything (even its own employees), so there could be problems. This disclaimer (at the risk of making another silly analogy) is like McDonalds saying "we're not responsible if we spit in your food and you get sick".
Section E of the warranty (page 18) says "Exclusions from limited warranty. This limited warranty shall not apply and Microsoft has no liability... if the Xbox Product:"... (section E5) "is damaged by programs, data, viruses, or files, or during shipments"
Not that you'd ever get one with the military grade security, but it's reassuring that Microsoft has no responsibility to do anything...
You don't even need logic gates -- if you've got two or more (100's of) switches, you can put them in parallel (Normally open contact switches) or series (Normally closed) and any one of them will trigger the alarm.
The only reason to add logic would be to latch an intrusion during power-off. But, I suspect that the motherboard already does that (could be wrong-that's the obvious question he should have answered).
> But even that has blackout points in the house, where construction or atmospheric conditions make it impossible to get a solid signal
Your house is so big that it has its own atmospheric conditions?? Like, if it's raining in the living room, you can always move to the family room where it's still sunny?
Actually, there's a simpler device that satisfies local peer-to-peer calls (at least my experience with WiFi range). It's been adapted to long range communications, but I prefer this neat hack is a bit more portable.
That would be correct if the current consumed was proportional to the RF power emitted, but that's not quite right. Even at low powers, you still have to power up the oscillators, filters, mixers, and the baseband processing. You also lose the benefit of a super-duper receivers in the tower that allow them to be exceptionally sensitive and use less TX power (unless you enjoy carrying around one of these)
Isn't bounds checking just a specialized case for checking any type of access to uninitialized memory?
That's a good chunk of it, but there are several cases of acces to initialized (and alloc'ed memory) that should also be detected:
- pointers to stale memory. Example: malloc, initialize, free, malloc again and get some reused memory that was left initialized before the free, and then attempted use of that data. (calloc zeros the memory, malloc doesn't)
- pointers exceeding array bounds. Example: int x[100][100], reading array element x[10][150] doesn't cause a segfault (but x[150][10] does)
- unexpected pointer alias (devious and borders between just a regular bug and a bounds-checkable bug). The function doesn't expect the two pointers passed to it to point to the same area of memory (example memcpy pointers can't overlap, memmove pointer can). Incidently, this assumption is usually a toggleable (& dangerous if you're not careful) optimization and can cause the compiler to generate 'bad' code - more limited languages (eg. Fortran 77, but not Fortran 90) that don't have pointers can be more agressively optimized! when I've got a function that could choke on this kind of thing, I usually code in a bunch of asserts to check for this case and raise a flag.
It's nice software (source) and a beautiful hack (a compliment), but it has a fundamental flaw that limits its use in some applications (like mine at the time)...
Something in my program was modifying free'd memory. To detect this, efence doesn't really free the memory (EF_PROTECT_FREE), which makes it consume a huge amount of space. Especially if your program does a lot of memory allocating and freeing, like mine did, the system runs out of memory and swaps until the cows come home.
I finally found my problem by changing my frees to clear the memory before actually freeing it - then my usual sanity checks would find the bad pointer.
WHAT'S BETTER -- PURIFY, from Purify Systems, does a much better job than Electric Fence, and does much more. It's available at this writing on SPARC and HP. I'm not affiliated with Purify, I just think it's a wonderful product and you should check it out.
There was a guy in washington, DC. that tried to use a strobe light on his balcony so that filming couldn't occur outside (not on his property). He had no beef with anyone - he just wanted money; he also hung a "Remember the Valdez" sign on his balcony overlooking an Exxon - again, just to semi-extort money.
Slashdot Mirror
Here's a quick way of looking at it--
A diesel engine has no torque at 0 rpm (that's why an electric motor is used to start it, and why it idles)
An electric motor typically has maximum torque at 0 rpm - coils can reach their full field strength and waste no time (due to inductance, di/dt=V/L) switching the current in them.
And all this time I thought that this was the definitive guide. Silly me. It's cool that 802 standards (which usually cost big bucks) are now available for a free download once they've been in print for 6 months. Way to go, IEEE! Now, if we can just convince ANSI to do the same... See also the main 802.11 homepage
All the pictures are included in this pdf mirror: http://www.mirrors.wiretapped.net/security/info/pa pers/networking/strange-attractors-and-tcpip-seque nce-number-analysis.pdf [1MB].
It doesn't display correctly with my version of KDE's PS/PDF Viewer, but good old ghostview works great.
It doesn't really have anything to do with what type of program it is....even single player games would be affected. it's simply an infectable executable that was run.
> I shouldn't have to run external programs to play games online.
So you won't run the wolfenstein demo? Or even the full install from the CD? If you would, then you could theoritically get a virus (no, not starting any rumors here). You do understand that you're limiting yourself to games that run solely from the browser and even then, there's no guarantee that you won't get malware.
No, I'm holding out for more. When they start selling stuffed nobel prize owners, then I'll pull out my wallet.
Damn. It took me longer to get around the lameness filter than it did to find the code. What the point of the "code" selection on the comment form when all it does is change the font?
And the funny thing - when I added the above paragraph to the post, it didn't pass the compression test -- but all that repetition I used did pass, and adding the above useful paragraph should have made it better... oh well...
Compiled under turbo c circa 3/97. As you can see, I've got one wire powering the 1820, and another for the data. I think I'm using the parallel port's open collector output with a built-in pull-up resistor, as required by the DS1820.
// LPT1
.
// interrupts off // reset pulse // look for ack... // wait min time
// LSB first // interrupts off // send a 1 // // send a 0 // lameness filter fix // lameness filter fix
// LSB first
// interrupts off
// allow powerup // if conv. done
The us_delay function is a hacked-up form of the built-in turbo c library tick_delay function - I'm not sure if it's still copyrighted, so I didn't include it. It may not be that useful because it was custom-tuned to my 486. Yep, I had an oscilliscope available to do the tuning, but there are otherways to tune the loop.
---- file test1821.c
#include <stdio.h>
#include <dos.h>
#include <conio.h>
#include "usdelay.h"
unsigned char outport1=0, outport2=0x0A;
#define lptbase 0x378
// for DS1821
#define DQ_hi() {outport2&=0xF7; outp(lptbase+2,outport2);}
#define DQ_lo() {outport2|=0x08; outp(lptbase+2,outport2);}
#define DQ_in() ((inportb(lptbase+2)&0x08)^0x08)
#define DS1821off() {outport1&=0xFB; outp(lptbase,outport1);}
#define DS1821on() {outport1|=0x04; outp(lptbase,outport1);}
// 1= no presence detect, 0=presence detected
unsigned char reset_onewire(void)
{ unsigned char alone;
disable();
DQ_lo();
us_delay(750);
DQ_hi();
us_delay(100);
alone=DQ_in();
us_delay(380);
enable();
return alone ? 1 : 0;
} / / lameness filter fix
void sendbyte_onewire(unsigned char byte)
{ unsigned char mask=1;
disable();
while (mask)
{ if (mask & byte)
{ DQ_lo();
us_delay(1);
DQ_hi();
us_delay(60);
}
else
{ DQ_lo();
us_delay(60);
DQ_hi();
us_delay(1);
}
mask <<= 1;
}
enable();
} / / lameness filter fix
unsigned char getbyte_onewire(void)
{ unsigned char byte=0;
unsigned char mask=1;
unsigned char bit;
disable();
while (mask)
{ DQ_lo();
us_delay(1);
DQ_hi();
us_delay(12);
bit=DQ_in();
us_delay(45);
if (bit)
byte |= mask;
mask <<= 1;
}
enable();
return byte;
} / / lameness filter fix
unsigned char read_1821(unsigned char cmd)
{ reset_onewire();
sendbyte_onewire(cmd);
return getbyte_onewire();
} / / lameness filter fix
void cmd_1821(unsigned char cmd)
{ reset_onewire();
sendbyte_onewire(cmd);
} / / lameness filter fix
#define readstatus_1821() read_1821(0xAC)
#define readTH_1821() read_1821(0xA1)
#define readTL_1821() read_1821(0xA2)
#define readtemp_1821() read_1821(0xAA)
#define start_1821() cmd_1821(0xEE)
#define stop_1821() cmd_1821(0x22)
void main()
{ int i;
unsigned char s;
printf ("=== DS1821 test ===\n");
DS1821on();
DQ_hi();
delay(100);
i=reset_onewire();
if (i)
printf ("No one-wire devices detected.\n");
else
{ printf ("ALONE=%d\n", i);
printf ("STATUS=0x%02x\n", (unsigned int) readstatus_1821());
i=(int) (char) readTH_1821();
printf (" TH= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
i=(int) (char) readTL_1821();
printf (" TL= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
i=(int) (char) readtemp_1821();
printf ("temp= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
start_1821();
getch();
printf ("STATUS=0x%02x\n", (unsigned int) readstatus_1821());
i=(int) (char) readTH_1821();
printf (" TH= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
i=(int) (char) readTL_1821();
printf (" TL= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
i=(int) (char) readtemp_1821();
printf ("temp= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
while (!kbhit())
{ if ((s=readstatus_1821()) & 0x80)
{ i=(int) (char) readtemp_1821();
printf ("temp= %6.1føC,%6.1føF\n", i*1.0, i*1.8+32.0);
start_1821();
}
}
getch();
}
getch();
DQ_lo();
DS1821off();
} / / lameness filter fix
lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away)
lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away) lamenessfilter doesn't like posts with too few characters per inch. I guess they like obtuse perl programs instead of nicer c programs (flame away)
P=E^2/R
So, for 5 volts over a 10k thermister, you get 0.0025W. Over a 100k resistor, you'll get 0.00025W. Hardly enough to toast any parts, but ideally you want no self-heating (which means power=0).
But, as long as you're not measuring the ambient temperature in the middle of a block of styrofoam, you won't really need to worry about selfheating - if you're in a good airflow or well connected to a mass of metal, any extra selfheating power will be disipated - there's not much temperature difference between a processor operating at 10 W and 10.00025 W.
The most extreme, fun way is to use pyrometric cones - just wait for these cones to droop and move the joystick, and you'll find out the temperature! Here's how to use the cones when upgrading the wiring of your computer.
A much more practical way is to use the Dallas Semiconductor (now bought by Maxim, and not the magazine)
Dallas has a demo application you can use as an example - a weather station and some good application note examples. It uses the DS1820 or the DS18S20 and you can get up to 2 free samples of each. This device is digital, so no calibration is needed for the accuracy you need. They have a lot of other temperature sensors; some even have alarm outputs, so once you program it, reading only one bit will tell you if the temperature is out of limits. It has a well-written and complete datasheet. They've got software for win32, linux, beos, java, and 8051. If you write your own software or modifiy theirs, you don't really need a serial port adapter; just a wire on the parallel port will do (and it will power the device, too!!)
If anyone's interested, I can dig up some c-code that I used - it works with the parallel port under dos.
For those who are curious, here's the sega ruling. It's good reading.
I was debugging a vender's fibre channel driver, supplied of course, as just a binary file and a few hook-like functions I could modify. I got a filesystem working over the fibre channel/SCSI, but using their functions, the individual block read/write test didn't quite work... the first 3 bytes were always wrong. I called the company, and they said, yeah, the first 3 bytes were always wrong, it's close enough.
...
I did a little more investigation and looked at their self-made pseudorandom number generator. It produced numbers like this:
35, 84, 17, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3
They were never returning any data - it mostly matched because the first block written looked just like the last one. I still don't know how or why the filesystem worked on it (even though it was calling the same basic functions)...
Whoops. My mistake - thanks for catching that.
Traditional CD's (like when used for music) are constant linear velocity. CDROM players vary, but can be constant angular velocity - this means that they don't have to change speed of the disc when accessing different areas (which takes some time to do), but also means that the linear speed (proportional to data transfer rate) varies between the inside and outside. That's why drives are labeled as "max ##x" - that's the transfer rate at the outside; at the same CAV, the transfer rate will be less at the inner grooves.
I was just going for a ballpark number, so it's still a good estimate. As a side note, I'm not so sure that this could have been done purely in software with a traditional drive.
First, there's the position synchronization issue -- there's no way to reference what angle of the CD you're writing to. And since CDs vary in their pitch, either intentionally (the main difference between 74 and 80 minute CDs) and accidently, you couldn't reliably precalculate where along the linear track to burn.
The other issue is actual control of the laser. Since recording is done by varying the pit lengths (or something like that), there is always a burn mark and the the only variation that your data causes to this is at a microscopic level.
Uh, they use relatively high-power lasers in fibre optics to achieve gigabit speeds easily. It's not that hard - usually diodes are driven with a constant-current source, and a fast-switching FET is used to short out the diode to turn it off. The power supply isn't shorted because the constant-current source limits the amount of current the circuit can draw.
Let's do some math: CD players turn at 1.2-1.4 m/s Constant Angular Velocity. To get 250 dpi at that speed (1X), each dot is 78 uSec, or about 12,800 dots/second. Gigabit speeds are literally a million times faster.
I'm not so sure that the laser is actually burning through the reflective backing, though - it looks like the pattern is only visible on the underside data area - just like you can see the difference between burnt and unburnt data.
only on the black-black-black bills.
Synaptics has a new touchpad for notebooks called the cPad. It has a B&W LCD under a (mostly) clear touchpad that can be used as a secondary display. It has it's own API, and looks pretty neat - it saves valuable screen space and I hope I could move the task bar down there. I've only seen it on the Toshiba Satellite 5100 series, but I'm sure Synaptics is agressively marketing it to other laptop manufacturers.
or just use the other standard color code...
$1 brown-black-gold
5 green-black-gold
10 brown-black-black
20 red-black-black
50 green-black-black
100 brown-black-brown
500 green-black-brown
nah, scratch that. I like yours better.
Well, let's take the disney land analogy that another poster used. Would I sue Disney if I were riding the Snow White ride and got run over by oncoming traffic, I think most people would think I could sue.
But it's an analogy that is just as silly as the ford one - it all comes down to what the customer expectations are for the product and how they jive with what Microsoft is willing to provide.
Microsoft requires users to dial into their servers -- not servers owned by the game's publisher. This is a big sticking point with some of the software companies because it violates the "don't let anyone get between you and your customers" rule of business. Since it's microsoft-certified software, microsoft hardware, and a microsoft network, you'd think you were in a safe area. But, microsoft can't control everything (even its own employees), so there could be problems. This disclaimer (at the risk of making another silly analogy) is like McDonalds saying "we're not responsible if we spit in your food and you get sick".
click here if the snow white link expired
Section E of the warranty (page 18) says "Exclusions from limited warranty. This limited warranty shall not apply and Microsoft has no liability ... if the Xbox Product:" ... (section E5) "is damaged by programs, data, viruses, or files, or during shipments"
Not that you'd ever get one with the military grade security, but it's reassuring that Microsoft has no responsibility to do anything...
You don't even need logic gates -- if you've got two or more (100's of) switches, you can put them in parallel (Normally open contact switches) or series (Normally closed) and any one of them will trigger the alarm.
The only reason to add logic would be to latch an intrusion during power-off. But, I suspect that the motherboard already does that (could be wrong-that's the obvious question he should have answered).
> But even that has blackout points in the house, where construction or atmospheric conditions make it impossible to get a solid signal
Your house is so big that it has its own atmospheric conditions?? Like, if it's raining in the living room, you can always move to the family room where it's still sunny?
Actually, there's a simpler device that satisfies local peer-to-peer calls (at least my experience with WiFi range). It's been adapted to long range communications, but I prefer this neat hack is a bit more portable.
That would be correct if the current consumed was proportional to the RF power emitted, but that's not quite right. Even at low powers, you still have to power up the oscillators, filters, mixers, and the baseband processing. You also lose the benefit of a super-duper receivers in the tower that allow them to be exceptionally sensitive and use less TX power (unless you enjoy carrying around one of these)
Isn't bounds checking just a specialized case for checking any type of access to uninitialized memory?
That's a good chunk of it, but there are several cases of acces to initialized (and alloc'ed memory) that should also be detected:
- pointers to stale memory. Example: malloc, initialize, free, malloc again and get some reused memory that was left initialized before the free, and then attempted use of that data. (calloc zeros the memory, malloc doesn't)
- pointers exceeding array bounds. Example: int x[100][100], reading array element x[10][150] doesn't cause a segfault (but x[150][10] does)
- unexpected pointer alias (devious and borders between just a regular bug and a bounds-checkable bug). The function doesn't expect the two pointers passed to it to point to the same area of memory (example memcpy pointers can't overlap, memmove pointer can). Incidently, this assumption is usually a toggleable (& dangerous if you're not careful) optimization and can cause the compiler to generate 'bad' code - more limited languages (eg. Fortran 77, but not Fortran 90) that don't have pointers can be more agressively optimized! when I've got a function that could choke on this kind of thing, I usually code in a bunch of asserts to check for this case and raise a flag.
Something in my program was modifying free'd memory. To detect this, efence doesn't really free the memory (EF_PROTECT_FREE), which makes it consume a huge amount of space. Especially if your program does a lot of memory allocating and freeing, like mine did, the system runs out of memory and swaps until the cows come home.
I finally found my problem by changing my frees to clear the memory before actually freeing it - then my usual sanity checks would find the bad pointer.
from the manpage:
There was a guy in washington, DC. that tried to use a strobe light on his balcony so that filming couldn't occur outside (not on his property). He had no beef with anyone - he just wanted money; he also hung a "Remember the Valdez" sign on his balcony overlooking an Exxon - again, just to semi-extort money.