Just this morning, Linus Torvalds released the Linux kernel 3.1 into the mainline branch. This was merely a few days after Linux kernel 3.0 hit the Internet. Apparently the new version numbering scheme is doing its job well. Still this release has been relatively silent and without much fanfare, as neither Linus or Kernel.org have published any announcements or posted on their mailing list yet.

Changes

The current lack of publicity in this version does not mean that there is nothing nice in this new release. There have been a plethora of new improvements whipped up in this batch of the kernel. Here are a few highlights:

1. Open source graphics driver improvements
• This is an epic win for GNU/Linux! Notable GPU fixes and speedups include the buggy Ivy Bridge, Intel GMA 500, Nouveau, and ATI drivers, among others.
2. Filesystem usage
• Various filesystem readers/writers have been polished: ext3, Btrfs, FAT, XFS, NFS, ReiserFS, HFS+, and SQUASHFS.
3. Dynamic Writeback Throttling
•  ”Writeback” is when programs copy data from RAM and write it to your hard disk. To keep busy programs from overwriting their own RAM data, “context throttling” comes in handy. Throttling is telling a process or two to not create any new data until the current data has been copied to disk, kind of like how a city crossing guard tells you when its safe to cross, and when it is not.
• Unfortunately, the older writeback was not very mindful of the filesystem dutifully tidying up your hard disk, and would sometimes interfere with its cleanup work and corrupt its structure. The new writeback system can now intelligently check when the filesystem is busy and adjust its throttling habits accordingly, keeping your hard disk clean and boosting performance.
4. OpenRISC support
• Yay! OpenRISC is a project by the OpenCores organization aimed at creating a modern computing CPU platform based upon the classic RISC, fully licensed under the GNU LGPL License, and now Linux can boot on it. I’m not surprised, as Linux can be made to run on basically anything.
5. Wiimote Controller support
• Finally, the Wii remote works! The driver has been around for a while, but it has now been added to the official kernel repositories.

More Information

To see a full description of the new Linux kernel 3.1 fixes and improvements, I’d recommend you visit this page at KernelNewbies.org. It explains the rather cryptic changelog in a well-organized, plain English wiki page. Now, all that is left is to wait for Linux kernel version 3.2, which (unsurprisingly, given the new warp-speed version numbering scheme) is currently in the works…

Introduction

Welcome, fellow hackers! This time, I will review a very nice hacking tool that I really find interesting: honeyd (pronounced “honey-dee” or “honey-daemon”). It is a powerful virtual honeypot tool written by Niels Provos and released as open source under the GNU General Public License, as part of the Honeynet project. It runs on GNU/Linux distributions and *BSD’s.

To anyone who doesn’t know, a honeypot is a public or private computer that is intentionally left insecure, unpatched, without an antivirus or firewall, etc. which actually encourages malicious hackers to attack it. This is a perfect tool for catching potential black-hat network intruders or spammers and monitoring their behavior, or even giving hackers a huge playground to explore andput their networking skills to the test without disrupting others.

If you have the cash, you can even set up multiple honeypots in your home or workplace, which act as convincing “decoy machines” that can help protect your legitimate computers from crackers. Networks like these are called honeynets. Now, let’s back up a bit. Note the keywords in the first sentence: If you have the cash. Setting up a honeynet as a hobbyist can be hard, space-wise and money-wise, but honeyd solves both of these issues completely with a quite revolutionary technology: virtual honeypots.

HoneyD is a Virtual Honeypot

Your typical, run-of-the-mill honeypots are made up of physical computers interlinked together, and finally, to the internet, should you wish. While it is foolproof, works effectively, and makes logging and forensics simple, it can be very costly to set up for a hobbyist, as it requires them to buy many large servers,  baby them, and run up the home electric bill. Remember that in most cases, more = better. There is also the additional risk of a malware infection leaking out of a honeypot onto a legitimate computer and destroying it.

The best way to solve this problem virtual honeypot, which is basically a daemon running on one or a several computers that generates virtual honeypot computers and places them on the network. Instead of having to buy and set up multiple physical computers, you now only need one computer which can generate as many virtual honeypots as you wish.

