Drcouzelis's Arch Linux Blog

Being a good computer user, I make backups. Even so, I’ve been kind of unhappy with my backup process, so I decided to try something a little different.

I’ve been using rsnapshot to backup personal files and settings that I think are important. But I’ve always had this uneasy feeling that something wasn’t quite right with my backups.

There are two important rules regarding backups:

1. Have one.
2. Be able to restore it.

That second one is where my concern was. The things I would backup include which Arch Linux packages I use. In theory, it shouldn’t be too hard to setup Arch Linux from a backup to the way I have it now. But I also host a website that uses mysql, and I think I’m backing it up correctly, but, you know, I’ve never tried restoring it, so I’m not really sure. Also, rsnapshot takes way longer to run that I thought it would.

So, I started using dd. My system is a good candidate for it because my primary hard drive and my backup are the exact same model. I was also excited to use it because I got to download and boot into the Arch Linux live CD again, which I haven’t seen in years. Good memories.

So, here’s how I do my new backups:

1. Boot into the Arch Linux live CD.
2. Take my external backup drive out of the fireproof box and plug it in.
3. Confirm the names of the two hard drives.
4. Use dd.
5. Wait.
6. Unplug the drive and put it away.
7. Relax.

My dd command:

dd if=/dev/INTERNALDRIVEsda of=/dev/EXTERNALDRIVEsdb bs=1M conv=noerror

The benefits of using dd to make an exact copy of my entire hard drive are:

• I can’t accidentally forget to backup something that I need to setup my computer. My data, my settings, my operating system, and my website all get backed up. Even my Haiku installation gets backed up!
• If my hard drive fails, I can swap it with my backup drive and be up and running again in a matter of minutes.
• I’ll have a copy of the lastest Arch Linux installation media lying around, just in case.

Possible drawbacks include:

• I only have one “copy” of my files, as opposed to one from from last week, one from the week before, and so on. I only ever had one copy, even when I used rsnapshot. I keep a backup mainly in case of a hardware failure, so one copy is all I need.
• I can’t automate it. That’s ok, because I don’t keep my backup hard drive connected to my computer anyway. Maybe someday when I’m rich and famous I’ll be able to afford an external hard drive and an internal backup hard drive.
• It’s easier to destroy my computer setup by making a mistake with dd than it is by making a mistake using rsnapshot. Well, be careful!

This has also been my first experience using the dd command. Such power. But, as with any power, it’s important to remember the old saying:

With great power comes great awesomeness.

Arch Linux turns ten this year.

It doesn’t feel like I’ve been using it for very long. Then I check my pacman log and see the first entry: “installed filesystem”, 2009-11-04.

It’s been almost two and a half years since I’ve installed a Linux distribution! I used to love installing new distros, even if it was just an upgrade. Now I haven’t done that in a long time.

And you know what? I don’t miss it one bit. I love always having the latest software and no need to reinstall anything.

I keep Haiku installed on a separate partition. I’d love to use that as my primary operating system, but I’m afraid it’s not very practical at the moment. Until then, I plan on using and loving Arch Linux for a long time.

Window placement is kind of a big deal to me. Out of all the different styles and algorithms for window placement, my favorite for the longest time has been “Random”. Random window placement had a better chance of putting an application window where I wanted it on the screen than any other option – until now.

But first, a bit about window placement:

Microsoft Windows tries to place a window where it was the last time you had it open. I thought this was a good idea at first, until I remembered I use many windows from the same application. Anyway, after that, I don’t know where Windows tries to put new windows.

GNOME 2, FVWM, and many other user interfaces I’ve tried seem to have a thing for the upper left corner of the screen. I hate the upper left corner of the screen! It’s the last place I want a new window is in the upper left corner of the screen, especially when I have a big empty desktop.

I’ve tried a few tiling window managers, but they just weren’t my thing. Oh, well.

Finally, I started using Openbox. I was sad at first, because everything looked great about Openbox except for one thing: the only options for window placement are “Smart” and “Under mouse”. I’m too lazy for “Under mouse” and when a window manager says “Smart” placement I usually don’t find it to be too smart.

I decided to look at the source code for the “Smart” placement, and I was pleasantly surprised! It goes through these logical steps:

1. If a window knows where it wants to go (like Pidgin instant messenger does) then just put it there.
2. If there are no windows open, then put it at the center of the screen.
3. If there are windows open, then find a space where it will fit and center it in that space.
4. Finally, if it can’t fit anywhere without overlapping another window, place in on the screen randomly.

I love it!

I finally gave in and started using the Openbox window manager.

I didn’t want to use it for the longest time for two primary reasons:

