Sipping Our Own Champagne – Lighting the Lantern 3

This is the third in a multi-part Lighting the Lantern series about the origin of Lantern Three.

If Lantern Three is a company about problem solvers bringing their expertise to the table, then dogfooding is appropriate, if not essential. We can’t be about solving problems the right way, once by outsourcing our company setup to someone who doesn’t share our values.

As tech folks, we had opinions about every aspect of our setup; as we’d advise others, we chose solutions that best-fit our needs.

Groupware: Google Apps

The first order of business was setting up our @lanternthree.com email addresses. Barry, George, and I cover the spectrum on email servers (installation and administration of MS Exchange, Lotus Notes, Novell Groupwise, Sendmail, and Sun One) and clients. George and I also have email history that goes back many, many years and incorporates mail from lots of clients. I consider myself a long-term beta tester of Google Apps since I migrated all of my personal email there in October of 2007.

John has lots of email

With only a handful of brief outages since I migrated, and given the few resources we have dedicated to administer our infrastructure, this was the easiest decision we made. It was effortless to setup our account skin it appropriately, and we were using Google Docs to collaborate within a week.

je-l3-inbox

Web hosting: Amazon EC2

Barry, George, and I all host physical servers that are directly Internet accessible in our homes. We could have easily hosted any required services on any of those machines (or even bought new ones).

Then why did we choose the Amazon Elastic Compute Cloud? It wasn’t because cloud computing is a buzzword, but because of all the benefits that cloud computing offers: the ability to inexpensively host highly available virtual machines with minimal worry about hardware failure, power, cooling, rackspace, bandwidth, and a slew of other obligations. While there are specific security considerations when utilizing clouds, industry best practices from other arenas certainly help. Proper storage and utilization of off-line private keys and certificate authorities permit the use of encrypted volumes, files, and transfers. This dramatically reduces the risk of data loss through drive attrition, loss of control, etc.

l3-ec2-console

We chose Amazon based on the maturity of EC2 and our specific needs. We may not suggest the same for every company, but it was the right decision for us when we made it.

Media Design

It was very important for us to find a design team who shared our values. Using the logo Stokefire procured for us as input, Will Rees and Bo Ramos were given total creativity to design our site, which freed me to focus on site structure and content. Once the design was locked down in early July, we were able to code the site and draft the content concurrently.  Will and Bo were also responsible for our WordPress theme, Twitter skin, and PowerPoint template. l3-website-design-comp

When we had a solid first draft of the entire site, we brought Stephanie Hay from Tellenger in to review and edit the site content, our bios, and our resumes to ensure everything was consistent.

Nic Tan is the photographer who shot most of our bio pictures; we expect to include more of his work in future versions of the site.

By hiring a team of professionals who shared our values, we became a fully branded new media company in about 90 days, and we’re thrilled with the results.

Author: John Eisenschmidt

Topic(s): Behind the Scenes

Published: November 12, 2009 14:32




So, you’re thinking about a SAN… (part 3)

Now that the transport has been established, the next decision is what storage system(s) to use to provide the data.  For most, this decision has the most impact on performance.  Controller performance, either in throughput or in Input/Output Operations Per Second (IOPS), number of spindles (physical disks), type of disk (FC, SATA, SAS, SSD, etc.), and the layout of those disks all come in to play.  Most storage arrays support a mix of disk types, so ensure that the controllers can keep up with the IOPS load in the storage configuration you want to provide (probably the biggest “set in stone” decision to make).  Some arrays are more flexible: you can add more controllers later on if you find out that the controllers are being stressed somewhere (cache, CPU, back-end IOPS, etc.).

The type of data you plan to store and the user expectation for how it will perform determine what disks are used in the array.  SATA is great for low performance, high capacity storage.  SATA does well with low IOPS and low contention (since seek times are generally higher than others and other features aren’t as advanced or are lacking) and so they serve archive or small workgroup storage well.  SAS and FC do well for high IOPS loads (high-volume e-mail, OLTP databases, etc.) but tend to have a high cost.

