While I'm certainly game for doing this, I don't think anyone has the spare time to design one. Yes, this could be hacked together with an "expensive" PC in short order, but it'd be just that, "a hack" -- clunky, huge, expensive, and overly complicated for your average idiot.
Completely on the rumor side, I've heard the ReplayTV uses a Motorola Coldfire processor -- as do a great many set-top DVD players. Having played with the coldfire, it's a good choice for such a thing as long as you have hardware for encoding and decoding. The instant you add hardware MPEG encoding, you add a few zeros on to the price.
Personally, I think it's a bad idea to not have a firewire or other high speed communication port on the box. It'd be nice to be able to interface it with other hardware. But I'm sure "the industry" would shit solid gold bricks if one could copy the MPEG data off the TiVo onto, say, a DVD.
Your memory is correct; there are several VCRs with "commercial advance technology." It's patented, but I've never bothered to look it up.
My RCA VCR has this wonderful little feature. In four years or recording crapy, noisy and snowy broadcast TV, it's only gotten the commercial marking wrong a half dozen times. It's not simply looking for a "blank screen." It's watching for a lot of things... breaks in CC, changes in advisory data, changes in the VBI, as well as the commercial marker signals -- you'd be surprised how many stations "leak" those.
Why stick a computer on the mast? BreezeCom makes radio-to-ethernet boxes you can hang on the mast. Then it's just a matter of pulling 10bT to the computer up to 200m away.
I've used these things before and they work great. I bridged the ethernet between two buildings 4miles apart at 1Mb/s -- of course there was a long range directional antenna at both ends.
There are 486's in obit (periodically.) They get hit by much worse things and still function. As long as it's not grounded, lightening isn't a big problem -- you've obviously never seen a demonstration of a Farrade cage.
HOWEVER, I'm not suggesting one take a desktop PC and strap it to the mast. What you need is an industrial computer -- computers designed for environments where humans could not survive (for long.) Those things are not cheap.
The best (cheapest) bet is single board computer (SBC.) Maybe even one of the "computer on a SIMM" creatures assuming you can attach the wavelan to it, etc.
We've all had things lost, destroyed, or mis-delivered at some point in our lives. UPS is generally very open to re-delivering such packages (sometimes it's more fun to drive over to the golf course to get it yourself.) Common sense applies here... if _you_ have the item that was _supposed_ to go to someone else, then that someone else doesn't have what they ordered and will have to go through some amount of hassle to get a new one shipped.
My credit card company ate 250$ because of this once and I never did get my Millenium II AGP gfx card -- the supplier claims to have shipped it out twice, but never could give me a tracking number. (I don't do business with them anymore.)
1 - They're politicians:: "If you can be screwed, then you will be screwed." 2 - This from a state that taxes your tax refund. (look real close at the funky math based on your 1040.)
It gets worse... they worked out some "scale" for accounting for your tax burden based on income (how much of my tax money was wasted on that.) But then they want you to pay your 6% tax on purchases over 1000$ -- basically you've been taxed twice (or more.)
And sadly, NC will certainly waste billions of dollars enforcing this via audits and exact rediculous fines. Of course we're all gonna put zero in that blank even tho' 99% of us can tally the charges down to the penny -- most online stores keep user accessable records. The loop-hole: it's a "Sales and Use Tax"... while the "use" part applies, the "sales" part generally doesn't.
Basically, NC is turning private citizens into companies. Companies don't pay sales taxes on their purchases as they pay them directly to the state(s). That's whole reason for "Federal Tax ID Numbers".
So, what are the politicians going to waste this tax money on???
Where do you live? Grady, SC? (that's a Doc Hollywood ref. btw. -- that was actually filmed in SC.)
There's lots of jobs in the southeast. They will, of course, be clustered in and around major cities. How many jobs do you expect to exist "out in the sticks" where there generally are no computers?
I grew up in Shelby, NC (about 15 miles north actually.) The only jobs in demand in Cleveland county are farming and industrial jobs. There are (or were) several textile mills and food processing plants in the area -- not a lot of demand for highly skilled workers and even less for highly skilled computer workers.
I've lived in Raleigh, NC for the past decade. There's certainly no lack of demand for skilled workers around here. In fact, in the past six years, I've had four unsolicited job offers -- the last one tracked me down from a three year old email address (he was determined.) If you count the "quicky" consulting jobs, that number goes up alot.
Finding a job is easy. Finding a job you like that will keep you happy is the difficult part.
The world is full of paranoid pricks. Next you'll want to sue every web site owner for recording your IP address... what they are doing/have done is nothing more than a web server log to track and bill usage.
Mellow out before you have a stroke. Welcome to the modern world -- no one can hide forever.
Air planes are not Faraday cages. There two main reasons for not using cell phones in air planes. First, cell phones can emit a good bit of RF (usually in the mircowave range) that can interfere with the systems on the plane at such proximity. And second, once you're in the air, your phone can "see" dozens of towers and thus confuse the cell network -- plus, at cruise altitude (~35k ft) your phone will have to push out enough power to injure you.
For the record, I've talked to people on cell phones during take-off.:-) (I;m surprised GTE didn't have a cow when that phone locked on every tower in the county.)
As the AC posted, radio stations have an FCC license for broadcasting in a specific frequency range. ADSL is not a broadcast signal. It's a captive signal designed to flow down a copper wire. As such, ADSL doesn't have the signal immunity that all other (high frequency) broadcast technologies have. The radio (read: broadcast) spectrum is very hostle place. Being able to pick out a signal mixed in with all the other signals, both natural and man made, is far more difficult than tuning in a cable TV station or processing a wired ethernet signal.
For example, the WebGear Aviator wireless ethernet hardware (made by Raytheon) uses a 2.4GHz microwave "radio" to transmit a maximum of 1.5Mbps. The bit rate is over 100x slower than the transmitter signal rate. That's an amazing amount of "give" for interference given the relatively few devices "around the home" emmiting microwave freq. interference -- and no, your microwave oven isn't one of them; it's a slightly higher frequency centered on the molecular "vibration" of water molecules.
'-w filename' records "snaplen" bytes of the packet to a file (-r reads it back) Once it's recorded, you can look at it with what ever. You can also doctor tcpdump (rather easily) to dump the isprint()able part of the packet. (I've done this a few times over the years.)
It's still going to be a bit "selective". There are lots of recognized names in the Linux community, however there are thousands more that aren't recognized. I'm one of the later. Honestly, I don't know how many lines of linux kernel code I've written -- I've never bothered to count. I, like many, have worked with Linux for years; and I've speced VA hardware for several projects -- one has been using the same pair of PPro200 boxes for 3+ years.
Not knowing how VA has collected the names and/or e-mail addresses, it's possible some people get "passed over" 'cause they cannot be found. Do you know what my e-mail address is? (*grin* No, it's not foo@bar.com) Altho' I'm not entirely hidden -- someone looking for a Linux kernel programmer/instructor managed to locate me via old linux-kernel archives:-)
Personally, I'd be more willing to fork over my money to support VA than I would for RedHat. I just have an aversion to people making money off everyone elses work. (In fact, RedHat has a history of messing with the code for the stuff in their distribution(s) -- esp. the kernel.)
Read the contract you "signed" for the service. Most ISPs frown on that sort of thing -- of course, that doesn't mean it cannot be done. Most modern cable modem hardware doesn't decode stuff not destined to it (MAC address filtering.)
Once when I was in college, the head sysadmin (bone head) had set his IP address to be the broadcast address. He was somehow surprised when I told him the root passwords.
Exactly where did I say the bits are contiguous? In the case of DeepCrack, the section of the keyspace it works with is alot larger than anything the proxy network would (could at the time) generate. The usual (old) client works with 2^28 key blocks which means it can process 4 non-contiguous 2^28 blocks just fine. DeepCrack cannot do that. (The current clients can process 2^28 up to 2^32(?) blocks at once (as a single contiguous set of keys) and can request a block larger than 2^32.)
I never said "key++" == "key += 1" (of course, that depends on how you define "key".) For DES that's absolutely not true -- suffice it to say, it's much faster to skip some of the reversable initial steps and start partway into the cypher.
No matter how much math is behind the "++" operator, it all comes down to moving from one key to another. At least to the "core", that's usually simple addition (or subtraction.) If my CSC stepping is spanning the entire keyspace and your stepping is spanning the entire keyspace, then it could be hard to decide on what "half the keyspace" means -- esp. if both of us are already working on the same half. Dividing the keyspace only requires ONE BIT in common. Likewise, further division requires more bits.
(Note to reader: Nugget is not a "coder". He's said this himself on several occasions.)
Dcyhper.net doesn't need to release their code to coopereate with anyone else. One only needs to know what section of the keyspace (i.e. what keys) each will be processing. CSC may not be as forthcoming as a linear search of the DES keyspace, but there are still keys to be checked.
There were two problems with DeepCrack (read the board minutes where BovineOne explained the options.) First, DCTI processes both the key and the compliment of the key (neato DES optimization) while EFF processes only the key. So, for every DCTI "block" assigned to DeepCrack, it would have to test the keys in that block twice -- the key and the compliment of the key. Second, DeepCrack eats much larger chunks of the keyspace. If DeepCrack were handled as a regular client, it would need it's own key proxy -- DC needs contigous blocks larger than the proxy network could handle.
In the end, the keyspace was broken down into 32 sections. DeepCrack started at one end of the sub-space and the DCTI proxy network from the other end. I'm not certain how the keymaster figured into all this. I wrote a perl script for dbaker to tally the key rate from the proxy network and DeepCrack.
While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.
DCTI publishes only a fraction of the source code. The only part they let the general public see is the "cores" -- the part at the heart of the client doing the actual project/contest work. There's a boat load of other source code that comprises the network layer, the buffer handling, and (the part they must protect to the death) the block encryption. Out of the entire tree, only two files must be hidden from the public.
Again, I'm surprised this amazingly weak method of protection has held for soo long. As my dad says, "Locks are to keep the honest people out."
They're ALL software... just depends on where the software is running: on your SCSI card, or within the OS.
Most common hardware (controller) RAID systems have the same power-down problem as the software (OS) systems. As this is for a "startup", I don't think a 25k$ RAID array is needed (yet.)
DeepCrack can process DES information in a few days, but they spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.
Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donatedsomething, I'd say everyone is getting what they paid for *grin*
OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm and is coming along nicely.)
"normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti:-)
Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)
The Cosm source code is available via anonymous CVS -- every single line of it. I'd have NextStep 3.3 buildable if I had hardware old enough to run it:-) (All my x86 hardware is too new to be supported. And my friend's NeXT's hard drive burned up.) It's installed on a Sparc5 (w/16M or RAM mind you) in the office next to mine but I'm out of network connections:-(.
That's a fairly standard PPC for embeded uses. What did you think they put in there, a G3?
While I'm certainly game for doing this, I don't think anyone has the spare time to design one. Yes, this could be hacked together with an "expensive" PC in short order, but it'd be just that, "a hack" -- clunky, huge, expensive, and overly complicated for your average idiot.
Completely on the rumor side, I've heard the ReplayTV uses a Motorola Coldfire processor -- as do a great many set-top DVD players. Having played with the coldfire, it's a good choice for such a thing as long as you have hardware for encoding and decoding. The instant you add hardware MPEG encoding, you add a few zeros on to the price.
Personally, I think it's a bad idea to not have a firewire or other high speed communication port on the box. It'd be nice to be able to interface it with other hardware. But I'm sure "the industry" would shit solid gold bricks if one could copy the MPEG data off the TiVo onto, say, a DVD.
Your memory is correct; there are several VCRs with "commercial advance technology." It's patented, but I've never bothered to look it up.
My RCA VCR has this wonderful little feature. In four years or recording crapy, noisy and snowy broadcast TV, it's only gotten the commercial marking wrong a half dozen times. It's not simply looking for a "blank screen." It's watching for a lot of things... breaks in CC, changes in advisory data, changes in the VBI, as well as the commercial marker signals -- you'd be surprised how many stations "leak" those.
Why stick a computer on the mast? BreezeCom makes radio-to-ethernet boxes you can hang on the mast. Then it's just a matter of pulling 10bT to the computer up to 200m away.
I've used these things before and they work great. I bridged the ethernet between two buildings 4miles apart at 1Mb/s -- of course there was a long range directional antenna at both ends.
There are 486's in obit (periodically.) They get hit by much worse things and still function. As long as it's not grounded, lightening isn't a big problem -- you've obviously never seen a demonstration of a Farrade cage.
HOWEVER, I'm not suggesting one take a desktop PC and strap it to the mast. What you need is an industrial computer -- computers designed for environments where humans could not survive (for long.) Those things are not cheap.
The best (cheapest) bet is single board computer (SBC.) Maybe even one of the "computer on a SIMM" creatures assuming you can attach the wavelan to it, etc.
That was Snowball in a mechanical Bill Gates suit. He beat Brain to the punch... as I recall, that was one of the "Jimmy Brain" episodes.
:-)
I'll have to check my PnB archive
We've all had things lost, destroyed, or mis-delivered at some point in our lives. UPS is generally very open to re-delivering such packages (sometimes it's more fun to drive over to the golf course to get it yourself.) Common sense applies here... if _you_ have the item that was _supposed_ to go to someone else, then that someone else doesn't have what they ordered and will have to go through some amount of hassle to get a new one shipped.
My credit card company ate 250$ because of this once and I never did get my Millenium II AGP gfx card -- the supplier claims to have shipped it out twice, but never could give me a tracking number. (I don't do business with them anymore.)
aah aah aah, higher than the Pentagon's published annual budget...
This is not at all surprising...
:: "If you can be screwed, then you will be screwed."
1 - They're politicians
2 - This from a state that taxes your tax refund. (look real close at the funky math based on your 1040.)
It gets worse... they worked out some "scale" for accounting for your tax burden based on income (how much of my tax money was wasted on that.) But then they want you to pay your 6% tax on purchases over 1000$ -- basically you've been taxed twice (or more.)
And sadly, NC will certainly waste billions of dollars enforcing this via audits and exact rediculous fines. Of course we're all gonna put zero in that blank even tho' 99% of us can tally the charges down to the penny -- most online stores keep user accessable records. The loop-hole: it's a "Sales and Use Tax"... while the "use" part applies, the "sales" part generally doesn't.
Basically, NC is turning private citizens into companies. Companies don't pay sales taxes on their purchases as they pay them directly to the state(s). That's whole reason for "Federal Tax ID Numbers".
So, what are the politicians going to waste this tax money on???
Where do you live? Grady, SC? (that's a Doc Hollywood ref. btw. -- that was actually filmed in SC.)
There's lots of jobs in the southeast. They will, of course, be clustered in and around major cities. How many jobs do you expect to exist "out in the sticks" where there generally are no computers?
I grew up in Shelby, NC (about 15 miles north actually.) The only jobs in demand in Cleveland county are farming and industrial jobs. There are (or were) several textile mills and food processing plants in the area -- not a lot of demand for highly skilled workers and even less for highly skilled computer workers.
I've lived in Raleigh, NC for the past decade. There's certainly no lack of demand for skilled workers around here. In fact, in the past six years, I've had four unsolicited job offers -- the last one tracked me down from a three year old email address (he was determined.) If you count the "quicky" consulting jobs, that number goes up alot.
Finding a job is easy. Finding a job you like that will keep you happy is the difficult part.
In a word, "NO"
The world is full of paranoid pricks. Next you'll want to sue every web site owner for recording your IP address... what they are doing/have done is nothing more than a web server log to track and bill usage.
Mellow out before you have a stroke. Welcome to the modern world -- no one can hide forever.
Air planes are not Faraday cages. There two main reasons for not using cell phones in air planes. First, cell phones can emit a good bit of RF (usually in the mircowave range) that can interfere with the systems on the plane at such proximity. And second, once you're in the air, your phone can "see" dozens of towers and thus confuse the cell network -- plus, at cruise altitude (~35k ft) your phone will have to push out enough power to injure you.
:-) (I;m surprised GTE didn't have a cow when that phone locked on every tower in the county.)
For the record, I've talked to people on cell phones during take-off.
As the AC posted, radio stations have an FCC license for broadcasting in a specific frequency range. ADSL is not a broadcast signal. It's a captive signal designed to flow down a copper wire. As such, ADSL doesn't have the signal immunity that all other (high frequency) broadcast technologies have. The radio (read: broadcast) spectrum is very hostle place. Being able to pick out a signal mixed in with all the other signals, both natural and man made, is far more difficult than tuning in a cable TV station or processing a wired ethernet signal.
For example, the WebGear Aviator wireless ethernet hardware (made by Raytheon) uses a 2.4GHz microwave "radio" to transmit a maximum of 1.5Mbps. The bit rate is over 100x slower than the transmitter signal rate. That's an amazing amount of "give" for interference given the relatively few devices "around the home" emmiting microwave freq. interference -- and no, your microwave oven isn't one of them; it's a slightly higher frequency centered on the molecular "vibration" of water molecules.
Read the manpage (if you dare :-))
'-w filename' records "snaplen" bytes of the packet to a file (-r reads it back) Once it's recorded, you can look at it with what ever. You can also doctor tcpdump (rather easily) to dump the isprint()able part of the packet. (I've done this a few times over the years.)
It's still going to be a bit "selective". There are lots of recognized names in the Linux community, however there are thousands more that aren't recognized. I'm one of the later.
:-)
Honestly, I don't know how many lines of linux kernel code I've written -- I've never bothered to count. I, like many, have worked with Linux for years; and I've speced VA hardware for several projects -- one has been using the same pair of PPro200 boxes for 3+ years.
Not knowing how VA has collected the names and/or e-mail addresses, it's possible some people get "passed over" 'cause they cannot be found. Do you know what my e-mail address is? (*grin* No, it's not foo@bar.com) Altho' I'm not entirely hidden -- someone looking for a Linux kernel programmer/instructor managed to locate me via old linux-kernel archives
Personally, I'd be more willing to fork over my money to support VA than I would for RedHat. I just have an aversion to people making money off everyone elses work. (In fact, RedHat has a history of messing with the code for the stuff in their distribution(s) -- esp. the kernel.)
Translation: We didn't get any new information from trapping their email that we didn't already have from agressive web proxying.
Read the contract you "signed" for the service. Most ISPs frown on that sort of thing -- of course, that doesn't mean it cannot be done. Most modern cable modem hardware doesn't decode stuff not destined to it (MAC address filtering.)
Once when I was in college, the head sysadmin (bone head) had set his IP address to be the broadcast address. He was somehow surprised when I told him the root passwords.
Exactly where did I say the bits are contiguous? In the case of DeepCrack, the section of the keyspace it works with is alot larger than anything the proxy network would (could at the time) generate. The usual (old) client works with 2^28 key blocks which means it can process 4 non-contiguous 2^28 blocks just fine. DeepCrack cannot do that. (The current clients can process 2^28 up to 2^32(?) blocks at once (as a single contiguous set of keys) and can request a block larger than 2^32.)
I never said "key++" == "key += 1" (of course, that depends on how you define "key".) For DES that's absolutely not true -- suffice it to say, it's much faster to skip some of the reversable initial steps and start partway into the cypher.
No matter how much math is behind the "++" operator, it all comes down to moving from one key to another. At least to the "core", that's usually simple addition (or subtraction.) If my CSC stepping is spanning the entire keyspace and your stepping is spanning the entire keyspace, then it could be hard to decide on what "half the keyspace" means -- esp. if both of us are already working on the same half. Dividing the keyspace only requires ONE BIT in common. Likewise, further division requires more bits.
(PS: Login you bloody git.)
(Note to Nugget: no one listens to AC's)
(Note to reader: Nugget is not a "coder". He's said this himself on several occasions.)
Dcyhper.net doesn't need to release their code to coopereate with anyone else. One only needs to know what section of the keyspace (i.e. what keys) each will be processing. CSC may not be as forthcoming as a linear search of the DES keyspace, but there are still keys to be checked.
There were two problems with DeepCrack (read the board minutes where BovineOne explained the options.) First, DCTI processes both the key and the compliment of the key (neato DES optimization) while EFF processes only the key. So, for every DCTI "block" assigned to DeepCrack, it would have to test the keys in that block twice -- the key and the compliment of the key. Second, DeepCrack eats much larger chunks of the keyspace. If DeepCrack were handled as a regular client, it would need it's own key proxy -- DC needs contigous blocks larger than the proxy network could handle.
In the end, the keyspace was broken down into 32 sections. DeepCrack started at one end of the sub-space and the DCTI proxy network from the other end. I'm not certain how the keymaster figured into all this. I wrote a perl script for dbaker to tally the key rate from the proxy network and DeepCrack.
While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.
DCTI publishes only a fraction of the source code. The only part they let the general public see is the "cores" -- the part at the heart of the client doing the actual project/contest work. There's a boat load of other source code that comprises the network layer, the buffer handling, and (the part they must protect to the death) the block encryption. Out of the entire tree, only two files must be hidden from the public.
Again, I'm surprised this amazingly weak method of protection has held for soo long. As my dad says, "Locks are to keep the honest people out."
Actually, I think some city planners could benefit from playing SimCity -- at least once!
:-)
Of course, I'm the kind of geek who'd be perfectly happy in a space station with no windows -- or even Chyeanne(sp) mountain
They're ALL software... just depends on where the software is running: on your SCSI card, or within the OS.
Most common hardware (controller) RAID systems have the same power-down problem as the software (OS) systems. As this is for a "startup", I don't think a 25k$ RAID array is needed (yet.)
DeepCrack can process DES information in a few days, but they spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.
:-)
Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donated something, I'd say everyone is getting what they paid for *grin*
OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm and is coming along nicely.)
"normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti
Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)
Simple public key cryptography and "blessed" clients. This method has worked for over a decade with other software.
See also: Cosm
:-) (All my x86 hardware is too new to be supported. And my friend's NeXT's hard drive burned up.) It's installed on a Sparc5 (w/16M or RAM mind you) in the office next to mine but I'm out of network connections :-(.
The Cosm source code is available via anonymous CVS -- every single line of it. I'd have NextStep 3.3 buildable if I had hardware old enough to run it
You're welcome to assist with code development, porting, or just watching us go...