Sometimes, we have to suffer a little.

 

…and replace all of our music and wallpapers.

So, my first attempt at the last project that I started playing with ended very badly.  I had made a few hacks to some of the source to bsd userland to get it to run on my systemd-based Debian distro.  It would appear that one of my “tiny modifications” caused a few issues, and eventually resulted in a kernel panic and un-bootable system.

Life is like that sometimes.  It was just a single partition, and since I generally know that I’m going to break things, I keep pretty regular backups of everything that I don’t want to lose.  I decided that since I wasn’t sure which of the packages the error was located in, I’d simply start over and pay much closer attention this time.

Anyhow, I’ve managed to repair most of the damage I’d done to the system, and get it back up and working with a hybrid GNU/BSD userspace.  So far, I’ve not noticed the steadily increasing memory usage like last time, but I also used valgrind to double-check myself this time around.  (I know you’re supposed to always check for leaks, but I was in a hurry…perhaps I should remember that being in a hurry can really slow down progress.)

Still, the nature of errors and experimentation means that some days, you’re going to break things.  The old adage about breaking eggs to make omelets comes to mind.

I guess that if there was a moral to this story, it would be “Always make backups of important objects in multiple locations.”

…and feel free to link me to some good wallpapers.

errors errors errors

 

This is not going well.

All really great ideas are probably going to end up in some degree of frustration.  I can’t say that anything that I’ve ever done that was worth doing was particularly easy.  Today is no real exception, but as I’m trying to port BSD’s Userland into a BBQ spin, I am reminded of what it is that makes us better.

Failure, repeated failure, and then persistence.

All easy ideas are well-documented and probably common practice.  It’s when you start to branch out into something that is interesting that you find yourself on the fringes of technology.  In this “wilderness” you can’t expect to find much documentation, and you’re certainly not going to find any “how-to’s” that will take your hand and gently guide you through the process.  This is what it takes to help our general understanding of how things work, because more than likely, they won’t just work without some effort.

It isn’t the failing that teaches us, but rather it’s when we stick with a project that is difficult that causes us to truly grow in our abilities.  A solid amount of persistence and ability to research will trump pure talent many times.  This is what causes me so much frustration when there is solid documentation and “how-to’s” available, but someone asks to be “spoon-fed” the commands needed to perform what is essentially a simple operation.  If I can find an answer by searching the first-page of answers from a search engine, then I generally won’t answer their question at all.  It behooves us all to learn to pay close attention to things that have been written.  In the case of someone learning a Unix-based OS, that may be as simple as reading the man pages.  In the cases of working on experimental software, it’s the ability to read the output from our compilers and determine what they’re trying to tell us.  Still, in the end, it all boils down to looking for clues, doing our homework, and not giving up.

It is frustrating, and it is time consuming.  There’s no doubt about that.  Still, it takes the collapse of our feeble structures before we really learn how to build a solid foundation.  Failure is to be looked at as one more chance to get it right, and so with that being said, strive on to finally stop failing.

…and RTFM.

The Recursive Nature of Automation

 

There is no better way to learn to do something manually than to write a way to automate it.

This has at least been a huge factor in my own experiences.  It’s probably one of the biggest reasons to take up writing scripts for daily maintenance, aside from simply making your own life easier.  By taking the time to write something that will “automagically” fill a need, you will probably find that you have a much better grasp on the core concept of what your project does.

Allow me to explain how this normally works for me.  I’ll decide that I could really benefit from a small tool to perform a series of operations.  Once I sit down and think about the entire process, I realize that I need to research out all of the possible options for each tool that I’m scripting for.  I’ll spend a few hours reading man pages in detail and playing with different command line arguments to see how passing variables to each of them is best performed.  After creating a skeleton form of the project, I’ll start looking into ways to make it better, harder to break, and to use less “spaghetti code”.  By doing this, I’ll normally figure out a few ways to cut corners and make the project cleaner.  By the time that I finish the project it will probably save me some time, but I’ll have also grasped a much deeper understanding of each operation that I’m performing.

Sed is one of the tools that I picked up using this method.  As I’ve mentioned before, my bash-scripting is mediocre at best.  I took some time to try to at least learn how to perform some basic operations with bash, and during this process I realized that I wanted to change how my output looked.  I read up on sed, and determined how to use the basic search-and-replace functions.  After getting it to work how I wanted in my scripts, I found myself replacing things that I would have once used my text-editor for with sed one-liners.  If I had a file where I wanted to replace a single variable in, I’d so it with sed.  I found after some use that it was generally faster than how I had previously performed the same operations.  I started to use it more and more, and thus went back and learned more about how sed worked.  Now, it’s not uncommon for me to use sed directly from the shell to perform an inline edit to a file.

I really cannot name all of the things that I’ve learned through the process of trying to not have to learn them.  My attempts at being lazy have often proven highly productive.  For this reason alone, I suggest trying to answer simple problems with automation.  While you may never write the greatest tool for the job, you will most certainly learn something useful in the process.