1. It didn’t have any like a task bar, and I couldn’t find any stand alone task bars that I liked.
2. It’s too popular. So many Arch Linux users use Openbox!

I had an epiphany recently, and that was that I really don’t want anything like a task bar. I use window shading a lot. When I want a window to be hidden, I simply iconify it to nowhere and bring it up again using the root menu. It’s great!

I have conky setup to give my all the heads-up information I need, and a slick theme to make everything look nice.

Openbox supports full compliance with things like full screen applications and changing the screen resolution, which my previous window manager lacked.

I’m happy with Openbox so far, and look forward to using it for a long time.

• There should be clear communication about what the problem actually is.

Don’t solve the wrong problem.

• Solve the problem to meet specifications.
• Perform test driven design.

If you are unsure of your goals then you’ll never reach them.

• Use debugging tools.

You can find and fix the problem much faster using debugging tools instead of print commands or, worse, randomly changing things.

• Don’t repeat yourself.
• Create a personal collection of software tools and libraries that I wrote.

Learn from the work you do, and keep it with you in order to use it in the future.

• Write modules with a single responsibility.

If a module tries to do more than one thing, splitting it up will probably make the design easier.

• Write against interfaces, not classes.

Even if it seems simple and silly to write a simple interface for a single class to use, chances are, in a big project, having it written against an interface will very likely make your life easier in the future.

• Learn how the entire software system works.

If you can be that person on the project that knows what every part of the system does, you’ll be invaluable.

Here are some general pointers I try to remember when writing code. Even though following these guidelines always helps me, I do a poor job at following them. So, I’m hoping that  I’ll follow them better if I write them down here.

Work from the top down

This can be a nice way to ease into writing . Think about what you want the code to do and write a function name that represents it. (for example, play_game(…)) Then, think about what you want that function to do, and write function names that represent it. (initialize_game(…), update_game(…), draw_game(…)) Keep doing this until you have super simple functions that need to be filled in to make everything work.

Design good data structures

This applies to both object oriented design and not. Spend time designing good data structures and objects. Design good relationships between them. I’m not going to describe what makes a data structure good or bad here, but for some reason I can always tell the bad ones when I begin trying to use them in functions.

Design good simple functions

Similarly to designing good data structures, design good simple functions. For example, if you have a function name that has the word “and” in it, it may be time to reconsider the design of your code.

Break the problem down into smaller parts

This is a more general way of summarizing all of the points above. Writing a new application may be a daunting task. Break the problem down into smaller problems, until the problems that remain are simple and easy to solve.

If you don’t have the data you need, move the functionality up to a higher level function

This one’s a little tricky to describe. If you’re working in a function and you seem to need to keep sending more and more data structures as parameters, stop and reconsider if that function is really the right place for all of that logic to happen. Consider moving it up into the function that calls that function instead. This principle seems to help me pretty often.

Code for the specific application you’re working on

This is one of the most important points in this list! It’s easy to think it’s a good idea to make your data structures and functions work well for other programs or “future projects”. You know, making your code generic and “reusable”. Well, stop it. The future projects you’re thinking of probably won’t ever get written, and you’ll waste time making your code generic instead of just making it work well for the program you’re working on.

I plan on learning how to use the Pyglet media library and the Cocos2d game library, along with gaining more experience with Python, by creating a simple video game. Here’s my next idea:

Spinbot is a platform puzzle game. It involves simple puzzles related to changes in perspective and changes in gravity.

Each puzzle takes place in a room. There are platforms scattered throughout the room. The player can move left and right and jump. Any time the player comes in contact with a surface, the screen rotates so that the surface they touches is the new “ground”. Gravity also changes to match the new rotation.

The goal is to guide the player, Spinbot, through the room in order to find and touch a glowing power sphere. Obstacles include surfaces with oil that the player can’t grab on to, and moving platforms.

I hate C++. I will never ever use it by choice to write software again.

C has been my favorite programming language for many years, but I never really did anything with C++.

I’ve decided it’s incredibly wordy, error messages from the STL are really hard to read, there are so many things I need to do myself instead of having the compiler take care of them for me, there are many ways to do everything, it takes an incredibly long amount of time to compile my small application, and the standard library is so small and painful to work with. I could go on and on.

I don’t hate pointers, I don’t need automatic garbage collection, but holy moley it feels like everything that’s been implemented in C++ has been done in the worse way possible.

Why is this language so popular? It has almost an infinite number of features, which can be nice I suppose. If you want a fast, compiled, object oriented capable language then there traditionally aren’t too many options. Some others are Ada and Objective-C.

I may have made a mistake. Before working on my first C++ application, I wrote my first Python application. I think Python spoiled me.