Once you pick a disk-type for a particular work load, how do you choose a volume format?  DBAs will always tell their SAN admin not to use RAID-5 because of the overhead to calculate parity for each write operation.  Well, maybe.  The reality comes down to user expectation.  If your array will deliver your cruelest database loads in adequate time running on RAID-5, what’s the problem?  If RAID-5 suffers, then RAID-1+0 it is.  With database workloads, it’s often not as simple as that.  Given the cost of SAN storage, making the most of it counts for a lot.  If there is a particular part of the database that could benefit from faster storage, it may be beneficial to put things like redo logs on the fastest configuration you can configure and put the database on something a bit slower, but more space efficient, and the archive logs (depending on how long you want to keep them and how fast they get created) on something more cost efficient.  Database systems like Oracle have excellent tools for determining what part of the database needs help.  I can also assure you, DBAs have a knack for letting the storage folks know when they need something.

When it comes down to allocating the storage out to the hosts, I try to allocate what is needed plus a small overhead.  Some operating systems are okay with the idea of growing a volume/LUN (Windows) and others are not (Solaris).  For those that are not, I recommend the use of volume management software that will allow you to add additional LUNs and grow the file system (Solaris does allow for this, for example).  Some storage arrays provide the notion of Thin Provisioning to work around this concept.  Personally, I oppose the very idea.  Thin Provisioning is a lie.  The array tells the host the volume is bigger than the amount of actual storage backing it up.  So long as the host doesn’t want to use all that storage, all is good.  (Does this remind you a bit of some financial scandals?)  If, however, the host decides that it needs that space, it is either allocated on demand or if there isn’t enough to be allocated, the write fails.  A SCSI write failure is bad because it means your file system is now corrupt.  The hope is that storage use will grow slowly enough that the SAN admins, who are hopefully paying attention, can add more storage to the array before the situation becomes critical.  There are a lot of “ifs” in this whole concept.  This whole thing relies upon the idea that 1. The SAN admin can add storage in a crunch (which means money from somewhere) 2. Everyone who is using the storage remembers that the numbers they see are lies and they don’t really have that much space, so plan accordingly and don’t do anything stupid, and finally 3. Nothing goes wrong.  By the third point, I mean that some job runs away dropping core files or a database autoextends itself blissfully because no one put an upper cap on it, or someone isn’t told the numbers aren’t right and they use the space “temporarily”.  Once TP space is allocated, it’s allocated.  The storage array has no way to know that a block has been freed since “zeroing” blocks isn’t generally done (we’ll get to this same idea with SSDs in the next section).  There is also an issue of resource consumption and human nature.  When people know where the hard wall is, they’ll respect it (as do file systems in that they leave themselves enough room to work and not get corrupted).  If people know that there is a limit out there somewhere (and who knows because there might be other TP users on the same array about which they have no idea), but not sure where, they might be tempted to gamble.  In any case, TP can put the SAN admins in a tough spot.  TP is sold by marketing folks as a storage saver (wait, you mean to tell me marketing people selling storage are trying to keep me from buying storage?  Something’s not right.  Oh, that’s right; they know if you lie to your users, that lie will catch up to you and you’ll come running to them at the last minute for more disks which will be a guaranteed sale!), but it is simply this: if SAN admins have to keep space free on the array to account for the possibility of TP growth vs. space free in file systems that goes unused, that space is still free (and wasted).  Smart planning and flexibility from volume managers on the host side can mean that you don’t need TP and you’re not wasting a lot of space either.  It will also help the SAN admins sleep better at night.

Now that we’re past all that, the last thing to remember with allocation is to have your application, be it a file system, DBMS, mail system, whatever, use the storage wisely.  By that, I don’t just mean space; I really mean understanding what’s underneath.  Issue read/writes in multiples of stripe widths (just the data piece, not parity, if any).  There is no magic bullet for this (as it depends entirely on how the admin configured the volume) and controllers in arrays can make up for some of this.  Make no mistake, a mis-alignment can cause a lot of undue stress on your storage.  For example, it used to be the case that the default start of an EFI disk in Solaris is misaligned if the LUN came off hardware RAID.  Ugh.  Pay attention.

In conclusion, the decisions made come down cost, both in equipment and in skilled people or support contracts, and workload/application.  There are examples of successful deployments for all the technologies mentioned in the previous posts.  Personally, where cost is no issue, I’m biased towards Fibre Channel.  That is not to say that I would pick it every time; I always try to choose the right tool, even though it may not be my favorite.  For example, there’s no point in moving an ant hill with a bulldozer.  If you want to create a low-load two node cluster, running a FC SAN is serious overkill because a couple of SCSI JBODs will do just fine.