honeyd is an open source application that tries to achieve that goal. Each and every honeypot is defined as a config file that you load and deploy. You can define virtually any aspect of these honeypots with a simple text editor, such as its operating system, ports, and more. Through the “honeyd-common” package, found in most Debian/*buntu repositories, honeyd can emulate a whole slew of port services, such as HTTP, FTP, telnet, rsh, SMTP, and plenty more.

When would a virtual honeypot be used in the real world? Here is an example scenario: a small company has three servers full of important data that it needs to protect vigilantly, as it cannot risk a malicious hacker break-in. All of the servers have an IDS (intrusion detection system) installed. If one of the servers is running honeyd, it will appear to any attackers that there are hundreds of computers on the network, when really there are only three.

The attacker will have to do much more research and perhaps think twice before hacking, for if they make one mistake and attack a honeypot, then the IDS will have them caught red-handed. Their IP address and attack methods will be logged, their port listings and network traffic recorded, and the timeframes noted. Remember that all of the attack’s details can be accessed and observed in real-time from the three legitimate servers running honeyd. It truly is the perfect trap, don’t you think?

Feature List

• Manipulates TCP/IP packets to create the illusion that there is a host on the network.
• At the time of this writing, honeyd supports up to 65,536 hosts at once.
• Convincingly emulates a plethora of port services.
• Can impersonate up to a thousand different operating systems.
• User can define unique virtual hosts using simple config files.
• Lets you catch spammers and network intruders, as well as observe the their behaviors.
• Safe and isolated from the true host computer(s).

Getting HoneyD

Installing on Debian, Ubuntu & friends from Repos

Firstly, open up your terminal. Then update your package listings as shown below:

user@linuxbox~$ sudo apt-get update

Next, install honeyd and its dependencies using apt-get.

user@linuxbox~$ sudo apt-get install honeyd honeyd-common

The package “honeyd” contains the actual honeyd service, and “honeyd-common” contains various scripts and extra components that will emulate all of the port services on the virtual honeypots, such as SSH, HTTP, rsh, etc.

Anything else

To install on Gentoo, Slackware, Arch Linux, etc. you should consult your respective wikis or documentation on how to install programs. Hopefully, honeyd and honeyd-common are included in your distro’s repositories. If not, compilation from source code is always an option. As for *BSD systems, I have no idea whether honeyd is included in the FreeBSD or OpenBSD ports or not, but you can always check.

Building a honeypot

To make a virtual honeypot in honeyd, you create a *.conf file using gedit, Kate, nano, vim etc. and load it. Below is an example configuation file that generates a Windows 2000 host and places it on the LAN.

# Make a new Win2K SP2 host called "windows".
create windows
set windows personality "Microsoft Windows 2000 SP2"
set windows default tcp action reset
set windows default udp action block
set windows default icmp action block
add windows tcp port 25 open
add windows tcp port 110 open

# Make this server run POP3 and SMTP email services.
add windows tcp port 25 "sh /usr/share/honeyd/scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport"
add windows tcp port 110 "sh /usr/share/honeyd/scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport"

# Finally, create the host and assign its IP.
bind 192.168.1.150 windows

To load the honeypot(s) into honeyd and deploy them, simply enter the appropriate commands.

user@linuxbox~$ honeyd -d -f honeypots.conf

The -d parameter forces honeyd not to run in the background as a daemon and dumps any and all output information into the terminal. If you wish to log the data  into a file, simply use the -l option.

user@linuxbox~$ honeyd -d -f honeypots.conf -l log.out

A simple nmap scan here shows that the honeypot indeed works…

Starting Nmap 5.00 ( http://nmap.org ) at 2011-08-26 21:48 IDT
Interesting ports on 192.168.1.150:
PORT     STATE  SERVICE
25/tcp   open   smtp
110/tcp  open   pop3

That’s about it! You now have a simple Windows 2000 honeypot on your LAN! All what you need now is to wait for attacks to start pouring in…

More Honeypot-related Tools

HoneyD was developed under the initiative of the influential Honeynet project. Founded in 1999 under the directive of Lance Spitzner, the Honeynet project has been researching honeypot technology heavily and pushing the frontier of its usage. Honeynet research members have also collaborated with other network security experts (such as Niels Provos) and even GSoC (Google Summer of Code) participants to produce high quality, free/open source honeypot tools, including Glastopf (honeypot that emulates many web vulnerabilities to help observe hackers in the wild), Honeywall CD (a bootable CD-ROM that provides tools to help automate the process of setting up, connecting, and deploying honeypots) , and Honeystick (a bootable USB flash drive with a DSL-based, Honeywall-automated honeypot). To see a full list of all Honeynet-published tools, visit their Projects page.

Other Resources

Besides checking out the Honeynet Project’s wesite and honeyd’s website, I would like to give a quick shout-out to two amazing blog posts that helped me get familiar with honeyd that I recommend you check out: Deploying Honeypots with HoneyD by Ulisses Costa, and honeyd tutorial part 1, getting started by Travis Altman. Read them. Now.

I would also like to recommend you read the book Virtual Honeypots: From Botnet Tracking to Intrusion Detection, written by the honeyd author himself, Niels Provos, with the help of Thorsten Holz. It is should teach you everything you need to know about virtual honeypots, and should help you greatly in understanding the internals of honeyd as well.

Overall Impressions

To tell you the truth, I never quite knew about nor cared for honeypots before. I came across the concept by surfing Wikipedia (yes, I do that; see my About page), and looked up the Honeynet project and read a bit about them. After checking out what tools had emerged from their research, my perspectives changed. Out of all of the tools, I took a liking to honeyd the most because it seems like an extremely promising tool that can be easily obtained on most GNU/Linux distributions. I love that it not only gives white-hats an edge against the black-hats, but that it also promotes research by providing an insecure playground of virtual hosts to let a beginning hacker train with nmap, ettercap, etc. and let their imagination run wild.

HoneyD Pros:

1. Very little maintenance need to keep the honeypots up and running.
2. Wide range of entirely unique hosts to choose from.
3. Virtual hosts are entirely isolated from the real host (no risk of malware leakage).

HoneyD Cons:

1. Hope attackers do not write a tool to isolate the fake IP addresses and defeat honeyd’s trickery.
2. Legality in the U.S. State of Michigan is questionable, as seen in honeyd’s old website and in the link on Michigan’s “Super DMCA” law.

I believe that honeyd is simply a great all-around honeypot program. It can impersonate any operating system or port service you throw at it, it has plenty of good features, and is easily obtainable in the Debian/*buntu repos. It is a very powerful, customizable, and cost-effective alternative to physical, hardware-based honeypots, which makes it perfect for budding hackers, hobbyists, or really paranoid users. I will gladly rate honeyd:

« 98% »

Awesome!

Visit SFML's project page

Introduction

Hello everybody and welcome! I decided that I will reviewing a very, very useful cross-platform library that I have been using often lately called SFML, which stands for “Simple and Fast Media Library”. For those who don’t know, SFML is a game library, which is a collection of C++ functions that can aid you in making games, and is similar in spirit to another more mature game library called SDL (“Simple DirectMedia Layer”).

Let’s say that you wish to create a sidescroller like Mario, for example. Instead of researching deeply through the net and going into the nitty-gritty of setting up the window and coding unimportant (but complex) components, you could simply bundle SFML together with your project’s code. SFML can take care of playing the sound effects or video cutscenes, displaying textures and loading game maps, interacting with OpenGL for 3D graphics, etc. while you focus on actually writing the game.

NOTE: SFML is not a game engine! It is a bit more low-level than that, and it does not include any drag-and-drop editors or media creation tools. It’s purely source code, and you are expected to already know how to program in order to use it. However, it  is powerful enough that you could actually help you create a game engine of your own.

In this review, I will go over the features of the library and explain what it can do. I will also supply an example C++ snippet that demonstrates how to initialize SFML, along with step-by-step explanations of what the program does and how it works. I will finalize by outlining SFML’s pros and cons, summarizing my overall impressions, and telling you whether it is worth being in your toolbox as a programmer.

Tech Specs

As mentioned in the introduction, SFML is targeted to be a replacement for another cross-platform game library called SDL (Simple DirectMedia Layer). SDL is much older than SFML, and was written and released under the GNU LGPL in 1998 by Sam Lantinga, former lead software engineer at Blizzard Entertainment working on World of Warcraft. SDL powers many games and still works wonderfully up to this day, but it has its faults. It is sometimes known to be quite cryptic at points, and since it is written in C, it does not utilize the wonderful object-oriented paradigm that is so revered by programmers these days.

This is where SFML comes in. SFML was written in C++ by Laurent Gomila in 2007, licensed under the zlib license. Unlike SDL, SFML is a modular and fully object-oriented library. Its source code and SDK are very neat in orderly, in comparison with SDL. In terms of speed and performance, SFML either meets SDL, and sometimes exceeds it in some 2D and 3D tests, as verified here and here. The library has many components, but each “module”, so to speak, is split up into several simple headers which you must include into your “main.cpp”:

1. Audio.hpp – Audio and sound effects subsystem
• Contains all of the functions that you need in order to play music or sound effects from a file or from a buffer.
2. Graphics.hpp – 2D graphics rendering
• Allows you to render 2D sprites, overlay text, display color, draw shapes, etc.
3. Network.hpp – Server/client networking subsystem
• Provides network LAN multiplayer functionality for your game.
4. System.hpp – Miscellaneous low-level functionality
• Lets you create threads, lock down game data so that other programs know they are in use, generate random numbers, etc.
5. Window.hpp – Window management
• This is the main SFML class. You can open a new window, set its options, and create an interface to OpenGL if you wish.

SFML is fully cross-platform and works under multiple compilers. It runs on Windows (MSVC/MinGW-GCC), Mac (Xcode LLVM/GCC), Linux (GCC, YACC, etc), and FreeBSD (CLANG, GCC, etc). One of the best things about SFML is that if you prefer programming in another language other than C++, you don’t have to worry. There are additional bindings to C, Microsoft .NET languages (C#/VB/etc), Python, D, and Ruby, which are also available for download at the SFML website here.

Example Program

To help any interested beginners out there understand how to use the library, I will walk you through with this example C++ source file, called “main.cpp”:

#include <SFML/Window.hpp>

int main(int argc, char *argv[])
{
    // Create the SFML window.
    sf::WindowSettings Settings;
    sf::Window App(sf::VideoMode(1024, 768, 32), "Test Game", sf::Style::Close, Settings);

    // Enter the game loop.
    while (App.IsOpened())
    {
        // Process mouse & keyboard input.
        sf::Event Event;

        while (App.GetEvent(Event))
        {
            // Clicking close button on window : exit
            if (Event.Type == sf::Event::Closed)
                    App.Close();

            // Hitting Escape key : exit
            if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
                    App.Close();
        }
            // Run your game logic stuff here...

            // Finally, display rendered frame on screen.
            App.Display();
    }

    // When everything is done, quit the program.
    return 0;
}

Assuming that the appropriate SFML development headers have been downloaded from the SFML website and placed into a directory that your compiler can find, this program should compile fine on Windows, Mac, GNU/Linux, and FreeBSD. If all goes well, when the program is executed, you should see a command-line window (this is purely for displaying SFML’s notifications or error messages, should it have to) along with another empty, black window titled “Test Game” which should look something like this:

The result of the SFML test program

To explain how this program works under the hood, I will explain what the source code does, step by step:

1. Starts the program.
2. Creates a new “sf:Window” that is titled “Test Game”:
• Window Name: App
• Resolution: 1024 x 768
• Color Depth: 32-bit
• Window Style: Minimize (-) and Close (x) buttons enabled only.
3. Runs the game loop:
• Checks input events. If the user clicks “X” on the window or hits the ESC key, quit the loop.
• Runs the game logic. Since we didn’t write that yet in this example, you will only see an empty, black window when the program is run.
• The current frame is ready to render! The current frame is displayed in the window by executing  “App.Display()“.
• Repeats the previous steps forever as long as the SFML window is open.
4. When the program exits the loop, it uses “return 0;” to tell SFML to shut down and quit the game.

Overall Impressions

I had used SDL plenty of times before and had a long, loving relationship with it, but that’s not to say I never had any bumps in the road. I take pride in keeping my code self-contained; that is, I like to make sure may code has absolutely no external third-party dependencies. If I ever need an external library, I just bundle the headers and source files with my program, add custom search directories in my Code::Blocks project, and make sure that they retain their appropriate licenses. This makes compiling my code easier for others and myself; no extra packages to download, no configuration files to tweak, etc. Just download, open the project, hit “Build”, and it’s done. But I had enormous difficulty making the SDL headers play nice on different machines or platforms, and that was my biggest (and only) gripe about it.

When I found out about SFML, I was only mildly interested, as I didn’t know what my expectations were. But I can tell you now that if I had any high expectations at all, SFML would have blown them all away. It was exactly what I wanted! A cross-platform, cross-compiler game library, similar in spirit to SDL, with very high performance, clear and concise documentation, a modular design, slim size, easy code management, and best of all, it was easy to embed into my program and make its source code play nice on any platform I pleased! It was a matter of downloading SFML, copying it to my project’s internal “include” directory, pointing Code::Blocks to it, and voilà! Everything ran smoothly and initialization worked flawlessly on my computer right out of the box. Also, I never really liked C++ very much and I have always preferred to use C, C#, and shell scripting as my primary language. But I have realized that SFML was the one library that successfully gave me the courage to tackle C++. Not only that, it actually made learning the language fun and interesting! No more boring “hello world” programs for me!

The only complaint that I have is a very minor one. Although SFML is easy to set up and use, it has the disadvantage of having less popularity and a smaller community than SDL. Because of this obscurity, it supports less platforms and has less tutorials and workshops than SDL. Once again, this is an extremely minor gripe, as SFML’s online documentation, wiki, and forum posts are absolutely stunning help resources, and should most certainly be enough to remedy any issues you may have.

SFML Pros:

1. Easy to download, include, and initialize (easier than SDL, in my opinion), and runs fast.
2. Fully takes advantage of object-oriented programming (great for most modern languages) & supports OpenGL 3.x (SDL doesn’t).
3. Similarities to SDL make it easier to migrate your project from SDL.
4. Source code has no dependencies (yay!)
5. Absolutely awesome online documentation and wiki.

SFML Cons:

1. Lack of popularity makes finding third-party resources and tutorials harder, and supports less platforms than SDL.
2. Modularity and object-oriented design is typically unnecessary if you are programming in C.
3. Image loading is rather basic in comparison to SDL_image.

Overall, I find SFML to be a wonderful game library! It runs great, has lots of features, is easier to integrate into your program than SDL in my opinion, and is a pleasure to use. I am honored to give it a score of:

« 96% »

Awesome!

Fed up with Ubuntu?

Introduction

I’ve seen many people get frustrated with Ubuntu’s new direction in terms of its user experience, its recently worsening speediness, and its mixed-bag Unity interface. I’m one of them! When I first tried Ubuntu back in 2008 (version 8.04 LTS), it ran like a dream on my shoddy 1.6GHz, 1GB DDR2 RAM, Windows Vista laptop. I loved GNU/Linux’s ease of use, efficiency, and its immunity to common viruses, worms, and rootkits. With each and every release, Ubuntu seemed to get better and better, with a slicker interface, better driver support, bugfixes, and a more diverse package repository every time. I was in total computing bliss!

When version 10.04 LTS was released, that’s when the s*** hit the fan. I initially liked its “new-and-improved” GNOME theme and I was enthusiastic about the new Linux kernel release. Later on, though, problems began to crop up for me. Wireless networking was suddenly unreliable and inefficient, the 2D/3D acceleration graphics drivers were worsening (Intel GMA 965 on-board chipset), the interface was getting increasingly sluggish, boot times were gradually lengthening, and despite my constant config file tweaking and fine tuning, my frail laptop eventually sank into a dependency hell. I tried out Kubuntu instead for a while, but I didn’t like KDE, so I wiped it soon after. I tried Xubuntu, and while it helped speed up my machine a little, I couldn’t seem to get used to Xfce and its little quirks either, so that distro was out the window as well.

Ubuntu version 10.10, however, was a far better performer on my laptop than 10.04, and with advanced command-line knowledge and some *NIX administration experience under my belt, I managed to keep Ubuntu chugging along for a long, long time on my weak laptop hardware. Those were reasonably happier days, and my programming experience flourished. By then, I now had a fully custom-built desktop with a Core 2 Duo, 2GB DDR2 RAM, which could run Ubuntu a lot better than my laptop, so I migrated my data there. Still, I longed for an alternative distro to Ubuntu that would run efficiently on my old laptop.

Much later, while online, I caught wind of the highly controversial user interface changes made in GNOME 3.0,  as well as the not-very-well-received Unity interface being dubbed “the GNOME 3.0 replacement”. Spurred by the bad experiences with 10.04 and the recent news about GNOME, I felt that there wasn’t much of a future left for me in Ubuntu. Determined, I began searching for viable alternatives. These were the noteworthy distros that I found:

1. Linux Mint
2. Debian
3. Ubuntu Minimal Install
4. Knoppix (haven’t tried it personally, so can’t review)
5. Arch Linux

I haven’t used Knoppix, but I’ve been aware of it for a long time. It’s an extremely lightweight Debian-based Linux distribution, packed with hundreds of apps, which can be downloaded here. Try it out if you can! Anyway, the above entries are sorted with the most viable *buntu-alternatives at the top, and the least viable at the bottom. I will give a thorough review of each option in this list that I have personally installed and tested myself, along with the pros and cons of each, including hyperlinks to their respective project pages for download.

If Ubuntu runs fine on your computer, use Ubuntu! If it doesn’t work well for you, use an alternative. As they say, “if it ain’t broken, don’t fix it”!

Linux Mint 11 "Katya" (GNOME)

Linux Mint

The most viable lightweight alternative to Ubuntu that still retains the point-and-click, drag-and-drop mentality would have to be Linux Mint. It is almost identical to Ubuntu, from the initial setup dialog to installing programs and updates. Not very technical and performs admirably for a direct Ubuntu derivative. For your user environment, you can choose between GNOME, KDE, Xfce, and LXDE. Also available is a convenient Debian-based Linux Mint ISO for even better performance (see more about Debian in the next review below).

Mint Pros:

1. Startup and overall performance is very good!
2. Based on the latest version of Ubuntu (or Kubuntu), but is much lighter on resources.
3. 100% binary compatible with *buntu & Debian packages, plus full support for PPA repositories!
4. The easiest distro for a Ubuntu/GNOME user to adjust to, next to Debian.

Mint Cons:

1. Installs non-free codecs and software (Flash & MP3) by default, which may be legally problematic in some countries.
2. Like Ubuntu, the system chugs along fine for a while, but eventually suffers a severe performance hit (though it is much, much less drastic).

Get it from Linux Mint’s home page.

Debian

Debian 6 "Squeeze"

If you are coming Ubuntu arena, and you want something different that will give you a great performance boost, but retain the awesome “aptitude” and “apt-get” package manager, then why not install pure Debian? Debian is the GNU/Linux distribution that Ubuntu itself is based upon, and has been around since 1993. It’s faster, more stable, it isn’t overly simplified like Ubuntu (don’t worry, you can install GNOME/KDE/Xfce/Fluxbox/etc. on top easily), and it’s simply less bloated. It is an extremely mature distribution with a simply enormous community of users and developers. When installing, you can pick which available GUI you want to use, or even not select one at all and use your computer through the command-line.

Debian Pros:

1. Hugely faster startup and performance (by a lot!).
2. Extremely stable and crashes less (has more stable drivers).
3. Is almost entirely binary-compatible with Ubuntu .deb files.
4. A good, stable, no-frills distribution that is easy to adjust to, if coming from *buntu.

Debian Cons:

1. Since it has more stable packages, you probably will have less than up-to-date software.
2. Its root account is enabled by default! (You can disable it by logging into a normal user account and typing “sudo passwd -l root”)
3. PPA repositories are a *buntu-only thing.

Get it from Debian’s home page.

Ubuntu Minimal Install

Ubuntu 10.10 Minimal

If you still feel at home in Ubuntu and you don’t want to switch to another distro, just stick with Ubuntu, but install a mini ISO instead! It gives you the bare minimum packages to get you started and when you log in, you are (like Debian/Arch) greeted with a command prompt. You can then install GNOME/KDE/Xfce/Fluxbox/etc. and customize your packages from the ground up. Note that while this still doesn’t completely solve the performance problems or any driver issues that you may have, it still can improve your desktop experience considerably! Like Arch Linux (see more on Arch in the next review below), don’t bother if you aren’t comfortable using the command-line.

Ubuntu Mini Pros:

1. Decent startup times at initial install (still a little bit slow, when compared with other distros, and will only get slower as you add more drivers or daemons).
2. Still uses “aptitude” and you still have the massive Ubuntu repos!

Ubuntu Mini Cons:

1. Still vulnerable to the Ubuntu-characteristic “slowdown” that degrades its performance over time (though much less drastic).
2. As with any Ubuntu install, it has lots of metapackages, forcing you to install bundles of independent software that you don’t quite need and you end up using only that one, specific program that you wanted while the other crap sits there, taking up unneeded disk space…

Get it from Ubuntu’s Minimal ISO page.

Arch Linux

Arch Linux

My second-favorite preference is Arch Linux, as it’s kind of like Gentoo Linux (which I like), but it’s easier to use and set up and has stunning documentation! It’s known to be very fast and extremely configurable. When you install it and edit your config files, you are greeted by a command prompt. Then, you can use the package manager (appropriately named “pacman”) to update your repository listings and install packages, similar to aptitude in Ubuntu/Debian. Very fast, but don’t bother if you aren’t comfortable with a command-line.

If you need help learning how to use pacman, but you are familiar with aptitude, here’s a basic aptitude-to-pacman equivalents list:

APTITUDE                 |   PACMAN
---------------------------------------------------------
aptitude                     pacman
aptitude search [target]     pacman -Ss [target]
apt-get autoremove           pacman -Ru
apt-get clean                pacman -Sc
apt-get install [package]    pacman -S [package]
apt-get remove [package]     pacman -R [package]
apt-get update               pacman -Sy
apt-get upgrade              pacman -Syu

Arch Pros:

1. Blazing fast startup (better than most Debian installs)!
2. Humongous repositories (“core” enabled by default, when you enable the “extra” and “community” repos, the package choice is massive)!
3. Is a “rolling-release” distro; no need to upgrade to new releases every year. You can install Arch and keep it up-to-date forever.
4. Easier than Gentoo and (more or less) just as fast.
5. Absolutely stunning documentation and wiki! Easy to understand and simple steps. It’s like you are reading a well-written, very easy to follow book on Linux at the library! It’s the friggin’ ultimate Linux bible!

Arch Cons:

1. Much more technical and “hackery” than Debian or Ubuntu. (well, duh!) You may need to edit some config files if your hardware is non-standard.
2. Very different directory structure than Debian-based distros!
3. Like Debian, its root account is also enabled by default, but can be disabled the same way.
4. A little picky about wireless drivers (on my machine).
5. GET USED TO PACMAN!

Get it from Arch’s home page.

Conclusion

After all of my experiences with GNU/Linux, I must say that I still love Ubuntu, as it was my first Linux distribution! It had opened my eyes to the Free Software Movement and the Open Source Movement, as well as *NIX and systems programming in general. However, I feel that I have sort of outgrown it, like how a little boy outgrows a faithful bike that he loved. I now use Linux Mint on my desktop computer, dualbooting with Windows 7, and I have Arch and Debian installations in Oracle VirtualBox. All the while, my aging laptop still runs Ubuntu 10.10 faithfully! In the end, I hope this will help you choose a good Ubuntu alternative distro!