First off, if you haven’t yet enabled the System Monitor, just right-click on your Panel and you should see it on the list. (Othewise: apt-get install gnome-system-monitor first)

By default the colors are all pretty similar. The first important tweak is to differentiate the Processor colors. Use whatever you want, but make sure they have enough contrast. (Not shown: I just fixed my green User color to contrast a little better.) Watching the Processor usage can show you a bit about the sites you spend time on (among several other things). If you’ve got a constant green bar (hmm, that sounds backwards to TDDers; maybe I should stay away from green), you might want to hunt down the tab hosting the unruly flash widget. Ideally, your system at rest should most often show a beautiful black box.

The second tweak I just made recently — and it’s growing on me — is to make outgoing network traffic red, and incoming yellow. Now I can see my backups to S3 in full swing when they kick in. And I might notice if anything is unexpectedly drifting outbound.

I also recently added the fourth Swap Space indicator just in case it ever kicks in, at which point I’ll know something is really awry. This one is probably not too important to have showing if you’re shy on Panel space.

Great! Now I can watch Firefox and a Mongrel take off with all my memory and know when to kill them. The monitor is also handy to see when something you’ve been running is (too often unexpectedly) finished. (I like using beep at the end of a long command for this too.)

I do still use top on occasion for its light weight. But sometimes it’s a bit more convenient to have a one-click GUI view of your system. Please share if you’ve got a more effective color scheme or if you use another light-weight tool for continuous monitoring.

The NIC and USB are obviously present.  ssh is highly expected (how else would you get in?), as is the ability to install anything that will fit in the 512 MiB of flash.  The audio output is missing, but if it supports any USB hub, you could connect an external USB drive and a USB amp like this one, and feed into your sound system.  Wonder what distro it’s using?

I’ve been using an old laptop to drive the audio for my whole house for several years.  This is not a great solution since it’s comparatively power hungry, loud, takes up space, and is dying.  With the wall-wart, that old system can disappear, and the wart can probably put out a lot better sound (with the USB amp).  I’ve considered replacing the laptop with an iTouch or some device, but I really like using the machine as a server for other purposes that a handheld would not support.

So far this system is just theoretical.  But I hope to get my hands on one of these and try it out.  Hmm, there are even USB monitors now; that could be interesting!

It would also make for a nice little backup server, hosting a drive for automated rsync.  There’s also the need for USB-powered eXtreme Feedback Devices (XFDs).  The ShivaPlug could handle some of that with a USB light or lava lamp.  Any other possibilities?  Let me know your experiences if you’re playing with one.

Thanks Jon for the link!

Good ol’ top. For years it’s been the cornerstone of process control. It’s the first place we turn to hunt down a rogue process, or just to watch how resources are consumed. Sure, you could use a handful of GUI tools, but I frequently find myself working strictly in a terminal on remote machines, where top is indispensable. This is a short overview of top‘s most important features that weren’t obvious to me until I got to practicing for the LPI exam a short while back. Now I’m making use of them quite regularly. To save you from wading through the 1,000-line manpage, here are the most useful interactive commands (you don’t have to worry about the CLI options).

• z — Turn on color. Beautiful! Don’t change them unless you’re looking to waste a lot of time
• s — This is the refresh interval. The default of 3 seconds can leave you puzzled. I like to set it to one or half a second. An alternative is to just press a bunch of times whenever you want to see an update.
• 1 — Change the number of processors shown. Though not a default, this is critical now that every machine we get on has 2 to 16 procs.
• H — Show threads. Try looking at Apache with and without this.
• i — Ignore idle processes. This helps you focus only on what’s really active; and makes everything fit on the screen.
• O – Order by some field. The most useful sub-selections here are q (resident memory), k (%cpu), and a (pid). Setting this helps keep your list from bouncing its order all around.
• c — Show whole command. Essential when you’ve got multiples of a similar command running.
• u — Only show what’s happening with a single user. That’s often $USER (you!), or some other luser.
• k — Kill a process with signal of your choosing. (Bonus: look into pgrep/pkill.)
• ? — Show the built-in help screen.
• ^g — Escape out of any menu screen.