Looking towards the future, the enterprise storage array is going to have some serious competition.  There are lots of exciting changes in storage going on currently.  There is the notion of object based storage (leaving behind the traditional general file system) and solid state disks (SSDs) maturing.  Object based storage is a completely different concept, but SSDs are not.  They’re still block-level storage devices, just faster.  SSDs are starting to see adoption in storage systems already (Sun is doing this) and is being made available into the general OS (Sun also doing this with ZFS in Solaris/OpenSolaris).  SSDs in ZFS are configured as a cache device, thus creating a hybrid pool of storage.  It’s a fantastic use of the technology.  When the SSD cost per GB reaches “good enough” and things like TRIM (the ability for the OS to mark a cell as unused so it can be erased — long story short, over time, SSDs themselves will lose track of what’s really used and what’s not which counts for true write size and wear-leveling) become universally implemented, storage may look a bit different.  Nonetheless, the present notion of a SAN and storage arrays still have a lot of great applications and many organizations can benefit from them.

Author: Barry Freese

Topic(s): Comparison

Published: November 8, 2009 21:07




Stokefire’s Guest Post on Lantern Three

The second post in our Lighting the Lantern series focused on Stokefire’s development of our brand. Since there are two sides to every story, we invited the Stokefire team to share their experiences working with us. Our thanks to them for accepting the invitation.

A peek inside the branders’ heads:

John came to Stokefire with what we found to be a wonderfully compelling idea. Roughly paraphrasing, it was this: “What if you could look back through your career and select the very best people you’d ever worked with, and ask them to come with you and create a company that did truly brilliant work?” This seemed a wonderful idea to our team. Every organization of size seems to have at least a few people who are there because it’s convenient to have someone in that particular seat, not because the person is the right person to be there. In what is perhaps a first for our organization, we encouraged John to hold off on investing in the brand until he had a better sense of who was going to be on the team and what their desires were. In most cases a brand is more powerful when the decision-makers are limited in number. In this case the philosophy of the company was known but the personality wasn’t yet set. We wanted to ensure we developed a brand that embraced both.

We’re glad we waited. In our kick-off meeting we met with John, Virginia, and George – whom we talked with at length about strategy, tactics, and differentiation – all the while assessing the organizational personality. We were blown away by the force of the team’s conviction. Passion is often missing from technology brands – but not from this. We knew almost immediately that there was enough power here to drive a brand home if we could find the right message.

During the evening meeting, we found many differentiators and sparks for potential brand directions. John’s team seemed both excited and occasionally disappointed as we discussed various ideas and sometimes had to set them aside as it was determined that the messaging wasn’t quite right or wasn’t unique within the market. That was until Virginia made an off-hand comment in explaining why she felt effectiveness was truly a differentiator for the team. To paraphrase, she said that the people John brought in are the type of people who have the talent to solve what the client’s self-described problem is, but also to understand any deeper causes of the issue and remediate those as well. In laymen’s terms (for my benefit) it was described as “When a client says he wants us to stop that annoying alert from disturbing him, there’s a difference between disconnecting the speaker or hiding the alert and actually solving the problem that’s causing the alert in the first place.”

From that discussion came a little note on our white board that said “You have to see the real problem to solve the problem.” It was just one of about fifty different things noted that day, but it was a great one.

As we revisited the board in the days that followed that one little item kept coming back. I know I chanted “You have to see it to solve it” a few thousand times as we went through the creative process. Ideas were tossed around about light spectrums, light sources, brightness, visibility and invisibility as well as dozens of other directions off of different notes. But we kept coming back to the “See it. Solve it.” concept, which incidentally turned out to be the ready-made tagline for the brand.

