We did lots of the usual things, plus some unusual things, to get the word out — press releases, blogger outreach, videos, tweets, etc. We’re pleased to trumpet our “Lighter” name, as indicating both a lighter-weight process and a lighter attitude than the traditional banks.

But in our research we discovered: we’re not the only “lighter capital” out there.

In fact, the industrial city of Wenzhou, south of Shanghai on China’s eastern coast, claims the title of “lighter capital of the world.” To wit:

In Wenzhou, there are more than 500 lighter manufacturers that produce 5,000 kinds totaling 500 million lighters each year. Among that, 80 percent are exported abroad. Lighters from Wenzhou make up 70 percent of the world’s market for lighters with metal shells, and 80 percent of the European market.

From the China Daily, http://www.china.org.cn/english/2002/Apr/31597.htm

So, to our “lighter” brethren across the big pond — 你好， 我们爱你的名字！

However, if you try to do this through the IDE, it will barf at you: “A reference to ‘System.Core’ could not be added. This component is already automatically referenced by the build system.”

Alas, that’s a big fucking lie. It’s referenced by the IDE when it invokes the build system, but not by MSBuild itself. So sometimes, you indeed must add such a reference, but you can’t do it from IDE-land. So close VS2010 and fire up vim. Add a line to the .csproj file in question, telling it to:

<Reference Include="System.Core" />

Hat tip to Ashby at StackOverflow:

http://stackoverflow.com/questions/1302488/the-type-or-namespace-name-linq-does-not-exist-in-the-namespace-system-data/4331322#4331322

I got to this point when recompiling something for .NET 3.5 that had originally been coded/built for .NET 4.0; it wouldn’t import the LINQ namespace without being told to import System.Linq, but then couldn’t find it without the System.Core reference being made explicit. Arrgh.

View BWR 1970s reactors in the USA in a full screen map

The March 2011 earthquake / tsunami / reactor emergency brought to the public eye the dangers of “active safety” in engineered systems.  Elements of reactor design and operation which may have seemed appropriate in the 1960s (when these reactors were designed) now seem like “what were they thinking??” anachronisms to concerned laypersons.

Specifically, I’m talking about the need for electrical pumps to be in continuous operation to prevent reactor core overheating; use of water (hydrolysible into 2H2 and O2, explosive and reactive gasses) as coolant; use of cladding and fuel alloys that are subject to fire risk and enhanced toxicity (zirconium and MOX); and storage of spent fuel rods in top-floor containment pools subject to sloshing and evaporation and requiring electrical pumping. Keep in mind that all of the bad shit at Fukushima started happening after the earthquake and tsunami had passed, during a period where the active safety systems relatively slowly stopped working.

(Lots of folks don’t realize it, but you can build stable, passively safe, high tech systems, to a degree. Simple airplanes are built to fly themselves. If you’re up in the air piloting a Cessna in level flight at, say, 5000 feet, you could probably take a 10 minute nap and live to tell about it. Yes, there’s gravity involved, but the aerodynamics involved let the plane stay up there either flying (engine on) gliding (engine off) for quite a while with no requirement for constant input and management. Contrast this with something like the Joint Strike Fighter, where the plane is intentionally aerodynamically unstable and, without the constant inputs of a high-speed computer, would fall out of the air like a brick. We want reactors that are boring and Cessna-like, not delicate JSF divas that literally melt down without enough attention.)

(Non-geek version: the Fukushima-type reactors are like delicate plates spinning on top of poles.  You can’t just leave them be without expecting to break a lot of shit.  And they don’t tend to revert to safe or stable states when they break.)

The above map names the US-based reactors with BWR type (boiling water; arguably the most dangerous type still in service), manufacture by GE (GE, Toshiba, and Hitachi were the suppliers at Fukushima), and construction dates that include the 1970s (1969 in the case of Nine Mile Point).  This does not mean that you should freak out if you live near these plants.  But it does mean that, in the broadest sense, these types of reactors are subject to the same types of risks as the Fukushima reactors.  (Keeping in mind that even Fukushima was fine for 30+ years until a 9.0 earthquake.)

