Sorry for the delay - here's some more reply.
Much of the talk recently has been to kill cable card entirely, and have the software that does the authentication, encryption, etc be running in a Java VM on the device itself. This means that the cable company does not need to send you a set-top box, (if you want one you just buy one at any store), or even a cable card. Your box just downloads the authentication and decryption program for the cable network and runs with it. I have heard about this, but I don't think that it is something will happen in the near term, simply given all the issues happening now. There is a need to roll out tru2way (electronics manufacturers like it, the FCC demands it) and the analog cutoff. Getting CableCards and tru2way working smoothly will take time. All the hardware for those two cut overs is in the pipe now, and it will need CableCards. So I think that is a ways off.
The idea is good for everyone - one less piece of hardware. Less hardware is good for the electronics manufactures and the cable company. It's good for consumers because it is one less thing they have to setup. I'm not sure of the technology for the idea however. I personally haven't seen any of the details of how the java-based security would work. Such code would have to be protected (by the network manufactures), but how is an open question.
Anyway, if the java-only security does happen, we move into a policy area - what would a cable company allow on its network. At that point a compliant stack would be all that is required, allowing the widest number of participants. I suspect that each cable operator would build a list of "validated" stacks that it would allow. How it would enforce that is unknown to me.
Then why does CableLabs mandate that CableCards be installed by special technicians, who put the card in the slot, then read some numbers into a phone? You've hit the nail on the head there - CableLabs. The major cable companies make up CableLabs, so that policy is something that would be in the best interest of the cable companies. As I posted above, I've read some things on the 'net that suggest cable operators are having difficulty with CableCards, so having the technician on site is a good idea. In the best case, it is as you describe - reading numbers to someone at the headend. In the worst case, check Anandtech for a review of the ATI CableCard device.
Heh... Written as if by a weapons-system engineer that doesn't realize his work is designed to kill people... Lol - I know where my bread is buttered. What I work on won't kill people, but it may be a giant pain in the rear.
I'll just comment on one choice quote:
The cable companies like that better too because the thing that has to be installed on the client side is small and may not even require a cable employee to install.
The licensing agreements for CableCARD (which all cable companies are required to agree to essentially by FCC mandate) requires that a technician install the card. This is to prevent the card from being paired to an unauthorized device. I have not heard that the technician was mandated by the FCC. I would understand if it was CableLabs (and therefore the cable companies) that would want to prevent pairing with an "unauthorized device". The reports I've read of end-user experience with CableCards is that the technicians are are required to handle all the issues that arise. In particular, there was an Anandtech review of computer-based CableCard device (from ATI as it was known then). That report involved several technicians on site to make things work and took 2 days....
Personally I haven't seen any particular issues working with CableCards versus older settops in a lab headend. Of course we don't have the legacy support issues that an in-production headend would have. So I think that eventually CableCards could be deployed without a visit, but that's more an operational/procedural/regulatory (apparently) matter.
Your description of the technology is spot on, but your description of the motivations behind the technology are a little naive. I'll admit I'm naive and optimistic:) One can't be too negative about their employer without being under constant stress. Not from the employer, but from within - a sort of cognitive dissonance. If I hated what my employer did and believed hateful things were done with malice and intent, I'd have to change jobs before going insane.
As for what I wrote, think first of "Never attribute to malice that which can be adequately explained by stupidity." Large standards and technologies created by groups run into many pitfalls, so I chose to pick "we didn't see that" to "we did it to screw everyone." You know, optimism:)
While that is indeed what CableCard does, it is combined with licensing restrictions that would prevent certain features. For example, only a complete certified hardware stack with approved features to prevent export of the raw HD MPEG feed can be licensed. That is probably true. I'm only speaking of the capabilities of the CableCard itself. It is the piece that talks to the cable headend and does the decrypting, based on what is told by the headend. I don't know anything about the approval process for 3rd party hardware and CableCards.
Are you claiming that the tru2way system and its licensing will will enable me to run one hardware manufacture's interface on a different manufactures DVR device?
Not exactly. If TiVo wrote its UI into a tru2way app, and BigBobsEpgAndMore was another UI as a tru2way app, then these apps would be *capable* of running on the same sets of hardware. What I haven't mentioned is how one would get those apps onto the devices... This happens over the cable network, so you'd be at the mercy of the cable company there.
But it quite as restrictive as that sounds - the hardware device (think: TV) is allowed to have its own software, so exactly what apps would be available is a bit of an unknown at this time.
.
Further, why is tru2way even needed?
The difference between simple CableCard and tru2way is that the cable company will provide applications on tru2way that will run on your TV to allow you to access OnDemand (VOD or Video on Demand), which a simple CableCard device would not be able to do.
I'll respond to more of your post later - I just don't have the time now!
Those systems were completely different cable technology than what the cable companies use. Buy "cable tech" I mean "network protocols". The hardware in the hotels was completely different.
The company I work for used to make those systems but is now involved in more modern cable systems. Those hotel systems were great - blazingly fast and reliable. They were not scalable - a few 100 simultaneous users at most.
Originally, CableCards only had one directional transmission capability. This prevented services such as on demand, pay per view, and guide data.
So, being a developer who writes software for tru2way stacks, let me point out where my understanding differs.
The purpose of the CableCard was to separate the specifics of how pay-per-view, subscription channels (like HBO) and encryption from the cable box. This would allow things, like the next HD TiVo box with the 2 CableCards, to handle subscription channels without a settop box. Guide data is not tied to the CableCard in any way.
The fact is, the cable industry moves slowly, and if you think about it, it has too because of the millions of installed devices. One can't simply swap out 10 million of anything with updated hardware without significant cost. So the first versions of the CableCard spec had 1-way (broadcast only) capabilities, while the next generation had 2-way and then 2-way with multiple simultaneous connections. Not all these versions were deployed, but there were specs, transitions testing and so on associated with each revision. Frankly I think that when the form-factor was chosen, the technology could not fit all the hardware for 2-way communication and multiple connections into the device, which caused the phased development.
The hardware complied with the CableCard 2.0 specification but the software for each card did not.
The CableCard is a hardware/software combination that provides a specified interface to the proprietary network encoding that the cable companies run on. The proprietary nature is not from the cable company, but the hardware vendors that provide that equipment. The CableCard provides a bridge, through the CableCard standard, to that network. This allows the TiVo to run all the TiVo software (just like the original boxes) but also directly access subscription channels if you've subscribed with them. The cable company then talks to the CableCard to control what channels are authorized and the TiVo talks to the CableCard to get a decrypted stream for authorized channels.
The cable companies didn't want manufacturers to use their own software in the boxes/televisions/DVRs that would be using the cable cards. No, the cable companies wanted them to use OpenCable Application Platform (OCAP). Of course this isn't an open platform at all.
Picture your Tivo now, with its great recording software. Compare that to the crappy software your cable company uses on their DVR. Well, the OCAP part of the CableCard 2.0 standard requires all hardware be running the cable company's software. In other words, your Tivo would have to be running Comcast/Cox/whoever's horrid interface instead of the standard one. At least, that's how I understand it.
This part is where you are way way off. The tru2way (OCAP) specification is a Java VM and library. That technology allows a company (like TiVo) to write their own Java applications that do what they like, look the way they want etc etc.
The difference from what TiVo (or the cable companies) do now and under tru2way, is that tru2way the hardware is replaced with a Java VM. That Java VM is then implemented by whatever hardware vendor (TV, TiVo box, set top, DVD player). The app runs in the Java VM. This way the cable application displays guide data, or TiVo's functionality, could be written in Java and run on any compliant hardware.
Something that gets left out is that tru2way requires CableCards to work, in the same way the TiVo box required CableCards to plug directly into a digital network.
Consumer electronics companies didn't like this at all. So they fought and protested, allowing the CableCard standard in general to slowly die. That's why most new TVs now don't even have card slots.
That's a little off-base. The CEA wants the same access it had when everyone had analog cable - that you could
It is two-way. In Europe, they've had a standard called MHP that's been around for a long time. In fact, that application is probably an ETV (enhanced TV) application, where the actual code is (to view the menu, handle the choices) is embedded in the broadcast stream. ETV isn't big in North America yet.
The 'tru2way' standard was called 'OCAP' and is based on MHP.
I took a class in English literature once, and the prof noted that the first book that we had to read was the Bible if we wanted to look at English writing critically. That implies that the ideas in the Christian Bible permeate the language. A study of "genetic origins of the supernatural" would then be very difficult as the language that questions are posed in could influence the outcome. More specifically, a speaker of English has very likely been exposed to the idea of "god" even if they do not subscribe to it. Furthermore, you'd have to here the idea of "god" to reject it, so I wonder if it is possible to distinguish between an innate tendency and the side-effects of exposure to the idea.
So many things in the culture I grew up in suggest the supernatural, even outside of religion. The Tooth Fairy. The Easter Bunny. Santa Claus. These are all entities that are described to the youngest children, but they are supernatural. I think that would constitute exposure to the idea at any rate.
To summarize, I am not trying to dismiss the ideas of either side, but suggest that questioning modern humans will be difficult. Also I think that the surviving artifacts of ancient human culture would tend to be on the religious/supernatural side as religion is an excellent tool for control. Call it the calculation of a shrewed leader or a corrupter of the religion, history shows this to have happened.
I pointed out in a different post that the human mind uses a simple ploy to keep operating smoothly. That is, the conscious mental model of reality differs subtly from subjective reality. This mechanism is used constantly to keep out details or ideas that would be distracting. For example, someone living in a warzone and someone living in a suburban North American area. Both have daily routines they go through, but one is much more life-threatening than the other. Both would notice anomalies in their environments, but they are, again, vastly different. Why ramble on with a pointless example? To back those posters that have already indicated that belief in the supernatural could be beneficial. The mechanism described above provides a possible means. Psychology research (sorry, don't have any studies handy to quote) has demonstrated this mechanism is present and useful to the individual.
Given that it is possible, I re-iterate that I don't think we can tell if the "supernatural" is a cultural suggestion, supported by a built-in mechanism, or a separate mechanism.
It's funny that so many argue strenuously against the parent post. There are many studies in the field of psychology that illustrate that humans create a model of the their world and sometimes their model is different from reality to help keep things running smoothly. A simple example would be a person who knows that a chicken had to be butchered to make that sandwich, but internally "forgets" the details.
So that's the mechanism - exposure to the idea would be all that is necessary. The idea is ingrained in Western culture, so if you speak/understand English, you've been exposed.
I saw something a few months back about a project you were trying to get off the ground called "Billy Bastard - Amateur Human Being". It sounded like a great premise and promised me something better than most television. Any updates? Air dates? General info?
Ahh yes, everyone comments with strong opinions without stating important assumptions. The simple answer is "yes, of course you can dynamically alloc memory". The important question not revealed is "why?". Once you have figured out exactly what the memory-related requirements are for you application then you can determine if you need dynamic allocations.
To answer that you need to ask questions like:
Will the app be long-running? If yes, you probably don't want a scheme that will fragment memory because eventually your heap will be too fragmented to allocated necessary contiguous blocks and it will have to reset.
Does the app need to allocate quickly? If yes, then you'll want to avoid allocating at all. Size your buffers ahead of time and never allocate dynamically. Also note that this is not to be confused by with hard real-time requirements. Many real-time applications need only bounded time on operations, so an ordinary allocator would perform very well on average and have known maximums because of bounded initial heap size.
Do you have to supply your own dynamic allocator? If there is an allocator available on the system, that may be the best route.
What are the patterns of your allocations? Does the app allocate many small chunks, a mixture of small and large; are they long lived or short lived? Allocation sizes effect performance and size usage of dynamic allocators.
I'll stop know because I can't think of any other good reasons off-hand. Static allocation is the best thing for many reasons - easy to use, easy to analyze, very fast. That's not practical for all applications, so my advice is to go with a simple allocator next - for C, malloc is good because everyone should know how to use it. Don't worry about speed or efficiency too much - performance usually isn't a problem. Look up "dl_malloc" (Doug Lea's malloc). It's a good public-domain allocator that looks like malloc and works very well allocating small chunks.
Malloc isn't a great fit if your app is constantly running out of space. In that case, find a good garbage collector or memory reordering scheme. Several garbage collectors make life easy by making allocations fast and solving the problem of free'ing memory.
Remember, don't pick an allocation scheme based on the problems you *think* you'll have. Pick an allocator whose major benefit matches your major issue.
First off, I'll just note that all my professional development career has been working with embedded systems.
Second, I'm gonna stay out of the whole "... but <language x> is not an issue because..."
There are many, many reasons to use C instead of C++ on an embedded system. The two biggest are
a) Portability
b) Stability/Conformance
C has a much better record of consistency between embedded platforms. It carries little baggage so most vendors get it right. If the same codebase has to run on several platforms, the specific C compiler for each platform probably produces code that behaves more consistently than C++ compilers.
Stability and confromance come from the fact that embedded vendors don't always spend the time keeping their compilers up to date, and you may be forced to used the vendor's compiler.
As a specific case from place of business: A new project was developed entirely on an emulated environment, beautifully done in C++. Object oriented and all that - this fit the project very nicely. The code was quite stable and was continuously tested with a dedicated rig that ran a huge battery of sample cases against the product. Then the port to the first target platform began. Turns out that it wasn't x86 and Microsoft C++ didn't run there. No problem - the vendore had a C++ compiler. But wait - it didn't support complicated features like "templates" so there was fiddling. By the time I saw the codebase, there were two sets of #ifdefs - one for WIN32 (which worked) and one for the platform (which did not). Later we took that code base, stripped out a bunch of features, converted to C and had it running on about 4 different embedded architectures.
Oh, and the low-end platform was a 25MHz 68331 with 2 MB total memory, 1.5MB total that our middleware could use, so effectively about 700 KB. And we used dynamic memory allocation.
The moral: C compilers are simpler so they tend to be better supported. If your team is more comfortable with some other language and the target supports it, go with that. Remember that maintenance will be the major portion so the more obvious the code is to the developers the better.
I think there is one thing that will make MS be happy with lots o' bandwidth - TV over IP. They own lots of patents in conjuction with it and started really developing after they realized that one monopoly (cable TV providers) doesn't like another (MS). Ignorance of the Internet by MS is so '90s - they had the money to make up for their ignorance.
sourcenav is pretty cool. I used it to learn a very complicated C++ codebase - really helped. Of course when I showed it to a someone who started recently, he asked why I just didn't use vi & tags. I didn't have good response.
> Does that mean that I have the private key that will decrypt all files encrypted with that public key?
Yes.
> How large a file or how many files do I have to decrypt to be assured that I have uniquely identified the private key?
If it decrypts the encrypted file (that is, you run the decrypting algorithm with the "key" you found and you get the un-encrypted text back exactly), then one. If the encryption system is good, the file doesn't have to be too big, but it should probably be a few kilobytes of input. More input may make it easier to discover the private key (choosen plaintext attack), but if the encryption is good it doesn't help.
Public key encryption systems are devised so that key collisions are unlikely. If there are none, that is good. If there are several, that is bad. If there are several that collide but it is hard to calculate what the other collisions might be, that is good. If the mathematical operations in the keyspace are difficult enough to make encryption possible, then calculating the collisions is just as difficult as calculating the private key given the public key.
> Is it true that if I don't give out a public key that I can produce documents that are in principle un-decryptable.
If you mean "I'll generate a public/private key pair and throw away the private key" then yes. Not terribly useful, but yes. But if you found a sufficiently random input source, you could just generate globs of random data that would be equivalent to that.
You are falling into a common trap where many people who have no experience with different mind-related issues step. They say things like "you're depressed - stop feeling sorry for yourself!" and "drugs dull your mind". Basic observation demonstrates that drugs do have an effect on the operation of the brain and that they can be useful.
Drugs and the treatment of mental issues are still rather brutuish and heavy-handed, revealing our poor understanding of the brain-mind-body system. That isn't to say that we have not learned anything, just that there is room for improvement.
I would agree that personal discipline would definitely improve a condition such as ADHD or depression, but it cannot be used in isolation. I have close experience with depression and it is definitely something that can beneifit from drugs - attempting to exert external control on a chemical imbalance. For some people, the benefit of drugs is the difference between being able to function normally and not.
I like to illustrate a parallel with the controversial treatment of chronic pain by some doctors. They prescribe massive doses of morphine for regular use - doses so high they would be lethal for you or me, but they allow people with certain kinds of chronic pain to move and function normally. I believe that for some people with metal issues, the same can be said of the drugs they take. For most people the drugs would be bad, wrong and perhaps deadly. For others, it allows them to operate normally. It supplies their bodies with something they cannot internally regulate anymore (much like diabetics and insulin).
The failure of individuals (and their doctors) to observe and find the appropriate drug for their condition is saddening. I refer to another post in this thread that indicated that several children die every year from using Ritalin. I contend that it was perhaps a mis-application of the drug, not necessarily the drug at fault. You don't digitalis just because you have chest pains.
I say your ideas are not wrong, but they don't describe something that is applicable to everyone. There are many treatments, conditioning, prepardness and personal changes that should be applied simultaneaously to control a mental issue such as ADHD. You are treating it like a bad habit - a rather narrow and simplistic view.
That's what the employers are counting on though. If everyone has that attitude then they can do what they want when the economy is "bad". The job market is never quite as bad as it seems and I know that it would be a very very serious decision to make if you had no alternatives. However, it is the only option that means anything to the employer. Working to the letter of your contract (job action, work-to-rule, working with rulers, whatever) is the other.
You have to be prepared to leave if you ever use that as a ploy with an employer too, or else they own you. No one wants that... I hope. If it gets bad and they won't change, leave. It is much better for you.
The CS452 Real-time programming (
homepage)
deals with a true microkernel. Actually micro kernel is a bad name - what is created is actually a nanokernel, closer to QNX than to MACH.
We start with some basic tools (a loader, C (or C++) compiler, some printf code and a frame-buffer driver. Then we write a message-passing real-time kernel. The kernel does very little - actually only starts a couple of initial processes, passes messages between processes and provides an interface to interrupts. Everything else is performed in a separate process. During the course, this kernel is developed and then each group (of 1 or 2 memebers) also has to write a system to control a train set or a robot. The real-time program is more work than the kernel creation, but every group ends up with a working nanokernel in about 5 or 6 weeks.
Each group is given alot of freedom to do what they would like, with only some basic guidelines to follow. The kernel must be message-passing and it must support real-time operation. By real-time, this means the scheduler is predicatable. The system setup loaded the kernel and programs into RAM directly so disk I/O was avoided. There is a serial terminal attached to a PC and the PC had a frame-buffer. Part of the requirements of the final project were to use the frame-buffer to display some graphics relating to the real-time actions being controlled (position of trains on the track showning movement for example).
Uh, I took that course and it is no "microkernel". It is a monolithic UNIX-style kernel running on top of a simulator of a MIPS-class chip.
The CS452 Real-time programming (
homepage)
deals with a true microkernel. Actually micro kernel is a bad name - what is created is actually a nanokernel, closer to QNX than to MACH.
We start with some basic tools (a loader, C (or C++) compiler, some printf code and a frame-buffer driver. Then we write a message-passing real-time kernel. The kernel does very little - actually only starts a couple of initial processes, passes messages between processes and provides an interface to interrupts. Everything else is performed in a separate process. During the course, this kernel is developed and then each group (of 1 or 2 memebers) also has to write a system to control a train set or a robot. The real-time program is more work than the kernel creation, but every group ends up with a working nanokernel in about 5 or 6 weeks.
Does it not seem obvious that flat-rate access is what powered the internet growth in North America? Europe has never seen the same internet growth because of metered local phone lines. The rebutal in the article made a good arguement and I agree with it. Companies will see a profit with fewer users if they use a flat-rate model. This in turn will lead to more people using the internet.
The same sort of thing has been going on forever in CS classes. You walk into class, the prof gives some arbitrary restrictions and then everyone bitches about it. You'd think that by the time one got to a level of higher education that one would be able to handle these little details.
Here's an example: I went to school at the University of Waterloo (Waterloo, Ont, CA) and they have a diverse computing environment. They had Sun machines, MIPS machines, DEC machines, HP machines - all running slightly different environments. Most ran gcc/g++, but even then there were differences in the system calls on each box. The environment allows seemless logins to any of these machines, but the profs always said "Your submissions will be graded on the Sun machines - please make sure it works there." They didn't care where you did your work as long as it ran in the test environment specified.
What am I saying?
Develop on whatever platform you want - the prof isn't going to sit behind you and watch you work.
Make sure that the program compiles and runs in the specified environment.
Whining isn't going to solve all life's problems so learn to handle these minor roadblocks. Do you honestly think that in the future you will always be able to dictate the programming environment you work in? It's great if you have that kind of control but don't count on it.
It's funny - every time Intel has been on the verge of releasing a brand new redesigned architecture (Pentium, PPro and now P4) there are many people who say "why don't we get it over with and put x86 out of its misery?".
Then the new chip comes out and a detailed look is done and the benchmarks and reviews start to say things like "it's just as fast as this RISC chip clocked twice as fast" etc etc. The x86 nay-sayers should wait until the new chip is out and have a look. They have survived the "CISC is dead! Long live RISC" and produced superior chips.
The x86 chips play to two kinds of buyers: the "I want best bang-for-the-buck" and "I like the software/OS that i have, I just want it to run a little faster". The first group is happy with x86 'cause they are inexpensive for the performance they provide (master of the obvious am I;) The second group, which is business and people that actually - I mean really depend on their computers. If they are depending on x86, they don't want it to change too much.
Slashdot Mirror
The idea is good for everyone - one less piece of hardware. Less hardware is good for the electronics manufactures and the cable company. It's good for consumers because it is one less thing they have to setup. I'm not sure of the technology for the idea however. I personally haven't seen any of the details of how the java-based security would work. Such code would have to be protected (by the network manufactures), but how is an open question.
Anyway, if the java-only security does happen, we move into a policy area - what would a cable company allow on its network. At that point a compliant stack would be all that is required, allowing the widest number of participants. I suspect that each cable operator would build a list of "validated" stacks that it would allow. How it would enforce that is unknown to me. Then why does CableLabs mandate that CableCards be installed by special technicians, who put the card in the slot, then read some numbers into a phone? You've hit the nail on the head there - CableLabs. The major cable companies make up CableLabs, so that policy is something that would be in the best interest of the cable companies. As I posted above, I've read some things on the 'net that suggest cable operators are having difficulty with CableCards, so having the technician on site is a good idea. In the best case, it is as you describe - reading numbers to someone at the headend. In the worst case, check Anandtech for a review of the ATI CableCard device.
The licensing agreements for CableCARD (which all cable companies are required to agree to essentially by FCC mandate) requires that a technician install the card. This is to prevent the card from being paired to an unauthorized device. I have not heard that the technician was mandated by the FCC. I would understand if it was CableLabs (and therefore the cable companies) that would want to prevent pairing with an "unauthorized device". The reports I've read of end-user experience with CableCards is that the technicians are are required to handle all the issues that arise. In particular, there was an Anandtech review of computer-based CableCard device (from ATI as it was known then). That report involved several technicians on site to make things work and took 2 days....
Personally I haven't seen any particular issues working with CableCards versus older settops in a lab headend. Of course we don't have the legacy support issues that an in-production headend would have. So I think that eventually CableCards could be deployed without a visit, but that's more an operational/procedural/regulatory (apparently) matter. Your description of the technology is spot on, but your description of the motivations behind the technology are a little naive. I'll admit I'm naive and optimistic
As for what I wrote, think first of "Never attribute to malice that which can be adequately explained by stupidity." Large standards and technologies created by groups run into many pitfalls, so I chose to pick "we didn't see that" to "we did it to screw everyone." You know, optimism
Are you claiming that the tru2way system and its licensing will will enable me to run one hardware manufacture's interface on a different manufactures DVR device?
Not exactly. If TiVo wrote its UI into a tru2way app, and BigBobsEpgAndMore was another UI as a tru2way app, then these apps would be *capable* of running on the same sets of hardware. What I haven't mentioned is how one would get those apps onto the devices... This happens over the cable network, so you'd be at the mercy of the cable company there.
.But it quite as restrictive as that sounds - the hardware device (think: TV) is allowed to have its own software, so exactly what apps would be available is a bit of an unknown at this time.
Further, why is tru2way even needed?
The difference between simple CableCard and tru2way is that the cable company will provide applications on tru2way that will run on your TV to allow you to access OnDemand (VOD or Video on Demand), which a simple CableCard device would not be able to do.I'll respond to more of your post later - I just don't have the time now!
Those systems were completely different cable technology than what the cable companies use. Buy "cable tech" I mean "network protocols". The hardware in the hotels was completely different.
The company I work for used to make those systems but is now involved in more modern cable systems. Those hotel systems were great - blazingly fast and reliable. They were not scalable - a few 100 simultaneous users at most.
Originally, CableCards only had one directional transmission capability. This prevented services such as on demand, pay per view, and guide data.
So, being a developer who writes software for tru2way stacks, let me point out where my understanding differs.
The purpose of the CableCard was to separate the specifics of how pay-per-view, subscription channels (like HBO) and encryption from the cable box. This would allow things, like the next HD TiVo box with the 2 CableCards, to handle subscription channels without a settop box. Guide data is not tied to the CableCard in any way.
The fact is, the cable industry moves slowly, and if you think about it, it has too because of the millions of installed devices. One can't simply swap out 10 million of anything with updated hardware without significant cost. So the first versions of the CableCard spec had 1-way (broadcast only) capabilities, while the next generation had 2-way and then 2-way with multiple simultaneous connections. Not all these versions were deployed, but there were specs, transitions testing and so on associated with each revision. Frankly I think that when the form-factor was chosen, the technology could not fit all the hardware for 2-way communication and multiple connections into the device, which caused the phased development.
The hardware complied with the CableCard 2.0 specification but the software for each card did not.
The CableCard is a hardware/software combination that provides a specified interface to the proprietary network encoding that the cable companies run on. The proprietary nature is not from the cable company, but the hardware vendors that provide that equipment. The CableCard provides a bridge, through the CableCard standard, to that network. This allows the TiVo to run all the TiVo software (just like the original boxes) but also directly access subscription channels if you've subscribed with them. The cable company then talks to the CableCard to control what channels are authorized and the TiVo talks to the CableCard to get a decrypted stream for authorized channels.
The cable companies didn't want manufacturers to use their own software in the boxes/televisions/DVRs that would be using the cable cards. No, the cable companies wanted them to use OpenCable Application Platform (OCAP). Of course this isn't an open platform at all.
Picture your Tivo now, with its great recording software. Compare that to the crappy software your cable company uses on their DVR. Well, the OCAP part of the CableCard 2.0 standard requires all hardware be running the cable company's software. In other words, your Tivo would have to be running Comcast/Cox/whoever's horrid interface instead of the standard one. At least, that's how I understand it.
This part is where you are way way off. The tru2way (OCAP) specification is a Java VM and library. That technology allows a company (like TiVo) to write their own Java applications that do what they like, look the way they want etc etc.
The difference from what TiVo (or the cable companies) do now and under tru2way, is that tru2way the hardware is replaced with a Java VM. That Java VM is then implemented by whatever hardware vendor (TV, TiVo box, set top, DVD player). The app runs in the Java VM. This way the cable application displays guide data, or TiVo's functionality, could be written in Java and run on any compliant hardware.
Something that gets left out is that tru2way requires CableCards to work, in the same way the TiVo box required CableCards to plug directly into a digital network.
Consumer electronics companies didn't like this at all. So they fought and protested, allowing the CableCard standard in general to slowly die. That's why most new TVs now don't even have card slots.
That's a little off-base. The CEA wants the same access it had when everyone had analog cable - that you could
It is two-way. In Europe, they've had a standard called MHP that's been around for a long time. In fact, that application is probably an ETV (enhanced TV) application, where the actual code is (to view the menu, handle the choices) is embedded in the broadcast stream. ETV isn't big in North America yet.
The 'tru2way' standard was called 'OCAP' and is based on MHP.
I took a class in English literature once, and the prof noted that the first book that we had to read was the Bible if we wanted to look at English writing critically. That implies that the ideas in the Christian Bible permeate the language. A study of "genetic origins of the supernatural" would then be very difficult as the language that questions are posed in could influence the outcome. More specifically, a speaker of English has very likely been exposed to the idea of "god" even if they do not subscribe to it. Furthermore, you'd have to here the idea of "god" to reject it, so I wonder if it is possible to distinguish between an innate tendency and the side-effects of exposure to the idea.
So many things in the culture I grew up in suggest the supernatural, even outside of religion. The Tooth Fairy. The Easter Bunny. Santa Claus. These are all entities that are described to the youngest children, but they are supernatural. I think that would constitute exposure to the idea at any rate.
To summarize, I am not trying to dismiss the ideas of either side, but suggest that questioning modern humans will be difficult. Also I think that the surviving artifacts of ancient human culture would tend to be on the religious/supernatural side as religion is an excellent tool for control. Call it the calculation of a shrewed leader or a corrupter of the religion, history shows this to have happened.
I pointed out in a different post that the human mind uses a simple ploy to keep operating smoothly. That is, the conscious mental model of reality differs subtly from subjective reality. This mechanism is used constantly to keep out details or ideas that would be distracting. For example, someone living in a warzone and someone living in a suburban North American area. Both have daily routines they go through, but one is much more life-threatening than the other. Both would notice anomalies in their environments, but they are, again, vastly different. Why ramble on with a pointless example? To back those posters that have already indicated that belief in the supernatural could be beneficial. The mechanism described above provides a possible means. Psychology research (sorry, don't have any studies handy to quote) has demonstrated this mechanism is present and useful to the individual.
Given that it is possible, I re-iterate that I don't think we can tell if the "supernatural" is a cultural suggestion, supported by a built-in mechanism, or a separate mechanism.
It's funny that so many argue strenuously against the parent post. There are many studies in the field of psychology that illustrate that humans create a model of the their world and sometimes their model is different from reality to help keep things running smoothly. A simple example would be a person who knows that a chicken had to be butchered to make that sandwich, but internally "forgets" the details.
So that's the mechanism - exposure to the idea would be all that is necessary. The idea is ingrained in Western culture, so if you speak/understand English, you've been exposed.
Sweet! I actually have copies of those somewhere. The reverse engineering process will begin immediately. Now where did I put my 286....
I saw something a few months back about a project you were trying to get off the ground called "Billy Bastard - Amateur Human Being". It sounded like a great premise and promised me something better than most television. Any updates? Air dates? General info?
The impact was to cause me to get a BMath degree...
Ahh yes, everyone comments with strong opinions without stating important assumptions. The simple answer is "yes, of course you can dynamically alloc memory". The important question not revealed is "why?". Once you have figured out exactly what the memory-related requirements are for you application then you can determine if you need dynamic allocations.
To answer that you need to ask questions like:
Will the app be long-running? If yes, you probably don't want a scheme that will fragment memory because eventually your heap will be too fragmented to allocated necessary contiguous blocks and it will have to reset.
Does the app need to allocate quickly? If yes, then you'll want to avoid allocating at all. Size your buffers ahead of time and never allocate dynamically. Also note that this is not to be confused by with hard real-time requirements. Many real-time applications need only bounded time on operations, so an ordinary allocator would perform very well on average and have known maximums because of bounded initial heap size.
Do you have to supply your own dynamic allocator? If there is an allocator available on the system, that may be the best route.
What are the patterns of your allocations? Does the app allocate many small chunks, a mixture of small and large; are they long lived or short lived? Allocation sizes effect performance and size usage of dynamic allocators.
I'll stop know because I can't think of any other good reasons off-hand. Static allocation is the best thing for many reasons - easy to use, easy to analyze, very fast. That's not practical for all applications, so my advice is to go with a simple allocator next - for C, malloc is good because everyone should know how to use it. Don't worry about speed or efficiency too much - performance usually isn't a problem. Look up "dl_malloc" (Doug Lea's malloc). It's a good public-domain allocator that looks like malloc and works very well allocating small chunks.
Malloc isn't a great fit if your app is constantly running out of space. In that case, find a good garbage collector or memory reordering scheme. Several garbage collectors make life easy by making allocations fast and solving the problem of free'ing memory.
Remember, don't pick an allocation scheme based on the problems you *think* you'll have. Pick an allocator whose major benefit matches your major issue.
First off, I'll just note that all my professional development career has been working with embedded systems.
Second, I'm gonna stay out of the whole "... but <language x> is not an issue because..."
There are many, many reasons to use C instead of C++ on an embedded system. The two biggest are
a) Portability
b) Stability/Conformance
C has a much better record of consistency between embedded platforms. It carries little baggage so most vendors get it right. If the same codebase has to run on several platforms, the specific C compiler for each platform probably produces code that behaves more consistently than C++ compilers.
Stability and confromance come from the fact that embedded vendors don't always spend the time keeping their compilers up to date, and you may be forced to used the vendor's compiler.
As a specific case from place of business: A new project was developed entirely on an emulated environment, beautifully done in C++. Object oriented and all that - this fit the project very nicely. The code was quite stable and was continuously tested with a dedicated rig that ran a huge battery of sample cases against the product. Then the port to the first target platform began. Turns out that it wasn't x86 and Microsoft C++ didn't run there. No problem - the vendore had a C++ compiler. But wait - it didn't support complicated features like "templates" so there was fiddling. By the time I saw the codebase, there were two sets of #ifdefs - one for WIN32 (which worked) and one for the platform (which did not). Later we took that code base, stripped out a bunch of features, converted to C and had it running on about 4 different embedded architectures.
Oh, and the low-end platform was a 25MHz 68331 with 2 MB total memory, 1.5MB total that our middleware could use, so effectively about 700 KB. And we used dynamic memory allocation.
The moral: C compilers are simpler so they tend to be better supported. If your team is more comfortable with some other language and the target supports it, go with that. Remember that maintenance will be the major portion so the more obvious the code is to the developers the better.
I think there is one thing that will make MS be happy with lots o' bandwidth - TV over IP. They own lots of patents in conjuction with it and started really developing after they realized that one monopoly (cable TV providers) doesn't like another (MS). Ignorance of the Internet by MS is so '90s - they had the money to make up for their ignorance.
sourcenav is pretty cool. I used it to learn a very complicated C++ codebase - really helped. Of course when I showed it to a someone who started recently, he asked why I just didn't use vi & tags. I didn't have good response.
Yes.
> How large a file or how many files do I have to decrypt to be assured that I have uniquely identified the private key?
If it decrypts the encrypted file (that is, you run the decrypting algorithm with the "key" you found and you get the un-encrypted text back exactly), then one. If the encryption system is good, the file doesn't have to be too big, but it should probably be a few kilobytes of input. More input may make it easier to discover the private key (choosen plaintext attack), but if the encryption is good it doesn't help.
Public key encryption systems are devised so that key collisions are unlikely. If there are none, that is good. If there are several, that is bad. If there are several that collide but it is hard to calculate what the other collisions might be, that is good. If the mathematical operations in the keyspace are difficult enough to make encryption possible, then calculating the collisions is just as difficult as calculating the private key given the public key.
> Is it true that if I don't give out a public key that I can produce documents that are in principle un-decryptable.
If you mean "I'll generate a public/private key pair and throw away the private key" then yes. Not terribly useful, but yes. But if you found a sufficiently random input source, you could just generate globs of random data that would be equivalent to that.
Now that's using your ass!
You are falling into a common trap where many people who have no experience with different mind-related issues step. They say things like "you're depressed - stop feeling sorry for yourself!" and "drugs dull your mind". Basic observation demonstrates that drugs do have an effect on the operation of the brain and that they can be useful.
Drugs and the treatment of mental issues are still rather brutuish and heavy-handed, revealing our poor understanding of the brain-mind-body system. That isn't to say that we have not learned anything, just that there is room for improvement.
I would agree that personal discipline would definitely improve a condition such as ADHD or depression, but it cannot be used in isolation. I have close experience with depression and it is definitely something that can beneifit from drugs - attempting to exert external control on a chemical imbalance. For some people, the benefit of drugs is the difference between being able to function normally and not.
I like to illustrate a parallel with the controversial treatment of chronic pain by some doctors. They prescribe massive doses of morphine for regular use - doses so high they would be lethal for you or me, but they allow people with certain kinds of chronic pain to move and function normally. I believe that for some people with metal issues, the same can be said of the drugs they take. For most people the drugs would be bad, wrong and perhaps deadly. For others, it allows them to operate normally. It supplies their bodies with something they cannot internally regulate anymore (much like diabetics and insulin).
The failure of individuals (and their doctors) to observe and find the appropriate drug for their condition is saddening. I refer to another post in this thread that indicated that several children die every year from using Ritalin. I contend that it was perhaps a mis-application of the drug, not necessarily the drug at fault. You don't digitalis just because you have chest pains.
I say your ideas are not wrong, but they don't describe something that is applicable to everyone. There are many treatments, conditioning, prepardness and personal changes that should be applied simultaneaously to control a mental issue such as ADHD. You are treating it like a bad habit - a rather narrow and simplistic view.
That's what the employers are counting on though. If everyone has that attitude then they can do what they want when the economy is "bad". The job market is never quite as bad as it seems and I know that it would be a very very serious decision to make if you had no alternatives. However, it is the only option that means anything to the employer. Working to the letter of your contract (job action, work-to-rule, working with rulers, whatever) is the other.
You have to be prepared to leave if you ever use that as a ploy with an employer too, or else they own you. No one wants that... I hope. If it gets bad and they won't change, leave. It is much better for you.
Panasonic ToughBook These are commercial ruggized notebooks. They look useful, but I don't know anyone who has any real-life experience with them.
We start with some basic tools (a loader, C (or C++) compiler, some printf code and a frame-buffer driver. Then we write a message-passing real-time kernel. The kernel does very little - actually only starts a couple of initial processes, passes messages between processes and provides an interface to interrupts. Everything else is performed in a separate process. During the course, this kernel is developed and then each group (of 1 or 2 memebers) also has to write a system to control a train set or a robot. The real-time program is more work than the kernel creation, but every group ends up with a working nanokernel in about 5 or 6 weeks.
Each group is given alot of freedom to do what they would like, with only some basic guidelines to follow. The kernel must be message-passing and it must support real-time operation. By real-time, this means the scheduler is predicatable. The system setup loaded the kernel and programs into RAM directly so disk I/O was avoided. There is a serial terminal attached to a PC and the PC had a frame-buffer. Part of the requirements of the final project were to use the frame-buffer to display some graphics relating to the real-time actions being controlled (position of trains on the track showning movement for example).
The CS452 Real-time programming ( homepage) deals with a true microkernel. Actually micro kernel is a bad name - what is created is actually a nanokernel, closer to QNX than to MACH.
We start with some basic tools (a loader, C (or C++) compiler, some printf code and a frame-buffer driver. Then we write a message-passing real-time kernel. The kernel does very little - actually only starts a couple of initial processes, passes messages between processes and provides an interface to interrupts. Everything else is performed in a separate process. During the course, this kernel is developed and then each group (of 1 or 2 memebers) also has to write a system to control a train set or a robot. The real-time program is more work than the kernel creation, but every group ends up with a working nanokernel in about 5 or 6 weeks.
Does it not seem obvious that flat-rate access is what powered the internet growth in North America? Europe has never seen the same internet growth because of metered local phone lines. The rebutal in the article made a good arguement and I agree with it. Companies will see a profit with fewer users if they use a flat-rate model. This in turn will lead to more people using the internet.
Here's an example:
I went to school at the University of Waterloo (Waterloo, Ont, CA) and they have a diverse computing environment. They had Sun machines, MIPS machines, DEC machines, HP machines - all running slightly different environments. Most ran gcc/g++, but even then there were differences in the system calls on each box. The environment allows seemless logins to any of these machines, but the profs always said "Your submissions will be graded on the Sun machines - please make sure it works there."
They didn't care where you did your work as long as it ran in the test environment specified.
What am I saying?
- Develop on whatever platform you want - the prof isn't going to sit behind you and watch you work.
- Make sure that the program compiles and runs in the specified environment.
Whining isn't going to solve all life's problems so learn to handle these minor roadblocks. Do you honestly think that in the future you will always be able to dictate the programming environment you work in? It's great if you have that kind of control but don't count on it.Then the new chip comes out and a detailed look is done and the benchmarks and reviews start to say things like "it's just as fast as this RISC chip clocked twice as fast" etc etc. The x86 nay-sayers should wait until the new chip is out and have a look. They have survived the "CISC is dead! Long live RISC" and produced superior chips.
The x86 chips play to two kinds of buyers: the "I want best bang-for-the-buck" and "I like the software/OS that i have, I just want it to run a little faster". The first group is happy with x86 'cause they are inexpensive for the performance they provide (master of the obvious am I ;) The second group, which is business and people that actually - I mean really depend on their computers. If they are depending on x86, they don't want it to change too much.