Disney chose a non-piracy-themed 'authenticity' metric because they are Disney; but how did they manage to sneak any variation of "Yeah, a search engine; but weighted on Metric X, as well as popularity!" past the patent office?
In the arms race between search engines and SEO abhumans, naive popularity became obsolete almost immediately, and made assorted additional weights, filters, and heuristics both necessary and obvious(at a general level, specific ones or specific implementations of one may well be nontrivial or even brilliant; but the fact that naive popularity is now the road to linkfarm hell is news to no one.)
Weighting for copy-cop-correctness is somewhat novel, since the customer demand isn't obvious; but I'm still not seeing how you can scrape an entire patent out of that(especially when the guys in the Patent and Trademark office have probably heard of the "Let's have a big list of registered trademarks for the sake of authenticity in commerce" concept once or twice before...)
That's a pretty decent short summary: The participating merchants are Not Happy with the cut that the CC companies take for transaction processing, so they are trying to work around them by building this 'CurrentC' program that is built on ACH; but with a UI slightly more friendly(and lower cost to process) than writing paper checks; along with a lot of 'loyalty card' style data gathering.
In principle, I'd be for it (except for the data gathering bullshit). The trouble is that, at least in the US, one of the things that makes CCs popular(and debit cards, checks, and some flavors of electronic funds transfers less popular) is that design and security model for ACH transfers is somewhere between 'painfully obsolete' and 'effectively nonexistent'; and, unlike CCs, the money goes right out of your bank account, immediately, if something goes screwy by ignorance or malice. Even if you do get it back(and your odds are much weaker) any overdraft fees or other bank charges incurred by the change in your account balance are your problem. Credit cards don't really have a markedly better security model ("Yeah, a short series of digits is both necessary and sufficient to charge your account, without any sort of authorization" is pathetic; but fraudulent CC charges don't hit your account directly; and the CC companies have (while largely ignoring actual architectural improvements) done a rather impressive job of building statistical and behavioral fraud-detection into their systems.
A challenge to the current credit card duopoly would be nice; but 'CurrentC' is a more or less transparent attempt by the merchants to disrupt the duopoly and seize every bit of the surplus value freed up by doing so, without offering customers the slightest incentive to cooperate.
You'd be well advised to trust neither(both credit cards and banks have been playing with ways to 'monetize' their information about your buying habits); but it is true that basically 100% of 'CurrentC' is designed as it is to solve a merchant's problem, not a customer's problem.
Some of this is good: I don't directly see the bite the credit card guys take; but that money doesn't spring into being by magic, it ends up in the prices I pay sooner or later.
Some of this is substandard-but-fixable: (the current state of the 'app'/UI/etc. is a bit of a clusterfuck because it was farmed out by a bunch of companies with core expertise in putting rectangular items with price tags on shelves); but those merchants would obviously have nothing against it being better.
The trouble is the stuff that is bad-by-design: the fact that it's even more expansively invasive than the existing 'loyalty card' schemes, and that it sidesteps most security arrangements to reduce cost, are core elements of the design.
I'm thinking that Lt. Col. Sharlene Pigg does not understand anything about morale or esprit de corps.
Arguably, the bigger problem is that the concept of 'cyber warrior' is an iffy fit for the army at best; and just plain incoherent nonsense at worst.
Obviously, now that electronic systems are valuable enough to be worth attacking, defending, and spying on, it's perfectly plausible that somebody is going to end up doing that job; but that's quite different than inferring the existence of 'cyber warriors', much less ones sufficiently closely analogous to conventional warriors that the army would be a logical outfit to have some(not that the Air Force, which seems to be the branch making the most noise about it, is an obviously better fit). Whatever Tron might have told you, 'cyber war' isn't going to be physical combat except more neon...
If the army is serious about a mandate broad enough that 'cyber warrior' actually fits, they are going to have to suck it up and, yes, accept that their current arrangements for training, evaluation, promotion, etc. include elements that are either supported by outdated assumptions or mere nostalgia.
If they aren't, they should get over whatever territorial pissing contest and/or painful misunderstanding of 'cyber war' has them trying to search for a supply of cutting edge IT and security people who are willing to put up with a system bent on evaluating their ability to pick up a rifle when necessary and either contract it or develop a non-dysfunctional relationship with an agency actually suited to the task(ostensibly the NSA, if somebody could pry them away from our email for a few minutes).
They are just going to have to choose: if they want to have one-size-fits-all processes(whether justified by the theory that all their people might actually need combat skills, or by cultural and institutional cohesion considerations), then they just aren't going to get to do everything, at least not well. If they want to do a wide variety of fairly disparate things, they just don't get to keep all their existing practices, at least not well(the only thing that would depress enthusiasts of boot camp and physical training more than just exempting some people from it entirely would be watering the requirements down enough that any pudgy keyboard jockey would be minimally inconvenienced by meeting them...)
Do you think that they'd be able to settle for the "Buy it for 250% the cost of doing it in house from the contractor with the most congressmen" compromise if we lost a land war somewhere else?
I found "GTX 970’s TDP meanwhile is lower than GTX 980’s thanks to the reduced clockspeeds and SMM count. The stock GTX 970 will be shipping with a TDP of just 145W" on Anandtech and figured that they are usually reasonably accurate. The 770 and 780 were seriously thirsty; but allegedly the 9-series is better. I apologize if I am in error.
With a ~150watt GPU, plus the rest of the system, you are going to have quite a time with heat dissipation in any case that is sufficiently waterproof. Even fairly impressive looking passive heatsinks are surprisingly feeble compared to the usual 'few heatpipes, bunch of fins, actual airflow' designs that normal PC hardware uses. Even if you can add enough of them to your computer's case, you still need an excellent thermal path from the CPU and GPU to the case(for reference, Zalman released a somewhat ridiculous case for this purpose a number of years back. As you can see from the photos, the design requires a pretty substantial number of custom heatpipes for the CPU and GPU to be in meaningful thermal contact with the big passive cooler side panels, while a custom PSU had to be used to keep that part cool. It also cost $1,500)
You may also run into trouble, even if CPU and GPU are OK; with high internal air temperatures: most PC gear has a variety of other heat sources(basically anything with electricity involved, VRMs, motherboard chipsets, RAM, etc.) that are typically ignored for water cooling purposes; but which depend on a modest flow of reasonably cool air to stay within their limits. A fanless PC with decent convection might be OK; but a sealed box isn't going to cut it.
If you can get away with it, your best bet would likely be breaking the problem into two parts: the sealed computer case, with waterblocks on the CPU and GPU, and a radiator with fan for cooling the air sealed in the case and keeping it moving for the benefit of lesser components; and the radiator module, which pumps coolant back into the computer case and cools the heated coolant coming out.
This should allow you to fully seal the computer side of things(with the exception of the necessary data and power connections, for which IP-rated connections are available, and the input and output hose fitting) without it cooking and dying; and leaves only the radiator, pump, and possibly a fan outside the sealed case in the radiator module. Given the demands of vehicle engine cooling and the common need for fully submersible pumps, both are available in very waterproof versions, and the heat dissipation of the radiator should actually improve if it's being sprayed down.
If cold is a concern, you'll of course need to use antifreeze in the coolant, and a temperature sensor in the computer module that either activates an internal heater, reduces coolant flow rate, or both, to allow the computer module to remain at a safe temperature.
Depending on the technology in question, it may not even be apparent to the special person(without domain specific knowledge that they may lack, or which may not even exist yet).
With something like an Oculus-style VR headset, the "Well, if we can put a screen in front of each eye and track acceleration and orientation, ideally with a fallback for recalibration when the drift from dead-reckoning with inertial sensors starts to creep in" concept is not particularly new. Relatively lousy versions even became just cheap enough to appear in modest quantities in video game arcades, and more expensive ones usually lurk around some academic and R&D operations.
However, unless they happened to have their finger on the pulse of the MEMs business, even an enthusiast of the technology would likely be inclined to dismiss it as a niche application at best(in largely the same way that, even among people who thought computers were pretty awesome and/or profited from selling them, it was hard to be too optimistic about their future ubiquity until transistorization and VLSI: even if the theoretical utility of building machines that do binary math was visible, there ain't no Moore's law for relays and vacuum tubes...)
As I understand it, the DK2 hardware interacts with the host computer at three points: there's an HDMI video in, which feeds the two screens(presented as a 1920x1080 monitor; but physically split into two 960x1080 panels), a USB interface for the in-device sensors and housekeeping purposes(accelerrometer, magnetometer, gyroscope, firmware updates, latency testing device), and a USB connected IR camera for head-tracking based on the IR LEDs on the head-mounted portion of the device).
How much OS-specific work needs to happen, and how is it distributed?
I'm assuming that the HDMI-in is fairly normal, unless they really broke the EDID/DDC or something(but obviously not going to be very pleasant unless the application drawing to the '1920x1080 monitor' knows that each of my eyes is only getting half of it).
Barring very good reasons(probably involving latency), I'd assume that the camera is just a UVC device; but that actually using it as anything but an expensive webcam requires the OR-specific head-tracking software to have access to it (the meat of which is presumably cross-platform; but DirectShow vs. V4L2 and other interacting-with-the-system stuff won't be).
The headset's USB interface presumably needs a specific driver, since 'read the outputs of a bunch of sensors and also firmware update' isn't exactly a USB Device Class; but would presumably be a comparatively lightweight 'wrap the sensor outputs and get them to the host as quickly as possible' thing, with the bulk of the motion and position tracking logic being mostly OS independent except for the layers it has to interact with to get headset and camera data.
Is this largely the extent of it (2 mostly standard interface, one device specific driver, plus having the motion and position tracking software running on Linux and interacting with the OS-specific interfaces to the drivers)? Do I fundamentally misunderstand how work is broken up within the Oculus system? Do I basically understand it; but it turns out that latency demands are so stringent that a variety of brutal modifications to the typical OS graphics system and GPU drivers are also required?
Would you be able to compensate for poor linearity with a hybrid approach involving a silicon detector and a layer of one of the formulations used in scintillation counters?
I'm thinking by analogy to the approach for making 'white' LEDs: the output of the LED alone is atrociously unsuitable, so you add a phosphor blob that absorbs some of the output and emits at enough other energy levels to fill in something resembling actual white light.
Would a silicon detector, with a layer of scintillation material chosen for good performance in areas that the silicon doesn't cover applied on top, potentially provide a more adequate result?
Are there any issues with silicon solar cells that make them (protected against visible light, obviously) unsuitable? Compared to power silicon or anything for computation you can get enormous area for relatively little money.
Does radiation detection(with actual accuracy, linearity, and repeatability, not just a quick demonstration that you can add some noise to a webcam by pointing a small sealed source at it) have currently good, or at least promising for the not too distant future, solid state options?
I'd imagine that for cost, robustness, and duration on battery power, the presence of little gas filled tubes, some with fairly delicate internal structure, that require a high voltage power supply is a necessary evil at best. In the case of a scintillation counter, the photomultiplier tube would be a similar headache.Are there better behaved options?
FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):
The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:
If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.
If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.
Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.
However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.
If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.
If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.
A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...
Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.
However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party in
They could make the argument; but I'm not sure that they could win it.
It is widely accepted that you can use a protected mark, so long as you don't do so deceptively, to provide information about your product(the usual formulation is "Store brand product, compare to Product(tm) active ingredients). Not a trademark violation, even if the trademark holder might not like it; just telling the customer what your product is intended to be compatible with.
In computing applications, since the data are usually being sent to an (often inflexible and buggy) program rather than to a human, and since identifying information is often necessary for operation, even more blatant use is often accepted. Most browsers still claim to be "Mozilla/5.0" followed by a bunch of other stuff, often equally trademarked and equally false, because that particular string was the only way to get the correct output from assorted crufty HTTP servers. In more adversarial cases, like Lexmark's battle with Static Control Components over toner lockout chips, SCC ended up being allowed to duplicate an even larger chunk of Lexmark's firmware, over Lexmark's objections; because that was deemed a technically necessary part of producing an interoperable toner cartridge.
The USB VID/PID is conceptually in a similar position to the browser UA: it's not hard to find; but not really there for human readers and subject to fairly specific technical limitations if you actually want it to work. "0x0403" is a valid VID. "0x0403 (compatible; China Cloneshop)" is not. It won't even work, much less request the correct driver. USB does provide for purely descriptive, human readable, information fields ('Manufacturer String Descriptor', 'Product String Descriptor', and 'Serial Number String Descriptor') and those aren't subject to technical constraints.
I certainly wouldn't want to be on defense if I were selling a product with somebody else's trademark misused in the string descriptor fields; but the VID/PID would be much more defensible.
In this case, it is not questionable at all. They don't have any right to use the vendor ID (VID) assigned to FTDI.
Why not? The USB IF won't be happy about it, and not being able to trust VID/PID pairs makes driver devs sad and prone to resort to ugly fingerprinting heuristics; but none of that establishes a legal monopoly on "0x0403" for FTDI.
According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.
The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.
Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.
I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.
Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.
Unless you are the sort of disconcertingly disciplined and organized person who sets up a monitoring and alerting system for their dinky little desktop, you probably aren't talking about 'the hard drive'. At a minimum, you are probably dealing with some flavor of RAID, or ZFS, or an iSCSI LUN farmed out by some SAN that does its own mysterious thing behind the expensive logo, or some other additional complexity. Flash SSDs are also increasingly likely to be involved, quite possibly along with some RAM caches in various places.
According to the eevblog report, the newest driver behavior involves reprogramming the USB PID of the target to 0, not merely refusing to do useful work with it.
Quite likely recoverable with some knowledge, unless it managed to close the door behind it on any future PID modifications; but munging a USB device's PID is definitely a step above simply refusing to talk to it.
Slashdot Mirror
Please replace 'cut competition' with 'increase harmony' wherever it appears. Thank you in advance for your cooperation.
Is that you, Macrovision?
In order to keep operating costs low it'll actually be a cartoon-laden frontend that serves up material from an existing source.
Disney chose a non-piracy-themed 'authenticity' metric because they are Disney; but how did they manage to sneak any variation of "Yeah, a search engine; but weighted on Metric X, as well as popularity!" past the patent office?
In the arms race between search engines and SEO abhumans, naive popularity became obsolete almost immediately, and made assorted additional weights, filters, and heuristics both necessary and obvious(at a general level, specific ones or specific implementations of one may well be nontrivial or even brilliant; but the fact that naive popularity is now the road to linkfarm hell is news to no one.)
Weighting for copy-cop-correctness is somewhat novel, since the customer demand isn't obvious; but I'm still not seeing how you can scrape an entire patent out of that(especially when the guys in the Patent and Trademark office have probably heard of the "Let's have a big list of registered trademarks for the sake of authenticity in commerce" concept once or twice before...)
That's a pretty decent short summary: The participating merchants are Not Happy with the cut that the CC companies take for transaction processing, so they are trying to work around them by building this 'CurrentC' program that is built on ACH; but with a UI slightly more friendly(and lower cost to process) than writing paper checks; along with a lot of 'loyalty card' style data gathering.
In principle, I'd be for it (except for the data gathering bullshit). The trouble is that, at least in the US, one of the things that makes CCs popular(and debit cards, checks, and some flavors of electronic funds transfers less popular) is that design and security model for ACH transfers is somewhere between 'painfully obsolete' and 'effectively nonexistent'; and, unlike CCs, the money goes right out of your bank account, immediately, if something goes screwy by ignorance or malice. Even if you do get it back(and your odds are much weaker) any overdraft fees or other bank charges incurred by the change in your account balance are your problem. Credit cards don't really have a markedly better security model ("Yeah, a short series of digits is both necessary and sufficient to charge your account, without any sort of authorization" is pathetic; but fraudulent CC charges don't hit your account directly; and the CC companies have (while largely ignoring actual architectural improvements) done a rather impressive job of building statistical and behavioral fraud-detection into their systems.
A challenge to the current credit card duopoly would be nice; but 'CurrentC' is a more or less transparent attempt by the merchants to disrupt the duopoly and seize every bit of the surplus value freed up by doing so, without offering customers the slightest incentive to cooperate.
You'd be well advised to trust neither(both credit cards and banks have been playing with ways to 'monetize' their information about your buying habits); but it is true that basically 100% of 'CurrentC' is designed as it is to solve a merchant's problem, not a customer's problem.
Some of this is good: I don't directly see the bite the credit card guys take; but that money doesn't spring into being by magic, it ends up in the prices I pay sooner or later.
Some of this is substandard-but-fixable: (the current state of the 'app'/UI/etc. is a bit of a clusterfuck because it was farmed out by a bunch of companies with core expertise in putting rectangular items with price tags on shelves); but those merchants would obviously have nothing against it being better.
The trouble is the stuff that is bad-by-design: the fact that it's even more expansively invasive than the existing 'loyalty card' schemes, and that it sidesteps most security arrangements to reduce cost, are core elements of the design.
How do you say "My pig sense is tingling." in Dutch?
Unfortunately, it's sometimes the people who most enthusiastically live up to the organization's standards that you have to watch out for.
I'm thinking that Lt. Col. Sharlene Pigg does not understand anything about morale or esprit de corps.
Arguably, the bigger problem is that the concept of 'cyber warrior' is an iffy fit for the army at best; and just plain incoherent nonsense at worst.
Obviously, now that electronic systems are valuable enough to be worth attacking, defending, and spying on, it's perfectly plausible that somebody is going to end up doing that job; but that's quite different than inferring the existence of 'cyber warriors', much less ones sufficiently closely analogous to conventional warriors that the army would be a logical outfit to have some(not that the Air Force, which seems to be the branch making the most noise about it, is an obviously better fit). Whatever Tron might have told you, 'cyber war' isn't going to be physical combat except more neon...
If the army is serious about a mandate broad enough that 'cyber warrior' actually fits, they are going to have to suck it up and, yes, accept that their current arrangements for training, evaluation, promotion, etc. include elements that are either supported by outdated assumptions or mere nostalgia.
If they aren't, they should get over whatever territorial pissing contest and/or painful misunderstanding of 'cyber war' has them trying to search for a supply of cutting edge IT and security people who are willing to put up with a system bent on evaluating their ability to pick up a rifle when necessary and either contract it or develop a non-dysfunctional relationship with an agency actually suited to the task(ostensibly the NSA, if somebody could pry them away from our email for a few minutes).
They are just going to have to choose: if they want to have one-size-fits-all processes(whether justified by the theory that all their people might actually need combat skills, or by cultural and institutional cohesion considerations), then they just aren't going to get to do everything, at least not well. If they want to do a wide variety of fairly disparate things, they just don't get to keep all their existing practices, at least not well(the only thing that would depress enthusiasts of boot camp and physical training more than just exempting some people from it entirely would be watering the requirements down enough that any pudgy keyboard jockey would be minimally inconvenienced by meeting them...)
Do you think that they'd be able to settle for the "Buy it for 250% the cost of doing it in house from the contractor with the most congressmen" compromise if we lost a land war somewhere else?
I found "GTX 970’s TDP meanwhile is lower than GTX 980’s thanks to the reduced clockspeeds and SMM count. The stock GTX 970 will be shipping with a TDP of just 145W" on Anandtech and figured that they are usually reasonably accurate. The 770 and 780 were seriously thirsty; but allegedly the 9-series is better. I apologize if I am in error.
With a ~150watt GPU, plus the rest of the system, you are going to have quite a time with heat dissipation in any case that is sufficiently waterproof. Even fairly impressive looking passive heatsinks are surprisingly feeble compared to the usual 'few heatpipes, bunch of fins, actual airflow' designs that normal PC hardware uses. Even if you can add enough of them to your computer's case, you still need an excellent thermal path from the CPU and GPU to the case(for reference, Zalman released a somewhat ridiculous case for this purpose a number of years back. As you can see from the photos, the design requires a pretty substantial number of custom heatpipes for the CPU and GPU to be in meaningful thermal contact with the big passive cooler side panels, while a custom PSU had to be used to keep that part cool. It also cost $1,500)
You may also run into trouble, even if CPU and GPU are OK; with high internal air temperatures: most PC gear has a variety of other heat sources(basically anything with electricity involved, VRMs, motherboard chipsets, RAM, etc.) that are typically ignored for water cooling purposes; but which depend on a modest flow of reasonably cool air to stay within their limits. A fanless PC with decent convection might be OK; but a sealed box isn't going to cut it.
If you can get away with it, your best bet would likely be breaking the problem into two parts: the sealed computer case, with waterblocks on the CPU and GPU, and a radiator with fan for cooling the air sealed in the case and keeping it moving for the benefit of lesser components; and the radiator module, which pumps coolant back into the computer case and cools the heated coolant coming out.
This should allow you to fully seal the computer side of things(with the exception of the necessary data and power connections, for which IP-rated connections are available, and the input and output hose fitting) without it cooking and dying; and leaves only the radiator, pump, and possibly a fan outside the sealed case in the radiator module. Given the demands of vehicle engine cooling and the common need for fully submersible pumps, both are available in very waterproof versions, and the heat dissipation of the radiator should actually improve if it's being sprayed down.
If cold is a concern, you'll of course need to use antifreeze in the coolant, and a temperature sensor in the computer module that either activates an internal heater, reduces coolant flow rate, or both, to allow the computer module to remain at a safe temperature.
Depending on the technology in question, it may not even be apparent to the special person(without domain specific knowledge that they may lack, or which may not even exist yet).
With something like an Oculus-style VR headset, the "Well, if we can put a screen in front of each eye and track acceleration and orientation, ideally with a fallback for recalibration when the drift from dead-reckoning with inertial sensors starts to creep in" concept is not particularly new. Relatively lousy versions even became just cheap enough to appear in modest quantities in video game arcades, and more expensive ones usually lurk around some academic and R&D operations.
However, unless they happened to have their finger on the pulse of the MEMs business, even an enthusiast of the technology would likely be inclined to dismiss it as a niche application at best(in largely the same way that, even among people who thought computers were pretty awesome and/or profited from selling them, it was hard to be too optimistic about their future ubiquity until transistorization and VLSI: even if the theoretical utility of building machines that do binary math was visible, there ain't no Moore's law for relays and vacuum tubes...)
As I understand it, the DK2 hardware interacts with the host computer at three points: there's an HDMI video in, which feeds the two screens(presented as a 1920x1080 monitor; but physically split into two 960x1080 panels), a USB interface for the in-device sensors and housekeeping purposes(accelerrometer, magnetometer, gyroscope, firmware updates, latency testing device), and a USB connected IR camera for head-tracking based on the IR LEDs on the head-mounted portion of the device).
How much OS-specific work needs to happen, and how is it distributed?
I'm assuming that the HDMI-in is fairly normal, unless they really broke the EDID/DDC or something(but obviously not going to be very pleasant unless the application drawing to the '1920x1080 monitor' knows that each of my eyes is only getting half of it).
Barring very good reasons(probably involving latency), I'd assume that the camera is just a UVC device; but that actually using it as anything but an expensive webcam requires the OR-specific head-tracking software to have access to it (the meat of which is presumably cross-platform; but DirectShow vs. V4L2 and other interacting-with-the-system stuff won't be).
The headset's USB interface presumably needs a specific driver, since 'read the outputs of a bunch of sensors and also firmware update' isn't exactly a USB Device Class; but would presumably be a comparatively lightweight 'wrap the sensor outputs and get them to the host as quickly as possible' thing, with the bulk of the motion and position tracking logic being mostly OS independent except for the layers it has to interact with to get headset and camera data.
Is this largely the extent of it (2 mostly standard interface, one device specific driver, plus having the motion and position tracking software running on Linux and interacting with the OS-specific interfaces to the drivers)? Do I fundamentally misunderstand how work is broken up within the Oculus system? Do I basically understand it; but it turns out that latency demands are so stringent that a variety of brutal modifications to the typical OS graphics system and GPU drivers are also required?
Would you be able to compensate for poor linearity with a hybrid approach involving a silicon detector and a layer of one of the formulations used in scintillation counters?
I'm thinking by analogy to the approach for making 'white' LEDs: the output of the LED alone is atrociously unsuitable, so you add a phosphor blob that absorbs some of the output and emits at enough other energy levels to fill in something resembling actual white light.
Would a silicon detector, with a layer of scintillation material chosen for good performance in areas that the silicon doesn't cover applied on top, potentially provide a more adequate result?
Thanks for the explanation, very helpful.
Are there any issues with silicon solar cells that make them (protected against visible light, obviously) unsuitable? Compared to power silicon or anything for computation you can get enormous area for relatively little money.
Does radiation detection(with actual accuracy, linearity, and repeatability, not just a quick demonstration that you can add some noise to a webcam by pointing a small sealed source at it) have currently good, or at least promising for the not too distant future, solid state options?
I'd imagine that for cost, robustness, and duration on battery power, the presence of little gas filled tubes, some with fairly delicate internal structure, that require a high voltage power supply is a necessary evil at best. In the case of a scintillation counter, the photomultiplier tube would be a similar headache.Are there better behaved options?
FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):
The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:
If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.
If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.
Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.
However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.
If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.
If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.
A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...
Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.
However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party in
They could make the argument; but I'm not sure that they could win it.
It is widely accepted that you can use a protected mark, so long as you don't do so deceptively, to provide information about your product(the usual formulation is "Store brand product, compare to Product(tm) active ingredients). Not a trademark violation, even if the trademark holder might not like it; just telling the customer what your product is intended to be compatible with.
In computing applications, since the data are usually being sent to an (often inflexible and buggy) program rather than to a human, and since identifying information is often necessary for operation, even more blatant use is often accepted. Most browsers still claim to be "Mozilla/5.0" followed by a bunch of other stuff, often equally trademarked and equally false, because that particular string was the only way to get the correct output from assorted crufty HTTP servers. In more adversarial cases, like Lexmark's battle with Static Control Components over toner lockout chips, SCC ended up being allowed to duplicate an even larger chunk of Lexmark's firmware, over Lexmark's objections; because that was deemed a technically necessary part of producing an interoperable toner cartridge.
The USB VID/PID is conceptually in a similar position to the browser UA: it's not hard to find; but not really there for human readers and subject to fairly specific technical limitations if you actually want it to work. "0x0403" is a valid VID. "0x0403 (compatible; China Cloneshop)" is not. It won't even work, much less request the correct driver. USB does provide for purely descriptive, human readable, information fields ('Manufacturer String Descriptor', 'Product String Descriptor', and 'Serial Number String Descriptor') and those aren't subject to technical constraints.
I certainly wouldn't want to be on defense if I were selling a product with somebody else's trademark misused in the string descriptor fields; but the VID/PID would be much more defensible.
In this case, it is not questionable at all. They don't have any right to use the vendor ID (VID) assigned to FTDI.
Why not? The USB IF won't be happy about it, and not being able to trust VID/PID pairs makes driver devs sad and prone to resort to ugly fingerprinting heuristics; but none of that establishes a legal monopoly on "0x0403" for FTDI.
That isn't actually so clear:
According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.
The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.
Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.
I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.
Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.
That's a joke. They should have been fined at least as much as the backwages were.
Why keep it civil? Seems only fair for whoever came up with this plan to spend some time stamping out license plates for Uncle Sam.
Unless you are the sort of disconcertingly disciplined and organized person who sets up a monitoring and alerting system for their dinky little desktop, you probably aren't talking about 'the hard drive'. At a minimum, you are probably dealing with some flavor of RAID, or ZFS, or an iSCSI LUN farmed out by some SAN that does its own mysterious thing behind the expensive logo, or some other additional complexity. Flash SSDs are also increasingly likely to be involved, quite possibly along with some RAM caches in various places.
According to the eevblog report, the newest driver behavior involves reprogramming the USB PID of the target to 0, not merely refusing to do useful work with it.
Quite likely recoverable with some knowledge, unless it managed to close the door behind it on any future PID modifications; but munging a USB device's PID is definitely a step above simply refusing to talk to it.