I Prefer a Stick: 2011

Wednesday, December 7, 2011

Quick notes on travel

On January 5, 2012 I'll be on a flight to Managua, Nicaragua. I've learned a lot along the way. This post will reflect the small bits of knowledge I've picked up along the way.

First, check the State Dept. site for the entry requirements for the country you're visiting. Delta checks your paperwork at check-in and if you're missing anything needed for entry, they'll refuse to let you board the flight.

If possible, find a good website dedicated to the country you're visiting as well (for Nicaragua, that's definitely NicaLiving.com).

ALWAYS do your research. Even after about a month of research, I learned this morning (even AFTER purchasing my ticket!) that Managua will only accept ONE checked bag because of my arrival date during a tourist season. Only found out because I read the full and very detailed Delta Contract of Carriage ( http://www.delta.com/legal/contract_of_carriage/index.jsp ). I don't believe I actually saw that directly linked from ANYWHERE during my ticket purchase. I'm going to ask at the desk if I can check both bags... this ought to be interesting :)

Also, you CAN take an uninterruptible power supply (UPS) on flights with you depending on your airline. Or should be able to. Most modern UPS's use (and are clearly labelled) "SEALED, NON-SPILLABLE BATTERY." Including my APC's lead-acid battery. :) Called some Hazmat hotline I found in a travel doc and the guy pointed me to this document. Hopefully you'll be able to find it if the link dies. It's called "Shipping batteries safely by air" and it's important to remember that the UPS makers don't want to have to spend extra worrying about whether their shipment method follows all the necessary regulations, etc. So for me at least, it'll work as long I'm under the 50 lb. checked luggage weight limit! :P

For Nicaragua, you should have at least USD$50 in cash on you and proof that you can support yourself during your stay... I don't know what that means so I'm just going to bring printed bank statements and hope that's enough. Certainly I'll be posting on here again if it's not! The USD$50 is for your visa, "tourist card," and the guy to help you through customs. At least in Managua, they can be a real pain.

Be sure your baggage is tough. I can't tell you how many stories I've read about people with crappy baggage that fell apart after a couple trips abroad. My bag is a Zuca Pro. Lifetime warranty, can be used as a seat (good for check-in and security lines at some airports), metal frame, great wheels, really tough, fits in overhead bins, and it's $65 cheaper in pink!

I'll add pictures later but hopefully this helps someone out! Please feel free to leave a comment or email me if you have a question.

Sunday, October 30, 2011

A brief overview of technology rebate experiences

So recently I built two very similar PC's for my own personal research. As part of the cost savings process, I bought multiple components with mail-in rebates (MiR's). This is a record of my experience.

Let's start with the good. My first check already came in from XFX. Yay!

My order for this part was placed September 4, 2011 and the check is dated October 7. If I recall correctly it couldn't have arrived later than the 15th. That means a maximum gap of just 6 weeks between these dates and I'm slow to mail this stuff! Please also note that XFX mails actual checks and not just those shitty prepaid cards from AmEx. They also don't hold your check hostage like a certain other company I'm about to mention...

OCZ offers their customers 6-8 week shipping for their AmEx cards... OR customers could just forfeit $2-3 of the value and receive it in 5-8 business days! :) Yeah. Right.

Notice something? Yes, I might have taken a week to get my documentation mailed. That's not what I meant! There's a 3 week and 5 day gap between OCZ receiving my documentation and going into "Reward Card processing." The funny part? XFX and OCZ's rebates use the same URL. Hmmm... I'd like to know whether OCZ pays for these added "features" or if XFX pays for speedy processing.

Of course since OCZ also owns PC Power & Cooling the rebates are just as wonderful a process:

Gee, thanks for continuing to hold onto my cash for me OCZ! UPDATE: And just like that, I received my first OCZ rebate the very next day after posting this.

Then there's Corsair... Yep, I was REALLY getting around with those rebates. I'm such an avaricious whore.

Seeing as today is October 30, 2011 I'm rather surprised by how much this sucks. Notably the Corsair site never leads you to an OCZ logo the way the XFX site does. That is, Corsair uses a different rebate processor than both OCZ and XFX. The acknowedged receiving the documentation on October 11 but have to do anything with it. Shit's like watching grass grow (but at least I can smoke that!).

Of course for all the problems the above suppliers might or might not have with the rebate process, no one can compete with Xigmatek...

(click for full size)