You could have seen most of this on the built-in help screen by simply pressing h or ?. But that menu has a pretty unintuitive layout, and the above is limited to the minimal set you really need. Now that you understand how everything works, and you’ve got it looking nice, just press W to write the configuration for permanent use. If you’re unhappy with the damage you just caused, just blow it away with: rm ~/.toprc

BONUS: You may have surprisingly seen “windows” in your top session, depending on what distro you get onto (maybe it was a Fedora?); that’s how I discovered them. Press h twice to get to the windows menu. I won’t get into all those details here — I don’t find the windows terribly useful, though they do appear to offer some sophisticated views. If you decide to use them, you can get started by pressing A, and then a continuously to cycle through displays. See if you can make sense of them, and then talk to me.

CAVEATS: Be careful not to run top with a fast refresh during any sort of benchmarking. It can chew up a bit of CPU time. Also, top versions vary widely depending on the distro you use; you might notice some different behavior than what I’ve described.
(This list also makes for a great sticky, as you see in the picture.)

top is a powerful tool that gives you a lot of information. If you got this far, you should now be able to make sense of most of the cryptic display, and be able to find your way around configuring it.

Seriously, it’s not going to take 700 years for FP to go mainstream. Some would argue that it already is. Python, Ruby, and others have adopted a number of FP features. Here’s all you need to get started right now and get ahead of the curve (right after you’ve installed Debian or Ubuntu).

Install Them All

I see tons more interpreters available (apt-get search …) for the main FP languages, but these are the ones that looked most stable and most widely used.

$ sudo apt-get install clisp guile-1.8 erlang ocaml ghc6

What did that just do? Okay, you can probably figure it out. But did you realize that you just put the entirety of mainstream FP and their REPLs at your fingertips? That includes interpreters/compilers for Common Lisp, Scheme, Erlang, OCaml, and Haskell. Vim and Emacs should have editing modes available for all of these.

You can invoke each of the REPLs respectively, like so.

$ clisp # Common Lisp
$ guile # Scheme
$ erl # Erlang
$ ocaml # OCaml
$ ghci # Haskell

Of course you’ll need to learn something about each of the languages to do anything at this point. But I’m just getting you off on the right foot. I’m not going to go into detail here why I chose the interpreters or languages that I did, but if you don’t know any better, these are a great start. I’m only getting started with all of these myself.

Free Online Material

You can check Amazon for books on any of these languages. Most of them are pretty expensive (except Programming Erlang, which I just ordered). But I’ll mention some free resources that all look valuable.

• Common Lisp Book (check out the sidebar on that page about the book’s popularity on Amazon!)
• Erlang Getting Started Guide (also in PDF)
• Erlang Reference Manual (also in PDF)
• Thinking in Erlang Mini-Book (PDF)
• Real World Haskell Book
• Developing Applications With OCaml

Stay Tuned

You might already be aware of the power of FP, or maybe the Wikipedia link at the top convinced you, or maybe you’ll remain a detractor. Hopefully I’ve at least whetted your appetite by showing how easy it is to get set up. I’ll plan to go into more detail about why I think FP is important in a future post (hint: performance, concurrency, code density, productivity, intelligent communities, mind-expansion, fun). I’m still in the process of discovering all the reasons.

Well, this kicks off my FP journey. Hope you’ll come along for the ride. First stop: erl

Linux distros these days tend to be pretty minimal in their default install mode. Many of us used to be in the habit of checking the “Install Everything” box in the earlier Red Hat days. But then the box disappeared, and it became a pain to get everything you needed, and most people moved on to use apt or yum, or some equivalent, to get their systems to a usable state. The modern idea is that you start out with the bare minimum to simply enable yourself to boot, fumble around, and install more stuff. Then you just use apt-get, aptitude, synaptic, or whatever, to install to your particular needs. On a fresh new Ubuntu 8.04 installation I see only ~300 packages.