If you want to do something positive about nuclear power in general, don’t freak out or ask for all nukes to be banned. Instead, the nuke-minded citizen should:

• …push for greater research on safer alternatives like pebble bed reactors.
• …push your Congressional representatives to get off their asses and open up a real, centralized, better-than-inaction interim solution for the nation’s nuclear waste. (This gets rid of fuel rods sitting in ponds at the very place where they can do the most incremental harm when things go wrong…)
• …pay, pay, pay. [Good] nuclear power will not be cheap. But it can be vastly improved from the Fukushima state of affairs. However, it will take enormous amounts of money for research, and the political will to eschew interim half-assed solutions (like putting cheap BWRs into service well into the 1970s, when other approaches were already either viable or in progress).

Don’t bang your head against your iptables or pf or PIX or ASA config.  First, check to make sure that the environment you’re checking from behaves right.  Do a “telnet google.com 21″ and see if it connects.

Some NAT setups in offices apparently try to do some stateful inspection of outbound active FTP in order to rewrite the addresses/ports involved, and these can intercept outbound requests on port 21, making it seem like any host is picking up on that port.

Try nmap’ing or telnet’ing from an outside host directly connected to the public internet.  And make sure that your subsequent security scans/checks come from such a host.

But everything has not changed.  Just try raising capital.

Software is now a service.  Hardware, indeed, infrastructure is now a service.  Need an office?  Use a Web service to pick a short-term coworking space.  Outsourcing?  Sure — there’s a service to manage those service providers.  Hell, the boys at OnCompare now have a service to help you select the services.  Everything you need is discoverable, trialable, and available 24/7, online, with a few clicks and a credit card, right?

But the moment you start to feel the rhythm, decide you want to dance to the music, and try to roll up funding to grow one of these agile new businesses, the record screeches to a stop.  Needle scratch, and silence: a disco full of folks staring at you.  Are you crazy?  You want what on demand? Capital as a service?

Yes.  You want just enough of it, just when you want it, conveniently and as automated as possible.  You want to try it out in 10 minutes, understand it, trust it, and, if you like it, use its APIs to integrate with your business processes.  This is how you advertise for clicks, how you get a new logo designed, and how you provision servers.

So what is money’s major malfunction?  When you can get 100,000 virtual server instances started for you in a minute, why does it take days and weeks (or worse) to get $100,000 in working capital?

Something’s wrong with this picture.  And it’s about to be fixed.

Find a money-man and ask him about “efficient markets.”  He will give you a sparkling smile and tell you the MBA answer, that markets tend to squeeze out transaction costs, and costly middlemen, and price gaps.  Then ask him about the cost of doing transactions with him.  Or ask if he’s a costly middleman.  Or ask what “price” he pays his investors to use the money.  Is he still smiling the MBA smile?

We like having coffee with our investors.  But you shouldn’t have to savor a fine latte from Cherry Street or Coupa to get funding.  Sand Hill Road is a lot more fun to travel on a bicycle carrying a picnic, than in a rental car carrying a pitch deck.  And banks are more fun once they’re turned into bars.

Money, especially the “buy side,” loathes change.  From where Money sits, everything is fine: by definition, wherever the Money is, folks are feeling pretty flush.  And so the Money will resist change, it will cling to its prerogatives.  Bankers would still be on the golf course by 3 PM if ATMs hadn’t revolutionized their customers’ expectations.  For heaven’s sake, it’s the year 2011, and the New York Stock Exchange still closes at 4 PM.  The barbarians are at the gates: it’s about time for the “buy side” to get a little less comfortable.

About to go public on the Big Board?  Toying with a half-billion M&A offer?  Trying to pioneer commercial space travel?  Building nuclear submarines?  OK, you want old-school money from old-school money-men, with old-school suits and rich mahogany, Corinthian leather, and white-shoe lawyers.  But rolling up the cash to take your SaaS company from $2 M to $4 M next year?  It it worth 12 weeks of pitching and partner meetings and Purell between uncounted firm handshakes, with no guarantee of success?