That's right. I've not received a check, an email, there's no website... Yep, I'm in the woods here :) I'm lucky I remembered that I sent this one in! FUN FACT: For a while at least (I've not looked at my rebate form) there was a personal email address to check with for updates on a rebate. Mmmmm, efficiency!

Anyway that's all I got for now folks but I hope you enjoyed the ride and appreciated my research.

BONUS TIME!!!

I bought that product on September 23. They still have a couple weeks to beat their record! :)

Tuesday, October 11, 2011

The fail of Google

When I was browsing for houses in Nicaragua online it kept offering to translate the pages via a toolbar at the top of Chrome's rendering. It's actually kind of annoying so I decided to read the "About Google Translate" section under the Options button and boy was I surprised. Here's the link if supplied.

https://www.google.com/support/chrome/bin/answer.py?answer=173424&hl=en-US

Here's what the page looks like to me today:

For a company that's supposed to be exceptionally expert at helping me find information their "help" site certainly isn't helpful. There's not even an immediately available way to report a dead link! Web design 101 FAIL. Congratulations Google. You aren't even good at what you're good at anymore.

Friday, June 10, 2011

Hackers Gonna Hack!

Wednesday, May 11, 2011

Fun Fact of the Day

I read somewhere a few weeks ago that Erlang took up 500K for a new "thread." I also read from the same source that programs could easily chew up massive (read: 16GB "server memory" costing ~$500 today from Newegg) amounts of memory. Well, using back of the envelope calculations I figured out that (assuming a 1MB thread size instead of 512KB) a server receiving 1Gbps would need:

Gbit = 1024 Mbit
Mbit ~= 1000Kbit
Kbit ~= 1000 Bits

1,024,000,000 bits downstream
DIVIDED BY
8 bits per byte
EQUALS
128,000,000 MegaBytes downstream

128,000,000
DIVIDED BY
650 Bytes (roughly the size of a request packet in a DOS attack with a long string name attached to the URL)
EQUALS
196,923 (and some change) <-- This approximates the number of request packets coming in

Now we're going to assume each request creates it's own thread so that we don't have to worry about privacy or code or variables spilling over from other users...

196,923 packets incoming
MULTIPLIED BY
1024 (1 MegaByte and roughly double the minimum space required to open a new thread)
EQUALS
201,649,230 (and some change)

Of course all this assumes that our packet queue takes up 0 memory and our processor is able to handle the memory allocations, etc. and we aren't even beginning to count things like memory overhead from pointers BUT it's the best estimation I've seen. And it indicates that I can very easily handle 1 Gbps DDoS attack on my server by writing it in extremely lightweight Erlang.

The design of my implementation of the server will GREATLY influence the amount of memory it chews up with each request and the stability of the server and where the performance bottlenecks will be. I believe designing to survive a DDoS attack would be an excellent choice for most servers and should be attempted.

Wednesday, March 16, 2011

Personal Issues (or RemoteFX)

So after a solid week of research, installation, reinstallation, and troubleshooting (and not necessarily in that order) I discovered why I couldn't get my server to work even when following some excellent step by step instructions.

RemoteFX actually requires two physical GPU's. Nowhere is this mentioned in the documentation because on servers chipset (and now integrated CPU) GPU's are basically at 100% penetration. RemoteFX needs the discrete GPU that will power the VM's and enable resource sharing. RemoteFX also needs a secondary display adapter to run the video capture software on. Why this is not mentioned anywhere or had to be implemented in this way I have no idea but there you have it.

RemoteFX actually requires dual GPU's even if one is extremely weak or even software based.

Hope you aren't stuck with an adapted Dell workstation without a video out and only one PCIe x16 slot :(

Tuesday, March 1, 2011

It's a beautiful day in the neighborhood!

It always feels like it's been ages since I did an update. Today I thought again of Mr. Rogers (aka Fred Rogers) and decided to name this post in his honor even though it has nothing to do with him. RIP Fred. ;_;

Today I worked out a better way to configure my VM's. I was working the walkthrough on setting up Citrix's XenDesktop Express (which by-the-by, does not have a time limit but rather user limit) when I noticed the walkthrough video included on the DVD talked about an article with several suggestions and among them was disabling SuperFetch. After a few days of digesting the info and finding a good place to try it (school of course, not work) I figured out some of the magic :) We run a VMWare ESXi/vSphere 4.1 server at school and (long story short) have bunches of verrrry slow VM's on there that would be much more useful if they required less time. For example, an update to an instance of an Exchange server running on the machine might take 30 minutes or more. Frankly that's unacceptable. After some testing I came a few conclusions about maximizing performance of virtual machines and have written them up here.