After some time on a machine you probably find that you’ve manually installed hundreds (or thousands!) of packages to satisfy all your development needs. Here’s a great way to get that critical, comprehensive package list and make sure your other oft-used machines have everything you need. (You might even want this in the crontab of your primary machine; it can be helpful for recovery purposes. I’ll discuss cron optimizations in a future post. And another future post will discuss why apt-get is Ubuntu’s killer feature.)

mocushla$ dpkg –get-selections | grep -v ^lib [>/some/backed/up/place/packages.log]

The list on my primary machine shows nearly 2,000 packages now. That’s a lot! Note that I’m excluding the libraries since they tend to just be dependencies. Including them can actually make an upgrade/rebuild/recovery more difficult.

A Minimal Package Set

You may also find yourself needing to get onto freshly installed machines with some frequency. Maybe it’s a new web host, or some lab machine you need to do some work on. For time and space reasons, it’s probably not practical to start off by immediately installing your full 2,000-package set, so you’ll want to come up with a minimal set which at least makes you dangerous.

As someone who regularly sits down at other people’s machines, or at fresh new machines, I’ve found the need to have a small set of essential packages that I install, just to be productive. Here’s my list (the green).

newbox$ sudo apt-get install build-essential screen zsh corkscrew mercurial subversion python ipython pychecker pylint ctags vim vim-scripts xfonts-terminux sqlite3 tree ntp mailx postfix mutt autofs nfs-common

This will install some other dependencies, of course, but it’s a pretty quick operation, requiring less than 100 MiB. There are various other essential packages not listed there, but they tend to be part of the basic install. Now you can just use something like “hg clone ssh://your-mocushla.com/yourhome” to pull in your well-organized, minimal $HOME setup — but I’ll talk about that in a future post.

Related tip of the day: Did you know you have tab-completion for apt-get? Try this:

newbox$ sudo apt-get install python-[tab][tab]y

How many of those have you had to discover by searching?

The Meme

What’s on your Minimal APT List? Or do you have a Yum List? Does it look different?

If you found this post interesting, you may be interested in some related book s: Linux Patch Management, and Ubuntu Hacks.

I’ve been thinking about how to prepare for Startup Weekend, which is approaching quickly. Part of the registration process was assigning yourself a “specialty”. Of the seven designations, I chose architect for myself, whatever that means. But the role-designation question might be useful, and I think it’s worth looking at all the hats to be worn and shared in a startup.

In my previous startup I tried to wear so many hats — too many — and we failed. Now for the big weekend we’ll get to distribute the hats broadly(!) and try to crank out the business in a mere 54 hours! There is a disconcerting lack of detail about how the groups are organized, but based on the number of specialties, I’d guess there are going to be 10-30 people per team. Being slightly unsatisfied with the roles prescribed on the registration page, I decided to enumerate the roles that I see as important to making a new site come together. Each includes some example duties/skills.

The Hat List

• Visionary/Architect. Idea generation, shape features, repositioning, market fit, competitive landscape, research.
• Lead Developer(s). AKA Hackers. A good place to have a pair of jelled programmers. Uses web framework, creates functionality; knows Python/Ruby, Javascript, AJAX, Flash(?), HTML, databases.
• Sysadmin. Network, web server, NFS (for VCS/file sharing), caching, other infrastructure, data backup, backup hardware, performance tuning, scalability.
• Toolsmith. Team is provided with: productive development environments (all users can say “apt-get install …“), frameworks, editors, interpreters, multiple browsers, GIMP/Photoshop, (D)VCS, wiki, maybe BTS, quick training/consulting on tools/environment, continuous integration.
• Webmaster. SEO, analytics, domain registration, site hosting, Apache/lighttpd.
• DBA. Helps developers plan schema, set up tables, design for scalability, tuning/optimizing.
• Graphic Artist. Color coordination, logos, icons, image libraries, etc.
• CSS Designer. Usability, accessibility, layout, look-n-feel.
• Content Creator. User-facing documentation, populate/organize wiki, design tutorial, usage studies.
• Customer Support. Answers phones, forum voice, FAQs, knowledge base, help entries, problem solving.
• Tester. Bangs on site, tries devious things, automates stress.
• Marketer. Evangelism, blogging, advertising.
• Manager. Coordinates all team member activities.
• Lawyer. Business setup, guidance, law interpretation.
• Chef. Handles all other (random) tasks to keep team functioning.