The final stage of brand development involved turning words into images. We worked with dozens of designers to find the right way to convey Lantern Three. We screened hundreds of concepts from locals and artists around the globe, providing art direction and guidance to drive the best concepts forward. It took a model-maker from across the Atlantic to develop what you see today. He pulled the three circles of overlapping color together and thus created a hidden “3″ that is hinted on the reverse of the Lantern Three business card, and is likely to show up in animations down the road. The logo showed the three circles of light, and at the same moment hid the numeral within. It was a spectacular way of illustrating both the obvious three lantern metaphor and also a secondary emphasis on seeing what is truly there rather than just what was explained or expected to be there.

We’ve admired how John and his team have brought this brand identity into their hearts – actively promoting and defending it in the market and with our own organization. It is a truly wondrous (and even a bit terrifying) feeling to find ourselves challenged by the Lantern Three team to live up to the brand that we’ve created for them. For Lantern Three and Stokefire, this is a brand that truly matters, and we wouldn’t have it any other way.

You can read more at Stokefire’s blog or follow them on Twitter.

Author: John Eisenschmidt

Topic(s): Behind the Scenes

Published: November 6, 2009 18:54




What’s in a Name? – Lighting the Lantern 2

This is the second in a multi-part Lighting the Lantern series about the origin of Lantern Three.

Having an idea is one thing, having the time to execute it another.

I made the jump from internal IT to independent consultant in November of 2007, but was also finishing school part time until August 2008. While I made notes and continued to refine the concept, my first tentative step forward was to contact Stokefire in October of 2008. Tate Linden and I played tag until February 2009, when we finally met in person. I sought Stokefire out simply to come up with a name, but what Tate suggested (and we ultimately did) was to develop our brand.

By then, I had developed the short-list of the best people I wanted to recruit. I expected to work with Stokefire on the brand development, and reach out to them when we had something tangible to show. Tate suggested the opposite, and I agreed that everyone deserved input into the creation of our organization (since I insisted this was a company about us as problem solvers, not me).

With the four of us on board from day one (and others willing to join “when the time was right”), the Stokefire team reduced a list of 100 potential names to 13, which we narrowed to three before landing on Lantern as the stem. Why did we choose Lantern Three? That’s a story to be told in-person.

The name turned out to be the easy part, as the Lantern Three brand began to take shape. Over the course of several months, we refined our mission, goals, and expectations. The Stokefire team stayed in near-constant contact with us until they were sure we were comfortable with our brand. In Stokefire’s guest post, they tell their side of our story.

With a name, logo, and brand strategy, it was time to shift Lantern Three from concept to execution. We’ll explore that in part three of our Lighting the Lantern series.

Author: John Eisenschmidt

Topic(s): Behind the Scenes

Published: November 6, 2009 18:45




So, you’re thinking about a SAN… (part 2)

Once you’ve decided that networked storage is the way to go, which option do you choose?  There are pros and cons to all of them, and picking the right tool for the job can make a world of difference.  Of course, that assumes money is no object.  For small organizations, especially in this economy, making do with what you have might be the only option.

NAS is a good choice for problems that span large areas, need to be shared, and where limited flexibility is acceptable.  For example: a college that needs a system to share out home directories is a great use for a NAS.  Students, faculty, and staff all need access to their files across the public network, and just about every OS on a desktop can use CIFS, NFS, or both.  NAS can also be a great option for low-cost shared storage or storage that needs to be provided over an unstable network.  The reason I say low-cost is that a NAS system can be a “roll your own” setup.  For example: Sun Solaris 10, Sun Cluster, and JBOD trays that support multiple initiators.  Highly available NFS and CIFS (via Samba) is ready to go.  The same can be constructed with Linux.  NFS systems can also be paired to backup systems through NDMP and spare the backup server some work.  NAS systems are also available from commercial vendors as a great option for those looking for something more turn-key.

That said, NAS has limitations.  You can’t be as creative with NAS as with block-level SANs.  A block level storage device coupled with basic volume management software in the host OS provide a fair amount of flexibility.  Example: When migrating from one disk array to another (the old array reached end-of-service-life), a new disk array was brought on-line, added to the hosts, storage mirrored using the host-side volume management, old storage detached, old array scrubbed, and old array shut down and rolled out the door.  The impact to the users of the ERP and E-mail system running on the old array?  Nada.  No one noticed.  Again, SANs provide block level storage.  You can build whatever file system you want, use Oracle ASM, or whatever else can make use of it; you’re not tied to a protocol or specific set of implemented features of a protocol (“Is that NFSv3 or NFSv4?”).