We think not.  For a specter is hanging over the Internet: the specter of capitalism.  And we believe that capitalism should and will deliver its promise as a service.  We at RevenueLoan are not the only ones who see this; we may not even be the ones who ultimately realize it.  But make no mistake: capital for growing technology companies is going to be available on-demand, as a service, and players in this market who ignore this trend do so at their peril.

There is a policy running on the system. There may be one or more databases in .sdb files which are files representing a possible policy that could be run. These are stored in c:\windows\security\database\. One may “export” a policy out to a configuration .ini file (the docs for secedit say .inf, but it is clearly the venerable .ini format), which policy comes either from a database .sdb file, or from the current running system policy (if no policy is specified when running secedit.exe on the command line).  One may edit this configuration .ini file (the docs ambiguously call it a “security template” as well, but the command line options all say “cfg”).  You then create a new security database .sdb file with the “import” syntax.  Contrary to a lot of stuff on the Web, you don’t need to put it into some particular magic database (but see below for path gotchas) like the original secedit.sdb; put it in a new one.  Once you have a new, valid, legit database .sdb file, you only then use “configure” to apply the database file to the current system.

Lots of gotchas here.

Sometimes when secedit.exe fails, it is silent, like a good UNIX program, but it will return an %ERRORLEVEL% so check that or you will be bamboozled.  It is noisy when it succeeds and sometimes even noisier when it fails (except when it’s silent).

Secedit silently failed in many confusing ways if either the security database .sdb or the configuration .ini was located on my z: drive, which in this case was a VMware shared folder on a Mac OS X system.  Move stuff to a C: temp dir, then clean up afterwards, because hey, writing xcopy lines in batch files is fun.

The configuration .ini files are in full on, utf-16 format.  Two fucking bytes per character.  Nice.

If you try to create a brand-new configuration .ini file without reference to anything, you do not get a listing of the default settings, but rather an unhelpful, nearly-empty file that informs you that Description=Default Security Settings. (Windows Server).

If you try to look up the values for the various sections, you just plain can’t get them anywhere.  If you go to this horrible javascript monstrosity of a reference site and click Technical Reference (for Windows Server Group Policy), you can get a giagantic, unstructured spreadsheet that has relatively lengthy (but non-technical) prose about the various settings.  But it won’t tell you which sections they go under in the .ini file, nor the requirements for each field, some of which are registry settings and some of which are not.  If you want to see something that was apparently done as a class project by a charity course taught for retarded non-native English speaking remedial computer science students by the generous and distinguished engineers of Microsoft (who are clearly working on better and more interesting problems than, oh, say, making sure the OS’s core security API is sensical and internally consistent), you can look at this horrifying jumble of shittiness, which can’t search for shit but mollifies you with funny Engrish when it fails (I am not kidding: “We probably hit search limit.  Try to redefine your search string.”) and as a bonus demonstrates the sloth of Azure serving AJAX (because, you know, actually putting the documents into an html page where anyone’s browser “find” function could speedily search for it would lack the pedagogical value to the retard-children-programmers).

You can maybe stay sane if you learn that the registry values are prepended by an integer and a comma, where that int seems to specify the data type of the reg value (4=integer, 7=text, 1=some other kind of text).

Specifically in the [Event Audit] section, there are values that are not registry values.  They are ints that appear to be bitmask math fanciness.  (Remember setting options on visual basic windows back in the ’90s, where you got to add up powers of 2? ).  It so happens that they all have two bits, the first one being “log successes” and the second being “log failures.”  So 0 is neither, 1 is successes, 2 is failures, 3 is both.  But this isn’t, as far as I can tell, anywhere on MSFT’s site and it’s sure as fuck not in the giant unstructured spreadsheet reference.

Much of the configuration .ini file can be omitted (so you can just overlay the parts you want).  But you MUST include the [Version] and [Unicode] sections or it will barf.  Use secedit /validate to check it.  However, “validate” does not mean that it will actually round-trip and work right; it doesn’t check the security identifiers in the [Privilege Rights] section so it’s quite possible to have a valid cock-up (see round-trip gotcha below).