That list looks pretty corporate-like. And there will be a number of obstacles if you try and partition these roles to more typical small-team startup structuring. But the list is useful if you happen to have a bunch of heads (15 or more) to throw at a problem, and a somewhat diverse skill/background set. For Startup Weekend these roles may work well as a starting point, but I also want to think about the more typical startup team, for which these hats may be too small.

No matter how small your team, none of these critical roles (hats) can be completely ignored indefinitely. This picture also uncovers why so many one- and two-person startups have a hard time getting to successful launch — the extent of this work may not be obvious when you think simply about the task of setting up a website.

Simplify and Combine Hats

It turns out that many people believe that the best way to actually implement a web business idea is to put a few (2-4) highly motivated and capable hackers together to build their vision. This has a lot of implications for the type of hackers that are needed — I’ll talk more about that below. For the sake of minimalism, let’s think about how a scant two-hacker team can possibly accommodate for that daunting role-list. It’s quite a diverse set of considerations! Does anyone really have deep experience in all these things? Probably not, but maybe it’s not necessary.

First of all, some of the roles can probably just be thrown out, or at least incorporated much later. Working from the bottom up, let’s first throw away the Chef. He’s an optimization that anyone else can step up to cover for. What’s important is that some team members are organized enough to recognize when latent Chef tasks are accumulating. Then take the Lawyer. She’s nice to have, but expensive and definitely not part of your core. She can just be used as a consultant if the Visionary or Manager can’t figure out if the business is set up correctly. Speak of the devil! Do we really need a Manager? Let’s just do away with the caste system and put everyone on the same level. We’re agile, we all communicate daily, and we have a great Visionary to tie everything together and keep us in check. And consider the Tester. Isn’t testing already happening at every level? The Developers are writing unit tests as they code (hopefully even before). The Sysadmin has set up continuous integration, and Customer Support has automated the regression suite. There certainly are a lot more tests to be written, but this task can probably be shared by other members. So now the Tester is gone, too.

Next, many of the roles can be clustered, and then combined.

The first cluster I see includes Content Creator, Customer Support, and Marketer. There’s a lot of work being done by these members, but it’s a similar user-friendly type that can fit all of these. Our worker needs to be friendly, charismatic, focused on the user experience, a good writer, extroverted, and multi-faceted. Let’s just combine these into a single Marketer role.

The next two, CSS Designer and Graphic Artis
t have some overlap. Let’s hope we can train our Artist (a color and visual expert) to write CSS. And the developers already know some CSS anyway. Besides, I consider someone who’s good at CSS also an artist. So now we simply have an Artist.

A good Sysadmin has probably been around the lab enough to have dabbled in setting up web servers, and understands a lot about hosting, so he’s already something of a Webmaster. And he’s surely enabled his users to be productive with tools, so he’s also a Toolsmith. He might even know a bit about being a DBA, and I think it would be within reach with some study. So I’ll simplify the back end roles of DBA, Toolsmith, Webmaster, and Sysadmin, singly into the latter. Anyway, some of the performance/scalability optimizations can come later. In fact, with EC2 or GAE, we have a lot less to worry about!

Now the Developer (Hacker) is who I see as the Surgeon, or Chief. She already knows how the major technologies interplay, and has had to learn a lot about about design (at least at the system level, but probably also everywhere from aesthetics to architecture). She can build things that are user-friendly. She knows best what’s involved in implementing every feature under consideration. She is the one to best see the big picture. And based all this glamorizing, I’ll conjecture that she should also be the Visionary. Of course, you’d want all of your members to have similar creative, big-picture abilities.

The Sombrero List

With all that simplification, the Hat List now looks like this:

• Developer
• Sysadmin
• Artist
• Marketer