Windows 7 VM's:
Not sure where the perfect balance lies but somewhere between 1 and 1.5 GB's of RAM the VM goes from slow and choppy to silky smooth.

Suggestions:
Set RAM at 1.5GB
Disable SuperFetch
Turn off the page file
Minimize video RAM

Exchange 2010 SP1 on 2008 R2:
Have not done much testing here but here's what I've got so far...

Suggestions:
Set RAM to 4GB
Turn off the page file
Minimize video RAM

Windows Server 2008 R2 with Global Catalog or Local Domain Controller functions:
Testing done on a Citrix XenServer install. Notably performance actually improved after disabling the page file.

Suggestions:
Set RAM to 1.5GB
Turn off the page file
Minimize video RAM

That's it for now folks, maybe I'll update this in the future (hopefully!) but probably not. I at least hope it was helpful for someone :) Thanks for reading!

Thursday, February 24, 2011

I think I just figured out UBB (usage based billing)

See I've been reading about this via DSL Reports and Ars Technica and between their posts and a post by Peter Nowak I do believe I have this figured out.

1) ISP's will not disclose data on congestion.
It's complicated but basically I believe congestion is created for political reasons. Not to support UBB mind you but to leverage the most money out of content delivery networks like LimeLight and Akamai. You'd have to do a lot of reading to see why I came to that conclusion but all my information stems from the discussion on NANOG around the Level(3)/Comcast dispute.

2) Marginal cost for ISP's is falling. Fixed costs are fixed.
High users of broadband don't really cost an ISP more money and we already know that. Netflix and (many) others claim a cost of less than 3cents/GB and falling to deliver traffic. So we know the ISP's are not proposing this to help cover the marginal cost of delivering a GB. On the other hand fixed costs are probably not decreasing as fast as ISP's would like.

3) ISP costs are tied to the price consumers pay.
I could look up a million economics theses supporting this or I could leave that as an exercise to the reader.

4) The more subscribers an ISP has then the less each pays (since almost all costs are fixed).

5) This encourages ISP's to pursue as many customers as possible at as high a density as possible.
Let's say it costs $250,000 to hook up a neighborhood. Each house costs another $250 to set up individually. Each GB costs 3cents (and falling!) to deliver. Hmmm... I wonder which cost the ISP is most concerned with recovering?

6) An ISP will deploy whatever methods it deems necessary to increase subscribers.
See this is arguably one of the great parts of capitalism. The ISP actually wants to spread its costs out as much as possible so it will continue lowering its prices (and reaching new customers!) until...

7) The bean-counters say it we go lower we might start losing money (or not making as much altogether).
Since the hardware costs cannot be lowered (I'm certain they've tried this approach as its the cheapest and least resistant) the ISP moves on to business strategies.

8) Someone says "Hey, what if we charged some users more and some less?"
The conversation might go something like this:
Executive A: "That's a great idea! How do we do it?"
Executive B: "It'll be like a toll road. You already pay taxes but the more you use the more you pay."

Conclusion: So the ISP in attempting to broaden its reach and connect the most households (subsidizing its costs and lowering its risk through a greater pool of customers) has developed what it describes as a "fair" billing system. There are other details like how an ISP wouldn't want wholesale customers competing with itself but this is basically the situation and the motivations as far as I can tell. Whether this is fair or an appropriate solution to the ISP's incessant search for improved efficiency is ultimately up to you.

Friday, February 18, 2011

Either it is or it is not.

Two possible reasons for running across the "error: Error parsing XML: unbound prefix" issue on building your Android app.

1) You have not properly specified an XML namespace for Android to use. Fixing this is easy, just add

"
xmlns:android="http://schemas.android.com/apk/res/android"
"

immediately after the opening of the first LinearLayout tag at the top of your document. This will allow the interpreter to parse the rest of your document and recognize the android: properties.

2) You have an error in your XML that is very likely a spelling mistake. When I was searching for this I was confused because it repeatedly specified the opening of the XML tag which was on a seperate line from the actual misspelling. I had to go down three lines to where I had specified andriod:id rather than android:id.

Hopefully this helps someone! :)