Biggest one: secedit CANNOT ROUND-TRIP. The security policy “export” may will (and does for me) produce an output with entries in the [Privilege Rights] section that refer to “Classic .NET AppPool” among others.  If you try to import and configure with this, you’ll get “No mapping between account names and security IDs was done” in the error log.  Turns out you have to manually fix this by adding “IIS AppPool\” before the names of these AppPool entities.  (Hat tip)  If you want to actually find out whether that, or some other hackery, fixes it to something that can be mapped to an SID, find yourself the PSTools download and test the name with PSGetSID.exe.  Awesome.

The “configure” option only really needs a .sdb database specified by /db.  If you give it an additional /cfg parameter, it will muddy up the .sdb with the contents of the specified config ini.  There is no benefit to using this, ever, other than skipping a step that could result in you keeping a sanity-preserving intermediate state backup.

The “overwrite” option doesn’t do what you think it does.  Especially with “configure.”  Just don’t use it, unless you are planning on destroying what is in your .sdb file(s).  The .ini configuration already wins in a tie.

The “configure” option is NOT ATOMIC, and it will happily set your system’s security policy partially to be what was in the file you indicated, and partially not (for example, with the broken round-tripping of IIS AppPool names).  There’s no way to find out whether or not the configuration will succeed, except to “suck it and see.”  And once it does partially, non-atomically make a goulash out of the then-current and database-specified settings, there’s no way to tell what succeeded or failed, except by reading the log, which is formatted in an unparseable mess.  Fantastic.

Today’s morning news and communications, then, were dominated by transportation-related issues.  “Schools are closed!”  “Courts closed!” “Clinics closed!”  “Stay home by all means!”

That wasn’t an option today at RevenueLoan — we had a closed deal to paper and two more to work on.  So I put on the hiking boots and the bubblegoose, and navigated foot-mobile through the mostly-closed Seattle streets.

And, while abnormality was the order of the day — 30 year old Seattleites sledding and sliding around like giddy 5th graders, hilly streets barricaded, and creep-crawling traffic throughout the day on main highways — what struck me most was the acute normality of the day for the small businesses I passed.

Local printing company — “open” for business.  Our caffeinated home-away-from home at Moka’s Cafe — check.  Tiny bookstore slinging used paperbacks and tacky tourist t-shirts — you bet.

The office windows across the street from mine, usually packed until 6 or 6:30 with yuppies at an Anonymous Top Online Retailer, are empty at 4:30.  A Major Local Operating System Vendor was beseeching people to stay home.  And, that’s fine — arguably most of the people out there driving today were assholes endangering themselves and others (at least if my anecdotal observations can be extrapolated).

But there’s something heartening about seeing that neon “Open” sign lit up — not the giant custom one in the corporate standard font, but the red-and-blue one you can buy at Costco when you’re first hanging a shingle.  Something heartening about the proud real-estate guy giving the walking tour to prospective tenants on pavement he just scraped and salted.  Something heartening about the beer distributor’s careful truck maneuvers as he pulls up to the corner bar to restock it for happy hour.

OK, fine, cynics: I know that these people are responding to the iron economic law that governs small business, and the simple reality that fixed costs don’t go away.  There is no East-coast failover data center for the guy who makes sandwiches on the corner, and there’s no corporate balance sheet to pay him his take-home if he no-shows.

But I think it’s more than that.  People doing their work because the work itself is valuable.  Yes, bonds have value.  Yes, big corporate edifices have power.  But imagine a world of 6 billion bondholder rentiers.  Who makes a tasty Jambo sandwich?  Who actually prints up your annual reports?  The work we do, cumulatively, is what makes humanity wealthy (and human, for that matter).

And those small businesses are the individual loci of non-abstractable human work.  The smallest functional unit that can deliver the value they do.  And they show up despite the snow.

So maybe it was the bright sun in the sky, reflecting off of the snowpack, and giving a blessed vitamin-D-blast on a Seattle winter’s day.  But something about the walk this morning, and the “open for [small] business!” that came to me from shop windows and storefronts, gave me a cheer.

However, the *.config regime is extraordinarily fragile and surprise-prone once you start trying to do more than just add name/value pairs to the <appSettings> section. The following are some gotchas that I hope you can avoid if you have to deal with this.

.EXE assembies get App.config, and Web DLLs get Web.config, but non-Web DLLs (e.g. tests) get App.config.

