Count Dooku is evil, but is being played. He thinks he's bringing down a bad thing and helping the good guys by leading the Seperatists, but he's being tricked by Sidious / Palpatine. There's a scene in Ep 2. where he tries to convince Kenobi that he's doing the right thing, and it's clear he's confused. He's a bad guy because he works for Sidious and is attacking the current government, but he thinks he's doing it for the right reasons.
I agree with the GP or GGP or whatever it was - this stuff just doesn't make any sense whatsoever.
And, for the sake of comity, I'll give you credit for trying your best to make sense of it, but what you've written is every bit as nonsensical as Episode II: Dooku is an evil character who purposefully joins with the evil Sidious to create the evil rebellion [or is it a good rebellion? - in Episode I it started as a tax revolt] that will eventually [and magically] evolve into a good rebellion that will bring down Sidious some twenty years later?
I'm sorry, but that's just plain nutso.
The absolutely awesome Episode III wrap-up of this would have been as follows: The Jedi, in their arrogance, follow Palpatine's lead and crush the good rebellion [killing the good Dooku in the process], only to learn, to their horror, that Palpatine was the evil one all along. As soon as Palpatine feels confident in his position, he and Anakin/Vader turn on the remaining Jedi, and kill them in a Pearl Harbor/9-11 holocaust, with only Kenobi & Yoda escaping their wrath.
But that possibility was ruined by the very last scene of Episode II, where Dooku is clearly portrayed bowing to Palpatine/Sidious as his master.
First, back in the day [before they were utterly screwed by Intel], Intergraph had some awesome hardware tech. More recently, they've evolved into something of a CAD/CAM software company, but maybe some of the/. old timers can chip in with tales of the glory years.
Second, Intergraph was screwed by Intel in much the way that SCO was screwed by IBM. In Intergraph's case, Intel engineers were up against a wall circa the late 486/early 586 timeframe, and came to Intergraph for help. Intergraph opened their IP portfolio to Intel, taught the Intel engineers how to design a modern CPU, and Intel proceeded to steal the entirety of that IP portfolio - hook, line, and sinker.
In SCO's case, IBM's AIX/PowerPC group was up against a wall when it came to porting something AIX-ish to x86 hardware, so SCO entered into a partnership with IBM to write a next-generation UNIX-ish operating system for x86 hardware, in what was dubbed "Project Monterey". SCO proceeded to pour the heart and soul of their company into Monterey [to include pretty much their entire R&D budget], whereas, just a short time before project completion, IBM discovered "free" software [i.e. Linux], and summarily announced to SCO that Project Monterey ceased to exist [effective immediately]. To this day, SCO doesn't know whether e.g. any Project Monterey code made its way into AIX, or any other IBM OSes.
Anyway, the moral of the story is that just because a small, innovative company [like the old Integraph, or the old SCO] doesn't take the politically correct stand in court doesn't mean that they don't have a legitimate grievance.
I always thought thoses Sybians were dirty. That they're spreading infection isn't too surprising. Who the heck drives around with one in their car though?
I hope you meant to say: Who the heck drives around with one in her car though?
No, Data Space Transfer Protocol is not "also known as" Data Socket Transfer Protocol.
First of all, Grossman's group at UIC tends to call it Data Space Transfer Protocol. On the other hand, the promotional and marketing material at National Instruments tends to call it Data Socket Transfer Protocol.
Second, there seems to be some confusion as to what is meant by a backend. I want some sort of a server [something traditional, like Oracle/DB2/SQLServer, or something a little new-fangled, like Objectivity/Caché/Poet/ObjectStore] to serve as the backend, receive all that data, and store it in some kind of a coherent "database".
I've written my own wire protocol + packers and unpackers. I tag every data value with its type (number, time, string,...) and message position (this I use to selectively leave out values under specific circumstances, i.e. to send partial messages). This arrangement works just fine: the wire format is machine independent, and quick to read and write. The coding overhead for message packing and unpacking is limited to pretty much a single function per message type (to identify the various fields), and conversion from and to wire format is done using two universal conversion routines.
This is precisely what I feared: You had to write the whole thing from the ground up.
If there's a quality vendor out there that's got any kind of pre-packaged data transfer protocol for moving strongly-typed data, I haven't found it yet.
Scientific programming question: Anybody have any experience with the Data Space Transfer Protocol? Also known as the "Data Socket Transfer Protocol"? National Instruments [NI] wrote a DSTP front end into LabVIEW, but if any major vendors have a DSTP back end, I haven't discovered it.
Or does anyone have any experience with any other methods of moving large amounts of [strongly-typed] data across the wire so that it comes to rest in a central repository in some sort of a coherent fashion?
Could you clarify? First of all, what's the "DV Bridge"? And how does this end up in a computer if there isn't a "capture card"?
On a somewhat related point, we've had a problem where some "cards" seem to be able to see Closed Circuit TV signals, and other cards can't see those signals. Unfortunately, I don't know what the name of the standard is [other than generic "NTSC"] that one card can see and the other card can't.
Our lab could really use some integration of microscope still shots and closed circuit video into our LabVIEW front-ends.
Unfortunately, National Instruments wants like $1500 for their video capture cards, which is like ten or twenty times the cost of a comparable WinFast/Hauppauge/ATi solution, i.e. NI is charging you like $100 for the hardware and $1400 for the LabVIEW drivers [the so-called "NI-IMAQ" library].
I did a ton of Googling, and the best I could find was the ADLINK Technologies Angelo RTV-24:
That's still about three to six times the price of the WinFast/Hauppauge/ATi solution, but it's not quite as stratospheric as the NI solution.
Anyway, does anyone have any experience with affordable LabVIEW still shot/closed circuit video capture, and do you have any recommendations on what to try [and, maybe even more importantly, what to avoid trying]?
They shipped versions up to and including 4.0 without doing proper buffer size checks in system calls. That's pretty awful really, any software executing on the machine had the ability to arbitrarily scribble on things, cause kernel-side faults etc. The main thing that protected them was that most Windows programmers never interacted with the (unprotected) NT system calls, they just used the higher level Win32 APIs. In Window 2000 the problem was restricted to a few dozen syscalls that do unusual things with memory. Harder to exploit, but probably possible.
Do you have any URLs or Google keywords that would give me a little more info as to what you're talking about?
I mean, they did get C2 certification pretty early on:
Are you saying that the industry was aware that there were [intentionally, not accidentally] ill-behaved library calls, and that the NCSC still awarded them C2?
Or are you saying that M$FT lied to the NCSC? Or maybe that the NCSC is a bunch of morons and C2 is meaningless?
Your post: "Plus, if you know the Windows NT kernel, you pretty much know the VMS kernel [wink wink]."
My puzzlement: Windows NT == VMS? Really? Are you serious?
More of a stab at M$FT - I think the gentleman's agreement they reached was that DEC wouldn't sue them over theft of proprietary trade secrets [i.e. theft of "Intellectual Property"] if M$FT agreed to port NT to Alpha hardware.
But as to the underlying question of the NT kernel: Folks, it ain't all that bad. In just about every test anyone ever throws at it, the NT kernel bitch slaps the competition.
Now the decision in NT 4.0 to break the pure client/server model, and bring the windows/graphics stuff into "Ring 0", may have contributed to some system instability [particularly if you're using a bleeding-edge video card], and the NT Domain/Active Directory network infrastructure may be a pale imitation of a true directory like what Novell can offer you, but the underlying Windows NT kernel itself ain't nothing to laugh at.
Oh, and VMS has this thing called a versioning file system, that, as far as I know, is still pretty much unique in the industry: With a versioning file system, you can, at least in theory, keep a history of all the "deltas", or "increments" to a file, so that you have, at least in theory, a record of every state the file has ever been in.
Plus, if you know the Windows NT kernel, you pretty much know the VMS kernel [wink wink].
Score one for Novell Marketing - the sorriest bunch of keystone kop nincompoops in the history of high tech marketing.
Now they don't have to explain to people that "No, our Ngage is something completely different."
PS: If anyone can explain to me what the hell "Ngage/xTeNd/Nsure" is supposed to mean [after what, three or four years of trying to decipher it?] then please attach a star to your forehead, and a big, shit-eating, teacher's pet grin to your face.
1) Cable is rapidly moving away from a broadcast-based network infrastructure [where you can put a "sniffer" on the network and "hear" everyone else's traffic], and towards an on-demand switched network [where you can only hear the traffic that is streamed directly to your jack], so that you can't even sniff the network to begin with [unless you were to physically break into your neighborhood's cable switch, and that sort of thing just screams local/state/federal "FELONY OFFENSE"].
Some of the new cable network protocols may allow you to sniff all the traffic in your local loop, but unless someone in your local loop chooses to on-demand download the particular content you're interested in, you aren't even going to be able to sniff an encrypted version of it.
I.e. before you'll have any hope of sniffing what you want, you'll need to be on a really big local loop, with neighbors who aren't skinflints [i.e. who will pay to download legitimate copies], and who share your interest in that particular content. And even then, you'll be sniffing something with individualized Public/Private key encryption, so good luck.
Our lab could really use some integration of microscope still shots and closed circuit video into our LabVIEW front-ends.
Unfortunately, National Instruments wants like $1500 for their video capture cards, which is like ten or twenty times the cost of a comparable WinFast/Hauppauge/ATi solution, i.e. NI is charging you like $100 for the hardware and $1400 for the LabVIEW drivers [the so-called "NI-IMAQ" library].
I did a ton of Googling, and the best I could find was the ADLINK Technologies Angelo RTV-24:
That's still about three to six times the price of the WinFast/Hauppauge/ATi solution, but it's not quite as stratospheric as the NI solution.
Anyway, does anyone have any experience with affordable LabVIEW still shot/closed circuit video capture, and do you have any recommendations on what to try [and, maybe even more importantly, what to avoid trying]?
Unless somebody uncovers a flaw in the underlying algorithm, you are not going to do any key cracking. CSS (the encryption used on DVDs) did get cracked, of course. That was the result of a poorly-chosen algorithm and sloppiness on the part of a CSS licensee. These are mistake the entertainment industry is not likely to repeat.
CSS is/was an enclosed system, did not involve a negotiation between peers [i.e. did not involve the potential for an exchange of public keys and the withholding of private keys], and, region-coding aside, did not involve session-based [i.e. individualized] encryption. Therefore it was theoretically breakable [all you had to do was place the de-encrypting software in a "de-bugger" and spend thousands - or maybe millions - of man-hours going over shift register logic to figure out what it was they were doing for the "encryption"].
The cable services are moving towards a really onerous model, however [onerous from the point of would-be pirates]:
1) Cable is rapidly moving away from a broadcast-based network infrastructure [where you can put a "sniffer" on the network and "hear" everyone else's traffic], and towards an on-demand switched network [where you can only hear the traffic that is streamed directly to your jack], so that you can't even sniff the network to begin with [unless you were to physically break into your neighborhood's cable switch, and that sort of thing just screams local/state/federal "FELONY OFFENSE"].
2) Even if you could sniff the network, the new smart boxes and smart protocols are doing public key exchange [in combination with private key withholding], so, unless you solve a Clay-Prize-worthy problem in mathematics, you're SOL as far as understanding what it is you're sniffing [which I guess is the point that the parent comment was making].
For the near future, the cable providers will continue to offer classic analog broadcast channels [maybe 0 through 49, or 0 through 99, if you're lucky] for backwards compatibility with older TV sets and older set-top boxes, but once you get up around Channel "100" in the newer systems, you're looking at encrypted, switched, on-demand traffic [where the encryption is session-based, i.e. individualized], so dream on.
PS: I once downloaded one of the new cable protocols - I think it was a story on/. at the time - and, while I can't seem to find it at the moment, I quite clearly remember that there was some seriously tedious, non-trivial communications theory that went into it - enough to make e.g. something like the Token Ring protocol look like a day at the beach by comparison. And if you ever saw one of Laura Chappell's old books with the fold-out diagram of the Token Ring packet, you'll know I ain't talkin' turkey here.
The sharpness of the output image cannot possibly be affected by how those bytes are computed.
Assuming the computations come to the same conclusion.
But e.g. 96-bit extended floating point calculations on Intel/AMD hardware will generally give different answers than 128-bit Sparc or Altivec calculations, and I'm sure you encounter similar problems in the high-end graphics market.
Second, modern graphics devices don't have any dedicated 2D hardware left in them. They all just use their 3D cores to do basic blit operations. Why waste silicon on specialist 2D blitting when you've got a gajillion megapixels of fillrate sitting right there in the 3D core?
DISCLAIMER: I am not a CAD phr33k, or a CAM phr33k, or a Graphics Designer, or even a Florist.
However, every graphics review I've ever perused indicates that Matrox's cards, with dedicated 2D hardware, put a sharper, cleaner, prettier picture on the screen than any 3D card from nVidia, ALi, 3D Labs/Oxygen, or their ilk.
It will be interesting to see how many people take the Linux plunge and break from the swirling vortex of regular, forced product updates. I am betting very few, unfortunately. It's just too much of a leap for most people...when Windows XP/20XX offers such a warm fuzzy UI feeling.
The look & feel of mmc.exe is so much different than the old NT 4.0 admin utilities that it might take me a while to find my way around an NT 4.0 box - wonder how quickly it would come back to me?
Oh, and wasn't it cool how you could start windows from the command line in NT 3.51: win.exe!!! Bringing the window system inside the kernel was such a bummer.
I can't say that I disagree with you, but I think the reason behind Nvidia or Ati not releasing is not just the fear of reverse engineering. They both have a lot innovation and expertise there. 3D drivers are a bit more complex than just simple wireless nic hw interfaces. Nvidia improving performance by mere driver upgrades by tens of percents on occasions is something they sure as hell don't want Ati to know the details about. I don't the linux market for 3D cards has jack to do with it either. They both most likely have the almost exact code in their windows drivers and that's the source they don't to release.
To both you and the grandparent: What does this tell you about Richard Stallman's crusade to destroy the very idea of intellectual property rights [as a first step towards abolishing any notions of private property whatsoever]?
That maybe there's some underlying value in intellectual property? That maybe it takes a lot of time and effort to create intellectual property? That maybe people who go to the effort of creating and distributing intellectual property aren't all that thrilled when a certain rogue element in society steals that intellectual property from them and BitTorrents/KaZaAs it for free? That maybe The Evil One(TM) might have been onto something?
If they had claimed that the plant should have stayed open because reel to reel tape is an ideal medium for distributing radio content while they themselves don't use it, that might be considered irony.
And the real irony is that that's hypocrisy, not irony.
The very last call I took at the IBM PC Help Center [which, I gather, is in peril of being relocated from the RTP to the PRC] was with the guy who administered the laptops that the astronauts took on the shuttle. Could only see about 100 of the 300 servers on his network, so we figured it was a networking problem [I was in networking, not laptops], and I spent three hours with him before we finally realized that it was the drivers for the PCMCIA bridge that were killing the ethernet stack. Updated the drivers and la voila - everything worked perfectly.
ANYWAY, this was early 1997, and he told me that the shuttle was filled with 8-bit processors dating from its design in the 1970s, and it was cheaper for them to have the astronauts carry light weight IBM laptops onboard as a form of an upgrade rather than ripping the beast apart at the seams and upgrading all those 8-bit processors to 32-bits [which I suppose nowadays would be 64-bits].
Wonder who they'll use for such sensitive equipment now that Big Blue has jumped in bed with Big Red?
Slashdot Mirror
Count Dooku is evil, but is being played. He thinks he's bringing down a bad thing and helping the good guys by leading the Seperatists, but he's being tricked by Sidious / Palpatine. There's a scene in Ep 2. where he tries to convince Kenobi that he's doing the right thing, and it's clear he's confused. He's a bad guy because he works for Sidious and is attacking the current government, but he thinks he's doing it for the right reasons.
I agree with the GP or GGP or whatever it was - this stuff just doesn't make any sense whatsoever.
And, for the sake of comity, I'll give you credit for trying your best to make sense of it, but what you've written is every bit as nonsensical as Episode II: Dooku is an evil character who purposefully joins with the evil Sidious to create the evil rebellion [or is it a good rebellion? - in Episode I it started as a tax revolt] that will eventually [and magically] evolve into a good rebellion that will bring down Sidious some twenty years later?
I'm sorry, but that's just plain nutso.
The absolutely awesome Episode III wrap-up of this would have been as follows: The Jedi, in their arrogance, follow Palpatine's lead and crush the good rebellion [killing the good Dooku in the process], only to learn, to their horror, that Palpatine was the evil one all along. As soon as Palpatine feels confident in his position, he and Anakin/Vader turn on the remaining Jedi, and kill them in a Pearl Harbor/9-11 holocaust, with only Kenobi & Yoda escaping their wrath.
But that possibility was ruined by the very last scene of Episode II, where Dooku is clearly portrayed bowing to Palpatine/Sidious as his master.
Two points.
First, back in the day [before they were utterly screwed by Intel], Intergraph had some awesome hardware tech. More recently, they've evolved into something of a CAD/CAM software company, but maybe some of the /. old timers can chip in with tales of the glory years.
Second, Intergraph was screwed by Intel in much the way that SCO was screwed by IBM. In Intergraph's case, Intel engineers were up against a wall circa the late 486/early 586 timeframe, and came to Intergraph for help. Intergraph opened their IP portfolio to Intel, taught the Intel engineers how to design a modern CPU, and Intel proceeded to steal the entirety of that IP portfolio - hook, line, and sinker.
In SCO's case, IBM's AIX/PowerPC group was up against a wall when it came to porting something AIX-ish to x86 hardware, so SCO entered into a partnership with IBM to write a next-generation UNIX-ish operating system for x86 hardware, in what was dubbed "Project Monterey". SCO proceeded to pour the heart and soul of their company into Monterey [to include pretty much their entire R&D budget], whereas, just a short time before project completion, IBM discovered "free" software [i.e. Linux], and summarily announced to SCO that Project Monterey ceased to exist [effective immediately]. To this day, SCO doesn't know whether e.g. any Project Monterey code made its way into AIX, or any other IBM OSes.
Anyway, the moral of the story is that just because a small, innovative company [like the old Integraph, or the old SCO] doesn't take the politically correct stand in court doesn't mean that they don't have a legitimate grievance.
I always thought thoses Sybians were dirty. That they're spreading infection isn't too surprising. Who the heck drives around with one in their car though?
I hope you meant to say: Who the heck drives around with one in her car though?
No, Data Space Transfer Protocol is not "also known as" Data Socket Transfer Protocol.
First of all, Grossman's group at UIC tends to call it Data Space Transfer Protocol. On the other hand, the promotional and marketing material at National Instruments tends to call it Data Socket Transfer Protocol.
Second, there seems to be some confusion as to what is meant by a backend. I want some sort of a server [something traditional, like Oracle/DB2/SQLServer, or something a little new-fangled, like Objectivity/Caché/Poet/ObjectStore] to serve as the backend, receive all that data, and store it in some kind of a coherent "database".
I've written my own wire protocol + packers and unpackers. I tag every data value with its type (number, time, string,
This is precisely what I feared: You had to write the whole thing from the ground up.
If there's a quality vendor out there that's got any kind of pre-packaged data transfer protocol for moving strongly-typed data, I haven't found it yet.
Scientific programming question: Anybody have any experience with the Data Space Transfer Protocol? Also known as the "Data Socket Transfer Protocol"? National Instruments [NI] wrote a DSTP front end into LabVIEW, but if any major vendors have a DSTP back end, I haven't discovered it.
Or does anyone have any experience with any other methods of moving large amounts of [strongly-typed] data across the wire so that it comes to rest in a central repository in some sort of a coherent fashion?
Thanks!
Could you clarify? First of all, what's the "DV Bridge"? And how does this end up in a computer if there isn't a "capture card"?
On a somewhat related point, we've had a problem where some "cards" seem to be able to see Closed Circuit TV signals, and other cards can't see those signals. Unfortunately, I don't know what the name of the standard is [other than generic "NTSC"] that one card can see and the other card can't.
Thanks!
Our lab could really use some integration of microscope still shots and closed circuit video into our LabVIEW front-ends.
Unfortunately, National Instruments wants like $1500 for their video capture cards, which is like ten or twenty times the cost of a comparable WinFast/Hauppauge/ATi solution, i.e. NI is charging you like $100 for the hardware and $1400 for the LabVIEW drivers [the so-called "NI-IMAQ" library].
I did a ton of Googling, and the best I could find was the ADLINK Technologies Angelo RTV-24:
at about $360: That's still about three to six times the price of the WinFast/Hauppauge/ATi solution, but it's not quite as stratospheric as the NI solution.Anyway, does anyone have any experience with affordable LabVIEW still shot/closed circuit video capture, and do you have any recommendations on what to try [and, maybe even more importantly, what to avoid trying]?
THANKS!
you wouldn't be writing code while drunk, would you?
Actually, I've found it more than a little disturbing to learn just how easy it is to write code after a couple of glasses of wine. Or even a bottle.
Makes you realize that a monkey really could do this shit...
They shipped versions up to and including 4.0 without doing proper buffer size checks in system calls. That's pretty awful really, any software executing on the machine had the ability to arbitrarily scribble on things, cause kernel-side faults etc. The main thing that protected them was that most Windows programmers never interacted with the (unprotected) NT system calls, they just used the higher level Win32 APIs. In Window 2000 the problem was restricted to a few dozen syscalls that do unusual things with memory. Harder to exploit, but probably possible.
Do you have any URLs or Google keywords that would give me a little more info as to what you're talking about?
I mean, they did get C2 certification pretty early on:
Are you saying that the industry was aware that there were [intentionally, not accidentally] ill-behaved library calls, and that the NCSC still awarded them C2?Or are you saying that M$FT lied to the NCSC? Or maybe that the NCSC is a bunch of morons and C2 is meaningless?
Your post: "Plus, if you know the Windows NT kernel, you pretty much know the VMS kernel [wink wink]."
My puzzlement: Windows NT == VMS? Really? Are you serious?
More of a stab at M$FT - I think the gentleman's agreement they reached was that DEC wouldn't sue them over theft of proprietary trade secrets [i.e. theft of "Intellectual Property"] if M$FT agreed to port NT to Alpha hardware.
But as to the underlying question of the NT kernel: Folks, it ain't all that bad. In just about every test anyone ever throws at it, the NT kernel bitch slaps the competition.
Compare e.g.:
Now the decision in NT 4.0 to break the pure client/server model, and bring the windows/graphics stuff into "Ring 0", may have contributed to some system instability [particularly if you're using a bleeding-edge video card], and the NT Domain/Active Directory network infrastructure may be a pale imitation of a true directory like what Novell can offer you, but the underlying Windows NT kernel itself ain't nothing to laugh at.From an old Slashdot post of mine, VMS 0wnz the 24X7 911 Emergency Dispatch market:
Oh, and VMS has this thing called a versioning file system, that, as far as I know, is still pretty much unique in the industry: With a versioning file system, you can, at least in theory, keep a history of all the "deltas", or "increments" to a file, so that you have, at least in theory, a record of every state the file has ever been in.
Plus, if you know the Windows NT kernel, you pretty much know the VMS kernel [wink wink].
Old time Novell Master CNI/Master CNE here.
Score one for Novell Marketing - the sorriest bunch of keystone kop nincompoops in the history of high tech marketing.
Now they don't have to explain to people that "No, our Ngage is something completely different."
PS: If anyone can explain to me what the hell "Ngage/xTeNd/Nsure" is supposed to mean [after what, three or four years of trying to decipher it?] then please attach a star to your forehead, and a big, shit-eating, teacher's pet grin to your face.
1) Cable is rapidly moving away from a broadcast-based network infrastructure [where you can put a "sniffer" on the network and "hear" everyone else's traffic], and towards an on-demand switched network [where you can only hear the traffic that is streamed directly to your jack], so that you can't even sniff the network to begin with [unless you were to physically break into your neighborhood's cable switch, and that sort of thing just screams local/state/federal "FELONY OFFENSE"].
Some of the new cable network protocols may allow you to sniff all the traffic in your local loop, but unless someone in your local loop chooses to on-demand download the particular content you're interested in, you aren't even going to be able to sniff an encrypted version of it.
I.e. before you'll have any hope of sniffing what you want, you'll need to be on a really big local loop, with neighbors who aren't skinflints [i.e. who will pay to download legitimate copies], and who share your interest in that particular content. And even then, you'll be sniffing something with individualized Public/Private key encryption, so good luck.
Our lab could really use some integration of microscope still shots and closed circuit video into our LabVIEW front-ends.
Unfortunately, National Instruments wants like $1500 for their video capture cards, which is like ten or twenty times the cost of a comparable WinFast/Hauppauge/ATi solution, i.e. NI is charging you like $100 for the hardware and $1400 for the LabVIEW drivers [the so-called "NI-IMAQ" library].
I did a ton of Googling, and the best I could find was the ADLINK Technologies Angelo RTV-24:
at about $360: That's still about three to six times the price of the WinFast/Hauppauge/ATi solution, but it's not quite as stratospheric as the NI solution.Anyway, does anyone have any experience with affordable LabVIEW still shot/closed circuit video capture, and do you have any recommendations on what to try [and, maybe even more importantly, what to avoid trying]?
THANKS!
Unless somebody uncovers a flaw in the underlying algorithm, you are not going to do any key cracking. CSS (the encryption used on DVDs) did get cracked, of course. That was the result of a poorly-chosen algorithm and sloppiness on the part of a CSS licensee. These are mistake the entertainment industry is not likely to repeat.
CSS is/was an enclosed system, did not involve a negotiation between peers [i.e. did not involve the potential for an exchange of public keys and the withholding of private keys], and, region-coding aside, did not involve session-based [i.e. individualized] encryption. Therefore it was theoretically breakable [all you had to do was place the de-encrypting software in a "de-bugger" and spend thousands - or maybe millions - of man-hours going over shift register logic to figure out what it was they were doing for the "encryption"].
The cable services are moving towards a really onerous model, however [onerous from the point of would-be pirates]:
For the near future, the cable providers will continue to offer classic analog broadcast channels [maybe 0 through 49, or 0 through 99, if you're lucky] for backwards compatibility with older TV sets and older set-top boxes, but once you get up around Channel "100" in the newer systems, you're looking at encrypted, switched, on-demand traffic [where the encryption is session-based, i.e. individualized], so dream on.PS: I once downloaded one of the new cable protocols - I think it was a story on /. at the time - and, while I can't seem to find it at the moment, I quite clearly remember that there was some seriously tedious, non-trivial communications theory that went into it - enough to make e.g. something like the Token Ring protocol look like a day at the beach by comparison. And if you ever saw one of Laura Chappell's old books with the fold-out diagram of the Token Ring packet, you'll know I ain't talkin' turkey here.
The sharpness of the output image cannot possibly be affected by how those bytes are computed.
Assuming the computations come to the same conclusion.
But e.g. 96-bit extended floating point calculations on Intel/AMD hardware will generally give different answers than 128-bit Sparc or Altivec calculations, and I'm sure you encounter similar problems in the high-end graphics market.
Compare: Matlab's Loss is Nobody's Gain or How JAVA's Floating-Point Hurts Everyone Everywhere . (Scroll down to the bottom of the page; they're PDF files, which is why I didn't link to them directly.)
Second, modern graphics devices don't have any dedicated 2D hardware left in them. They all just use their 3D cores to do basic blit operations. Why waste silicon on specialist 2D blitting when you've got a gajillion megapixels of fillrate sitting right there in the 3D core?
DISCLAIMER: I am not a CAD phr33k, or a CAM phr33k, or a Graphics Designer, or even a Florist.
However, every graphics review I've ever perused indicates that Matrox's cards, with dedicated 2D hardware, put a sharper, cleaner, prettier picture on the screen than any 3D card from nVidia, ALi, 3D Labs/Oxygen, or their ilk.
It will be interesting to see how many people take the Linux plunge and break from the swirling vortex of regular, forced product updates. I am betting very few, unfortunately. It's just too much of a leap for most people...when Windows XP/20XX offers such a warm fuzzy UI feeling.
The look & feel of mmc.exe is so much different than the old NT 4.0 admin utilities that it might take me a while to find my way around an NT 4.0 box - wonder how quickly it would come back to me?
Oh, and wasn't it cool how you could start windows from the command line in NT 3.51: win.exe!!! Bringing the window system inside the kernel was such a bummer.
Hmmm.
Virgin.
MILF.
Enter cognitive dissonance, stage left.
To both you and the grandparent: What does this tell you about Richard Stallman's crusade to destroy the very idea of intellectual property rights [as a first step towards abolishing any notions of private property whatsoever]?
That maybe there's some underlying value in intellectual property? That maybe it takes a lot of time and effort to create intellectual property? That maybe people who go to the effort of creating and distributing intellectual property aren't all that thrilled when a certain rogue element in society steals that intellectual property from them and BitTorrents/KaZaAs it for free? That maybe The Evil One(TM) might have been onto something?
If they had claimed that the plant should have stayed open because reel to reel tape is an ideal medium for distributing radio content while they themselves don't use it, that might be considered irony.
And the real irony is that that's hypocrisy, not irony.
Yeah, we probably saw upwards of 50/50 Ethernet/Token Ring at the IBM PC Help Center circa late 1996/early 1997.
But I bet we saw a greater percentage of Token Ring than anybody outside of maybe Madge...
I spent three hours with him before we finally realized that it was the drivers for the PCMCIA bridge that were killing the ethernet stack.
In retrospect, this was IBM in early 1997, so it might have been that the drivers for the PCMCIA bridge were killing the token ring stack.
Anyway, it was just about eight years ago, so be a pal, and cut me some slack...
The very last call I took at the IBM PC Help Center [which, I gather, is in peril of being relocated from the RTP to the PRC] was with the guy who administered the laptops that the astronauts took on the shuttle. Could only see about 100 of the 300 servers on his network, so we figured it was a networking problem [I was in networking, not laptops], and I spent three hours with him before we finally realized that it was the drivers for the PCMCIA bridge that were killing the ethernet stack. Updated the drivers and la voila - everything worked perfectly.
ANYWAY, this was early 1997, and he told me that the shuttle was filled with 8-bit processors dating from its design in the 1970s, and it was cheaper for them to have the astronauts carry light weight IBM laptops onboard as a form of an upgrade rather than ripping the beast apart at the seams and upgrading all those 8-bit processors to 32-bits [which I suppose nowadays would be 64-bits].
Wonder who they'll use for such sensitive equipment now that Big Blue has jumped in bed with Big Red?