The right mindset.

A few months back, I received an e-mail from what I’d call an “internet friend.”  This would be the category that I put people in when I’ll most probably never meet them face-to-face, but due to working together or simply speaking via e-mail or on mailing lists, I’ve gotten to know a good deal about them.

For the sake of discussion, Manuel “GekkoP”, sent me an email regarding something I’d written on a Linux forum about building and using cwm on Debian Sid.  It was a simple “thanks for the write up” kind of email, and due to his ventures into building a system from source code I thought he might enjoy some of the projects that I currently play with.

To make the long story short, he’s gone from using Ubuntu and Linux Mint to building LFS, and most currently, installing and configuring killx.  I saw a post that he had made today about the issues with getting a broadcom wireless driver working on killx, that he was making progress and was detailing attempts.  It was another simple “tried this, didn’t work, tried this too, also didn’t work, tried this, and….well, finally, I have it working.”  Then he detailed the step-by-step instructions so that anyone else attempting the same thing might learn from his experiences.  After a comment regarding how positive he was about this whole experience, he said something that I think is worth repeating.

“No frustration whatsoever. With killX and LFS I’m learning so much, I’m already happy. This wireless thing is just another reason to learn something new.” – gekkop

This is something that gets overlooked in many places, but I’d consider this the perfect mindset to hang on the outer-rims of Unix-like operating systems.  Building all of your software without dependency checking, and often from tarballs and git repos, can be highly frustrating.  Often it spirals into dependency chasing purgatory.  Coming at the task with a “I’m happy to be learning from this experience” attitude cannot be overstated.  Rather than looking at it as a pain, when viewed as an interesting adventure, it can be a very immersing experience that can teach you a lot about the contents of the system you’re running.

Too often, I believe that there is a level of self-imposed ignorance about the environment that we work in.  By taking the approach of constructing each piece of the system, you have a much better grasp of how it all fits together, which in turn gives you greater control over things when they don’t work out exactly as you expected.  By taking Gekko’s attitude, it’s not only personally enriching, but enjoyable.  We could all use to be “happy already” about difficulties.

Just for Fun

One of the things that we should never forget in the midst of all of the “hard work” to be done on any project, regardless of if it’s FOSS or if we’re doing it for a living, is to have fun.  It’s easy to get so wrapped up in whatever we’re working on that we forget why most of us got started doing this in the first place.  You should enjoy the work, or find something else to do with your time.  There’s nothing more depressing than a programmer who doesn’t enjoy programming.

Now, I’m not saying that there isn’t time for work.  There are times to take the work seriously, but never take yourself too seriously.  I do think that you should certainly get outside and enjoy the outdoors, but on the days where there’s nothing better to do, start a little project that serves no purpose and is just fun to work on.  These little projects come in all shapes and sizes, but the primary purpose should be that you enjoy working on it.  It doesn’t matter if anyone else will ever want to use it.  Just enjoy the work.

Some of the best ideas come from little projects like this.  While you’re enjoying something as simple as writing a little script to do something useful, you may come up with a better way to do something that you’ll need in the future.  One of the other fun games that I like to play is the “optimize for performance” game.  It’s where you take something that already works, and treat it like the guys with the little Honda Civics do…make it faster.

A while back, at the BBQ, we were going back and forth with trying to minimize RAM usage.  This got to the point that people were going way beyond what should be considered normal, but it was all in good fun.  Sub 15MB systems running xserver and a window manager is not the kind of thing that most people would bother with, but it was simply a game for those of us playing with it.  I spent days working on trying to get the most out of a kernel build, which turned out to be one of the least significant changes that was made.  Still, I learned a great deal about resource management.

A few months later, I got a project to get an old thin-client (with 64MB of onboard RAM to be used as a download station across serial) to run an OS that people without Unix experience could launch, operate, etc.  It turns out that all of the things that we had spent so much time just playing with paid off towards quickly completing a project.

Have projects that are fun, and don’t stress about them, but never fail to use those moments to remind yourself why you started whatever it is that you do.  Sometimes, you’ll rekindle a fire that has long since began to smolder.

Feature Creep: The Silent Killer

 

I have to credit a friend for the quote, but I have been revisited by this subject on numerous occasions as I’m what you might call a “minimalist designer” and I wish to bring it up again.

Don’t let feature creep overcome simplicity. I see this all the time — “How can I make <simple tool> do everything <readily available complex tool> can do?” Or the feature requests end up turning <elegant simple tool> into just another <bloated slow complex tool>. In my mind, you’re building a bicycle, not an SUV. Bicycles are the most efficient transportation system ever invented. – Pidsley