.EXE assemblies look for filename.exe.config, which is in App.config format.  Normally, DLLs do NOT get a config file; rather, they inherit / acquire whatever config is in place in their runtime environment.  But there are two important exceptions.  Web services / sites get built as DLLs.  Their execution environment (presumably IIS or the dev server) looks for Web.config and its format.  Test projects (of the MS type that Visual Studio 2010 makes by default) get built as DLLs, as well, but they get run by (mstest? vstudio?) an execution environment that looks for an App.config file.

So, to sum:

• .EXE => App.config
• .DLL Web project => Web.config, via its server runtime
• .DLL Test project => App.config, via the test / IDE runtime
• .DLL other => none, inherits runtime environment

Sections such as <appSettings> can be externalized into other files, but there are two subtlely different and incompatible ways to do so.

Specifically, you can add a “file” or “configSource” attribute to your appSettings section.  If you use “file,” that file will be read and will override default values that are set in that section in the .config main file.  If you use “configSource,” however, you must not set any values in your .config main file, and instead must entirely scope out that section (and that section alone, save for the XML declaration) in the file whose name you specify.

Frustratingly, “file” and “configSource” have different rules for what may be included (relative / absolute paths, parent directories, etc.).  Especially restrictive are the rules for Web.config, I believe, though I don’t have them straight.  Effectively what this means is that if you have several Web projects that require a shared configuration section, you cannot put your customSection.config in a parent directory and have your projects pull it in (thereby keeping a Single Point of Truth); rather, you have to propagate multiple copies out to all of the sub-Projects (ick).

For more on this: re: configSource, re: file from MSDN.

Web.config settings are mostly inherited from machine.config down through a hierarchy, but confusingly stop being inherited at the sub-directory level in IIS.

Sometimes, or at least most of the time by default, Web.config settings for a given directory are merged with those of parent directories, and are merged with machine-level config as well.  This can lead to somewhat unfortunate results if you have an app in a subdirectory of another app with divergent configruation requirements.  This fellow seems to have figured out how to resolve this.

Be alert, though, because not all settings *do* propagate properly.  First, a parent Web.config can indicate that its settings should not be inherited.  Second, collection settings are merged together, not replaced, by child specifications.  Third, some settings, just seem stubbornly not to propagate (see this MSDN article which suggests that “anonymousIdentification” does not propagate because it is a secret never-properly-set default magical element).  Finally, the above-quoted MSDN article raises the good point that Web.config only applies to ASP.NET stuff, and that there is an entirely different regime for static content and plain old ASP files.  So watch yourself, there, Tex.

Giving yourself this privilege is possible with Professional/Ultimate versions of Windows, but not Home Premium, via secpol.msc, which just doesn’t exist (and can’t be downloaded). (Funny, I don’t recall the comparison chart having a checkbox for “can actually use computer” that was missing from Home Premium.)

If you try to set this for yourself, don’t bother trying to use C# or PowerShell. You’ll need to manually wrap the unmanaged C++ advapi32 APIs, and pass all kinds of structs and pointers back and forth.

In the end, just give up on whatever it was you wanted to use symlinks for.

To the biggest firms with the best ratings — think IBM or MSFT — money is basically free, with coupon yields at sub-2%.

But to middle-market (say, $100M – $500M sales) and lower-end of middle market (let’s say $20M – $100M) companies, bank credit is simply not available at any price.

Interestingly, this week at a discussion with some regional commercial bankers, my partner Andy Sack heard gripes from the loan officers about extraordinarily tight credit conditions for single-digit-millions size facilities. (Of course, loan officers always gripe when “the credit guys” say no, but it’s worse now than usual, and importantly, not much better than 2008).

So: until or unless the big banks stop getting money for “free,” they’ll be quite content to sit on it and/or plow it for nearly-free into premium credits in large deals.  Don’t expect small business credit to loosen up until, paradoxically, rates have risen somewhat.

(Don’t expect us to have that problem over at RevenueLoan.  We’re funded by private equity investors specifically to prove out the royalty/revenue-based financing model, so A. our money costs us “private equity rates” and B. we’re on a mission to fund small businesses!)