Posts (page 2)
Outrageous Stats:
Stock: 300HP, 300lb ft. of Torque
After Dinan: 414HP, 474lb ft. of Torque
I dont have the testing gear, but rumoured to be in the 4 second range for 0-60mph.
Needless to say, it is insanely fun.
In my professional opinon - AT&T should not get a single dollar for any service they offer. I could explain in great detail, but I'll just leave it as simply stated as "I never plan on doing business with AT&T and I would recommend you not either"
On 10/15/07, david benett wrote: They even had a Cesna flying ahead of them
http://jalopnik.com/cars/speed-record/alex-roy-reveals-transcontinental-run-claims-record-310735.php
-----------------------------------------------------------------------------------------------------------------
On 10/16/07, Ben Lutch wrote:
I still claim my 3 hrs 21 min (verified by you Tongue) to be the fastest UCLA-to-MTV run practically achievable. These dudes' average speed cross-country was ~90mph, and mine was closer to 100mph (forget the exact mileage). That was also the run where I hit 175+mph on I-5
Now driving a 525i with 3 baby seats,
b
-----------------------------------------------------------------------------------------------------------------
On 10/15/07, david benett wrote: I can attest to the time.
I called him on his land line in Mt. View 3 hours and 21 minutes after leaving Westwood.
-----------------------------------------------------------------------------------------------------------------
On 10/15/07, Jon Prall wrote:
The Cessna is officially cool. That plane is refueling a lot as well though.
I've done this exact trip (Napa to northern Massachuesttes and Napa to Sebring Florida (Central FL)). Both trips took me less than 48 hours. Both with cars in tow though.
There are two alternative vehicles that would be interesting. My truck, which has 120 gallons, but could be changed to have 300 gallons. Top speed is 100MPH but it can store food, has a bathroom and with two people there wouldn't need to be any stops whatsoever.
With 300 gallons and the truck getting 9 miles to the gallon, you still get 2,700 miles before you have to refuel. Having more than 300 is also easy.
So that trip is simply a set the speed at 100 and don't stop. Downside, there are lots of times where you simply can't go 100 with the truck and you can't make up the time by driving faster than 100.
Next Vehicle: A motorcycle. Currently a BMW motorcycle with a top speed of over 173 miles per hour, has a 7.1 gallon tank and get 40mpg (when going really fast) netting 284 miles. Even if ugly, a sensor goes into the main tank, when it's is low, it turns on the pump of the auxiliary tank which then fills the main tank. A standard accessory is a 'top case' from bmw that sits high above, but behind you. It holds 13 gallons. A bladder situation could easily make this a total of 20.1 gallons netting 804 miles between fill ups. You would need to fill up 4 times and there would be plenty to spare. I give the m5 8 fill ups.
The motorcycle has some serious advantages if it has the range of 800 miles. Coast to coast = always hit traffic in some city. Motorcycle = lane split.
That motorcycle does 173 like it is nothing: http://www.youtube.com/watch?v=tqvkNDx6JwM
I've driven the coast to coast thing enough times to know that it is always a two lane road and *constantly* you are are stuck between an asshole on the left hand lane and semi-truck in the right. It's a little sketchy, but you get used to lane splitting a semi and a car.
Motorcycles are small on radar too. That said, they are more than capable of carrying a ridiculous array of gadgets and communication devices.
Downside, gotta do it solo. 31 Hours is a long time for one but doable.
Also, the m5 is fast, but the ability for the K1200S to just jump to 173 and back down is far easier than in the m5.
Totally tempting. Would be fun as hell. Who's flying the plane for me?
jp
----------------------------------------------------------------------------------------------------------------------------------------
On 10/16/07, Ben Lutch wrote: Had you asked me 10 years ago, I would have been headed to the Palo Alto airport to get a license.
I am a lesser man
b
-----------------------------------------------------------------------------------------------------------------
The brutal reality of this endevour can be found here:
http://www.wired.com/cars/coolwheels/magazine/15-11/ff_cannonballrun?currentPage=1
This is the best explanation yet about three phase power:
Three Phase Power: The most common type of 3 phase is called 3 phase WYE. This is a
5 wire power system with 3 phases, neutral and ground. The three phases are 120 degrees
out-of-phase with each other, requiring only one Neutral return wire. The shared Neutral
reduces overall wiring costs. Another advantage of 3 phase is the “dual voltage” capability.
A three phase connection can provide 120 volts by connecting phase to neutral or 208 volts
by connecting phase to phase. This is ideal for a system where equipment operating at
both voltages is required. One power cable and receptacle can replace three single-phase
connections. One 3 phase 20 amp connection is equal to 60 amps of single-phase power.
3 phase power is ideal for power intensive environments such as data centers or large ATE
(Automated Test Equipment) systems.
http://www.pulizzi.com/store/2007_Catalog/2007_Catalog_Full.pdf
Next Question - How can you utilize 3 phase and how would the wiring be?
First, there are 5 wires - 3 (Phase A, B, and C) are hot (208V), a Neutral, and a Ground
If you want three 120 volt circuits you connect each phase to Neutral.
Phase A to Neutral
Phase B to Neutral
Phase C to Neutral
If you want three 208 volt circuits you connect each phase to another phase.
Phase A to Phase B
Phase B to Phase C
Phase C to Phase A
Neutral is not used for creating 3 phase 208 circuits. In either 120 or 208 cases the Ground wire is there purely for safety and does not carry any voltage.
This is my blog and I get to say what I want - This happened purely because a stupid bitch in a Ford Excursion drove over my parked bike. Said stupid bitch drives away leaving no note or information. I am not done with stupid bitch.
There is so much to learn from Mad Men on AMC.
There us a lot of simply horrible behavior, but when they are 'on' negotiating a business deal, or showing how it is done at a cocktail party, it is simply amazing to watch. This is a great show.
1) Capacity First - Optimizations Later - this rule broken will guarantee downtime. Do not optimize under the stress of downtime - focus on capacity first.
2) Make sure you have every net available to catch you – Postgres examples - WAL Files, Slony Replication, Snapshot technologies, Disk based DB versioning (spinoff of Snapshots)
3) Do not 'Optimize' problems into your architecture. Often things created to solve problems turn into operational albatrosses to maintain later.
4) Keep it simple. Keep it simple, because you are smart. Do not make it overly complex because you can.
5) Caching should be used very sparingly and really in order to protect resources that are hard to horizontally scale. If you can scale something horizontally, rarely is it wise or prudent to add a caching layer. If used, it should be to gain performance for the end user NOT to gain capacity for a web site; otherwise, you have just created another bottleneck that has very unclear limits of capacity and their potentially negative impact to the system as a whole.
6) Don't code everything in house; do not buy everything from vendors - use the right tool for the business at the right time
7) Negotiate - the only way to negotiate with real strength is to have done the homework of creating options that are viable so that you would be willing to walk from your preferred vendor if necessary. Do not bluff.
8) Always N+1 and if N=1, do not under any circumstances use +1 for anything but waiting for N to fail. There are many times when opportunities to have N+2 arise – take advantage of them.
9) Data loss is never a risk the company can take - this has been universally true. The cost of lost data far exceeds the cost to ensure data cannot be lost
10) Parallelize whenever and wherever you can - this is an important way of thinking when it comes to multiple locations. For example, If MogileFS were setup to be location aware and needed to replicate its data in real time, it should work so that each MogileFS server can replicate its data to the entire load balanced farm of MogileFS servers at the other end. Implement many to many wherever possible.
11) RTFM - To this day, I will read the entire manual of a pair of RAID cards to see what the subtle differences are. The devil is in the details. Do your homework
12) Know your bottlenecks and know how to spot them - every layer - know if you are blocking on disk, RAM, or CPU. It is usually that simple.
13) Have a regular capacity management process - Do not react. Be proactive. Knowing where your soft spots are is critical to staying ahead of the capacity curve.
14) Don't promote failures and do not fear change
15) Do not breathe your own exhaust. Do not think that the output of your work should be the motivator for how you do things in the future.
16) Ops people that code should write ops tools, not application software
17) The value of a project manager, tech writer, and financial analyst in the ops organization should not be underestimated. They will more than pay for themselves.
18) Monitor EVERYTHING - alert on actionable only, record other for trend information
19) Have a regular process to look at trend data everywhere
20) Do not make the monitoring so noisy that it becomes useless
21) Ensure your monitoring system is so simple EVERYONE in the company can easily use it. It is surprising how often ops metrics turn into business metrics, marketing metrics, sales metrics, etc.
22) Do post mortems only if the people that can make changes are there. Otherwise, it is a waste of time.
23) Publish your post mortems. Attach the event data to the post mortem so people can easily look at keynote for example and connect the incident to the data.
24) Assign people to be point people for every bit of technology.
25) Assign backup people to those primary people.
26) Hire constantly - even when you do not have headcount - always be hiring.
27) Be your own harshest critic. You can always improve no matter how smart you are or think you are.
28) Compare yourself to as many companies as possible. Look outside of the company.
29) Pick one Tradeshow/Conference, only one, per year and go. If the one meets more than once a year fine, but pick one and only one.
30) Buy what you need, not what you want. Never ever, take off your corporate hat and leave the "what's easiest and safest for me" hat on.
31) Do what is best for the business always, even if that means you should not be there.
32) Formulize accountability - record commitments, circle back on those, expose commits not made.
33) You should not get more than one or two times to fail. There is goodness in fear
34) Be ruthless - your competitors are.
35) Think of the work you do as something you want to sign your name with when done. That also means finish the job.
36) Be available for others.
37) Partner with startups - give them your expertise and scale and you will be rewarded with free product, sometimes for life.
38) Capacity is a business/product issue. This means the net cost per page/post/login, etc. must be visible to make the right business/product decisions.
39) Always beat the budget. The Operations group is usually the largest spender of discretionary money. Revenue targets are often missed, but the Operations group has many ways usually to defer spending, etc.
40) Because something sucked in the past, does not mean it will suck today or in the future - try things and have the tools to test
41) Documentation - document everything - well. Make it so new people should not have to talk to anyone to learn everything
42) Create gigantic plotter size drawings of the physical layouts of your data center
43) Create gigantic plotter size drawings of the logical flows of each of your products
44) Faq-O-Matic, Wiki, something where people can easily post "this is how you fix this" and make it very findable. This is where a tech writer comes in handy
45) Make sure everyone, truly everyone is totally replaceable
46) Most people get more done at home, than at the office, some people do not.
47) Bundle your orders - you get to ask for the most discounts, contract terms, etc when you have batched your hardware orders. Ask for everything - price locks, spares kits, lease terms, everything before they get the PO.
48) Develop long term relationships with your vendors - make sure you can call them at your next job
49) Give everyone in ops everything they could ever use to make them useful remotely - Treo’s, EVDO card, dual 24" LCD Panels, ANYTHING and EVERYTHING. The costs will be more than paid back by effective remote employees. Remember Ops (and Eng) are power users and understand what a pixel is and will make the most of screen real estate.
50) Be a complete stick in the mud with IT standards. Until the Mac runs office 2k7 and outlook, you have to run some form of windows. Period. Unless it is *all* Macs - it destroys office productivity for meeting/calendaring, contact management, mail lists, etc. If an employee is willing to stake their job on running an instance of XP on parallels, fine. This is very rare
51) Have a streamlined purchasing process - know your budget, make sure you get to manage to it.
52) The weekly meetings must have continuity. Items from previous meetings committed to then must have accountability.
53) Create a separate escalation system to involve engineering into the problems with code that effects operations negatively
54) Incorporate Operations staff in every stage of a feature or product development. From design, so that scalability, monitor ability, reliability are baked in, to production which makes sure operations is responsible for hardware procurement, monitoring systems in place, run books written, etc and that it launches on time and according to operational standards
55) Practice for being a real company - Sarbanes, WebTrust, SAS 70, Visa, Banking, etc. Do not forget that if you are successful you are going to have to deal with this stuff. It is easier earlier in the process, if it is nothing more than awareness and knowledge vs. any real change early on. Deploy a ticketing/task tracking tool. USE IT. Put change control/change management into the same system. USE IT. Keep putting info in there. It helps to figure what "what changed in the last week" as an example.
56) Do not make it hard to have redundancy or multiple locations. Things are hard in the beginning, but do not slow your success down with bad architecture that does not allow true scale and reliability.
57) Oracle Standard Edition is affordable. If you can constrain your use of Oracle to Standard Edition, there is no reason that a viable business even a small startup cannot use it.
58) Postgres and MySQL are free for a reason. If you do not really care about transactional integrity, MySQL is fine. Until the mandatory chaining of the words 'Vacuum' and 'Postgres' is broken, Postgres represents an unpredictable, usually negatively surprising database. InnoDB - Oracle owns it and you have to pay the man on that now.
59)