Comment: Re:Tradeoff? (Score 1) 146
I've always wondered why there isn't some kind of expansion port standard for video cards on laptops. Let me plugin a video card black box onto the side of my laptop! I don't care if I need a power adapter for the video card box. That way I can use the normal onboard graphics as needed, but occasionally, when I want to game, I can just plugin my video card box, turn on my laptop, and the laptop will automatically switch to using it for graphics. Heck, maybe the port could be PCI express (without power if needed), that way it could have other uses as well.
Anybody more familiar with this issue (hardware or market) have any thoughts on the feasibility of this? Anybody know why something like this hasn't been done?
Possible reasons on the top of my head:
Laptop makers want a user to buy a whole new laptop when it is "slow".
Hardware issue.
Most users wouldn't use it and we only cater to the top X% of people.
Comment: MOD PARENT UP (Score 1) 308
Maybe someone will mod this up for others to see, but the thread is probably too old already. Thanks again.
Comment: Thanks (Score 1) 4
WOW! Hey thanks a lot. A lot of good quality information. I appreciate how you went through some of the reasons for choosing what you did as well. I've bookmarked this and will look into some of these technologies as I get time. Thanks!
Comment: Re:Advantages and disadvantages (Score 1) 308
I'm interested in your setup. I imagine some others that read your post might be as well. Perhaps some links to components you are using and an overall cost would be good. I'm interested in comparing this to some of the other options mentioned in this thread. Does your setup work with HD 1080P movies? That part is required for me.
Also, are you sure the people expressing interest every month don't just want to copy your particular collection and are drooling at the chance?
Comment: Re:Shannon-Hartley still in effect. (Score 2) 147
You get 56k out of it because of compression. Actual physical bandwidth is limited to about 34kbps of actual data transfer.
I'm no expert, but I did go to Wikipedia and it appears to indicate that your statement is false and 56k is indeed the base speed. http://en.wikipedia.org/wiki/56_kbit/s
However, with upload speed you appear to be more correct. (33.6 for V.90 and 48 for V.92)
http://en.wikipedia.org/wiki/56_kbit/s_modem
Modem compression (v.44 for example) can provide much faster rates than 56k. For highly compressible text, Wikipedia suggests topping out at 3:1 (~150kbit/s) rates.
http://en.wikipedia.org/wiki/V.44#Error_control_and_data_compression
If you feel my understanding on these Wikipedia articles is off, I'm definitely interested in hearing more.
Comment: Re:Texas Budget Deficit (Score 4, Informative) 811
This sounds easy on the outside, but in reality it is not if you are doing it right. (FYI: I have experience adding a third party sales tax vendor (similar to the API you write about) into ecommerce websites.) It definitely does not take 5 minutes and I wouldn't suggest that any script kiddie do it. (You are dealing with real money here.) In the real world, you have to deal with all sorts of things like:
*) Taxes that vary depending on the type of item being bought. (Meaning you have to make sure your items have the various classifications for all the various laws.)
*) Need to then deal with crediting taxes on order cancels/returns/changes, which can be even more fun when you are doing it for a split quantity returned.
*) Error handling when remote API goes down
*) Validating user inputted address matches up with a valid tax address.
*) Shipping is taxable for some areas and others not. So again, you get to deal with this headache every time there is an order return or other order changes.
It's definitely doable, just not near 5 minutes doable and is definitely a cost to be considered by smaller sites.
Comment: Re:Duh (Score 1) 227
I replied to a similar post above with: I don't think this would work, because the javascript could be modified as well. This means the modified man in the middle javascript could just return the expected hash.
Comment: Re:Duh (Score 1) 227
I don't think this would work, because the javascript could be modified as well. This means the modified man in the middle javascript could just return the expected hash.
Comment: Re:Duh (Score 1) 227
This solution only works against listeners, not injectors. So it provides a defense for those cases. It is not any less secure, but I admit to it being useless in this case where they probably were doing injection. (Didn't read article, probably should've.)