When considering the networking for block-level storage devices, keep in mind that generally block level storage  does not fail gracefully.  Storage, above all, has to be correct 100% of the time, so having a reliable network between host and storage is critical.  Performance is second to correctness.  There are lots of options for block level networking and vary greatly both in cost and performance.  Some of the choice here depends on the storage array and what it can provide.  For arrays that support ISCSI (which is a means of moving the SCSI protocol over IP networks), this can be a cheap block level network setup.  Solaris has an ISCSI target capability built-in, and that married to ZFS is great to get your feet wet with ISCSI (but there’s no redundancy, so I wouldn’t trust it for a production system).  Like NAS, this option can be implemented over your existing IP network (although I don’t recommend it) and cheaply since many operating systems have software ISCSI initiators.  There are hardware HBAs available too.  However, even with a dedicated back end network, it’s still an IP network which has shortcomings when it comes to storage.

Fibre Channel is a very widely deployed answer to the block level network problem.  This option is not exactly cheap.  Fiber Channel is a network, first and foremost, that was designed with storage in mind.  Concepts like flow control, “routing”, and loop detection are different.  Getting into Fiber Channel can be a bit pricey in that FC requires special switches and HBAs in the servers (not to mention cabling).  FC is usually implemented in duplicate (creating two different, disconnected networks called fabrics) so under certain conditions or even a fabric failure is a non-event to the servers.  FC also comes in a variety of speeds and, so far, has maintained backwards compatibility.  FC comes in 1Gb/s, 2Gb/s, 4Gb/s, and 8Gb/s.  Ethernet comes in 1Gb and 10Gb.  In my experience, 10Gb/s to the host is too much and 1Gb/s is too little.  Sure, things like port channels can work around some of this, but single link speed flexibility is a nice thing to have.  There is a lot of intelligence built into FC in the switches which provides the true beauty of FC.  One bit of wisdom with FC switches: don’t mix switch vendors.  Even switch vendors like McData and Brocade (Brocade bought McData several years ago) who have developed firmware to make each switch platform (M-EOS and FOS) play nicely with each other, still only have a limited set of features in compatibility mode.  Homogeneous fabrics make life easier and allow you to take advantage of features that would otherwise be disabled or limited.

Another option for storage networking is very new and being pushed by Cisco and Brocade:  the idea, called Data Center Ethernet, merges Ethernet and FC into one network. .  It’s a neat idea…on paper.  The advantage for organizations that deploy large FC networks is reducing cabling and switching costs because both types of data move over 10Gb/s Ethernet links.  The downside is that it requires special switches (you still have to have a fabric controller!) and special HBAs.  Unlike with FC, you can’t use your older, slower FC HBAs as part of a rolling upgrade (well, sort of), and the Ethernet port in your server won’t cut it either.  To be more clear, you can combine the DCE and FC systems together, but in order to move to DCE completely, you’ll need to buy all new HBAs.  I cannot say that I have any first hand experience with this technology.  It has been proposed to me by sales folks, and aside from the cost of adoption, it’s also a very new technology.  Going back to one of my first points, storage has to be right.  Bleeding edge and storage is a match I try to avoid.  I was also told that DCE is the future, to which my reply was “I was told five years ago that FC was dead.”  I assure you, FC isn’t dead.  Storage folks, in order to “keep it right”, like to keep it simple.  It’s nice to have a separate set of switches that do one thing and one thing well.  Cisco and Brocade may be on to something, but SAN architects are a very conservative lot so I suspect adoption will be slow.

There are other options from the “experimental” (like ATAoE) to the niche (InfiniBand with Lustre) .  NAS with either NFS or CIFS, ISCSI, and FC seem to be the leaders thus far in terms of install base.

Now that you’ve decided on what transport will meet your needs, our next installment will help you figure out what should dish out your data.

Author: Barry Freese

Topic(s): Comparison

Published: November 1, 2009 21:14




Lantern Three Receives Small Business Certification from the Commonwealth of Virginia

For Immediate Release

Lantern Three Logo