That appears to leave us needing four team members with really big heads for five-gallon hats. For now, let’s call such members Surgeons. Can a single surgeon do all these things? What about two? How do you divide the work? Which tasks should you do in tandem, in serial, in parallel? If you’ve only got two members, should they have opposite skillsets — a developer-sysadmin and an artist-marketer? Are all of these roles part of the core? Do all the roles need to be addressed early on? Those are hard questions. There are plenty of startup examples where one or two people have done all this themselves. Most of the successful examples simply involve a couple surgeons who have figured out how to cover all the bases.

Becoming a Surgeon

Here are some thoughts on how to get Hackers to the level and focus of Surgeon:

• Diversify your skillsets. Learn some high-level languages. Try out a couple web frameworks. Be able to satisfy any development role.
• Learn about system administration. I don’t have much data to back this, but I’ve found that many of the famously successful hackers have at one time in their careers been sysadmins. E.g., ESR, Robert Morris, Tim O’Reilly, and many more. Try browsing resumes of your hacker heroes and see if any of them don’t have this qualification. Such work gives you an important practical perspectives on usage patterns, systems topologies, hardware limitations, lifecycles, automation, tool availability, user-friendliness, user-stupidity, etc.
• Make use of infrastructure services. If you’ve made use of EC2 and other Amazon/Google services, you don’t need to figure out how to scale to hundreds of app, database, file, and web servers. Know what services are out there to avoid building your own data center.
• Get the administrative work out of the way early. Once you’ve got a somewhat scalable system in place, then your Sysadmin efforts can be cut way back, and you can take off the hat.
• Outsource some of the artistry. Many sites are now available for you to shop for cheap graphics based on many criteria. And for logos, you can hire an artist inexpensively to do short-term, direct work with you. Icons are also a dime-a-dozen and freely available from various sites.
• Learn something about color. You can probably figure out CSS without too much effort, and get an artist to do some graphics for you. But you need to be careful about choosing a holistically attractive color scheme that works well across fonts, icons, boxes, panes, images, and everything else a user looks at.
• Start a blog. The detailed reasons to do this will be coming in a blog post soon. In short, blogging is marketing, talking to customers, SEO, documentation, administration, design, and a web app, all in one.

After making the Hat List, I was reminded of the traditional Chief Programmer Team, which is probably derived from Fred Brooks’ Surgical Team (hence the Surgeon designation). I hit most of the roles you see shown in that picture, but the scheme for web startups looks a bit different — the Hat List has added a few new roles specialized for web startups, and the Sombrero List has optimized away many some of them.

Attributes of Surgeons

If it’s really possible for a couple of surgeons to build a startup, we should figure out what some of the necessary surgeon characteristics are. Maybe the traits simply need to be distributed amongst the surgeons. Based on the roles above (and other assumptions), here are some qualities that would seem necessary of the special type of hacker who is fit for being a Web Startup Surgeon — one who would break many of the traditional geek stereotypes:

• gets along with others, including users and programmers
• understands users
• good communicator
• can find and recognize the right partner(s)
• somewhat extroverted (to meet/find partners)
• immersed in the real world (to see real problems worth solving)
• up-to-date on most current trends
• can generate good ideas
• can see the big picture
• good attention span, not too distracted by minutia
• can implement ideas quickly (and thus uses the right tools)
• multi-faceted
• optimistic, and not easily beaten down

Summary

• There are a lot of hats for startup founders to wear; consider the hat list when estimating the workload.
• At the core of a startup are hackers.
• It is possible to start a business with just a small number of hackers.
• It is a unique type of hacker who is fit for founding a startup.
• Diverse hacker skillsets are a must.
• Some roles can and should be inexpensively outsourced; others can be postponed. r />
• Some Sysadmin knowledge is important in a team, but much of the work can be done up-front and through services.

It’s an exciting time to be building a startup. Stay tuned to see if mine will have what it takes to succeed.

Disclaimer: This has been a thought-study on the various roles in startups, and on the hackers who play them. I don’t claim to be an authority on these matters, but I am hoping to understand the dynamics necessary to make a startup succeed.