Category: Work

Sep 09 2009

RIP Nortel

[UPDATE: Avaya did indeed win the auction, for nearly twice their stalking-horse price. We'll see how that plays out.]

This Friday, Nortel’s enterprise products division will be auctioned. Avaya is the stalking-horse, with numerous other companies additionally submitting bids. If history holds, Nortel Enterprise will not be Avaya’s, but belong to someone else (despite all the buzz Avaya and its partners are making). Regardless, that someone will acquire the best enterprising data switching platforms made.

Hands-down, the ERS 5000 -series has continued to be the best integrated UTP switch, since coming onto the scene many years ago. Beefy backplane, generous uplinks, flexible stacking, decent price-point. I’ve baked switches from every vendor willing to send me gear, and no one can handle the battery like an ERS 5000.

The ERS 8600 chassis-based platforms also make a mockery of the competition. Robust, redundant backplanes; extremely flexible slotting options; ridiculous feature set; decent price-point. Better marketing could have really pumped this line, as a number of the slot options were best-of-breed. Again, I’ve baked a number of chassis, and the 8600-series delights on most all of the benchmarks that matter.

There are lots of other diamonds in the enterprise space. Quite a lot. I’m not a “loyal” customer of anyone: I believe in market Darwinism. Unfortunately in this case, the best products were latched onto a fiscally irresponsible company, led by brain-dead opportunists who from the outset have undermined the legacy that is … was … Nortel.

I look forward to Friday – to see who’s getting the chance to own the best-of-breed enterprise networking products, and hope when they sit down and take a good look, they realize what an amazing set of assets they have, and Do The Right Thing with them.

Regardless, Nortel is a less-than-skeletal image of its former self, and a venerable multi-century legacy is all but a footnote.

Sep 08 2009

A Rebuttal of a Rebuttal…

Somehow, while clicking away at the Internet, I managed to get to this blog post, which is a rebuttal of this article by Cory Doctrow about cloud computing. Please keep in mind I dislike most of the things that come off of Cory’s fingers intensely, and even elements of the aforementioned article. Where I blew an artery was at the rebutter saying:

Cloud computing fosters intense competition.

This is not just wrong (people are wrong all the time, and I don’t blog about it), it’s dangerously wrong. Nowhere in technology have we had less competition potential, and more monopoly potential than in the realm of cloud computing. Why? Cloud computing is all about size and marketing. I remember back in the day when I was happily using WebCrawler to scour the Intertubes for what I wanted to find, when some jerks from Stanford started some crappy search engine called Google. Pffft. “There’s tons of competition in the search engine market”, the analysts said. I was concerned then, I’m concerned now.

Any centralized Internet service is about size and marketing. Read up on my last post if you want to know how I feel about centralized services in general. Right now there are three major players in the “cloud computing” market. That will grow, as did search engines, to probably 20 major players and everyone will think I’m nuts, and then they will be slammed against the wall by One.

One that claims not to be evil.

One that believes (truly) they’re doing good.

One that rules them all.

This is not some psychic prediction, this is the recognition of a pattern that has played out too many times in the young life of the commercial Internet.

Sep 02 2009

Distributed By Design

The Internet, by taking its name literally, means “the network between networks”. 40 years ago today, the Men and Women that first started implementing the technologies that grew up to be the Internet didn’t want to create one network- they wanted to unify distributed networks redundantly. They wanted to do it this way so that a problem on one network, had literally no impact on other networks – and especially no impact on the Greater Network.

Yet humans are congregational, fashionable beasts. Humans, in general, want to be where there are other humans- even virtually. They want to be a “part of something”. They want to be on Facebook or MySpace. They want an iPhone. They want a Gmail account. They want to be LinkedIn. They love fads and the feeling of faux exclusivity that they bring, like Twitter. They fight against distribution.

The Fallout of Centralization

When Gmail is offline for a few hours, it makes international news. Millions of people across the globe are without e-mail! Crisis! Panic! When Facebook “gets a virus”, it’s international news! Millions of people are at risk! Crisis! Panic! When Twitter gets knocked offline, it’s international news! Millions of people can’t tell each other what they’re eating! Crisis! Panic!

Why won’t they get their e-mail from a more local provider? Why won’t they get other services from a more local provider? Why do people by Macs? Why do people like malls? They fight against distributed designs, and try to pull things together. “One-stop shopping” to a network neophyte is all giggles and rainbows- To a network architect it’s “bad design”.

Internet history is littered with fads and centralized solutions that inevitably fail to retain attention after the Next Big Thing arrives: But distributed solutions tend to last much much longer. Why?

The Argument for Centralization

There’s only one reason Google loses more money than my lunch cost every time someone watches a YouTube video: Control. Companies offer centralized services so they can control their users, their content, and their market. Facebook doesn’t care about user privacy or quality services, they care about making money (or, in their case, losing less money). They want you to be on their site as often and for as long as possible, and they’ve already sold your information in order to fund more gizmos and whirligigs (“apps”, they call them) to keep you coming back and sticking around. Control.

If Facebook was distributed – anyone could put up their own Facebook-compatible site, and allow other geographically-similar people to use it – how would they exercise control? How would they censor you, collect your personal data and sell it? How would they push you the latest version of your favorite whirligig? How would they profit off of you (or prevent someone else from profiting off of you)? Control.

While Gmail is a centralized interface to a distributed system (collectively known as “e-mail”), they’d just love it if everyone used Gmail and there was no distributed e-mail system. They mine your e-mail for keywords to target ads at you, making truckloads of money at the expense of your privacy- Ads that companies pay a premium for because Google can already “guarantee” you’re interested. Control.

The Argument for Distribution

Keeping components small, simple, and “close” is a doctrine of many disciplines, and is imperative for “critical infrastructure”. I have more than one client that intentionally buy equipment from multiple vendors, to reduce risk of single-vendor product failures. Several only update a fraction of systems and application software to new versions at a time, to reduce risk of debilitating bugs (one client, literally, has some 8 year-old operating systems running unpatched for this reason). More, and more institutions have multiple WAN (“Internet”) connections, from multiple providers, to reduce risk of single-provider failures.

Distributed infrastructure is more about “us” (the global network users)  than “you” (the individual). You don’t care whether Gmail (with a few million users) is down, or whether your ISP (with a few thousand users) is down: all you care about is that you can’t get to your e-mail. Because of this, it’s hard to convince “you” that distributed is better. You, the individual, don’t care about network survivability or how many other people are impacted- you only care about yourself, and your inability to access your mail.

Would you like to travel to your State capital to go to a centralized hospital? How about to the National Library to check out a book? When it comes to travel-related logistics, most people go “duh, local hospitals and libraries and schools and whatnot make tons of sense”: But once they go online – once that facade of geography is lifted – eYouSpaceFaceGoogleTwitterBookMailBay.com really is the best thing in the world, OMG?!!

HOWTO

So what can we do? What can you do? Appreciate and utilize local, distributed infrastructure. Don’t outsource/offshore your new whizbang application when your local hosting provider can handle it. Limit your dependence on centralized services, and find distributed substitutes where needed. Pretty much every infrastructure application has a distributed counterpart, many of them with much much less evil than their centralized cousins. I’m not saying “don’t go to website X” – I enjoy Wikipedia and CNN and all sorts of centralized information sources – but I don’t depend on them for communication, and I certainly know other places to go if they’re offline.

Distributed service architectures are about freedom and survivability. Centralized service architectures are about captivity and control. Happy Birthday, Internet. I look forward to another 40 years of architectural ingenuity.

Jul 27 2009

FOSS’s Microsoft Hatred “a Disease”

Purloined wholesale from SlashDot, and reposted. The hypocrisy of a vocal minority of FOSS-purists has been overwhelming. As Linus accurately points out, we’re all in it for selfish reasons. No one likes working on the boring bits, and we all contribute our best code to the things we care about at the moment.

“In the aftermath of Microsoft’s recent decision to contribute 20,000 lines of device driver code to the Linux community, Christopher Smart of Linux Magazine talked to Linus Torvalds and asked if the code was something he would be happy to include, even though it’s from Microsoft. ‘Oh, I’m a big believer in “technology over politics.” I don’t care who it comes from, as long as there are solid reasons for the code, and as long as we don’t have to worry about licensing etc. issues,’ says Torvalds. ‘I may make jokes about Microsoft at times, but at the same time, I think the Microsoft hatred is a disease. I believe in open development, and that very much involves not just making the source open, but also not shutting other people and companies out.’ Smart asked Torvalds if Microsoft was contributing the code to benefit the Linux community or Microsoft. ‘I agree that it’s driven by selfish reasons, but that’s how all open source code gets written! We all “scratch our own itches.” It’s why I started Linux, it’s why I started git, and it’s why I am still involved. It’s the reason for everybody to end up in open source, to some degree,’ says Torvalds. ‘So complaining about the fact that Microsoft picked a selfish area to work on is just silly. Of course they picked an area that helps them. That’s the point of open source — the ability to make the code better for your particular needs, whoever the “your” in question happens to be.’”

Jul 20 2009

“You’re Welcome”

[NOTE: This post was from 5/20/2008, but went unpublished]

Where has this phrase gone? I’ve stopped saying it, subconsciously. I think it’s because everyone around me doesn’t say it. Then, for some not concious reason the other day, I said it and was scowled at. I found that interesting.

We are, it seems, obligated to minimize our efforts that people thank us for. Instead of saying “you’re welcome” we say “no problem” or “no big deal”: We go out of our way to make the other party feel like their thanks was nice, but unnecessary-that our expended life energy on their behalf was somehow forgiveable and not worthy of mention- instead of making it clear that their thanks was necessary, and yes we did do something that they should remember- our life energy was expended for them, and is forever lost.

The scowl was because I committed a modern faux paux: My expression of “you’re welcome” obligated the thanker to acknowledge- internally at least- that someone did do something for them, and it wasn’t just “no big deal” or “no problem”, and they resented that.

So it ends now. The responses of ‘np’ and ‘nbd’ will be replaced with what they should have been all along: “You’re welcome” (or ‘yw’) and I heartily encourage everyone else to do the same.

May 19 2009

“Secure Programming”

Earlier this year I developed a two-day seminar for a client on “secure programming” techniques. The intended audience was automation programmers, but at the last minute, after seeing the “syllabus”, they decided to include their application programmers. The result was a flurry of re-working to accommodate the Java crowd in addition to the Perl/PHP/Python crowd. In the end, the bulk of the message was the same. While I can’t republish my stack for trade-secret reasons, I can dump the agnostic bits (mostly my slide notes) here. The code examples will be in human-readable Perl or pseudo-code, but will work in any language.

Users Are Un[trust]worthy

The first, and most important point, is that you can never trust user-supplied data. Ever. Just because your whiz-bang drop-down box only shows the user four options, doesn’t mean they can’t end up sending `rm -Rf /`. This is the single largest threat against an in-house application. User-supplied data must always always be vetted, sanitized and treated as if it could take over the world. A lot of programmers use rapid-application-development tools to create interfaces. These tools are a boon for creating slick interfaces, but generally a complete bust at data integrity enforcement. You tell it “make this a date field”, and it does… But anyone with a quick script can insert 40MB of garbage data, which will at best crash your application, and at worst, overflow a buffer that had improper bounds (see next point) and allow “remote execution of arbitrary code” (READ: You’re fucked).

So how do you fix this? Regardless of the languages you program in, they probably have a regular expressions (regexp) library. Many popular languages even have “Perl-Compatible Regular Expressions” (PCRE), as there is no better language for data process than Perl, and its regexp syntax is well-defined (albeit with a moderate learning-curve). Regexps are the easiest way to enforce your intentions with data.

unless($userdate =~ m#^\d\d\d\d/\d\d/\d\d$#) { Freak_Out(); }

That’s a one-liner that says, exactly,”unless the data in the variable $userdate begins with four-digits, followed by a fore-slash, followed by two-digits, followed by a fore-slash, followed by two-digits, and that’s it – Freak Out”. (m – we’re matching, # – start the regexp, ^ – match at the begining of the data, \d – a digit (0-9), $ – match the end of the data, # – end the regexp).

You could easily write a function to do this for you:

sub Is_Date {
  my $userdate;
  if($userdate =~ m#^\d\d\d\d/\d\d/\d\d$#) { return 1; }
  else { return 0; }
}

Then just call

unless(Is_Date($usercrap)) { Freak_Out(); }

every time you need to check that you’ve REALLY got a date. Not hard. The user could still be entering the data wrong, but that’s not the secure programmer’s job. :)

It is imperative that your application go out of its way to recognize crap as soon as it can. Don’t pass a variable containing unchecked user-supplied data to a dozen  or so functions before checking it. Accept it, and check it immediately. SQL injection attacks are another whole can of worms that can take advantage of improper sanitization, and frequently get executed in strange places. Sanitize early.

I know you guys aren’t writing AJAX stuff, but I’d be derelict if I didn’t hammer this out anyhow: If you trust JavaScript or any other client or browser -executed code to do your security bits for you, you are not only a moron, but should be made to wear a Scarlet Zero for the next few years. Zero for “0wn3d”. Just because you write JavaScript, doesn’t mean that’s how the browser will execute it. ANYONE can rewrite your JavaScript to do whatever they want. The above IsDate function, if implemented in client-side JavaScript can easily simply “return 1″ regardless of what’s passed. You must never trust client-supplied data regardless of whether you believe it was vetted client-side. It must be vetted server-side. Must. Must. Must. If, for user convenience, you want to implement something to trap errors quickly client-side, that’s groovy, but in no way does it excuse you from vetting the content once submitted to your application.

I can’t say this enough. It seems like common-sense, and a lot of you are nodding at me right now, but a month on you’re going to write a quick webform with radio-button selection, and someone in Bejing is going to own your database server because they submitted `echo root:fXAWEOo7DsNSM:0:0:0:0::: > /etc/shadow` to the “What’s your favorite fruit?” question. [PAUSE] It’s funny right now, it’s not funny when you’re facing a DoD inquiry.

Data Sizes Are Critical (AKA Know Your Data)

The second most important thing I can convey to you is the concept of sanitizing types. Those of us in the room that are automation programmers and write in the P-languages don’t have to give a shit about this, but those of you using Java, C or anything that comes out of Redmond, WA need to listen up: If you’re blindly stuffing data into a restricted type, you better be damn certain it’s the right size. Last year one of your competitors had a nice lad write an internal automation system that took data from a database and did things with it. Anyone know how large a MySQL blob-type is? 64k bytes. Anyone know how large a Microsoft Visual BASIC date-type is? 8 bytes. Thankfully, he wasn’t writing a user-facing application. [PAUSE] Last I heard, he was writing TARP-laundering algorithms for AIG.

Everytime you hear about a “buffer-overflow” attack, this is because some moron didn’t check data before stuffing it into memory. The lower-level you code, the more important this is. The example I gave about the VB app only cost the contractor a few dozen-thousand dollars and a loss-of-face from their client because VB just panics and dies when you do that. If you’re coding in C and not running on a very secure linux box with a memory-jockeying system, you may well have just overwritten your security code with:

blahblaWastingSpaceUntilYourDataTypeIsOverblahblahblahCall Function DoSomethingBad

Yeah, that’s what a buffer-overflow looks like. Know your data, and when in doubt cast. A lot of instructors shy away from casting. It slows things down, it causes a lot of compile-time checks that frequently create errors or warnings in otherwise clean code. Casting is the absolute best way to make sure you’re not blowing out a primitive type. Of course, if you’re writing into a char-array, that’s not going to help you, but that’s your problem. :)

Lazy Handles

You guys know all about access permissions, so I’m going to skip over a bunch of stuff. One thing I’ve seen here and elsewhere, is opening handles – network sockets, database handles, file handles, directory handles, etc. – as users with way more permission than necessary. Sure, it’s easier for you, but what happens when your code gets hosed and someone from Bulgaria managed to inject themselves in before you’ve let go of that handle? Explaining to your boss that you opened the files as root “because it was easier” isn’t going to fly. Your application needs to run restricted, which you already know, and you absolutely cannot wantonly elevate handles without damn good reason. I can’t count the number of applications I’ve seen – Hell, applications I’ve written – that immediately connect to a resource as God himself to do some stuff that’s pretty primitive – and maybe, MAYBE one operation in fifty that actually needed that access. Which leads to the next problem here…

Keeping handles open longer than necessary, or in anticipation of future operations. If your application does six operations on a resource and only one needs the assistance of Angels, then that’s the only operation that gets the Silver Trumpets – the rest can stew along the rest of us. I don’t care if you’re doing all six of those operations at once: you run the primitives as a primitive user, and then either change-user or fork or whatever you need to do as the elevated user for that one operation. Yeah, I groan about it too. But that’s it. Every moment your application has an elevated resource connection, is a moment that someone is going to get their

INSERT INTO USERS user='yakov',password='smirnov'; GRANT ALL FOR ALL TO USER identified by 'yakov';

into your data. It’ll take your auditors a fiscal quarter before they find that account.

With the exception of operating-system handles, you can almost always switch out, rebind, setuid, or the like, without making a new connection.

1176da21241f79203fbd93e367f35142

Yeah, encrypt everything. I know you guys are using SSL for nearly all resource connections, which is ridiculously important. Even the server-to-server stuff that we used to shrug off and say “yeah, well it’s on a switched network, and in the same room” has got to be encrypted on the wire. There are too many techniques and tools out there to get in the middle of those streams, and we all know how reliable network administrators are at picking up that stuff. [PAUSE]

Even within your application, if you’re writting out temp data, encrypt it from possibly prying eyes and processes. If you’ve got in-memory data that’ll be sitting around for some time, and might be a candidate for swapping, encrypt it in memory. How many of you have ever even considered encrypting live data? If that data gets stale, and the operating system decides to swap out some pages, that stuff is possibly going to be visible unless your infrastructure takes into account encrypted swap and the like. In lots of languages, encryption and decryption of relatively small amounts of data (< available RAM) is pretty simple. I’m not advocating it for everything, but there’s not much harm in:

$data=encrypt($data);
{ #Long
  #Running
} #Block.
$data=decrypt($data);

If something weird happens, and some or all of $data is swapped out because it’s not being used, it’s useless to an attacker.

Apr 27 2009

They Lie Because They Can

Bruce has an excellent post about the data you’re voluntarilly giving to corporations. While he takes a consumerist view, and makes excuses for you frittering away your privacy (which I’m sure you’ll appreciate), the meat of this article is that if you trust corporations to do the Right Thing with your information, you need to reassess why you trust profit-motivated entities.  All that “community governance” crap is just a facade to get you to trust them with more information, so they can make more profit.

Mar 12 2009

Personal E-mail @ Work

This topic has come up a bit lately, with some clarifications of delineations between what is expected out of employees with regards to their job and “the Internet”. This should obviously not be construed as policy by any means (see the bottom of every blog page for the disclaimer).

A lot of people- especially those of us who’ve been here forever- use our @potsdam.edu accounts exclusively/near exclusively. We have no policy that explicitly states you can’t use it for personal purposes.

My general guidance is based on volume: Is most of your e-mail work-related or personal? If it’s clearly mostly work, then I certainly don’t foresee someone having a legitimate problem with it. If you get 20 emails-an-hour for non-work stuff, and only a few for work, then maybe it’s time to punt to a different mail service for the personal stuff. This may be especially true if you enjoy online shopping, and get prolific amounts of “sale flyers” and “deal” e-mails. That could be looked at as “more bad” than the occasional e-mails from friends and relatives with links to pictures of their “cute” kids.

My $0.02.

Feb 10 2009

Of Hemlines and Oars

naach na jaane aangan tedha

Aada theriyadhava koodam konal endralam

Árinni kennir illur ræðari

Buruk muka, cermin dibelah

Altíð bagir illum barni okkurt

Złej baletnicy przeszkadza rąbek u spódnicy

Whether the proverb is Hindi, Tamil, Norse, Malay, Farose, Polish or dozens of other languages and cultures the result is the same: A bad workman blames his tools.

We are faced with a financial meltdown the likes of which most currently-working people have never experienced. We’re faced with budget slashes, and across the board those that have been generally insulated from economic pressures are now feeling the pain. Those that aren’t usually insulated thusly are probably unemployed, underemployed, or in similarly dire situations. People that have to-date been frivolous are having to rethink. Organizations that bleed capital are pondering surgery. Localities are looking at cuts that transcend “austerity”. Given all of these truths, it  amazes me how much people are spending and moreso (and more depressingly so) how little people are innovating.

Innovation: The Missing Link

Organizational people are generally good at looking at numbers, and figuring out where to pull money from. See a fat account with “low value”? Raid it. See a moderate account with “moderate value”? Tax it. See a way to provide “pain” while stoking the “poor me” fires? Twist it… hard. Organizational people are generally piss poor at finding, recognizing or rewarding innovations that not just save money, but provide enhanced value. The reasons for this vary and are less than simple, but it comes down to knee-jerk reactions: Organizations spend if they can and raid if they can’t, instead of challenging what they spend (thus encouraging innovation) and weathering the inevitable lean times without too much constraint.

In these tough times, innovative consultants are in unprecedented demand to look at processes and fix them; To analyze inefficiencies and correct them; To trim recurring expenses (read: license fees) at the expense of initial productivity hurdles; To point out possible organizational innovations (the surprising, subtle, and obvious alike) and provide direction.

Innovative people can leverage innovative technologies and spread very little money very very far. Whether it’s saving $400,000/year from licensing your operating system and database, or tossing beanbags and boardgames for your customers to destress with during critical periods, innovations matter.

The most common excuses I’ve heard for not innovating are tool-blame. The word “tool” is loose (as it is in the proverbs). “It’s my job to do X, so X+1 isn’t my problem.” “Our organization uses Pricey Fuzzy Widgets, and retooling to use Cheaper Shaved Widgets would be inconvenient.” “We can’t innovate X because we have to do Y.” Where those maintaining the status quo see their job description as a hurdle, innovators see lack of ambition. Where the novice sees impossibility of retooling, innovators see enhanced value and long-term savings. Where the naysayers miscorrelate requirements, innovators see new platforms and migration paths.

I’ve mentioned “enhanced value” a few times here (and elsewhere). That’s an important term when talking about innovation. Not all innovations are about saving money. Some of the best innovations are about “enhanced value”. Example: You spend $100/month on cable TV, for 4Billion Channels. Satellite TV offers 12Gazillion Channels for $100/month.  You haven’t saved money, you’ve enhanced value. Perhaps more relevant: You spend $675,000/year licensing SSL certificates from Big Vendor, when you could be spending $20,000 from Little Vendor. Possibly more relevant, yet: You spend $400,000/year licensing your operating systems and database platforms from Big Gorilla, when you could be spending $17,000/year with a free/open alternative. Even more relevant: Instead of allowing your Department of Redundancy Department to go buy Flashy Amazing Product for $1bajillion, require them to work with in-house development to figure out what they need and how much that would cost to develop.

Buy vs. Build vs. “Buy Free”: The TCO Debate

If you’re not big on understanding technology or have more money than innovative ambition (or brains, perhaps), you probably love cutting checks to vendors for “superior”, “polished”, “commercial”, “patented”, “Fisher-Price” products. After all, everything “out there” must be better than the team down the hall can build it. In your defence, perhaps the development team are more “maintainers” than actual “developers” (Said differently: Perhaps they’ll tell you where to shove your project proposal) in which case there needs to be some personnel adjustments. In their defence, you probably haven’t really tried.

If, however, you’re not keen on high acquisition fees, recurring license fees, exorbatant training fees, disruptive mandatory updates, frequent bugs that take weeks/months/never to be addressed – in-house (or project-sourced) development is a very relevant solution you should really pay attention to. It should, in fact, be mandated from the top-down that in-house (or project-sourced) development be considered prior to any software/service acquisition. After all, the Department of Redundancy Department doesn’t care if their $1bajillion Flashy Amazing Product could be developed in-house for $6,000 in already-funded labor, they just love their salesperson and don’t want to have to talk to the “geeky people” – but the Chief Financial Officer sure as hell should. The organization will not only save money but see substantial enhanced value. The Department of Redundancy Department doesn’t really care about either, they just want a new pair of shoes.

When looked at objectively, some services are clearly better bought. Your in-house development group is probably not best suited to build a word processing package, for example, when there are others that are cheaply/freely available. The in-house development group may know of better/cheaper alternatives to that which the Flash Salesperson is trying to pimp.

“Project-sourcing”, or out-sourcing the work on a project is also something worth considering if true “in-house” isn’t an option due to workload or expertise. The project will be built to your specifications using your tools and can be maintainable by your people (assuming you can write a half-decent spec). Costs will generally be higher than in-house development but especially in a demand market, can become very competitive when shopping the spec around.

Operating systems and database platforms are some of the most universal Buy vs. “Buy Free” savings realizers for most organizations. These costs, while sometimes low-per-unit, get staggering when multiplied across the enterprise and further throughout time as recurring costs. The aforementioned $400,000/year license cost was for a relatively small 85-server operation (~half of which were database servers, most of the rest of which were application servers). On the same hardware they rolled out a “free” operating system, and an “open” database platform where they paid ~$8000/year for support. They estimate ~$9000/year in salarytime above-and-beyond what they used to spend for the “commercial”,”patented”,”Fisher-Price” package.

Understanding those numbers, acknowledging you may need a different level of monkey to maintain a different system, seeing the “Big Picture” and executing a plan like that takes a lot of risk, patience, and innovation. You can’t blame the mirror because you’re ugly, your hemline because you can’t dance, your oars because you suck at rowing, your tools because you’re a bad workman: You have to push through and innovate- Not just because “times are tough” and “resources are meager”, but because an investment in human capital pays dividends, and innovation is always the right decision.

Feb 05 2009

Training–

A student asked me in class last night, how I “keep up” with changes in technology. Without hesitation I answered “by doing”.

People frequently think there is some magic to being good at something. There isn’t. Whether we’re talking about computer networking, cold-water diving, flying a plane, fixing cars, or anything else in life: The best training is doing it. Not reading a billion magazines. Not doing a billion pull-ups. Not sitting through a lecture and getting a bullshit grade. Doing it. The thing you’re trying to do.

Anything else is a distraction.

This is often hard for novices to grasp. They’ll read a book or pick up a magazine that gives them bullet points on how to succeed at X, and go “aw man, if I check off that list I can do X”. They’ll read a biography about someone they perceive as “cool” and hang on how they succeeded, planning on following that path.

They’re distracted from reality.

Reality is very simple: Do it. Don’t try to do it. Don’t overcomplicate and overplan. DO it. DO it. DO it.

Anything else is a distraction.

WordPress Themes