... "You had an assembler? Man! In my day, we entered code in by hand, and not with those wimpy hex keypads, WE set switches in binary and toggled the deposit or deposit next switch."
Anyway cold spots or cold bursts seem pretty common when most people experience ghosts or strange events. Was your apartment real cold before the even took place?
Dunno, I was just waking up and saw the damn thing move (or thought I did). I did feel chills down my spine seeing this, but I attribute that to fear of the unknown. After checking for the depressions in the carpet, I got dressed, left to grab a bite to eat (and settle my nerves), and came back about an hour later. There were no other events in that apartment before or after.
I had one other experience in a new house we had just bought, hearing what sounded like hammering. Even though no one was running water (pipes making noise), I could not explain it. Though, there are so many plausable explanations I don't consider it "freaky". I have heard and investigated strange noises before (ever hear a house settle?) so they tend to not suggest themselves as anything other than natural.
Building settling? It would have to settle a hell of a lot to overcome the coefficient of static friction between the bike tires and carpet and handlebar and wall (that it leaned against). I dunno either. It's got me stumped.
Oh this was a doozy to fix. Well, finding it was tough too, but only because management wouldn't let us do a proper root cause analysis until it was way too late, chosing instead, to "tweak things, take carefull measurements, and see what improves things". Of course, by the time the go-ahead was given to do the root cause analysis, customer was royally pissed, and we were given little time.
Basically, we had this distributed test system with embedded test controllers in about 1500 locations, nation-wide (no, not in North America, but it was still a fairly big country). There was a central location with master controllers managing the whole thing. And there was a networking bug.
Like many embeded systems, this one had a feature which would permit downloading new operating code to it. And, while normal operation worked fine, most of the time we downloaded new code the remote units would lock up and the watchdog would reboot them (to the original operating code). Now, software download testing done in our labs with PCs basically FTPing code to the units worked fine. Software download with the Solaris-based "real" master controllers worked fine. Software download in the field didn't. For some reason, the PC-based testing was done at the same data-rates as under field conditions, but the Solaris-based testing wasn't (go figure). And there lay the key.
See, for some reason, the Solaris networking stack would try to initialize the TCP round-trip timer based on sending a single byte on a newly opened socket and adjust it from there. This was fine when sending short (i.e. "normal" command and control") packets. But software download rammed long packets down the pipe. So, the RTT was set based on the ACK of a single byte, and then the next transmission involves about 1500 bytes... at 9600 bps. You guessed it, TCP timeout and retry. See, the Solaris stack was dumb, it didn't know that the last byte hadn't been sent yet before starting it's ACK timer... Of course the fact that we had a virtual device tunnelling all this traffic encapsulated in PPP frames over an X.25 circuit and locally accepting whole IP frames in one gulp didn't help... the poor Solaris TCP/IP stack got SOOO confused.
So, anyway, here's Solaris sending duplicate packets in fits and starts, and here's our box receiving them and throwing most of them away. To accomodate the slow datarate and long packets, a rather large TCP window was used, which just made things worse... Solaris would send a single byte of payload, initialize it's TCP RTT, and then squeeze off a window of data in several packets. These would time out... Solaris would repeat... But wait, it gets better!
Eventually Solaris would see all these ACKs coming back, for older packets, in multiplicate. Well, after two acks for the same old packet (i.e. with future packets already acked), it would move the window back and start all over.
So far, all we've got is a really slow, messed up link. But, because of the slow TCP RTT convergence at Solaris' end, our poor embedded target is getting duplicate packets left and right, and, more importantly, repetitions of packets that came before one's already acknowledged. In fact, Solaris was being a bit too aggressive in resending windows, doing it on the second duplicate "old" ACK instead of the third one. But, the important thing is, our embedded TCP stack had a bug handling this situation... and we crashed big time.
O.K. So we find the problem. Easy to fix, and update all the units... all over the country.... with hundreds of truck rolls... at our expense. I don't think so. Boss insists that it be fixed using the existing download mechanism.
Now, at this point I should perhaps mention that none of this code was my responsibility. But, I had a reputation for making miracles happen, so it suddenly became my responsibility (I HATE that -- getting shit for not fixing someone elses bugs fast enough, but that's another rant).
Lots of people were still insisting on teaking some parameters, and trying stuff, and to be fair, some FTP client mods helped Solaris' TCP RTT converge better, minimizing timeouts, but it still wasn't perfect. The application guys weren't about to throttle back their PPP virtual device because they were "too busy" so we got no help there. The damn download app was trying to compensate for a situation that it just didn't have enough data about. I knew this was not going to lead to an acceptable solution... poor app was being so overly conservative in sending data that throughput was shot to hell. Clearly the code in the remote test controllers had to be fixed... after all it had the worst bug of all. But how?
To summerize, you need to download a lot of code to a unit that you can't download a lot of code to at any reasonable rate of speed. It was suggested to make the download app really conservative, but I pointed out that even if it worked 99.99% of the time, after 6000 packets, the chances of not crashing due to the bug were only 54%. It would have taken forever and the customer was pissed, and my boss wanted it yesterday, and, and everyone was mad that I hadn't fixed it yet. (This three days into the root cause analysis).
Clearly, we had to download new code to the test controllers. We could download a little (because that didn't tickle the bug) slowly, but that was about all. I suggested the following:
"We find a minimal fix for the broken TCP/IP stack in the test controllers, download an in-situ patch program, that upon reset, patches the relevant pages in flash, and reboots. Then, using the more robust stack, we download a final working version that fixes the rest of the bugs" (by this time we found about 6, but only 2 were critical).
Management went ape-shit, to put it politely. "You want to download SELF-MODIFYING code!? That breaks ALL the rules!! And you call yourself a miracle worker?" (Er, no, they did, I never said that, but I digress). Clearly someone needed a scapegoat and I was about to become it. The legitimate concern was, of course, that if it didn't work and locked up the test controllers, we'd have to roll a truck to each site. But, without a solution, we'd have to do that anyway, so what did we have to lose?
Now, I wasn't in this alone... I had help from the guy responsible for the download app, and the guy resposible for the flash drivers in the test controller. We all agreed that this was the best way to proceed, and after much arguing, name-calling, and time wasting were given the go-ahead. O.K. we're one week into our alotted two-fix "fix it or else" deadline.
Well, we managed to fix it, tested with 20 live customer test head controllers (pipelining the development and testing of progressively refined versions), stressed it, and it worked like a charm. I think, of some 1500 remote test controllers, all but 20-40 got repaired this way, and those had other problems.
Me, when it came to review time, got a note that "Rene improved software download performance". That's it. One stinking sentence. Saved the company at least some $250k - $500k in repair costs, avoided a potential multimillion $$$ contract cancellation, and that's all I get?
I no longer work for that company and am much happier now working elsewhere. But I think this bug, and subsequent fix, ranks up there with NASA-grade "no, we can't send anyone there" repair hacks.
Being on both sides of the interview fence, I find that those that are a clear cut above the rest get the offer, and soon. The decision is usually made the day of the interview. I've never waited more than 12 hours for a positive response.
It used to be that you'd interview everyone and then pick. More recently (though this may have changed with the downturn), it's been, "If you like the guy let's make an offer" and move on to the next one if the offer is rejected.
Yes, of course, but that mechanism relied heavily on the difficulty of implementing certain types of circumvention, en masse. Even "bring your own" paper to the photocopier was more hassle than "supply your own bandwidth" to my server.
I very much desire a technical solution to help enforce traditional fair use principles. Lacking one, we will see technical solutions that are far too blunt.
Fair question. First, when I refer to "fair use", I'm thinking in terms of the Copyright Act. This permits making a reasonable number of archival copies and/or modest sized extracts for dscussion, critique, etc.
It strikes me that permiting unlimited copying for storage solves the archival problem, all you need to ensure is that you do not lose the playback private key, so have multiple keys made/available. In terms of specific numbers, I was thinking not in terms of one or two, but potentially dozens or even hundreds, but certainly not tens of thousands.
Extraction for critique is an issue that I didn't address, though. Clearly extraction of lower resolution content shouldn't be a problem, but sometimes extraction of full resolution content is necessary -- for example if critiquing a compression technology and illustrating visible artifacts. In such cases, it may be possible for the playback device to limit how much of such extraction is possible. Certainly a daily/weekly limit on use of such a function would not be unreasonable. But, you want to prevent 1000 people from extracting 1/1000th of a movie and reassembling it, for example, and ANY full-resolution extraction mechanism would suffer this flaw. Perhaps a "pay for excerpt" mechanism would work, but that does not satisfy fair use, IMHO.
Oh, and with transcrypters shared temporarily with friends, yeah, you could take the movie (for example) to a friend's house and share that way.
Ya know, I've been thinking about this for a long time... is there a mechanism to protect copyright yet still respect fair use rights? What characteristics would such a mechanism have? Could some aspect of the dreaded SSSCA actually be beneficial here?
I certainly don't have all the answers, but I do have a few observations:
For copyright protection to be effective, content must remain encrypted from receipt by the consumer, to display by the device. Of course at some point it is available (i.e it can be seen and/or heard), but presumably, the cost of equipment to digitally capture such content at a sufficient resolution to threaten master redistribution would be prohibitive for the consumer.
Of course, storing such content is not a problem, if it can only be played back on a restricted set of devices, i.e. content custom-encrypted for each and every consumer. Of course this raises three questions: 1) How can such encryption be done effectively, especially for broadcast or multicast delivery? 2) How do you deal with playback equipment that breaks down, or with vendors that go out of business and so can't "clone" decryptors in such equipment when it breaks. 3) How do you permit multiple playback devices with the same key for convenience within a single household?
Question 1 can be addressed thus: broadcast and multicast content is encrypted with a public key that matches a common private key in all receivers. Yes, this is a weak link, but the receiver need not be a display device -- content would still have to be uniquely encrypted for a particular display device (more on this later). Furthermore, most broadcast content is likely time-sensitive -- it's value diminishes with age. Of course, hacking such a receiver to expose the private key would attract strong SSSCA-like sanctions. Non-broadcast content could be encrypted at source with a public key provided by the consumer at time of purchase, presumably via automated electronic means. It is important, however, that the corresponding private key not be known by the consumer, lest unencrypted versions of the content become available to her. Appropriate signing, by an authority the content provider recognizes, of the public key provided by the consumer (from his equipment) alleviates this.
Question 2 is easily addressed. Clearly each piece of playback equipment has, within it, a decryption module that is (a) sealed and relatively impervious to attack, (b) contains a unique private key. The relevent external connections to this module are encrypted content input and analog decrypted content output. Such modules will be generally customized for each type of equipment. Of course this raises the question of what do you do if the playback equipment, with a unique key fails, and the manufacturer goes out of business (and so can't clone a decrypter module).
This brings us to question 3. Clearly, there is a conflict between uniquely keyed playback equipment, singly-keyed broadcast receivers, and the consumer's desired storage and transport of content around the home. Enter the "transcrypter".
A transcripter is a piece of equipment designed to take content encrypted with its public key, decrypt it internally, and reencrypt it with the public key of another piece of equipment. Placing a transcrypter ahead of any playback device will thus effectively alter it's public key. Transcrypters also have the property that, although manufactured with a unique key, can be cloned to the key of another transcripter (perhaps some limited number of times), thus permitinng several playback devices to share a common key. Of course, when cloning a transcrypter, they have to authenticate eachother to ensure that the public keys correspond to private keys that are "secure" within the transcrypter. Furthermore, while transcrypters should be relatively inexpensive devices, their price should deter distribution of many numbers of cloned transcrypters with encrypted content. Authentication of transcrypters with eachother can be simply a case of detecting public keys signed by an approprliate authority known to the hardware. Hacking a transcrypter, of course, would attract SSSCA-like sanctions.
Transcrypters would allow custom encryption of received content to a common public key used by the consumer, and perhaps, registered with some authority. Receivers would have built-in transcrypters to output content encrypted with this common consumer's public key. Playback devices would have transcrypters to reverse the process. Content encrypted at the source for a consumer would be encrypted with the common public key for all the consumer's transcrypters.
The issue of signing authorities, is, of course, a tricky one politically, however, it is not unreasonable for a piece of equipment to identify peer equipment certified by a common industry body, or its own manufacturer.
More problematic of course, is the registration or at least the signing of a consumer's common public key -- clearly the consumer can't generate the public/private key pair lest they get access to unencrypted content. If a third party (say a transcrypter manufacturer) generates the keypair and signs the public key, they can impersonate the consumer, generate lots of cloned transcrypters, and incriminate the consumer as a content pirate. One solution is to have the transcrypter generate the keypair itself, and trust an external authority for signing the public key. It should be possible to do this in a manner where the transcrypter can be trusted to not disclose the private key to anyone. For example, the transcrypter can allow for arbitrary code execution, particularly to access it's external interfaces, with hard-coded internal transcryption routines and key generators that remain private. This would allow open source networking code to be run on it that could be audited.
Of course, these ideas are just the tip of the iceberg. I'm open to a critical analysis, and realize that the hackability of such devices (receivers, playback devices, and especially transcrypters) is probably the weakest link. However, I'd much rather see SSSCA-type laws applied to a small set of devices and a much broader set (like general-purpose computers), and this may bne one way to do this and still respect fair use.
On the one hand, I am a scientist, and therefore reject any notions that do not survive the scrutiny of the scientific method.
On the other hand, I have seen things I can not explain. This is one of them:
When I was still single, and living in an apartment, c. 1990, I awoke from a nap and thought I saw my bicycle in the hallway outside my room move backwards... frame move back, pedels reversing, the whole thing move... about a foot.
Though this freaked me out, I figured I must have been dreaming in a half-asleep state and investigated. If the bike had actually moved recently, there'd be a noticible indentation where the carpet had been previously compressed by the tires.
Sure enough, such a carpet mark was quite noticible for a foot in front of both wheels.
To this day I can not explain this. I lived alone, and no one else was present at the time. It was rather unnerving.
Actually, I've always preferred to own rather than rent. But, to each his/her own. I had lots of gadgets when I was single (and renting), but didn't want to raise a family in an apartment, so bought a house when I got married. Gadget accrual slowed down significantly then.
As for the HDTV satellite feeds, DirectTV has few, and only if you pay for some silly "everything" package. But, I hope this will change over time, so I sprung for the twin dual-LNB 18x24" elliptical dish (besides, it was cheap future-proofing over the standard single dual-LNB 18" dish). I am fortunate in that I can get about 8 local terrestrial DTV broadcasts out of Dallas, TX, and some of them are starting to broadcast in HD. FWIW, I have a Sony 32" HD-ready direct-view set, and HD-DTC100 receiver, purchased from Crutchfield (only $9.95 inside delivery!). I stayed with a 4:3 format because most material my wife watches is still either analog 4:3 or DTV 4:3. We have a horribly large collection of VHS tapes (mostly movies for the kids). The Sony does a nice job of upsampling 480i to either 960i or 480p as well.
I haven't set up a media server yet, primarily because of the lack of a quiet MPEG2 playback device (i.e. not a PC with noisy fans) that looks like a hifi component. I have wired 6 rooms for 2xRG6 and 2xCat5e though, and recently installed a DSL connection. There's nothing like sinking your own email. Headend includes a 8 port 10/100 Mb/s firewall/switch and Trunkline 5x8 multiswitch. Terrestrial DTV is via an attic-located Terk antenna with a ChannelVision 15db RF amp.
Embedded software development. Specifically, right now, big honkin' routers. In previous lives I helped develop POTS test equipment (to test all British Telecom phone lines each night), automated directory assistance systems that employ speech recognition, mobile radio modems, X.25 PADs and switches, and national CD-ROM based telephone/address databases.
After 11 years, it was time to get a new TV. Driving old cars and not paying the "30% depreciation driving a new car off the lot" also helps.
For the rest of us, there's a recession and, oh by the way, planes are falling from the sky, plague is spreading through the land and the world is about to end any day.
Yeah, I know. I left a previous job, sold a house in a horribly overpriced neighborhood, moved to Texas, and bought a cheaper one twice the size. The recession is good for mortgage rates. As for the other "chicken-little" comments, what good would it do to panic? Besides, receiving and paying my bills on-line means I get almost no paper mail, so "hakuna-matata to mail anthrax delivery".
The trick is to keep enough saved up so you can weather the inevitable downturn in the economy, and not live paycheque to paycheque.
I think so. While I don't have a TV with SVGA in, I do have a Sat/DTV receiver (Sony SAT-HD100) with SVGA out that will definately do 1080i. Also, many HDTV-ready sets have "component" inputs. I believe that SVGA to component conversion boxes exist for between US$100 and $200.
Sure, now I'm made aware of this, after shelling out relatively large sums of money for an HDTV-ready set and an HDTV receiver (terrestrial and satellite).
The thought of building up a personal A/V library accessable anywhere in my home has always been a dream of mine: I have about 220 CDs (approaching the limit of my custom stereo cabinet designed to hold "enough") and countless VHS video tapes. I HATE contemporary storage solutions: expandable usually means ugly, and elegant (like my stereo cabinet) usually mean limited. If anything, I want original media archived away generally out of site and out of mind. Thus, the desire for a remote, unobtrusive, media server.
Timeshifting broadcast programs to some fraction of this server's space is a natural extention of the idea.
So, such technology would be a welcome addition to my media server idea: besides my main (expensive) HDTV setup, I could have lesser playback equipment in other rooms that could leverage this technology (server side), and perhaps dedicate yet another satellite receiver or two for timeshifting purposes (quite willing to pay another $10 a month for the privelege).
Yes, that was the point I was (hastily) trying to make... it is not software per se that needs to be regulated, any more than steel has to be regulated (unless part of a larger, potentially dangerous system). You, sir (or madam?), made it better than I. Thank you.
Why should software developers be treated
differently than architects and engineers?
Because, unlike a bridge, plane, road, or car (for example), the public isn't generally exposed to software against their will, and if they are, can choose to not let it affecf them (i.e. not run it). Software can't fail if it isn't run, and there is nobody forcing you to run a particular piece of software.
Oh, I was thinking of something completely different: grab the AC/97 5 line (I think) serial bus signals from the mobo and run them to an AC/97 codec that gives either S/P-DIF on a card inside the box, or out to an external AC/97 analog codec.
But, yeah, Crystal Audio has some nice stuff... they once sent me a Digital Audio Product Reference book for free even though I made it clear that I was a hacker who'd probably never make more than one of something. Kudos to them.
I do wish that Allwell's site had more details about that box... they mention MPEG2 hardware decoding (using a Sigma Designs chip -- the same as in the Hollywood+ card someone else mentioned) as a standard feature of the iDVD3036, but I want such a box with the MPEG2 decoder and without the DVD drive. Allwell does not make it clear if such a thing is available.
It doesn't have to be, but I think that it would be cheaper to provide a digital output than a clean analog one.
In those cases where there is none, and you can't add a sound card with one (like this), I've often toyed with the idea of intercepting the AC/97 digital audio bitstream, and with a bit of hardware hacking, produce an S/P-DIF output of the "standard" stereo channels... or just pulling the whole AC/97 interface signals out of the box and use an external codec.
You have a point, but I've found that the hash generated from the bus drivers to be a big contributer to noise inside a PC. Often the sound card itself (or in this case, the on-board sound interface) is it's own worst enemy in this regard (as far as cheap sound cards go).
Bottom line is that I'd be wary of an analog audio interface from a digital device sight unseen (or rather sound unheard).
The environment in a PC is very noisy, from a digital "hash" perspective. Analog circuits are sensitive to interference in this environment. I'm told that really good sound cards shield against this, but it is a difficult thing to do and get right. (In a dedicated consumer device, the circuitry can be layed out to avoid this, but a PC is subject to change: adding/removing cards, etc.)
Better (as in professional) sound cards have provisions for external digital I/O and external A/D and D/A boxes (much better than your run of the mill consumer DAC).
So, the request for a digital audio output connection isn't without merit.
Slashdot Mirror
... "You had an assembler? Man! In my day, we entered code in by hand, and not with those wimpy hex keypads, WE set switches in binary and toggled the deposit or deposit next switch."
$7E $CD03
JMP WARMS ; jump to warmstart entry point
Dunno, I was just waking up and saw the damn thing move (or thought I did). I did feel chills down my spine seeing this, but I attribute that to fear of the unknown. After checking for the depressions in the carpet, I got dressed, left to grab a bite to eat (and settle my nerves), and came back about an hour later. There were no other events in that apartment before or after.
I had one other experience in a new house we had just bought, hearing what sounded like hammering. Even though no one was running water (pipes making noise), I could not explain it. Though, there are so many plausable explanations I don't consider it "freaky". I have heard and investigated strange noises before (ever hear a house settle?) so they tend to not suggest themselves as anything other than natural.
Building settling? It would have to settle a hell of a lot to overcome the coefficient of static friction between the bike tires and carpet and handlebar and wall (that it leaned against). I dunno either. It's got me stumped.
Basically, we had this distributed test system with embedded test controllers in about 1500 locations, nation-wide (no, not in North America, but it was still a fairly big country). There was a central location with master controllers managing the whole thing. And there was a networking bug.
Like many embeded systems, this one had a feature which would permit downloading new operating code to it. And, while normal operation worked fine, most of the time we downloaded new code the remote units would lock up and the watchdog would reboot them (to the original operating code). Now, software download testing done in our labs with PCs basically FTPing code to the units worked fine. Software download with the Solaris-based "real" master controllers worked fine. Software download in the field didn't. For some reason, the PC-based testing was done at the same data-rates as under field conditions, but the Solaris-based testing wasn't (go figure). And there lay the key.
See, for some reason, the Solaris networking stack would try to initialize the TCP round-trip timer based on sending a single byte on a newly opened socket and adjust it from there. This was fine when sending short (i.e. "normal" command and control") packets. But software download rammed long packets down the pipe. So, the RTT was set based on the ACK of a single byte, and then the next transmission involves about 1500 bytes... at 9600 bps. You guessed it, TCP timeout and retry. See, the Solaris stack was dumb, it didn't know that the last byte hadn't been sent yet before starting it's ACK timer... Of course the fact that we had a virtual device tunnelling all this traffic encapsulated in PPP frames over an X.25 circuit and locally accepting whole IP frames in one gulp didn't help... the poor Solaris TCP/IP stack got SOOO confused.
So, anyway, here's Solaris sending duplicate packets in fits and starts, and here's our box receiving them and throwing most of them away. To accomodate the slow datarate and long packets, a rather large TCP window was used, which just made things worse... Solaris would send a single byte of payload, initialize it's TCP RTT, and then squeeze off a window of data in several packets. These would time out... Solaris would repeat... But wait, it gets better!
Eventually Solaris would see all these ACKs coming back, for older packets, in multiplicate. Well, after two acks for the same old packet (i.e. with future packets already acked), it would move the window back and start all over.
So far, all we've got is a really slow, messed up link. But, because of the slow TCP RTT convergence at Solaris' end, our poor embedded target is getting duplicate packets left and right, and, more importantly, repetitions of packets that came before one's already acknowledged. In fact, Solaris was being a bit too aggressive in resending windows, doing it on the second duplicate "old" ACK instead of the third one. But, the important thing is, our embedded TCP stack had a bug handling this situation... and we crashed big time.
O.K. So we find the problem. Easy to fix, and update all the units... all over the country.... with hundreds of truck rolls... at our expense. I don't think so. Boss insists that it be fixed using the existing download mechanism.
Now, at this point I should perhaps mention that none of this code was my responsibility. But, I had a reputation for making miracles happen, so it suddenly became my responsibility (I HATE that -- getting shit for not fixing someone elses bugs fast enough, but that's another rant).
Lots of people were still insisting on teaking some parameters, and trying stuff, and to be fair, some FTP client mods helped Solaris' TCP RTT converge better, minimizing timeouts, but it still wasn't perfect. The application guys weren't about to throttle back their PPP virtual device because they were "too busy" so we got no help there. The damn download app was trying to compensate for a situation that it just didn't have enough data about. I knew this was not going to lead to an acceptable solution... poor app was being so overly conservative in sending data that throughput was shot to hell. Clearly the code in the remote test controllers had to be fixed... after all it had the worst bug of all. But how?
To summerize, you need to download a lot of code to a unit that you can't download a lot of code to at any reasonable rate of speed. It was suggested to make the download app really conservative, but I pointed out that even if it worked 99.99% of the time, after 6000 packets, the chances of not crashing due to the bug were only 54%. It would have taken forever and the customer was pissed, and my boss wanted it yesterday, and, and everyone was mad that I hadn't fixed it yet. (This three days into the root cause analysis).
Clearly, we had to download new code to the test controllers. We could download a little (because that didn't tickle the bug) slowly, but that was about all. I suggested the following:
"We find a minimal fix for the broken TCP/IP stack in the test controllers, download an in-situ patch program, that upon reset, patches the relevant pages in flash, and reboots. Then, using the more robust stack, we download a final working version that fixes the rest of the bugs" (by this time we found about 6, but only 2 were critical).
Management went ape-shit, to put it politely. "You want to download SELF-MODIFYING code!? That breaks ALL the rules!! And you call yourself a miracle worker?" (Er, no, they did, I never said that, but I digress). Clearly someone needed a scapegoat and I was about to become it. The legitimate concern was, of course, that if it didn't work and locked up the test controllers, we'd have to roll a truck to each site. But, without a solution, we'd have to do that anyway, so what did we have to lose?
Now, I wasn't in this alone... I had help from the guy responsible for the download app, and the guy resposible for the flash drivers in the test controller. We all agreed that this was the best way to proceed, and after much arguing, name-calling, and time wasting were given the go-ahead. O.K. we're one week into our alotted two-fix "fix it or else" deadline.
Well, we managed to fix it, tested with 20 live customer test head controllers (pipelining the development and testing of progressively refined versions), stressed it, and it worked like a charm. I think, of some 1500 remote test controllers, all but 20-40 got repaired this way, and those had other problems.
Me, when it came to review time, got a note that "Rene improved software download performance". That's it. One stinking sentence. Saved the company at least some $250k - $500k in repair costs, avoided a potential multimillion $$$ contract cancellation, and that's all I get?
I no longer work for that company and am much happier now working elsewhere. But I think this bug, and subsequent fix, ranks up there with NASA-grade "no, we can't send anyone there" repair hacks.
Being on both sides of the interview fence, I find that those that are a clear cut above the rest get the offer, and soon. The decision is usually made the day of the interview. I've never waited more than 12 hours for a positive response.
It used to be that you'd interview everyone and then pick. More recently (though this may have changed with the downturn), it's been, "If you like the guy let's make an offer" and move on to the next one if the offer is rejected.
I very much desire a technical solution to help enforce traditional fair use principles. Lacking one, we will see technical solutions that are far too blunt.
It strikes me that permiting unlimited copying for storage solves the archival problem, all you need to ensure is that you do not lose the playback private key, so have multiple keys made/available. In terms of specific numbers, I was thinking not in terms of one or two, but potentially dozens or even hundreds, but certainly not tens of thousands.
Extraction for critique is an issue that I didn't address, though. Clearly extraction of lower resolution content shouldn't be a problem, but sometimes extraction of full resolution content is necessary -- for example if critiquing a compression technology and illustrating visible artifacts. In such cases, it may be possible for the playback device to limit how much of such extraction is possible. Certainly a daily/weekly limit on use of such a function would not be unreasonable. But, you want to prevent 1000 people from extracting 1/1000th of a movie and reassembling it, for example, and ANY full-resolution extraction mechanism would suffer this flaw. Perhaps a "pay for excerpt" mechanism would work, but that does not satisfy fair use, IMHO.
Oh, and with transcrypters shared temporarily with friends, yeah, you could take the movie (for example) to a friend's house and share that way.
I certainly don't have all the answers, but I do have a few observations:
For copyright protection to be effective, content must remain encrypted from receipt by the consumer, to display by the device. Of course at some point it is available (i.e it can be seen and/or heard), but presumably, the cost of equipment to digitally capture such content at a sufficient resolution to threaten master redistribution would be prohibitive for the consumer.
Of course, storing such content is not a problem, if it can only be played back on a restricted set of devices, i.e. content custom-encrypted for each and every consumer. Of course this raises three questions: 1) How can such encryption be done effectively, especially for broadcast or multicast delivery? 2) How do you deal with playback equipment that breaks down, or with vendors that go out of business and so can't "clone" decryptors in such equipment when it breaks. 3) How do you permit multiple playback devices with the same key for convenience within a single household?
Question 1 can be addressed thus: broadcast and multicast content is encrypted with a public key that matches a common private key in all receivers. Yes, this is a weak link, but the receiver need not be a display device -- content would still have to be uniquely encrypted for a particular display device (more on this later). Furthermore, most broadcast content is likely time-sensitive -- it's value diminishes with age. Of course, hacking such a receiver to expose the private key would attract strong SSSCA-like sanctions. Non-broadcast content could be encrypted at source with a public key provided by the consumer at time of purchase, presumably via automated electronic means. It is important, however, that the corresponding private key not be known by the consumer, lest unencrypted versions of the content become available to her. Appropriate signing, by an authority the content provider recognizes, of the public key provided by the consumer (from his equipment) alleviates this.
Question 2 is easily addressed. Clearly each piece of playback equipment has, within it, a decryption module that is (a) sealed and relatively impervious to attack, (b) contains a unique private key. The relevent external connections to this module are encrypted content input and analog decrypted content output. Such modules will be generally customized for each type of equipment. Of course this raises the question of what do you do if the playback equipment, with a unique key fails, and the manufacturer goes out of business (and so can't clone a decrypter module).
This brings us to question 3. Clearly, there is a conflict between uniquely keyed playback equipment, singly-keyed broadcast receivers, and the consumer's desired storage and transport of content around the home. Enter the "transcrypter".
A transcripter is a piece of equipment designed to take content encrypted with its public key, decrypt it internally, and reencrypt it with the public key of another piece of equipment. Placing a transcrypter ahead of any playback device will thus effectively alter it's public key. Transcrypters also have the property that, although manufactured with a unique key, can be cloned to the key of another transcripter (perhaps some limited number of times), thus permitinng several playback devices to share a common key. Of course, when cloning a transcrypter, they have to authenticate eachother to ensure that the public keys correspond to private keys that are "secure" within the transcrypter. Furthermore, while transcrypters should be relatively inexpensive devices, their price should deter distribution of many numbers of cloned transcrypters with encrypted content. Authentication of transcrypters with eachother can be simply a case of detecting public keys signed by an approprliate authority known to the hardware. Hacking a transcrypter, of course, would attract SSSCA-like sanctions.
Transcrypters would allow custom encryption of received content to a common public key used by the consumer, and perhaps, registered with some authority. Receivers would have built-in transcrypters to output content encrypted with this common consumer's public key. Playback devices would have transcrypters to reverse the process. Content encrypted at the source for a consumer would be encrypted with the common public key for all the consumer's transcrypters.
The issue of signing authorities, is, of course, a tricky one politically, however, it is not unreasonable for a piece of equipment to identify peer equipment certified by a common industry body, or its own manufacturer.
More problematic of course, is the registration or at least the signing of a consumer's common public key -- clearly the consumer can't generate the public/private key pair lest they get access to unencrypted content. If a third party (say a transcrypter manufacturer) generates the keypair and signs the public key, they can impersonate the consumer, generate lots of cloned transcrypters, and incriminate the consumer as a content pirate. One solution is to have the transcrypter generate the keypair itself, and trust an external authority for signing the public key. It should be possible to do this in a manner where the transcrypter can be trusted to not disclose the private key to anyone. For example, the transcrypter can allow for arbitrary code execution, particularly to access it's external interfaces, with hard-coded internal transcryption routines and key generators that remain private. This would allow open source networking code to be run on it that could be audited.
Of course, these ideas are just the tip of the iceberg. I'm open to a critical analysis, and realize that the hackability of such devices (receivers, playback devices, and especially transcrypters) is probably the weakest link. However, I'd much rather see SSSCA-type laws applied to a small set of devices and a much broader set (like general-purpose computers), and this may bne one way to do this and still respect fair use.
It would have hardly been light... but more importantly, even light quakes were reported on the news and none were...
Think of the HORROR, the HORROR!
On the other hand, I have seen things I can not explain. This is one of them:
When I was still single, and living in an apartment, c. 1990, I awoke from a nap and thought I saw my bicycle in the hallway outside my room move backwards... frame move back, pedels reversing, the whole thing move... about a foot.
Though this freaked me out, I figured I must have been dreaming in a half-asleep state and investigated. If the bike had actually moved recently, there'd be a noticible indentation where the carpet had been previously compressed by the tires.
Sure enough, such a carpet mark was quite noticible for a foot in front of both wheels.
To this day I can not explain this. I lived alone, and no one else was present at the time. It was rather unnerving.
The product of the number of digits and symbols for a number X, in base e notation, is less than in any other base.
As for the HDTV satellite feeds, DirectTV has few, and only if you pay for some silly "everything" package. But, I hope this will change over time, so I sprung for the twin dual-LNB 18x24" elliptical dish (besides, it was cheap future-proofing over the standard single dual-LNB 18" dish). I am fortunate in that I can get about 8 local terrestrial DTV broadcasts out of Dallas, TX, and some of them are starting to broadcast in HD. FWIW, I have a Sony 32" HD-ready direct-view set, and HD-DTC100 receiver, purchased from Crutchfield (only $9.95 inside delivery!). I stayed with a 4:3 format because most material my wife watches is still either analog 4:3 or DTV 4:3. We have a horribly large collection of VHS tapes (mostly movies for the kids). The Sony does a nice job of upsampling 480i to either 960i or 480p as well.
I haven't set up a media server yet, primarily because of the lack of a quiet MPEG2 playback device (i.e. not a PC with noisy fans) that looks like a hifi component. I have wired 6 rooms for 2xRG6 and 2xCat5e though, and recently installed a DSL connection. There's nothing like sinking your own email. Headend includes a 8 port 10/100 Mb/s firewall/switch and Trunkline 5x8 multiswitch. Terrestrial DTV is via an attic-located Terk antenna with a ChannelVision 15db RF amp.
Embedded software development. Specifically, right now, big honkin' routers. In previous lives I helped develop POTS test equipment (to test all British Telecom phone lines each night), automated directory assistance systems that employ speech recognition, mobile radio modems, X.25 PADs and switches, and national CD-ROM based telephone/address databases.
After 11 years, it was time to get a new TV. Driving old cars and not paying the "30% depreciation driving a new car off the lot" also helps.
For the rest of us, there's a recession and, oh by the way, planes are falling from the sky, plague is spreading through the land and the world is about to end any day.
Yeah, I know. I left a previous job, sold a house in a horribly overpriced neighborhood, moved to Texas, and bought a cheaper one twice the size. The recession is good for mortgage rates. As for the other "chicken-little" comments, what good would it do to panic? Besides, receiving and paying my bills on-line means I get almost no paper mail, so "hakuna-matata to mail anthrax delivery".
The trick is to keep enough saved up so you can weather the inevitable downturn in the economy, and not live paycheque to paycheque.
I think so. While I don't have a TV with SVGA in, I do have a Sat/DTV receiver (Sony SAT-HD100) with SVGA out that will definately do 1080i. Also, many HDTV-ready sets have "component" inputs. I believe that SVGA to component conversion boxes exist for between US$100 and $200.
The thought of building up a personal A/V library accessable anywhere in my home has always been a dream of mine: I have about 220 CDs (approaching the limit of my custom stereo cabinet designed to hold "enough") and countless VHS video tapes. I HATE contemporary storage solutions: expandable usually means ugly, and elegant (like my stereo cabinet) usually mean limited. If anything, I want original media archived away generally out of site and out of mind. Thus, the desire for a remote, unobtrusive, media server.
Timeshifting broadcast programs to some fraction of this server's space is a natural extention of the idea.
So, such technology would be a welcome addition to my media server idea: besides my main (expensive) HDTV setup, I could have lesser playback equipment in other rooms that could leverage this technology (server side), and perhaps dedicate yet another satellite receiver or two for timeshifting purposes (quite willing to pay another $10 a month for the privelege).
So, bring it on
Yes, that was the point I was (hastily) trying to make... it is not software per se that needs to be regulated, any more than steel has to be regulated (unless part of a larger, potentially dangerous system). You, sir (or madam?), made it better than I. Thank you.
Why should software developers be treated differently than architects and engineers?
Because, unlike a bridge, plane, road, or car (for example), the public isn't generally exposed to software against their will, and if they are, can choose to not let it affecf them (i.e. not run it). Software can't fail if it isn't run, and there is nobody forcing you to run a particular piece of software.
But, yeah, Crystal Audio has some nice stuff... they once sent me a Digital Audio Product Reference book for free even though I made it clear that I was a hacker who'd probably never make more than one of something. Kudos to them.
I do wish that Allwell's site had more details about that box... they mention MPEG2 hardware decoding (using a Sigma Designs chip -- the same as in the Hollywood+ card someone else mentioned) as a standard feature of the iDVD3036, but I want such a box with the MPEG2 decoder and without the DVD drive. Allwell does not make it clear if such a thing is available.
In those cases where there is none, and you can't add a sound card with one (like this), I've often toyed with the idea of intercepting the AC/97 digital audio bitstream, and with a bit of hardware hacking, produce an S/P-DIF output of the "standard" stereo channels... or just pulling the whole AC/97 interface signals out of the box and use an external codec.
Bottom line is that I'd be wary of an analog audio interface from a digital device sight unseen (or rather sound unheard).
2. CDs only have 16 bits of resolution, unless you've got HDCDs.
3. Disk is cheap, rip uncompressed WAV files.
Better (as in professional) sound cards have provisions for external digital I/O and external A/D and D/A boxes (much better than your run of the mill consumer DAC).
So, the request for a digital audio output connection isn't without merit.