In the relentless pursuit of perfection, I've decided to compile Chromium from source code and see how much of a performance increase, if any, would follow. The computer in question is my netbook, powered by i686 Arch Linux with an XFCE DE, but running on an Intel Atom N280 @ a measly 1.66GHz, so I'll take any performance boost I can get.
Using Arch's build system, and GCC 4.5's new 'atom' CFLAG, I began compiling the latest version and 5 hours later it was completed. I ran two benchmarks on both the pre-built i686 binary supplied by the chromium package in the Arch repositories, and my compiled version: Peacekeeper, and Sunspider. Results are as follows:
Peacekeeper Browser Benchmark (Units are 'points', more is better)
Sunspider Javascript Benchmark Results
Conclusion? From this point onwards I'm going to compile as much as I can manually, rather than using pre-built binaries, but I'm going to do it on the Phenom II x4 box. Compiling on an atom is somewhat reminiscent of the early '90s.
Showing posts with label Arch. Show all posts
Showing posts with label Arch. Show all posts
Thursday, August 5, 2010
Thursday, July 29, 2010
Reviving the Desktop
Been busy lately. The ~10 year old drive in my Phenom II box finally kicked the bucket (random chance whether BIOS would recognize it at boot, bad sectors galore, et cetera), so I bought a new one: A 1TB WD Caviar Black (WD10000LSRTL). I was a bit apprehensive shipping it from Newegg with all the horror stories of drive damage as a result of UPS' shipping procedures, so I opted for the retail packaging ($10 extra, w/o free shipping). The drive arrived, and was immediately plugged in so I could double check it's SMART attributes, as well as run badblocks on it to check for bad sectors and everything came back a-ok.
First a fresh copy of Windows 7 was installed (In a fit of rage, I formatted the NTFS partition on the old drive and turned it into an Ext4 storage partition). That went fairly without incident, save for the hours I spent finding and installing all the programs I use, updating drivers, et cetera. At this point I'm obligated to mention that whenever I install Linux, it takes me about 5 minutes to open a terminal and tell the package manager to download everything I need, and then I can go about my day until it finishes. In Windows, it takes significantly longer, especially with having to use your web browser to navigate to each program's site individually, and painstakingly sit through dozens of "Next, Next, Next, I Accept, Finish" install 'wizards'... But I digress. After all the programs were installed, as well as my full Steam game library, I let the disk defrag for a few hours. Defrag finishes, and I can get on with more important things; Namely, saving my Arch setup. I put way too much work into it with the compiz effects, my custom scripts, and everything else to just let it go to waste by reinstalling from scratch.
I used a fairly standard partition setup on the Arch box with separate /, /boot, and /home partitions. This was by far the easiest part of the day. I put both drives in the tower, and booted into whatever livecd I had lying around (I think it was the server edition of ubuntu 8.10) and mounted the partitions in the appropriate places. Then just copied everything over using the 'a' argument, which preserves the files exactly.
I.e.:
Easy, peasy, and the box now runs fine (after making the appropriate changes to Grub's menu.lst and the fstab of course). Next in line is the netbook, which is going to get a fresh Arch install in time for LinuxCon (Currently running a rather useless Chromium OS since the wireless drivers are refusing to cooperate). Originally I was going to install Gentoo on it, but compiling on an Atom is a special kind of hell, and until I have the patience and the time to do it, Arch is a much better choice. Plus I can always use the Arch build system for the packages I'll be using the most.
First a fresh copy of Windows 7 was installed (In a fit of rage, I formatted the NTFS partition on the old drive and turned it into an Ext4 storage partition). That went fairly without incident, save for the hours I spent finding and installing all the programs I use, updating drivers, et cetera. At this point I'm obligated to mention that whenever I install Linux, it takes me about 5 minutes to open a terminal and tell the package manager to download everything I need, and then I can go about my day until it finishes. In Windows, it takes significantly longer, especially with having to use your web browser to navigate to each program's site individually, and painstakingly sit through dozens of "Next, Next, Next, I Accept, Finish" install 'wizards'... But I digress. After all the programs were installed, as well as my full Steam game library, I let the disk defrag for a few hours. Defrag finishes, and I can get on with more important things; Namely, saving my Arch setup. I put way too much work into it with the compiz effects, my custom scripts, and everything else to just let it go to waste by reinstalling from scratch.
I used a fairly standard partition setup on the Arch box with separate /, /boot, and /home partitions. This was by far the easiest part of the day. I put both drives in the tower, and booted into whatever livecd I had lying around (I think it was the server edition of ubuntu 8.10) and mounted the partitions in the appropriate places. Then just copied everything over using the 'a' argument, which preserves the files exactly.
I.e.:
# mkdir /mnt/old /mnt/old/boot /mnt/old/home \
> /mnt/new /mnt/new/boot /mnt/new/home
# mount /dev/sda3 /mnt/new/boot
# mount /dev/sda5 /mnt/new/home
# mount /dev/sda4 /mnt/new/
# mount /dev/sdb3 /mnt/old/boot
# mount /dev/sdb5 /mnt/old/home
# mount /dev/sdb4 /mnt/old/
# cp -av /mnt/old/* /mnt/new/
Easy, peasy, and the box now runs fine (after making the appropriate changes to Grub's menu.lst and the fstab of course). Next in line is the netbook, which is going to get a fresh Arch install in time for LinuxCon (Currently running a rather useless Chromium OS since the wireless drivers are refusing to cooperate). Originally I was going to install Gentoo on it, but compiling on an Atom is a special kind of hell, and until I have the patience and the time to do it, Arch is a much better choice. Plus I can always use the Arch build system for the packages I'll be using the most.
Wednesday, April 7, 2010
GNU/Linux on HP Devices
I've been a fan of HP for a while now, for a consortium of reasons. They've been active in the GNU/Linux community for quite some time (and are sponsoring LinuxCon 2010, which I will be attending), and recently I've been reminded of why I gravitated towards them in the first place. When I first switched to GNU/Linux, one of the biggest issues I ran into was my old Lexmark printer being completely non-functional. In the interest of fairness I should mention that it's recently come to my attention through multiple sources that Lexmark has begun to step up to the plate on this issue, and for that I praise them.
However at the time, there was no such good-fortune, so I wound up going out and purchasing an HP Deskjet F4200. In a wonderful piece of irony, the installation procedure took about 30min on Vista (believe me, I know) and required multiple reboots. When I plugged it into my then Linux Mint 7 box, it worked out of the box... immediately. Setting it up to be shared took up a whole 30 seconds, and I was truly astonished at how it 'just worked'.
As a student, I need to print a lot, and I can not put enough emphasis on the phrase 'a lot', so a working printer is a necessity. For various reasons, the hp eventually got disconnected due to various OS reinstalls, computer rebuilds, and similar issues, and sat in my closet for a while. Today I wired it up to my Arch x86_64 box, and was again pleasantly surprised at how painless it was.
Now, nothing on Arch ever 'just works', that's almost the point, but the setup was as painless as can be expected. After installing hplip and cups (along with all dependencies of course) via pacman I plugged in the printer via usb, and ran dmesg to make sure it was recognized. It was, so I set about the actual printer configuration. After adding cups to the daemons array in my rc.conf, I stumbled across CUPS' Web-UI, which basically grabbed my hand and walked me through the entire printer setup. The phrase 'ease-of-use' instantly came to mind. You can manage printers, jobs, and pretty much anything else you can think of. I'm going to forward some ports later so I can administer it remotely over the web from wherever I am.
It's becoming more and more apparent that GNU/Linux directly equates to increased functionality.
However at the time, there was no such good-fortune, so I wound up going out and purchasing an HP Deskjet F4200. In a wonderful piece of irony, the installation procedure took about 30min on Vista (believe me, I know) and required multiple reboots. When I plugged it into my then Linux Mint 7 box, it worked out of the box... immediately. Setting it up to be shared took up a whole 30 seconds, and I was truly astonished at how it 'just worked'.
As a student, I need to print a lot, and I can not put enough emphasis on the phrase 'a lot', so a working printer is a necessity. For various reasons, the hp eventually got disconnected due to various OS reinstalls, computer rebuilds, and similar issues, and sat in my closet for a while. Today I wired it up to my Arch x86_64 box, and was again pleasantly surprised at how painless it was.
Now, nothing on Arch ever 'just works', that's almost the point, but the setup was as painless as can be expected. After installing hplip and cups (along with all dependencies of course) via pacman I plugged in the printer via usb, and ran dmesg to make sure it was recognized. It was, so I set about the actual printer configuration. After adding cups to the daemons array in my rc.conf, I stumbled across CUPS' Web-UI, which basically grabbed my hand and walked me through the entire printer setup. The phrase 'ease-of-use' instantly came to mind. You can manage printers, jobs, and pretty much anything else you can think of. I'm going to forward some ports later so I can administer it remotely over the web from wherever I am.
It's becoming more and more apparent that GNU/Linux directly equates to increased functionality.
Tuesday, March 23, 2010
Linux as a Gaming Platform
This past week, I've gotten more and more Windows-native games (as well as *nix ports) to run on my Arch x86_64 box. I originally built the computer with gaming in mind, but with Windows 7 getting worse and worse by the minute, booting into Windows just to play a game was becoming a more and more laborious task, not to mention that dirty feeling you get when you boot a computer and the Windows logo pops up.
I had originally used the latest stable version of Wine (1.0.1) obtained from Arch's User Repository, but found it was just as buggy as my previous Wine experiences. I managed to get Halo to run as mentioned in a previous post, however there were still relatively minor issues that persisted, such as the odd screen flicker, graphical problems on screen panning, and an odd box of discoloration that appeared in the top-right corner of the screen.
On a whim I decided to upgrade to the latest developmental version of wine (1.4.1), which was also in the AUR, though the PKGBUILD required some minor editing as wget was met with a 404 error trying to download the necessary files from the link given in the PKGBUILD. Luckily a fellow Archer posted a revised PKGBUILD in the comments, and it worked like a charm. Once the new Wine was up and running, I double-checked Halo to make sure the upgrade didn't brick it... Far from, it increased performance ten-fold, which is hard for me to say because it really wasn't bad at all to begin with. Suffice to say an immediate performance increase was more than noticeable.
After perusing the Wine AppDB for games I owned that were known to work well with Wine, I decided I'd give Half-Life 2 and Counter-Strike: Source a go. I encountered, and eventually fixed the same problem in both games. They would both load, but neither rendered any sound. After a quick trip through 'winecfg' I set the sound to OSS instead of ALSA, and it now works wonderfully. Not quite sure why, since ALSA is recommended explicitly over OSS for Wine, but with ALSA I can only play Halo, and with OSS all three games work. I suspect it has something to do with Steam, but I'll leave well-enough alone for now.
Now for the less-troublesome ports. There are countless remakes of the original DOS doom, most adding additional functionalities such as the ability to jump/crouch or have crosshairs, et cetera. Chocolate-Doom (AUR, detecting a trend here?) is a play on 'Vanilla Doom', as in the untouched original DOS version. It is as close to the original as possible, and preserves only original functionalities, as well as the original bugs. Using chocolate-doom I was able to play Doom 1, Doom 2, TNT, and Plutonia, just by setting the -iwad option on the command line and the path to the wad. Now I bought the id Super Pack on Steam some time ago, so I have access to the WADS on my Windows partition. Of course starting the game via a rather long terminal command isn't exactly efficient, so I wound up toying around with my ~/.bashrc file and got a rather satisfactory result.
~/.bashrc is used to create 'Aliases' for commands entered into the shell, using a very simple configuration file. Here's the portion of my ~/.bashrc pertaining to chocolate-doom:
Now instead of using the -iwad argument and specifying the full file path, I can just append a bit to the end of the command, so 'chocolate-doom1' will launch chocolate-doom using the DOOM.WAD. Much more efficient.
Getting away from the first person shooter category for a bit, Astromenace(AUR) is an extremely addictive space-scrolling 3D spaceship shooter, that is open-source. It also features RPG elements, as you buy a spaceship (from a rather large selection), and set about custom-configuring it with various hardware components such as shields, power-sources, engines, and of course weaponry. You earn money at the end of each level, which you can spend on these things as well as hull-upgrades. The difficulty level is also very customizable, you aren't presented with a simple easy/medium/hard menu, you actually get to specify various game mechanics such as damage bonuses, armor bonuses, and the like. You can also speed up/slow down the game in play using the F5-F7 keys. It is extremely addictive, and took up a few days of my life, but it is by far the best native Linux game of its kind I have ever seen.
My only hesitation about Linux originally was having to sacrifice quality gaming time to gain all of Linux's other benefits, but thanks to an increase in the availability of native/ported games for Linux, and the truly fantastic work Wine's developers are doing, I may eventually be able to rid my HDD of that ugly NTFS partition for good.
I had originally used the latest stable version of Wine (1.0.1) obtained from Arch's User Repository, but found it was just as buggy as my previous Wine experiences. I managed to get Halo to run as mentioned in a previous post, however there were still relatively minor issues that persisted, such as the odd screen flicker, graphical problems on screen panning, and an odd box of discoloration that appeared in the top-right corner of the screen.
On a whim I decided to upgrade to the latest developmental version of wine (1.4.1), which was also in the AUR, though the PKGBUILD required some minor editing as wget was met with a 404 error trying to download the necessary files from the link given in the PKGBUILD. Luckily a fellow Archer posted a revised PKGBUILD in the comments, and it worked like a charm. Once the new Wine was up and running, I double-checked Halo to make sure the upgrade didn't brick it... Far from, it increased performance ten-fold, which is hard for me to say because it really wasn't bad at all to begin with. Suffice to say an immediate performance increase was more than noticeable.
After perusing the Wine AppDB for games I owned that were known to work well with Wine, I decided I'd give Half-Life 2 and Counter-Strike: Source a go. I encountered, and eventually fixed the same problem in both games. They would both load, but neither rendered any sound. After a quick trip through 'winecfg' I set the sound to OSS instead of ALSA, and it now works wonderfully. Not quite sure why, since ALSA is recommended explicitly over OSS for Wine, but with ALSA I can only play Halo, and with OSS all three games work. I suspect it has something to do with Steam, but I'll leave well-enough alone for now.
Now for the less-troublesome ports. There are countless remakes of the original DOS doom, most adding additional functionalities such as the ability to jump/crouch or have crosshairs, et cetera. Chocolate-Doom (AUR, detecting a trend here?) is a play on 'Vanilla Doom', as in the untouched original DOS version. It is as close to the original as possible, and preserves only original functionalities, as well as the original bugs. Using chocolate-doom I was able to play Doom 1, Doom 2, TNT, and Plutonia, just by setting the -iwad option on the command line and the path to the wad. Now I bought the id Super Pack on Steam some time ago, so I have access to the WADS on my Windows partition. Of course starting the game via a rather long terminal command isn't exactly efficient, so I wound up toying around with my ~/.bashrc file and got a rather satisfactory result.
~/.bashrc is used to create 'Aliases' for commands entered into the shell, using a very simple configuration file. Here's the portion of my ~/.bashrc pertaining to chocolate-doom:
alias chocolate-doom1="chocolate-doom -iwad ~/Data/DOOM.WAD"
alias chocolate-doom2="chocolate-doom -iwad ~/Data/DOOM2.WAD"
alias chocolate-doom-plutonia="chocolate-doom -iwad ~/Data/PLUTONIA.WAD"
alias chocolate-doom-tnt="chocolate-doom -iwad ~/Data/TNT.WAD"Now instead of using the -iwad argument and specifying the full file path, I can just append a bit to the end of the command, so 'chocolate-doom1' will launch chocolate-doom using the DOOM.WAD. Much more efficient.
Getting away from the first person shooter category for a bit, Astromenace(AUR) is an extremely addictive space-scrolling 3D spaceship shooter, that is open-source. It also features RPG elements, as you buy a spaceship (from a rather large selection), and set about custom-configuring it with various hardware components such as shields, power-sources, engines, and of course weaponry. You earn money at the end of each level, which you can spend on these things as well as hull-upgrades. The difficulty level is also very customizable, you aren't presented with a simple easy/medium/hard menu, you actually get to specify various game mechanics such as damage bonuses, armor bonuses, and the like. You can also speed up/slow down the game in play using the F5-F7 keys. It is extremely addictive, and took up a few days of my life, but it is by far the best native Linux game of its kind I have ever seen.
My only hesitation about Linux originally was having to sacrifice quality gaming time to gain all of Linux's other benefits, but thanks to an increase in the availability of native/ported games for Linux, and the truly fantastic work Wine's developers are doing, I may eventually be able to rid my HDD of that ugly NTFS partition for good.
Thursday, March 4, 2010
Halo & Doom 3 on Linux
First things first, I'm officially converted; Arch is my new OS. It truly is infinitely customizable as you build it from the ground up, and I'm loving every minute of it. Anyway...
Gaming has long-been the one thing tying me to Windows. Yes there are Linux games, but let's face it: there's no Linux equivalent for some of the great Windows games out there, such as Half-Life, Halo, Call of Duty, et cetera. WINE is a possible solution, but to be honest I've never had much luck with it. I managed to get Dreamweaver running in it a few years back, but haven't touched it since then. Several days ago I figure I'd give it another go and try to get Halo CE (the first one) running.
Initially I tried it on my laptop, with an ATI Radeon 3200HD chipset, however the open-source Radeon drivers weren't getting along too well with it. The opening videos worked (I didn't need to pass the --novideo argument), but when the game loaded as far as the initial menu screen... Well I'm not sure how to describe it. Suffice it to say it was pretty recognizably a graphics issue rather than a WINE issue.
At this point I decided that rather than fiddle around with building Catalyst from AUR on a 64-bit machine, I'd try it out on my desktop, which has a more powerful Nvidia card (9600GT) anyway. That worked like a charm. The proprietary Nvidia drivers are fantastic, almost to the point where I forgive Nvidia for making them proprietary, but not quite. The game will load in a window or fullscreen (depending on your wine settings or command line arguments) and play damn-near flawlessly, which is way more than I would expect from attempting to run a DirectX game on Linux.
There is also no need for a no-cd-crack, you can use the official executable. When you run the update program it will patch the game to the latest version (1.09 I believe), which eliminates the need to actually have the cd in your drive every time you want to play the game.
While on the subject of Linux Gaming, I feel obligated to mention there is a Doom III port that will run natively on Linux available from IDsoftware's FTP Server. There's also tons of other goodies on there so make sure to give those a glance as well. I personally installed the doom3 package available in the Arch User Repository, but I have used the version available on the FTP server before on Mint, Ubuntu, and Debian successfully.
Note that you will need to copy files pack000.pk4 through pack004.pk4 from the retail version to your Doom 3's base directory (there is a directory named 'base', I am not referring to Doom 3's root directory) on the Linux box in order for the game to work (What, did you think they were giving it out for free?). If you bought Doom 3 through Valve's Steam, the needed files will be in your ...\steamapps\common\doom 3\base folder, otherwise just search for files with a .pk4 extension via your favorite method. Now as for cd keys...
I bought (yes really, no warez here) Doom 3 via steam. When you launch it the first time it displays a cd key, which I'll call key-A. It also creates two files in your Program Files (x86)\Steam\steamapps\common\doom 3\base folder called doomkey and xpkey, both of which contained different keys, which I'll call key-B and key-C. All 3 keys are 16 characters, and when the Doom 3 port launches, it prompts you for a 16+2 digit key. So now I have three separate, and equally useless keys. I sent an e-mail to Steam's customer support asking for a new key, but I doubt they'll be scrambling to help out a Linux user, so I had to rely on a little MacGyver-ing to get Doom 3 running.
For some reason, id Software chose not to disable console access while the key prompt was up. Maybe this was intentional, maybe not, but either way it allows you to circumnavigate the key-verification process which is legal provided you have actually purchased the game and corresponding cd key. So when I launch Doom 3 on Arch, I am greeted with the rather annoying prompt. Then I just ~ into the console and 'map game/delta4' (or any other map for that matter), and it will set about loading that map, thus circumnavigating the buggy cdkey authorization prompt. It's a hack, but at least I can play Doom 3 on Linux now.
NOTE: This will not help you play the game without purchasing it. You will still need to supply the .pk4 files mentioned above from the purchased version in order to play, the method I have provided is merely a means of circumnavigating a process that can prevent legitimate Doom 3 owners who have legally purchased their copy of the game from playing it on Linux, which they are entitled to do as it does not violate the terms of the EULA.
id Software is the only game company I know of that actually ports their games to Linux, and makes the ports freely available for users who have already purchased the Windows version. As such, you should actually buy id Software's games and show your support for their actions. There is currently an ID Super Pack available on steam for $70, which is an unfathomable deal considering you get over 20 games including the DOOMs, Quakes, Hexens, Heretics, Wolfensteins, and more. And no I do not benefit in any way from you doing that. I just like to support companies that support me, and by porting their fantastic games to Linux, id Software has done just that.
UPDATE: April 10th 2010
Here's how to fix the cd-key issue. Copy the doomkey and xpkey files to your ~/.doom3/base directory. Special thanks to Filip Oščádal of www.mxd.cz for the solution.
Gaming has long-been the one thing tying me to Windows. Yes there are Linux games, but let's face it: there's no Linux equivalent for some of the great Windows games out there, such as Half-Life, Halo, Call of Duty, et cetera. WINE is a possible solution, but to be honest I've never had much luck with it. I managed to get Dreamweaver running in it a few years back, but haven't touched it since then. Several days ago I figure I'd give it another go and try to get Halo CE (the first one) running.
Initially I tried it on my laptop, with an ATI Radeon 3200HD chipset, however the open-source Radeon drivers weren't getting along too well with it. The opening videos worked (I didn't need to pass the --novideo argument), but when the game loaded as far as the initial menu screen... Well I'm not sure how to describe it. Suffice it to say it was pretty recognizably a graphics issue rather than a WINE issue.
At this point I decided that rather than fiddle around with building Catalyst from AUR on a 64-bit machine, I'd try it out on my desktop, which has a more powerful Nvidia card (9600GT) anyway. That worked like a charm. The proprietary Nvidia drivers are fantastic, almost to the point where I forgive Nvidia for making them proprietary, but not quite. The game will load in a window or fullscreen (depending on your wine settings or command line arguments) and play damn-near flawlessly, which is way more than I would expect from attempting to run a DirectX game on Linux.
There is also no need for a no-cd-crack, you can use the official executable. When you run the update program it will patch the game to the latest version (1.09 I believe), which eliminates the need to actually have the cd in your drive every time you want to play the game.
While on the subject of Linux Gaming, I feel obligated to mention there is a Doom III port that will run natively on Linux available from IDsoftware's FTP Server. There's also tons of other goodies on there so make sure to give those a glance as well. I personally installed the doom3 package available in the Arch User Repository, but I have used the version available on the FTP server before on Mint, Ubuntu, and Debian successfully.
Note that you will need to copy files pack000.pk4 through pack004.pk4 from the retail version to your Doom 3's base directory (there is a directory named 'base', I am not referring to Doom 3's root directory) on the Linux box in order for the game to work (What, did you think they were giving it out for free?). If you bought Doom 3 through Valve's Steam, the needed files will be in your ...\steamapps\common\doom 3\base folder, otherwise just search for files with a .pk4 extension via your favorite method. Now as for cd keys...
I bought (yes really, no warez here) Doom 3 via steam. When you launch it the first time it displays a cd key, which I'll call key-A. It also creates two files in your Program Files (x86)\Steam\steamapps\common\doom 3\base folder called doomkey and xpkey, both of which contained different keys, which I'll call key-B and key-C. All 3 keys are 16 characters, and when the Doom 3 port launches, it prompts you for a 16+2 digit key. So now I have three separate, and equally useless keys. I sent an e-mail to Steam's customer support asking for a new key, but I doubt they'll be scrambling to help out a Linux user, so I had to rely on a little MacGyver-ing to get Doom 3 running.
For some reason, id Software chose not to disable console access while the key prompt was up. Maybe this was intentional, maybe not, but either way it allows you to circumnavigate the key-verification process which is legal provided you have actually purchased the game and corresponding cd key. So when I launch Doom 3 on Arch, I am greeted with the rather annoying prompt. Then I just ~ into the console and 'map game/delta4' (or any other map for that matter), and it will set about loading that map, thus circumnavigating the buggy cdkey authorization prompt. It's a hack, but at least I can play Doom 3 on Linux now.
NOTE: This will not help you play the game without purchasing it. You will still need to supply the .pk4 files mentioned above from the purchased version in order to play, the method I have provided is merely a means of circumnavigating a process that can prevent legitimate Doom 3 owners who have legally purchased their copy of the game from playing it on Linux, which they are entitled to do as it does not violate the terms of the EULA.
id Software is the only game company I know of that actually ports their games to Linux, and makes the ports freely available for users who have already purchased the Windows version. As such, you should actually buy id Software's games and show your support for their actions. There is currently an ID Super Pack available on steam for $70, which is an unfathomable deal considering you get over 20 games including the DOOMs, Quakes, Hexens, Heretics, Wolfensteins, and more. And no I do not benefit in any way from you doing that. I just like to support companies that support me, and by porting their fantastic games to Linux, id Software has done just that.
UPDATE: April 10th 2010
Here's how to fix the cd-key issue. Copy the doomkey and xpkey files to your ~/.doom3/base directory. Special thanks to Filip Oščádal of www.mxd.cz for the solution.
Thursday, February 11, 2010
Roll Your Own
I've become quite the avid distro hopper over the past few months, not necessarily because I was looking for something a particular distro couldn't offer, but more out of an idle curiosity. I originally started my Linux journey with Mint 6, and since then have toyed around with various *buntu's, DSL, Puppy Linux, Knoppix, Backtrack, Debian, et cetera; They all had their own strengths and weaknesses. I've gotten to a point where I wanted to build my own distro, from the ground up, without having to actually make a distro... That is to say, I wanted a minimalist install with a light footprint like Puppy, with the stability of Debian, vast customization potential, and the availability of packages and a coherent package management system on par with aptitude and the Ubuntu repositories. It seems like a tall order until you consider Arch Linux.
Arch is a VERY minimalist install, to give you an idea of how minimalist I'm talking, it doesn't even come with sudo, openssh, python, or a GUI. It is absolutely perfect for older machines and package management is a breeze, but I'll get to that in a minute. The installer is very simple and straightforward, certainly one of the most simple CLI installs I've ever done. The installer pretty much configures the network for you, then asks which packages you'd like to install, then it further fine-tunes those categories allowing you to select individual packages for installation as opposed to hundreds of them that you will probably never use in a default Ubuntu install. After the install is done you do the obligatory restart and begin to configure the system to your liking using pacman, Arch's package manager.
Now I am very, very fond of my beloved apt, but pacman won me over. In keeping with Arch's philosophy of designed simplicity, it is just that: A very powerful, yet very simple and easy to use system. My second concern when initially trying Arch was that there may not be a large number of packages available. With Mint/*buntu I was never at loss for packages, the repositories had everything. Debian's repos were good as well, though due to their snail's-pace release cycle everything is hopelessly outdated. So far I have found everything I needed through pacman, and it is all bleeding-edge in terms of software-version. Arch is a rolling distro, meaning there are no main releases just one update after another. This rolling-release model, combined with the speed at which the packages are updated provides the most cutting-edge OS I have ever seen. When I installed Firefox from the repositories, it gave me version 3.6, some distros are still working off of the 3.0 series (I'm looking at you here Debian). Even the more obscure packages are unbelievably up-to-date such as d4l, et cetera.
Pacman also made installing gnome a breeze, and I quickly got media/networking set up as well. It's a little more command-line-kung-fu than I'm used to, but for the most part it was a really good learning experience. Some might consider this a detriment, but getting hands-on with configuration files, setting up xinit manually, and specifying which modules to load when, and what daemons to start on start-up gave me a whole new insight into the undercarriage of Linux, something I could never have seen with Mint/Ubuntu which makes everything very easily usable.
In short, after less than 12 hours of using Arch, I believe this will now become my distro of choice. I've been looking for this distro for years, I just never knew the name of it.
Arch is a VERY minimalist install, to give you an idea of how minimalist I'm talking, it doesn't even come with sudo, openssh, python, or a GUI. It is absolutely perfect for older machines and package management is a breeze, but I'll get to that in a minute. The installer is very simple and straightforward, certainly one of the most simple CLI installs I've ever done. The installer pretty much configures the network for you, then asks which packages you'd like to install, then it further fine-tunes those categories allowing you to select individual packages for installation as opposed to hundreds of them that you will probably never use in a default Ubuntu install. After the install is done you do the obligatory restart and begin to configure the system to your liking using pacman, Arch's package manager.
Now I am very, very fond of my beloved apt, but pacman won me over. In keeping with Arch's philosophy of designed simplicity, it is just that: A very powerful, yet very simple and easy to use system. My second concern when initially trying Arch was that there may not be a large number of packages available. With Mint/*buntu I was never at loss for packages, the repositories had everything. Debian's repos were good as well, though due to their snail's-pace release cycle everything is hopelessly outdated. So far I have found everything I needed through pacman, and it is all bleeding-edge in terms of software-version. Arch is a rolling distro, meaning there are no main releases just one update after another. This rolling-release model, combined with the speed at which the packages are updated provides the most cutting-edge OS I have ever seen. When I installed Firefox from the repositories, it gave me version 3.6, some distros are still working off of the 3.0 series (I'm looking at you here Debian). Even the more obscure packages are unbelievably up-to-date such as d4l, et cetera.
Pacman also made installing gnome a breeze, and I quickly got media/networking set up as well. It's a little more command-line-kung-fu than I'm used to, but for the most part it was a really good learning experience. Some might consider this a detriment, but getting hands-on with configuration files, setting up xinit manually, and specifying which modules to load when, and what daemons to start on start-up gave me a whole new insight into the undercarriage of Linux, something I could never have seen with Mint/Ubuntu which makes everything very easily usable.
In short, after less than 12 hours of using Arch, I believe this will now become my distro of choice. I've been looking for this distro for years, I just never knew the name of it.
Subscribe to:
Posts (Atom)
