If you want it cheap, there's really no point in even buying the FTDI-to-serial chips, counterfeit or not. A modern MCU with a USB slave will cost as much as the converter chip (or less!), and you get the MCU for free. Since most things need the MCU, that's like a no-brainer, really. No point in making counterfeit chips, just use your MCU.
Not only that, but the driver makes the assumption that the PID change is actually effective. I have implemented the protocol on an MCU, but still use a physical FTDI chip literally glued to the board but non-functional as a token against any claims of impropriety. The MCU pretends that a whole bunch of config requests that would do EEPROM writes and such "succeed", but all that's modified are values in RAM, and those values aren't used for anything else.
I actually ship a device that implements FTDI's protocol in an MCU, and simply glue an otherwise unused FTDI chip to the board as a physical "license token". It's more reliable that way, and I can offer way better buffering and sync than the FTDI chip would allow. As long as they don't use real crypto in their chip, I'm not worried - an afternoon with a protocol analyzer should solve any issues. And if they do use crypto, then I'll probably have my buddy decap the chip and look for the private key bits on the die.
I don't think it'd be inefficient at all if you use a modern compiler. If the compiler happens to notice some loops and vectorize stuff, it may be actually way more efficient per clock cycle than the original machine was.
Hungary is, sadly, turning into authoritarian regime focused on maintaining the power of those at the top. Anything that feeds their spending habits is on the table, I'm sure. We should expect more news like that coming from Hungary:(
It doesn't matter what the lawmakers' intentions were, the truth is that such laws will end with you killed or your car damaged. First hand experience.
If there are cars ahead of you blocking the intersection, how would you ever clear it in any time? Now you might argue that you shouldn't enter the intersection if you can't clear it. Great, so you'll end up rear-ended, or killed by the irate armed idiot who decides that you've sufficiently annoyed him. The law has to reflect the reality, not someone's lofty but patently useless desires.
"If the light goes red before you clear the intersection you ran it." That's false in quite a few U.S. states. In Ohio, for example, if you're in the intersection when the light turns red, you're merely required to clear the intersection ASAP. That's all, and it's perfectly legal to do so.
Cars have airbags so that the people who refuse to buckle their safety belts wont die.
That's just so wrong. Nope, the airbags are the supplemental restraints. They work together with seat belts. Airbag deployment in a frontal collision actually makes you more likely to get injured if you wear no seatbelts, than if you had none - at least for the driver. I've had a T-bone with side airbag deployment, and I can assure you that in this particular case, the seatbelts alone would have done nothing. Again: the restraint system in a car is designed as a system. It's not designed to save you from anyone's folly, it's designed to save you from effects of sudden deceleration. The causes of such sudden deceleration can be and often are beyond human control.
This is a site serving what amounts to static content with simple lookup. There's zero reason to even use a database outside of startup. On startup simply put it into a native data structure in your programming environment of choice, and be done. MongoDB with replica sets, my ass, that's just crazy. The whole lookup application could be a couple of files on a CDN, a single executable and a single bootstrap data file. And syslog somewhere to listen to the traffic updates. It could run on a VM image with a dozen files on it - literally. Heck, you might not even need any dedicated application servers. Just slice-and-dice the data into multiple, reasonably-sized json files, sliced by VIN ranges, as have the webapp do the lookup entirely using the static content. Then all you do to deploy is upload a bunch of files to a CDN.
The "enterprisey" scalability is probably an entirely overblown and over-the-top approach for such a simple web app. All of the executable and the data needed to serve this app fits comfortably in memory, all at once. You don't need anything fancy. The "effort" needed for lookups and generation of the replies is really tiny, as long as you use a solution that is compiled (or JITed). I'm pretty sure any modern multicore desktop machine would easily handle all of the load and completely saturate a couple gigabit pipes with html in response to the requests. Images and static content belong on a CDN (duh).
The entire dynamic content of the site could be served by a simple C++ executable that doesn't even need to use a database outside of startup. Populate a couple static data structures from sqlite, use libmongoose, microhttpd or a similar httpd library, and you're done. Fast n' easy, the entire deployment could consist of two files: a staticly linked server executable + bootstrap data file. The whole code, with syslog output, could probably fit a couple thousand lines or two, with comments and license headers:)
I'm probably feeding the troll, but who the fuck cares if the middle is not thin? Heck, I'd say who the fuck cares if the sides aren't thin - I have no problem with the look of the inch-thick '07 aluminum iMac. It'd be sheer insanity to try and make the whole thing as thin as a laptop, with the power supply inside of it. You can save quite a bit of money by not making it super-thin where the guts are.
These days the "hackery" is equivalent to booting to a working partition (can be on a USB stick) and running Multibeast. It's about as fire-and-forget as it gets.
There are two ways to a hackintosh: using random hardware, and using hardware that's purposefully selected to use the same components that Apple uses in their hardware. The "I''ll just try running OS X on whatever I have" route is perilous and ill-advices. Buying stuff from tonymacx86's buyer guide is a much saner choice, and it worked great for myself.
I've been using one for almost a year now, and there's no looking back. It was only tricky to set up because initial releases of Mavericks were trickier than the current release. I'd say it was a day well spent to set it all up. These days, using it is no different than using any Apple hardware would be, except that after OS version upgrades one has to reboot to the recovery partition and re-run Multibeast.
Modern HDDs media have coercivity so high that the Earth's magnetic field, and the fields from nearby "electronics", are immaterial. The best thing you can do to a HD is leave it alone, not spinning, in a non-condesing atmosphere. As long as the spindle doesn't seize up due to lubricant migration, it might well last for centuries.
Slashdot Mirror
If you buy from legit vendors (DigiKey, Newark, Mouser, etc.), you're not gonna get counterfeit FTDI chips. Period.
If you want it cheap, there's really no point in even buying the FTDI-to-serial chips, counterfeit or not. A modern MCU with a USB slave will cost as much as the converter chip (or less!), and you get the MCU for free. Since most things need the MCU, that's like a no-brainer, really. No point in making counterfeit chips, just use your MCU.
Not only that, but the driver makes the assumption that the PID change is actually effective. I have implemented the protocol on an MCU, but still use a physical FTDI chip literally glued to the board but non-functional as a token against any claims of impropriety. The MCU pretends that a whole bunch of config requests that would do EEPROM writes and such "succeed", but all that's modified are values in RAM, and those values aren't used for anything else.
I actually ship a device that implements FTDI's protocol in an MCU, and simply glue an otherwise unused FTDI chip to the board as a physical "license token". It's more reliable that way, and I can offer way better buffering and sync than the FTDI chip would allow. As long as they don't use real crypto in their chip, I'm not worried - an afternoon with a protocol analyzer should solve any issues. And if they do use crypto, then I'll probably have my buddy decap the chip and look for the private key bits on the die.
I don't think it'd be inefficient at all if you use a modern compiler. If the compiler happens to notice some loops and vectorize stuff, it may be actually way more efficient per clock cycle than the original machine was.
Hungary is, sadly, turning into authoritarian regime focused on maintaining the power of those at the top. Anything that feeds their spending habits is on the table, I'm sure. We should expect more news like that coming from Hungary :(
On a modern cellphone, the whole thing could probably run in the baseband processor :)
It doesn't matter what the lawmakers' intentions were, the truth is that such laws will end with you killed or your car damaged. First hand experience.
A modern Intel Mac will boot into FreeDOS, no problem. It's more like a PC without the BIOS Setup, and supports booting straight into OS X :)
I've had plenty of success with Crucial and their M500 and M550.
If there are cars ahead of you blocking the intersection, how would you ever clear it in any time? Now you might argue that you shouldn't enter the intersection if you can't clear it. Great, so you'll end up rear-ended, or killed by the irate armed idiot who decides that you've sufficiently annoyed him. The law has to reflect the reality, not someone's lofty but patently useless desires.
"If the light goes red before you clear the intersection you ran it." That's false in quite a few U.S. states. In Ohio, for example, if you're in the intersection when the light turns red, you're merely required to clear the intersection ASAP. That's all, and it's perfectly legal to do so.
There's a 50mph road not far from where I'm at, with several intersections with traffic lights on it. The yellow light lasts more than 5 seconds.
Cars have airbags so that the people who refuse to buckle their safety belts wont die.
That's just so wrong. Nope, the airbags are the supplemental restraints. They work together with seat belts. Airbag deployment in a frontal collision actually makes you more likely to get injured if you wear no seatbelts, than if you had none - at least for the driver. I've had a T-bone with side airbag deployment, and I can assure you that in this particular case, the seatbelts alone would have done nothing. Again: the restraint system in a car is designed as a system. It's not designed to save you from anyone's folly, it's designed to save you from effects of sudden deceleration. The causes of such sudden deceleration can be and often are beyond human control.
For what amounts to read-only data, it's a trivial problem with multiple, trivial solutions.
This is a site serving what amounts to static content with simple lookup. There's zero reason to even use a database outside of startup. On startup simply put it into a native data structure in your programming environment of choice, and be done. MongoDB with replica sets, my ass, that's just crazy. The whole lookup application could be a couple of files on a CDN, a single executable and a single bootstrap data file. And syslog somewhere to listen to the traffic updates. It could run on a VM image with a dozen files on it - literally. Heck, you might not even need any dedicated application servers. Just slice-and-dice the data into multiple, reasonably-sized json files, sliced by VIN ranges, as have the webapp do the lookup entirely using the static content. Then all you do to deploy is upload a bunch of files to a CDN.
The "enterprisey" scalability is probably an entirely overblown and over-the-top approach for such a simple web app. All of the executable and the data needed to serve this app fits comfortably in memory, all at once. You don't need anything fancy. The "effort" needed for lookups and generation of the replies is really tiny, as long as you use a solution that is compiled (or JITed). I'm pretty sure any modern multicore desktop machine would easily handle all of the load and completely saturate a couple gigabit pipes with html in response to the requests. Images and static content belong on a CDN (duh).
The entire dynamic content of the site could be served by a simple C++ executable that doesn't even need to use a database outside of startup. Populate a couple static data structures from sqlite, use libmongoose, microhttpd or a similar httpd library, and you're done. Fast n' easy, the entire deployment could consist of two files: a staticly linked server executable + bootstrap data file. The whole code, with syslog output, could probably fit a couple thousand lines or two, with comments and license headers :)
Buffer is one way of looking at it. Another way is a multiple-issue pipeline.
Or, perhaps, they are absurdly bad at catching the real ones, so they must turn the imaginary ones into real ones since they are much easier to catch.
"to arouse lust towards children" One could equally say that this satisfies said lust without, you know, involving any real children...
I'm probably feeding the troll, but who the fuck cares if the middle is not thin? Heck, I'd say who the fuck cares if the sides aren't thin - I have no problem with the look of the inch-thick '07 aluminum iMac. It'd be sheer insanity to try and make the whole thing as thin as a laptop, with the power supply inside of it. You can save quite a bit of money by not making it super-thin where the guts are.
These days the "hackery" is equivalent to booting to a working partition (can be on a USB stick) and running Multibeast. It's about as fire-and-forget as it gets.
There are two ways to a hackintosh: using random hardware, and using hardware that's purposefully selected to use the same components that Apple uses in their hardware. The "I''ll just try running OS X on whatever I have" route is perilous and ill-advices. Buying stuff from tonymacx86's buyer guide is a much saner choice, and it worked great for myself.
I've been using one for almost a year now, and there's no looking back. It was only tricky to set up because initial releases of Mavericks were trickier than the current release. I'd say it was a day well spent to set it all up. These days, using it is no different than using any Apple hardware would be, except that after OS version upgrades one has to reboot to the recovery partition and re-run Multibeast.
Modern HDDs media have coercivity so high that the Earth's magnetic field, and the fields from nearby "electronics", are immaterial. The best thing you can do to a HD is leave it alone, not spinning, in a non-condesing atmosphere. As long as the spindle doesn't seize up due to lubricant migration, it might well last for centuries.