I really cannot express how accurate this is, and it’s one of the most destructive things for a FOSS project.  The Unix philosophy is “Do one thing well.”  Too often, once we accomplish this goal of doing one thing well, we start trying to do other things well from the same platform.  After some time, rather than doing one thing well, we are doing lots of things as well as possible.  This slows down our entire implementation for the original goal because now we’re loading up all of the tools to do all of the things that we want to support, which leaves us now doing the thing that we set out to do a little bit less efficiently than it started out.  Generally, though, it doesn’t stop there.  We add “just one more feature” or “just one little change” until now we’re getting errors and issues from all of the little additions that can totally break our project for some users.  For those people, we’re not even doing the one thing at all anymore.

This grows and spreads over time.  Everybody wants that “Just one more thing” added in until there are hundreds of things stacking up, and more things going on is equivalent to more potential sources of bugs.  More bugs require more fixes, and more fixes for things that were never the original goal is more pointless upkeep.

When designing a project, and I don’t care if it’s just a simple bash script or a huge compiled C program, always look carefully at what your goal is.  If something doesn’t help you achieve that goal, then trash it.  It’s often hard to toss out an idea that seems cool, but if it doesn’t add to the project directly, then it needs to go.  By doing this early on, you’re saving yourself a huge amount of headache over the life of any project.

The Joy of Creativity

 

The term “teamwork” is thrown around in lots of circles, especially in management seminars and business meetings.  The truth of the matter is somewhat different to how it is often presented, though.  For there to be true teamwork, every person must be able to bring something to the group that would otherwise be missing.  If the group (or ‘team’) is properly constructed, there won’t be any need to promote teamwork, as it will simply be present.  All members should be able to realize the value of each person involved without being prompted to work together.

The FOSS world breeds teams more through people who have similar goals better than anything that could be constructed by a business meeting.  Simply put, if a project thrives, it is normally through the combined effort of people who simply wish to see the project succeed.  There may be a “leader”, but they are generally in that position because of their contributions (such as Linus Torvalds), or through simply having the entire group’s goals in mind.  If the team works, then the leader is there because the other members respect them enough to take instruction or advice from them.

The best teams are composed of creative individuals with a common goal.  It’s not all about technical skill.  While you obviously need to have the skill to implement an idea, often times a simple idea can grow into something worthwhile because it’s creative enough to survive the natural selection of open source software.  I have lucked into meeting some truly creative people who work together through what is probably considered ‘chaotic-experimentation’ by onlookers.  I can’t say that I’ve ever heard someone simply say “That is not a good idea.”  It is generally tested, or tried, or written…and the end result is either trashed or it grows into a useful end product.

The creativity of the people involved often take what is a simple idea and they say something like, “…but wouldn’t it be better if…” and from there the idea takes on a life of its own.  While there may be plenty of technical knowledge, that simple phrase can often lead to ideas and new concepts that would have never existed otherwise.  Creativity is often overlooked, but it is essential to every good idea that has ever existed.  Good ideas tend to survive.

…now with 90% more breakage.

 

I clearly remember the day that I lost anything resembling good judgement, and began the long trek towards learning to love control.  I was a new Linux user, happily playing with Ubuntu and Debian Stable.  I started looking at commits to the kernel from organizations, and I ran across one called “Gentoo Linux.”  Now, I’d installed Linux before, and so I burned off a CD and booted it up.  I was met with a cold, heartless prompt.  I assumed that this had to have been a mistake.  I looked up “Install Gentoo” and was met with a few funny images, and a handbook about how to correctly install the OS.  It took me about 2 days in all.  I didn’t set up use-flags correctly, I failed to build a working kernel, and I spent hours looking at cfdisk man pages on my working Debian box to try and figure out what I had done wrong (boot flags are important.)

I eventually ended up with a working system.  I used it for a little while, but that install changed the way that I personally viewed the system itself.  If all of that was going on under the other systems, then how much more was there to learn?  I started poking around in files, looking things up online.  I did the LFS build.  I started pulling tarballs instead of using package managers, and built things from source while changing the source to see how I could change the way the programs worked.  This often ended in broken packages, non-booting systems, etc.  I never did let it discourage me.  I chose early on to read before I asked questions, and by doing so, learned a great deal about how things worked.

Since then, I’ve been on a perpetual quest for bigger and better ways to break things.  Not that breaking is the goal, but it’s almost assured to happen if you try to do things that are aggressive enough to a system.  I have learned and am still learning more and more about how a *nix system works, and I have no intention of stopping.

Experimenting has led me to a far greater understanding of the environment that I work in, while also leading to a kind of “enlightenment” about how all of the systems are essentially the same underneath it all.  I have come to love the “let’s see what this does” mentality, and tend to find far more enjoyment with systems that are experimental.  I can’t speak for everyone, but I’ve learned more through breaking things than any amount of stability could have taught me.  There’s something about having to fix your own mistakes that helps the whole system make more sense, and the lessons are more easily remembered.

All I can suggest is that if you take this route, only ask for help if you are totally certain that you’ve read everything on the subject that is out there.  Having questions is of no value if someone else answers them for you.