FAIRFAX, VA – Oct. 29, 2009 – Lantern Three’s application for Small Business Certification was approved today by the Commonwealth of Virginia’s Department of Minority Business Enterprises (DMBE). This permits Lantern Three to bid on solicitations set aside for small, woman-owned, and minority-owned (SWaM) businesses through the eVA Portal.

Signed by Gov. Jim Gilmore on May 24, 2000, Executive Order 65 defined Virginia’s e-government initiatives, including the mandate for an electronic procurement system. Since 2001, procurement for all Virginia agencies has been conducted through their Enterprise Electronic Procurement System, called eVA. eVA’s benefits include increased purchase transparency and Commonwealth Accountability, leveraged buying power, increased administrative efficiency, reduced cost of goods and services, increased competition, improved access to business opportunities and procurement information, improved access to business opportunities for small, woman-owned, and minority-owned businesses, faster delivery times, conduct business electronically and efficiently, and reduced duplication of systems and and unnecessary costs.

Signed by Gov. Tim Kaine on Aug. 10, 2006, Executive Order 33 established 12 directives “designed to promote economic justice and eliminate impediments to a more equitable procurement process.” Initiative one states, “It shall be the goal of the Commonwealth that 40% of its purchases be made from small businesses. This includes discretionary spending in prime contracts and subcontracts.” Virginia’s DMBE certifies vendors for participation in SWaM set-aside solicitations in the eVA Portal.

As a provider of business and technology solutions, Lantern Three’s services are eligible for consideration in any solicitation by the Commonwealth through October 2012.

About eVA

eVA is a web-based purchasing system used by Virginia government. State agencies, colleges, universities and many local governments use eVA to announce bid opportunities, invite bidders, receive quotes, and place orders for goods and services.

More information about eVA can be found here:
http://www.eva.state.va.us/learn-about-eva/learn-about-eva.htm
http://www.doe.virginia.gov/VDOE/Technology/soltech/LegislativeDocs/executiveorder65.htm

About DMBE

The mission of Virginia’s Department of Minority Business Enterprise is to promote access to the Commonwealth of Virginia’s contracting opportunities and ensure fairness in the procurement process. DMBE has two key goals: (1) increase the number of certified businesses in the Commonwealth, and (2) increase the total dollars allocated to SWaM vendors as a percentage of all discretionary spend or contract dollars.

More information about DMBE can be found here:
http://www.dmbe.virginia.gov/aboutus.html
http://www.eva.state.va.us/SWAM/executiveorders.htm

About Lantern Three, LLC

Lantern Three is a consultancy that provides pragmatic solutions at the intersection of business and information technology. Our practice of seasoned professionals has proven successes with program and project management, design and implementation of large enterprise systems, business process re-engineering, business intelligence, design and implementation of disaster recovery solutions, staff development, leadership coaching, and strategic planning. Industry experience includes federal and state government, higher education, non-profit, private and public for-profit, entertainment, and publishing.

More information about Lantern Three can be found here:
http://www.lanternthree.com

###

Media Contact:
John Eisenschmidt
202-905-2750
je@lanternthree.com
http://www.lanternthree.com

Author: John Eisenschmidt

Topic(s): Press Release

Published: October 29, 2009 14:51




So, you’re thinking about a SAN… (part 1)

In most situations I’ve seen, moving to enterprise storage comes about as an evolutionary development.  This begins with systems administrators, who have lived with Just a Bunch of Disks (JBODs) scattered across a variety of servers, looking to change how their storage works.  How does an organization decide to move into centralized storage, especially today’s world of cloud computing?

What can a Storage Area Network (SAN) do for me?

  • Storage is usually the slowest part of any computer system, big or small.  Getting storage right can improve performance in a variety of applications.  Using a storage array allows servers to get the benefit of many spindles when they need it, and also allows intelligent controllers to be shared by multiple servers.
  • Speaking of multiple servers, storage arrays almost always support multi-host initiated virtual disks.  While this can be done with JBODs, the scale that is possible doesn’t compare.  Creating shared storage for clusters is easy.
  • One-stop-shop for data replication.  There are many data replication options out there.  Some applications will replicate their own data, some volume managers or file systems will do it.  Both of these options have big ifs and aren’t universal.  Having a storage array, or an intermediate device, replicate the data means the OS, file system, application, etc. doesn’t matter; the same replication strategy works for Windows, Linux, Solaris, AIX, and any other OS you can hook to the array.
  • Less waste.  You can allocate the storage you need where you need it and that’s it.
  • Just like with JBODs, you still have your hands on your data.