I wish there was a language that was like Python but compiled like C. I’m sure many programmers want the same thing. Maybe one exists, but if it does I don’t think it’s very popular yet.

For now, I think I’m going to start using Python a lot more. Throughout my life as a programmer, I’ve written software in assembly and C. I’ve learned a lot about good programming principles and managing all of the details in the code myself.

But I’m getting of tired of it. Writing code in a language like C++ can be kind of fun, but I never get anywhere. Alternatively, with Python I can have fun and actually finish an application.

In what ways have I contributed to the free and open source software community? And what can you do to help? Here are some thoughts.

I love helping FOSS projects, but it can be difficult to decide what to do.

Keep it simple

Choose a project where you need to learn one thing at a time.

There are languages (examples: Python, C), libraries (examples: GTK, Qt), and programming paradigms. (examples: GUI programming, threaded programming) When you begin working on a project, you will probably need to learn something new. Try to learn only one thing at a time. For example, if you have to learn gstreamer and GTK (two libraries) at the same time then you might become frustrated. Or, if you have to C++ and Qt (a language and a library) at the same time then you might become frustrated.

So, try to learn one thing at a time.

Working with other FOSS developers

I love working online with FOSS developers. When I get to talk to the lead developer of a project, it feels like I’m talking to a celebrity.

Of course, you should join the mailing list and bug tracker for the project you want to work on. I don’t usually introduce myself. Instead, I just start helping, and people will know me soon.

My FOSS experience

Here are some examples from my FOSS experience.

Many years ago, I wanted to write a new FOSS application. I couldn’t think of any new applications to make, so I decided to make a video game. There are never too many video games.

I learned many things by making video games:

Languages: C, Objective-C, Java, Assembly, Ada

Libraries: Allegro, SDL, Java SWING

I’ve submitted many bug reports to many different projects, such as wxWidgets, Allegro, Udiskie, and Haiku. I really like submitting bug reports and working with the developers to fix the problem. It’s easy to do and I get to use better software.

I maintain some AUR packages. (very easy, but it helps FOSS)

I helped write the documentation for some software from the Arch Linux community, such as Packer and Udiskie. I’ve contributed to the Arch Linux wiki.

Recently, my wife and I wanted a new application for budgetting. I decided to write one. I used Python and wxWidgets. It works pretty well. My next goal is to convert it to C++ and wxWidgets, and then make a version for Haiku using C++ and the Haiku API.

Interesting things

You should definitely work on something that you think is interesting. To me, that’s Arch Linux, Haiku, bug reports, and documentation. Try to find things that are interesting to you!

Lastly, don’t make your goal too big and don’t try to do too much. There are many many people helping in FOSS. If everyone does a little bit, then we can make something great.

It was announced on the GNOME developer list that GNOME 3 won’t have minimize or maximize buttons:

http://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html

That’s a huge change. My initial reaction was “Whaaa?”, but then I started thinking about how I use my window manager (currently FluxBox). I almost never use the minimize and maximize buttons, and certainly wouldn’t miss them if they were gone.

The mailing list message talks about helping users learn a new work flow. This reminded me of when I started using Haiku. Haiku has a powerful file manager called Tracker. Tracker is a spatial file manager, which means every folder opens in its own window. The first thing I wanted to do was change it to a navigational file manager. So, I went to the Haiku documentation.

I found the information I was looking for, which included this comment:

Before you switch Tracker to Single Window Navigation mode, because that may feel more familiar to you, we recommend giving the menu based browsing a try first, as that may actually work much faster for you after getting used to.

So, I decided to continue trying Tracker as a spatial file manager, and now I really like it.

Now, in regards to GNOME 3, it’s hard for me to express how I feel about it. Let’s see if I can summarize it:

• There are too many things that move around the screen. Things go from the window view, which shows almost nothing but the window you’re actively using, to the activities view, which shows everything at once. And I mean everything, every workspace, every window, every running application, every recently used document, directories, and search. And those things were all designed to move and live and grow as you use your computer, which means things are shifting around a lot.
• It forces a new workflow on users that doesn’t appear to be better than another workflow. This may not be a bad thing. Haiku kind of enforces a new workflow, but I quickly learned to like it. With GNOME 3, I have no idea how the new workflow is supposed to benefit me. Which leads to:
• How will they train people? When GNOME 3 is released, the new design may be great for many many people, but they need to learn how to use it before they can benefit from it.
• It requires accelerated graphics.

GNOME 3 hasn’t been released yet, and my opinion will probably change. I hope the GNOME developers know what they’re doing, because I sure don’t know what they’re doing.