“If you build it…” but how?

There are many different options for building the storage communication network (or utilizing an existing network) for sharing storage.  In our installment, we’ll examine how to choose between a Network Attached Storage (NAS) solution (NFS or CIFS), or block-level SAN (ISCSI, Fibre Channel, Fibre Channel over Ethernet, etc.) .

Author: Barry Freese

Topic(s): Comparison

Published: October 28, 2009 21:43




I Have an Idea – Lighting the Lantern 1

This is the first in a multi-part Lighting the Lantern series about the origin of Lantern Three.

My Information Technology career began in the back-office, providing IT services in organizations whose mission was not the creation or propagation of technology. In business parlance, my projects and I were overhead; every dollar we spent reduced our bottom-line. Our mission was to focus on projects that returned value, not to buy and implement IT for IT’s sake.

The inverse argument is the strategic value IT can provide: Amazon, FedEx, and WalMart bet on technology early, and could not exist today as an all-people/all-paper business. Most organizations seem to fall somewhere between IT is overhead and technology will reboot our business model.

Since technology decisions seem to create more decisions, most organizations hire consultants to aid them through their project. There are several reasons to hire consultants:

  • Experience – they bring lessons-learned from similar projects
  • Expertise – they have skills you either do not have or do not want to hire
  • Objectivity – you may be too close to an issue, and more inclined to make a costly mistake

I have worked with consultants throughout my IT career: people from large firms and one-person-shows, ranging from long-term engagements to one hour. A few were outstanding , most were mediocre, and some were not a best-fit for our needs (a few ejected from the client site before their engagement was over).

By far, the best consultants I hired or worked with:

  1. were experts at solving our problem
  2. solved our problem as quickly and efficiently as possible
  3. left as soon as our problem was solved

Since there seemed to be a shortage of consultants who met this criteria, I often discussed starting a consultancy with the folks I felt embodied those attributes.

Without a catchy name though, an idea is just an idea…

Author: John Eisenschmidt

Topic(s): Behind the Scenes

Published: October 28, 2009 13:17




Congratulations, 5AM Solutions!

Congratulations to our partner, 5AM Solutions, for being named one of the “Great Places to Work” in the Washington DC area by the Washingtonian magazine. As your partner since 2007, we know it’s well deserved.

Author: John Eisenschmidt

Topic(s): Partners

Published: October 27, 2009 16:41




Minimalist X window managers on Apple OS X Leopard (10.5)

Updates:

  • 3/5/2010 – Snow Leopard xmonad configuration detailed in this follow-up post
  • 12/25/2009 to fix several hours and point out functionality of Fluxbox and Blackbox on Snow Leopard.

Perhaps you have used a full-time *NIX box as your main desktop in the past.

In many cases, you will probably find that many of those folks are just using Apple machines now, due to the aesthetics of the hardware, ease of native use of Windows and *NIX applications, giving you the best of all three worlds (licensing is another topic . . . ).

This is a great way to stick with your normal OS X install, but be able to switch back to just X11 so you can have tons of windows open and be able to read everything quickly. This setup does not require any dual-booting, nerfing of copy/paste, etc.

I’ve been doing this with Leopard and Snow Leopard. I prefer xmonad, but haven’t succeeded in building it cleanly on fresh installs of Snow Leopard, so am providing two sets of instructions.

Ratpoison and xmonad are both very lightweight, minimalistic, fast window managers for X11. You’ll find that they both strive to be as simple and quick as possible to permit the fastest usage of lots of windows while allowing you to maximize the use of your screen real estate.

Ratpoison instructions will work for either Leopard or Snow Leopard. xmonad only works with Leopard at the moment, due to the 64-bit haskell compiler (GHC) build work being done for Snow Leopard.

They each allow you to dynamically create and remove workspaces that are independent within X11, and do not overlap with OS X’s “Spaces”.

xmonad stands out in a couple areas:

  • easy to rotate/resize/retile windows
  • a bit cleaner, simpler
  • mouse highlighting to switch windows

Try them out.

Other applications like tmux may be helpful to create another dimension of windows and flexibility.

Fluxbox and Blackbox are both fairly simple and clean, and each have functional ports available from MacPorts, so you can copy the settings below for Ratpoison and use those if you are interested.

1. Load X11 and XCode development tools from Apple OS X media.

If you want to use xmonad, perform the following steps, or skip to step 6 for Ratpoison. (Leopard only at this point)

2. Download the GHC package for Apple Leopard (same package for Leopard and Snow Leopard at this time)

3. Download the GHC X11 source package (bottom of page)

4. Install the Haskell X11 package:

tar xf X11-1*tar*
cd X11-1*
runhaskell Setup.hs configure
sudo runhaskell Setup.hs build
sudo runhaskell Setup.hs install

5. Install xmonad; pull down the latest source core distribution from the xmonad site

tar xf xmonad-0*tar*
cd xmonad-0*
sudo runhaskell Setup.lhs configure
sudo runhaskell Setup.lhs build
sudo runhaskell Setup.lhs install

If you want to use Ratpoison, perform the following steps, or skip to step 8. (Leopard or Snow Leopard)

6. Install MacPorts using their instructions.

7. Install Ratpoison: sudo port install ratpoison

Combined steps for either window manager.

8. Launch x11, and set a few settings in preferences. On the “Input” tab, ensure that only the following two options are checked:

Emulate three-button mouse
Enable key equivalents under X11

9. Close x11.

10. Pull down awesome X11 fonts from proggyclean. Save them in ~/Desktop/fonts/ or a directory of your choice. Gunzip the PCF files.

11. Open a command prompt and run mkfontdir in the directory to create a fonts dir file.

12. Copy over the stock xinitrc: cp /usr/X11/lib/X11/xinit/xinitrc ~/.xinitrc

13. In ~/.xinitrc, comment out twm, clock, all the xterms, and the if/for loop that runs the stuff in /usr/X11/lib/X11/xinit/xinitrc.d/

14. Append to ~/.xinitc:

/usr/X11/lib/X11/xinit/xinitrc.d/10-fontdir.sh
xset fp+ ~/Desktop/fonts
xset fp rehash
cd
quartz-wm --only-proxy &
if [ -f /usr/local/bin/xmonad ]; then
/usr/local/bin/xmonad &
elif [ -f /opt/local/bin/ratpoison ]; then
/opt/local/bin/ratpoison &
fi
xterm

15. Create ~/.Xmodmap with the following contents:

clear Mod1
clear Mod2
keycode 63 = Mode_switch
keycode 66 = Meta_L
add Mod1 = Meta_L
add Mod2 = Mode_switch

16. Create ~/.Xdefaults with the following contents (adjust the font name if you selected a font other than ProggyTiny with slashed zero):

XTerm*font: -*-proggytinysz-medium-*-*-*-10-*-*-*-*-*-*-*
XTerm*reverseVideo: on
*VT100*reverseVideo: on

17. Launch X11.

Welcome to faster scrolling, paging action, and nice automatic (and fast!) tiling of windows.

A couple of notes:

  • Cut and pasting:
    • within x11 only, you can highlight text and it is on the clipboard
    • to put it on the clipboard for aqua apps, hit command-c as usual with aqua apps
    • to paste within x11 (from either x11 or aqua), just use option-click or middle-click
  • xmonad specific:
    • ctrl-n – new xterm
    • meta-1 through meta-9 will take you through different workspaces in xmonad, which are independent of your built-in virtual desktops in OS X
    • meta-. and meta-, will rotate and redo tiling of windows
  • Ratpoison specific:
    • ctrl-t, s – split vertically
    • ctrl-t, S – split horizontally
    • ctrl-t, tab – moves focus
    • ctrl-t, c – creates new terminal window
    • ctrl-t, ? – help and tips

The only real issue I have with this approach is that I rarely have windows strictly 80 characters wide, so that makes it harder to visually realize when I should be wrapping lines. Luckily nvi(1) and fmt(1) have that covered for me.

Hat tip to Eric Hanson for pushing me in the xmonad direction!

Author: George Lewis

Topic(s): How to,Technical

Published: October 26, 2009 00:05




« Newer Posts — Older Posts »